Le 04/11/2019 à 15:44, Mike FABIAN a écrit :
But on Fedora (and probably most other Linux systems), it seems like pt is used for Portuguese Portuguese.
Is there an “offical” policy?
What shall we do?
Hello mike,
For now, there is no issue in Weblate. The translator explicitly selected pt_pt instead of pt. I can rename the language code for your project if you wish.
For the rest of the Linux ecosystem, I have no idea, but I feel like the Linux ecosystem handles locales in a very basic way. In the web ecosystem, there is a list of priority, but I'm unsure this really exists in Linux.
A Brazilian Portuguese user should have in his list of priority, something like: pt_br before pt before pt_pt
This really is the same issue as the zh-tw, zh-cn change to zh-hant, zh-hans. Here is another side effect: https://github.com/mozilla/addons-server/issues/5829
The source of this Mozilla issue is https://code.djangoproject.com/ticket/18419 which was a change closed in May 2013!
I'm unsure we should force Weblate to have a specific behavior, but rather let upstream projects to decide what language codes they wish to use, depending on their own deployment constraints.
Jean-Baptiste
Jean-Baptiste jean-baptiste@holcroft.fr さんはかきました:
Le 04/11/2019 à 15:44, Mike FABIAN a écrit :
But on Fedora (and probably most other Linux systems), it seems like pt is used for Portuguese Portuguese.
Is there an “offical” policy?
What shall we do?
Hello mike,
For now, there is no issue in Weblate. The translator explicitly selected pt_pt instead of pt. I can rename the language code for your project if you wish.
Yes, I think that is better.
I’ll take the current push request as it is, having it in pt_PT is better than nothing, but I think it is better if it moves to pt.
For the rest of the Linux ecosystem, I have no idea, but I feel like the Linux ecosystem handles locales in a very basic way. In the web ecosystem, there is a list of priority, but I'm unsure this really exists in Linux.
A Brazilian Portuguese user should have in his list of priority, something like: pt_br before pt before pt_pt
Currently it is like that on Linux.
If a user runs in pt_BR.UTF-8 locale, translations are first searched in
/usr/share/locale/pt_BR/LC_MESSAGES/ibus-typing-booster.mo
if that doesn’t exist
/usr/share/locale/pt/LC_MESSAGES/ibus-typing-booster.mo
is tried as a fallback.
If a user runs in pt_PT.UTF-8 locale, translations are searched first in
/usr/share/locale/pt_PT/LC_MESSAGES/ibus-typing-booster.mo
and if that doesn’t exist again
/usr/share/locale/pt/LC_MESSAGES/ibus-typing-booster.mo
is tried as a fallback.
As the two variants of Portuguese are apparently quite close to each other, it makes sense to have one of them as a fallback for the other. So it makes sense to put the translations for one of them into
/usr/share/locale/pt/LC_MESSAGES/ibus-typing-booster.mo
and the other variant into the more specific directory. Apparently on Linux it has been the custom to put Portuguese as spoken in Portugal into /usr/share/locale/pt.
CLDR does it the other way round, as you can see here:
https://github.com/unicode-org/cldr/blob/master/common/main/pt_BR.xml
the pt_BR.xml is practically empty, so it just falls back to
https://github.com/unicode-org/cldr/blob/master/common/main/pt.xml
which contains the Brazilian Portuguese translations.
And
https://github.com/unicode-org/cldr/blob/master/common/main/pt_PT.xml
is not empty but contains the translations where Portuguese in Portugal is different from Portuguese in Brazil.
This really is the same issue as the zh-tw, zh-cn change to zh-hant, zh-hans. Here is another side effect: https://github.com/mozilla/addons-server/issues/5829
I fill the Chinese case is somewhat different as simplified Chinese is not a good fallback for traditional Chinese and traditional Chinese is not a good fallback for simplified Chinese.
I don’t think we would gain anything to move to zh-Hant and zh-Hans on Linux and cause a lot of trouble with locales and backward compatibility.
The source of this Mozilla issue is https://code.djangoproject.com/ticket/18419 which was a change closed in May 2013!
I'm unsure we should force Weblate to have a specific behavior, but rather let upstream projects to decide what language codes they wish to use, depending on their own deployment constraints.
Yes. I think it is OK as it is now that Weblate offers the choice and the projects/translators can decide which codes to use.
Btw, in ibus-typing-booster I started a zh_TW translation and translated just one single string, just to make the zh_TW translation exist already in ibus-typing-booster. If somebody starts translating ibus-typing-booster into traditional Chinese, he will see that zh_TW exists already and use that and there is danger to accidentally choose zh_Hant.