8000 [Intl] Provide more locale translations by ro0NL · Pull Request #35517 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Intl] Provide more locale translations #35517

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 30, 2020
Merged

[Intl] Provide more locale translations #35517

merged 1 commit into from
Jan 30, 2020

Conversation

ro0NL
Copy link
Contributor
@ro0NL ro0NL commented Jan 29, 2020
Q A
Branch? 4.3
Bug fix? yes
New feature? no
Deprecations? no
Tickets Fix #35513 (comment)
License MIT
Doc PR symfony/symfony-docs#...

This enables more locale translations, available upstream, which are valid. In this case esp. locales with a numeric region code, eg. es_419

This should return true in Locales::exists(), which is currently not the case. By providing the translation, it implicitly exists as well.

cc @jkobus

Comment on lines 97 to +98
"en": "Engels",
"en_001": "Engels (Wêreld)",
Copy link
Contributor Author
@ro0NL ro0NL Jan 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from a user perspective, this creates 2 entries in the Locale form type. It may be confusing 🤔 but i tend to believe it should be filtered manually, if desired.

ie. en (no region) vs en_001 (world region) could be considered equivalent, whereas the first may assume 001 for a region implicitly ... but that's outside our domain

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so the user may select en_001 to explicitly provide a region and opt out from some specific region (hence "world"), whereas in case of "en" the app may assume any region.

Fine as-is for me 👍

@fabpot
Copy link
Member
fabpot commented Jan 30, 2020

Merging into 4.4 as 4.3 ends of maintenance is tomorrow and this PR might be a slight behavior change.

@fabpot fabpot changed the base branch from 4.3 to 4.4 January 30, 2020 15:14
@fabpot
Copy link
Member
fabpot commented Jan 30, 2020

Thank you @ro0NL.

fabpot added a commit that referenced this pull request Jan 30, 2020
This PR was submitted for the 4.3 branch but it was merged into the 4.4 branch instead (closes #35517).

Discussion
----------

[Intl] Provide more locale translations

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #35513 (comment)
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

This enables more locale translations, available upstream, which are valid. In this case esp. locales with a numeric region code, eg. `es_419`

This should return true in `Locales::exists()`, which is currently not the case. By providing the translation, it implicitly exists as well.

cc @jkobus

Commits
-------

27cc120 [Intl] Provide more locale translations
@fabpot fabpot merged commit 27cc120 into symfony:4.4 Jan 30, 2020
9C57
@ro0NL ro0NL deleted the intl branch January 30, 2020 15:18
This was referenced Jan 31, 2020
@jkobus
Copy link
Contributor
jkobus commented Jan 31, 2020

Thanks @ro0NL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0