Jean-Baptiste <jean-baptiste@xxxxxxxxxxx> さんはかきました: > 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. -- Mike FABIAN <mfabian@xxxxxxxxxx> 睡眠不足はいい仕事の敵だ。 _______________________________________________ i18n mailing list -- i18n@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to i18n-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/i18n@xxxxxxxxxxxxxxxxxxxxxxx
