In the LANGUAGE environment variable, but not in the LANG environment variable, ‘ll_CC’ combinations can be abbreviated as ‘ll’ to denote the language’s main dialect. For example, ‘de’ is equivalent to ‘de_DE’ (German as spoken in Germany), and ‘pt’ to ‘pt_PT’ (Portuguese as spoken in Portugal) in this context.
Take a string
fmt.Println(gotext.Get("en_US"))
and translate it in the .po file:
# pt_PT.po
msgid "en_US"
msgstr "pt_PT"
# pt_BR.po
msgid "en_US"
msgstr "pt_BR"
According to the excerpt above, pt should be expanded to pt_PT, when plain pt is not available. However, it is not:
Is this a bug, an improvement, a proposal or something else? Describe it.
This is a bug/deviation from the gettext behavior. When language is specified, but translation file is named language_country, msgid is returned instead of the main dialect.
What's the expected behaviour, the current behaviour and the steps to reproduce it?
The main dialect version should be returned instead of the fallback string.
Comments
The library does not deal with environment variables. However, I believe this should be the default behavior; the developers using this library can handle differences between LANG and LANGUAGE themselves; supporting expansion for every language string should not break anyone, and can be handled easily in the application itself.
Ok, so I checked and gettext does the same as gotext. Fallback pt_PT -> pt does work as expected; the documentation made me think that pt -> pt_PT would work as well.
gettext documentation 17.2.2 states that:
In the LANGUAGE environment variable, but not in the LANG environment variable, ‘ll_CC’ combinations can be abbreviated as ‘ll’ to denote the language’s main dialect. For example, ‘de’ is equivalent to ‘de_DE’ (German as spoken in Germany), and ‘pt’ to ‘pt_PT’ (Portuguese as spoken in Portugal) in this context.
Take a string
and translate it in the .po file:
According to the excerpt above,
pt
should be expanded topt_PT
, when plainpt
is not available. However, it is not:Is this a bug, an improvement, a proposal or something else? Describe it.
This is a bug/deviation from the gettext behavior. When language is specified, but translation file is named language_country,
msgid
is returned instead of the main dialect.What's the expected behaviour, the current behaviour and the steps to reproduce it?
The main dialect version should be returned instead of the fallback string.
Comments
The library does not deal with environment variables. However, I believe this should be the default behavior; the developers using this library can handle differences between
LANG
andLANGUAGE
themselves; supporting expansion for every language string should not break anyone, and can be handled easily in the application itself.