Re: should we allow pt_pt in weblate? was Re: [Fedocal] Reminder meeting : L10N

Jean-Baptiste <[email protected]> さんはかきました:

> 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 <[email protected]>
睡眠不足はいい仕事の敵だ。
_______________________________________________
trans mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]