You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some locale names use ll_CC.@variant instead of ll_CC. The @variant can denote any kind of characteristics that is not already implied by the language ll and the country CC. It can denote a particular monetary unit. For example, on glibc systems, de_DE@euro denotes the locale that uses the Euro currency, in contrast to the older locale de_DE which implies the use of the currency before 2002. It can also denote a dialect of the language, or the script used to write text (for example, ‘sr_RS@latin’ uses the Latin script, whereas ‘sr_RS’ uses the Cyrillic script to write Serbian), or the orthography rules, or similar.
The same functionality is supported by other translation tooling e.g. weblate, which seems to at least suggest it's not completely unheard of.
At work, we're using gettext in our application and have recently had to add more fine-grained locales to our product, e.g. en_GB@education, in order to specialise for a particular markets but we've hit an impasse with ruby-gettext via its use of the locale library because it effectively throws away any information after the secondary code.
Is there any reason why this can't be supported? Would you consider a patch for this?
The text was updated successfully, but these errors were encountered:
According to the gettext docs, a locale may include additional information after an
@
symbol:The same functionality is supported by other translation tooling e.g. weblate, which seems to at least suggest it's not completely unheard of.
At work, we're using
gettext
in our application and have recently had to add more fine-grained locales to our product, e.g.en_GB@education
, in order to specialise for a particular markets but we've hit an impasse withruby-gettext
via its use of thelocale
library because it effectively throws away any information after the secondary code.Is there any reason why this can't be supported? Would you consider a patch for this?
The text was updated successfully, but these errors were encountered: