Jean-Baptiste <jean-baptiste(a)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.
--
Mike FABIAN <mfabian(a)redhat.com>
睡眠不足はいい仕事の敵だ。