-
Notifications
You must be signed in to change notification settings - Fork 451
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
Do not discard locale modifiers (@variants) #946
Comments
Hi, thanks for chiming in! One issue I see here is that Babel does currently not have support for custom locales (#454), and For the time being, to allow this (very valid!) use, I think
If you're willing to give a PR a shot, please do! |
Thanks for your kind reply, @akx. I already started poking at the code, and sure thing: it's not as trivial as it might have seemed at the start. Lol. Getting I don't think that loading a locale with a modifier should fail per se. In general, if e.g. I need this functionality for PO files, where The real challenge will be to maintain API compatibility / provide proper integration into
|
Locale modifiers ("@Variants") are described in the GNU gettext documentation like this: > The ‘@variant’ can denote any kind of characteristics that is not > already implied by the language ll and the country CC. […] It can also > denote a dialect of the language, … Wherein Babel previously would discard these, this patch stores the modifier information in the `Locale` objects, handling string representation accordingly. Not implemented is the lookup of a meaningful description of modifiers, but instead — for now — an identity mapping is provided. Resolves: python-babel#946 Signed-off-by: martin f. krafft <madduck@madduck.net>
Locale modifiers ("@Variants") are described in the GNU gettext documentation like this: > The ‘@variant’ can denote any kind of characteristics that is not > already implied by the language ll and the country CC. […] It can also > denote a dialect of the language, … Wherein Babel previously would discard these, this patch stores the modifier information in the `Locale` objects, handling string representation accordingly. Not implemented is the lookup of a meaningful description of modifiers, but instead — for now — an identity mapping is provided. Resolves: python-babel#946 Signed-off-by: martin f. krafft <madduck@madduck.net>
Locale modifiers ("@Variants") are described in the GNU gettext documentation like this: > The ‘@variant’ can denote any kind of characteristics that is not > already implied by the language ll and the country CC. […] It can also > denote a dialect of the language, … Wherein Babel previously would discard these, this patch stores the modifier information in the `Locale` objects, handling string representation accordingly. Not implemented is the lookup of a meaningful description of modifiers, but instead — for now — an identity mapping is provided. Resolves: python-babel#946 Signed-off-by: martin f. krafft <madduck@madduck.net>
Locale modifiers ("@Variants") are described in the GNU gettext documentation like this: > The ‘@variant’ can denote any kind of characteristics that is not > already implied by the language ll and the country CC. […] It can also > denote a dialect of the language, … Wherein Babel previously would discard these, this patch stores the modifier information in the `Locale` objects, handling string representation accordingly. Not implemented is the lookup of a meaningful description of modifiers, but instead — for now — an identity mapping is provided. Resolves: python-babel#946 Signed-off-by: martin f. krafft <madduck@madduck.net>
Locale modifiers ("@Variants") are described in the GNU gettext documentation like this: > The ‘@variant’ can denote any kind of characteristics that is not > already implied by the language ll and the country CC. […] It can also > denote a dialect of the language, … Wherein Babel previously would discard these, this patch stores the modifier information in the `Locale` objects, handling string representation accordingly. Not implemented is the lookup of a meaningful description of modifiers, but instead — for now — an identity mapping is provided. Resolves: python-babel#946 Signed-off-by: martin f. krafft <madduck@madduck.net>
Locale modifiers ("@Variants") are described in the GNU gettext documentation like this: > The ‘@variant’ can denote any kind of characteristics that is not > already implied by the language ll and the country CC. […] It can also > denote a dialect of the language, … Wherein Babel previously would discard these, this patch stores the modifier information in the `Locale` objects, handling string representation accordingly. Resolves: #946 Signed-off-by: martin f. krafft <madduck@madduck.net> Co-authored-by: Aarni Koskela <akx@iki.fi>
Locale modifiers ("@variants") are described in the GNU gettext documentation like this:
This seems useful for various purposes, and yet, the Babel source code completely discards the modifiers, saying "we don't care about them":
This is especially problematic, because "private use subtags", as defined by RFC4646 are not properly handled by Babel, and neither are the private use region subtags 'AA', 'ZZ', and in the ranges 'QM'-'QZ' and 'XA'-'XZ', which basically leaves an implementer no choice to extend translations beyond the strict scope of the provided
locale-data
.The RFC makes it clear that private use subtags and private region subtags aren't primary choice mechanisms, and should only be used where no other approach suffices.
Python's own
gettext
handles locale modifiers just like you'd expect, and while it seems that theLocale
class would need to be modified to represent modifiers, there appears no reason why "we should not care" about these.Please do not discard them. I am happy to have a shot at providing a PR if replies here are encouraging.
The text was updated successfully, but these errors were encountered: