On Mon, Oct 24, 2022 at 11:31 PM Jonathan Corbet <corbet@xxxxxxx> wrote:
Thanks for having me.
Resending without the screwy address that my mailer decided to put in
for Alex, sorry for the noise.
I am neutral about the change, and prefer less churn for code.
But if we have to, zh_hant/hans is better then CN and TW to comfort
other regions, like zh_SG, zh_HK etc.
Thanks
Alex
Jonathan Corbet <corbet@xxxxxxx> writes:
[Adding some of the other folks interested in translations]
Matthew Wilcox <willy@xxxxxxxxxxxxx> writes:
I think we're better off following BCP 47:I want to go hide somewhere :)
https://www.rfc-editor.org/info/bcp47 rather than the libc locale format.
That will imply renaming it_IT to simply "it", ja_JP to "ja" and
ko_KR to "ko". The two Chinese translations we have might be called
"zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs
Simplified script. If they really are region based, then they'd be
zh-CN and zh-TW.
I think you're right to conflate all dialects of Spanish together, just
as we do all dialects of English.
Jon, this feels like policy you should be setting. Are you on board
with this, or do you want to retain the mandatory geography tag that
we've been using up to now?
I'd kind of prefer to avoid renaming the existing translations, as that
is sure to create a certain amount of short-term pain. But I guess we
could do that if the benefit somehow seems worth it.
Of course, if we're thrashing things, we could also just call them
"Italian" (or "Italiano"), "Chinese", and so on. I don't *think*
there's a need for the names to be machine-readable. We should stick
with ASCII for these names just to help those of us who can't type in
other scripts.
If asked to set a policy today, my kneejerk reaction would be to leave
things as they are just to avoid a bunch of churn. But I don't have a
strong opinion on how this naming should actually be done, as long as we
can pick something and be happy with it thereafter. What do the
translation maintainers think?
Thanks,
jon