From previous confusion experienced, only one language code format to be used. By default Zanata uses xx-XX (same with Transifex), it would be simple to use default unless any particular reason to use other format? Current xx Recommended xx-XX For example, Japanese Current ja Recommended ja-JP
I think we should be using the de facto gettext/glibc standard, as most of our software currently do (GNOME, freedesktop.org, Fedora-specific apps, many others). It's almost exclusively xx, and xx_YY only in some specific cases where it makes sense (namely bn_IN, en_GB, pt_BR, sr@latin, zh_CN, zh_TW). It would probably make it easier to use for software developers, and translators as well.
(In reply to Piotr Drąg from comment #1) > I think we should be using the de facto gettext/glibc standard, as most of > our software currently do (GNOME, freedesktop.org, Fedora-specific apps, > many others). It's almost exclusively xx, and xx_YY only in some specific > cases where it makes sense (namely bn_IN, en_GB, pt_BR, sr@latin, zh_CN, > zh_TW). It would probably make it easier to use for software developers, and > translators as well. I respectfully disagree. The way glibc is doing language code tags is way out of date and should not be encouraged. We should push BCP 47 whenever possible, which would hopefully push glibc into action as well. Btw, BCP 47 also means _not_ mandating the country subtag (or any other subtags) like ja-JP unless absolutely necessary to make the geographical, or any other distinctions between locales(like en-GB vs en-US, sr-Cyrl vs sr-Latn, etc.).
(In reply to Piotr Drąg from comment #1) > I think we should be using the de facto gettext/glibc standard, as most of > our software currently do (GNOME, freedesktop.org, Fedora-specific apps, > many others). It's almost exclusively xx, and xx_YY only in some specific > cases where it makes sense (namely bn_IN, en_GB, pt_BR, sr@latin, zh_CN, > zh_TW). It would probably make it easier to use for software developers, and > translators as well. +1 In addition, this is the same with Transifex. So I think it will be easier to handle during the migration to Zanata.
(In reply to Miloš Komarčević from comment #2) > I respectfully disagree. The way glibc is doing language code tags is way > out of date and should not be encouraged. We should push BCP 47 whenever > possible, which would hopefully push glibc into action as well. > Well, you should start with GNU probably, then convince GNOME, KDE, and pretty much the rest of the FOSS world. Doing it only from one translation platform side is not going to be helpful, and will only unnecessarily complicate things.
Just to add my two cents to this discussion, Zanata can handle both the xx and xx-XX locale codes; it's more a matter of configuration than anything else. I would recommend to have that decision ready before setting up the real production instance though.
Zanata can(In reply to Piotr Drąg from comment #4) > (In reply to Miloš Komarčević from comment #2) > > I respectfully disagree. The way glibc is doing language code tags is way > > out of date and should not be encouraged. We should push BCP 47 whenever > > possible, which would hopefully push glibc into action as well. > > > > Well, you should start with GNU probably, then convince GNOME, KDE, and > pretty much the rest of the FOSS world. Doing it only from one translation > platform side is not going to be helpful, and will only unnecessarily > complicate things. Talking about de facto, have a look in "locale -a". It is in format of like ja_JP (except eo, which do not have any country associate with it). As Carlos said, in Zanata, can handle xx and/or xx-YY team, if you set client locale mapping"<locale map-from="ja">ja-JP</locale>, you can output ja.po for ja-JP locale team.
Zanata can even handle the modifier "@format", so you can use en_US@piglatin inkscape-0.48.4 has it.
(In reply to Ding-Yi Chen from comment #6) > Talking about de facto, have a look in "locale -a". > It is in format of like ja_JP (except eo, which do not have any country > associate with it). > > As Carlos said, in Zanata, can handle xx and/or xx-YY team, if you set > client locale mapping"<locale map-from="ja">ja-JP</locale>, you can output > ja.po for ja-JP locale team. It's quite unrelated to locales. I'm talking about translation filenames, which are almost universally like this: https://git.gnome.org/browse/nautilus/tree/po If Zanata can handle ja.po under ja-JP team, then it's ok with me, even if I see this as unnecessary. But it can also lead to problems: for example Russian is spoken in many countries (and is an official language in few), why should the team be under ru-RU if a translator is from, let's say, Kazakhstan? That's why country codes (and country flags even more) are problematic when it comes to languages. I think it's better to not use them in the first place, unless absolutely necessary.
Indeed, the region code should only be included when there is a difference for the same language in different regions that affects the translation. Even a small language like Swedish is spoken in more than one country (Sweden and Finland). The LOCALE I use is, since I live in Sweden, sv_SE.utf8. But when I CREATE A TRANSLATION, I've yet to encounter a case where I feel I would like to have different translations for sv_SE and sv_FI. Both the locales sv_SE.utf8 and sv_FI.utf8 should be able to use the same message catalog, named "sv".
(In reply to Piotr Drąg from comment #8) > (In reply to Ding-Yi Chen from comment #6) > > Talking about de facto, have a look in "locale -a". > > It is in format of like ja_JP (except eo, which do not have any country > > associate with it). > > > > As Carlos said, in Zanata, can handle xx and/or xx-YY team, if you set > > client locale mapping"<locale map-from="ja">ja-JP</locale>, you can output > > ja.po for ja-JP locale team. > > It's quite unrelated to locales. I'm talking about translation filenames, > which are almost universally like this: > > https://git.gnome.org/browse/nautilus/tree/po If you don't trust what 'locale -a' says, how about gettext itself? https://www.gnu.org/software/gettext/manual/gettext.html#Locale-Names Quote: "You might think that the country code specification is redundant. But in fact, some languages have dialects in different countries. For example, ‘de_AT’ is used for Austria, and ‘pt_BR’ for Brazil. The country code serves to distinguish the dialects." Also please aware that when you can simply specify LANG=en_AU to get the Australian Time and Monetary Format, translation with Australian spelling. On the other handle, if you just specify LANG=en, you just get the "default" English, no Time and Monetary format. > even if I > see this as unnecessary. But it can also lead to problems: for example > Russian is spoken in many countries (and is an official language in few), > why should the team be under ru-RU if a translator is from, let's say, > Kazakhstan? That's why country codes (and country flags even more) are > problematic when it comes to languages. I think it's better to not use them > in the first place, unless absolutely necessary. ru-RU merely means Russian used in Russia, it is irrelevant where you live and where you were born. If a Chinese Translator happen to know the correct spelling, grammar, and terms use in ru_RU, he/she is welcome to translate under ru_RU. Actually a lot of our Spanish translators are not come from Spain. So a Kazakhstan Russian speaker can either translate in ru_RU if ru_KZ is identical to ru_RU, or create a ru_KZ some they can use there own spelling and terms without stomping in ru with everybody else. (In reply to Göran Uddeborg from comment #9) > Indeed, the region code should only be included when there is a difference > for the same language in different regions that affects the translation. > Even a small language like Swedish is spoken in more than one country > (Sweden and Finland). The LOCALE I use is, since I live in Sweden, > sv_SE.utf8. But when I CREATE A TRANSLATION, I've yet to encounter a case > where I feel I would like to have different translations for sv_SE and > sv_FI. Both the locales sv_SE.utf8 and sv_FI.utf8 should be able to use the > same message catalog, named "sv". Quote from http://en.wikipedia.org/wiki/Finland_Swedish Finland Swedish is regulated by the Institute for the Languages of Finland. Official Swedish is not supposed to be very different from Swedish as found in Sweden. There are however e.g. words regarded as archaic in Sweden, but commonly used in Finland, and terms that differ from their counterparts in Sweden, often because of slight differences in the related legislation. So sv_FI is a necessity as if Finland Swedish want to keep their own terms. If all under sv, they have no way to keep their own terms. Actually there is an RFE stating for copy between the languages (Bug 1130636), so sv_FI can copy from sv_SE and made the necessary change, and vice versa.
Yes, there are some very few and very minor differences between Swedish in Finland and Swedish in Sweden. There are also differences within Sweden. On the same order of magnitude in my judgement. During more than 20 years I've been involved in translating open source software, no one has ever suggested it would make sense to create a separate translation for Swedish in Finland. It does make sense to have different LOCALEs for Sweden and Finland. We have different currencies, for example, so the currency codes are different. But I'm pretty confident I can speak for the entire teams when I say it would NOT make sense to create separate translations for Swedish. We don't want that extra burden. And we do not want any administrative tasks for automatic copying either. So please, do not do this split for Swedish.
(In reply to Göran Uddeborg from comment #11) > But I'm pretty confident I can speak for the entire teams when I say it > would NOT make sense to create separate translations for Swedish. We don't > want that extra burden. And we do not want any administrative tasks for > automatic copying either. A quick Google search on "sv_FI.po" indicates that projects do use "sv_FI" (It is funny to see a project even has zh_AU) > So please, do not do this split for Swedish. In Zanata, if you are a project maintainer, you can enable sv_SE or sv and disable every languages you don't want. The command line clients, by default, will not output the empty So far none of our public servers have "sv_FI", however, it is not nice to reject the requests to create "sv_FI" as Swedish is an official language in Finland. But even that, don't worry. The command line clients, by default, will not output the empty translations. So unless people do translate sv_FI, it won't appear in your package.
> A quick Google search on "sv_FI.po" indicates that projects do use "sv_FI" That's not surprising. For example, some localization systems less flexible than gettext can't handle a common per-language translation. If a user uses the sv_SE locale for such a system, it will only look for a sv_SE.po file. Such systems won't fall back to sv.po. If you maintain translations for such a system, you will have to duplicate the po file the way you describe above. If that duplication is done automatically, the po files will be identical. If it is done manually, all too often one will lag behind. So there does exist sv_SE.po and sv_FI.po files out there. But I still haven't seen a case where there are an intentional differences. Any case where both are up to date and correct, and still intentionally different. I'm not omniscient. Such cases may exist somewhere. But it is not the rule, and it would be unfortunate to impose it on Fedora packages. > In Zanata, if you are a project maintainer, I'm not. In Zanata, I'm only acting as a translator. And my goal here is to avoid tedious and pointless work to copy identical files under several names. Whether it is done automatically after being set up, or if it is maintained manually, it will add complexity and pointless extra work. > it is not nice to reject the requests to create "sv_FI" That's not my point. If any Swedish speaking person in Finland would want a separate translation of any domain, I would certainly not object. In that case, we could split that particular domain in an _FI and an _SE version. But until that happens, I want all translations to be shared. If I translate a domain, I want that translation to be available for people speaking Swedish in Finland. And conversely, if someone translates for Swedish in Finland, I want to use that translation even though I use the sv_SE locale. I'm trying to avoid duplication of work in an already pretty small community. I want any efforts done to be useful to as many as possible.
(In reply to Göran Uddeborg from comment #13) > > A quick Google search on "sv_FI.po" indicates that projects do use "sv_FI" > > That's not surprising. For example, some localization systems less flexible > than gettext can't handle a common per-language translation. If a user uses > the sv_SE locale for such a system, it will only look for a sv_SE.po file. > Such systems won't fall back to sv.po. True. Actually it is up to project maintainers whether sv_SE -> sv.po or sv -> sv_SE.po. Translators only role won't need to worry about the actual output. > But until that happens, I want all translations to be shared. If I > translate a domain, I want that translation to be available for people > speaking Swedish in Finland. Actually using only "ll_CC" format facilitate the the sharing. Let me elaborate. In translate.zanata.org, you can have any locale format you want. So, it has both sv and sv_SE, and the translation, translation memory and glossary cannot share amongst them. Thing go even worse with Chinese locales, for simplified Chinese translators, there are three teams for them to choose from. zh-Hans zh-Hans-CN zh-CN But they actually mean the same thing, yet the translation resource cannot be share. We don't want same thing that happen to fedora.zanata.org again, so I convince Noriko to use the ll_CC format, as: 1. It is recommended by gettext 2. That's what locale -a output 3. Fedora supports it 4. The language team name looks uniform (except for Esperanto (eo), which don't have any country associate with it), so easy for new translators to choose. 4. This make project maintainers' life easy. If they want sv.po instead of sv_SE.po, they can just chop of the country code if there is only one 'sv'; on the other hand, they need a big conversion table that say sv should be converted to sv_SE. > I'm trying to avoid duplication of work in an already pretty small > community. I want any efforts done to be useful to as many as possible. True, that's why Noriko and I try to unify the language team name, so Swedish team won't be separate into sv and sv_SE. You can just work under sv_SE before, regardless whether sv_FI exists or not. If someone does want a sv_FI, you do not need to be migrated.
(In reply to Ding-Yi Chen from comment #14) > 1. It is recommended by gettext > 2. That's what locale -a output > 3. Fedora supports it Locales do not equal translations. They are a "layer above" translations, providing localization information (dates, currencies etc.) to existing translations. Please see how gettext itself stores its translations: http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-tools/po http://translationproject.org/team/index.html > 4. The language team name looks uniform (except for Esperanto (eo), which > don't have any country associate with it), so easy for new translators to > choose. > 4. This make project maintainers' life easy. If they want sv.po instead of > sv_SE.po, they can just chop of the country code if there is only one 'sv'; > on the other hand, they need a big conversion table that say sv should be > converted to sv_SE. > Using country codes is opening a big can of worms. Should we create separate translation teams for dozens of Latin American Spanish-speaking countries? Some Russian-speaking Ukrainians might be angry at Russia right now and don't want to work under ru-RU. What then? Is Kosovo an independent state? Depending of your answer, you made its citizens or a part of Serbia angry. Soon we might get a request for Kurdish translations, who don't have "their own country" associated with the language. One might make a convincing argument for ku_TR or ku_IQ, or both, or something else entirely. Choosing any might offend Kurds, Turkish, maybe Iranian or who knows who else. These are just examples of how complicated this matter is. There are many more. I guess what I'm trying to say is that it's a technical problem as much as a political one. We as Fedora should avoid involving ourselves in conflicts we might never have proper knowledge or authority to judge. There is a standard of storing translations in FOSS, and I think we should stick to it.
(In reply to Ding-Yi Chen from comment #14) > 1. It is recommended by gettext As has been pointed out, that is not true. It is the recommended format for LOCALES. Not for TRANSLATIONS. These two are distinct things. A translation should only be named "ll" unless the "CC" part is actually needed. Both I and others have been trying to explain this to you several times now. Are you trolling? > 2. That's what locale -a output Which is irrelevant, since that lists locales. It is perfectly fine for different locales to share a single translation. > True, that's why Noriko and I try to unify the language team name, so > Swedish team won't be separate into sv and sv_SE. You can just work under > sv_SE before, regardless whether sv_FI exists or not. > > If someone does want a sv_FI, you do not need to be migrated. Again, I do want the two locales sv_SE and sv_FI share the same sv translation. If you mandate a CC name for languages that don't need it, you split things up. I don't know Chinese. If not all users of that language can use the same "zh" translation because the language differs between different countries, you should certainly split your translations in different zh-CC domains. There are other examples. Portuguese, for example, obviously differs enough between Portugal and Brazil that they often want separate translations. And then, of course they should be able to have that. But don't force all other languages to split, just because a few need it. The rest of us want to share the translation efforts between different countries.
(In reply to Piotr Drąg from comment #15) > Locales do not equal translations. They are a "layer above" translations, > providing localization information (dates, currencies etc.) to existing > translations. Please see how gettext itself stores its translations: Yes, they do, at least for Chinese (zh_CN, zh_TW, zh_HG) , English (en_US, en_GB), Spanish (es_ES, es_MX, ...) , French (fr_FR, fr_CH,..), Portuguese (pt_PT, pt_PR) . I think I just cover the five major languages. So I can use LANG=en_GB to specify I want English with British spelling. Tell me how I get British English with your suggestion? > http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-tools/po > > http://translationproject.org/team/index.html Well, they are inconsistent, *shrug*. > Using country codes is opening a big can of worms. Should we create separate > translation teams for dozens of Latin American Spanish-speaking countries? By looking at /usr/share/locale, they already do. > Some Russian-speaking Ukrainians might be angry at Russia right now and > don't want to work under ru-RU. What then? Yet the language itself is called "Russian". > Is Kosovo an independent state? Depending of your answer, you made its > citizens or a part of Serbia angry. The "Country code" should be renamed as "region code", as it merely defines regions. Having a region code does not say you are independent. HG and MO are Chinese cities, yet they have their own codes. > Soon we might get a request for Kurdish translations, who don't have "their > own country" associated with the language. One might make a convincing > argument for ku_TR or ku_IQ, or both, or something else entirely. Choosing > any might offend Kurds, Turkish, maybe Iranian or who knows who else. If they have "region code" and the languages are official languages, then they should be deemed as legitimate language teams. Or, can you think of exact reply that does not sound like "your language is too small to deserve a language team?" > There is a standard of storing translations in FOSS, and I think we should > stick to it. The "standard" you mentioned does not accommodate the existing translation. It does not handle the existing translation like en_GB and es_MX. (In reply to Göran Uddeborg from comment #16) > But don't force all other languages to split, just because a few need it. > The rest of us want to share the translation efforts between different > countries. The action I purpose is merely a method to prevent Swedish splits into sv and sv_SE. You also don't want that happen, right?
(In reply to Ding-Yi Chen from comment #17) > Yes, they do, at least for Chinese (zh_CN, zh_TW, zh_HG) , > English (en_US, en_GB), Spanish (es_ES, es_MX, ...) , French (fr_FR, > fr_CH,..), Portuguese (pt_PT, pt_PR) . > I think I just cover the five major languages. > > So I can use LANG=en_GB to specify I want English with British spelling. > > Tell me how I get British English with your suggestion? > There is a need for an en_GB translation. There is also a need for zh_CN, zh_TW, pt and pt_BR translations. There is probably a need for a de_CH translation. There certainly is no need for pl_PL, ru_RU or sv_SE translations, as pl, ru and sv are sufficient. On the other hand, there is a need for pl_PL, ru_RU, ru_UA, sv_FI and sv_SE *locales*. And that's why they exist. Translations and locales are two different concepts, and this is the last time I repeat that, as I feel we repeated this particular argument enough times already. > > http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-tools/po > > > > http://translationproject.org/team/index.html > > Well, they are inconsistent, *shrug*. > Ok, then please compare some other major projects: https://git.gnome.org/browse/gnome-shell/tree/po http://l10n.kde.org/teams-list.php http://git.xfce.org/apps/mousepad/tree/po https://git.fedorahosted.org/cgit/anaconda.git/tree/po/LINGUAS https://github.com/MidnightCommander/mc/tree/master/po (fi_FI.po and sv_SE.po are leftovers of a Transifex's bug, fixed in 2009) Do you start to see a pattern here? > By looking at /usr/share/locale, they already do. > Almost all of them, if not all, are there because of libgweather, which is a special case, as it contains locale information not included in glibc. > Yet the language itself is called "Russian". > Yes it is. And? In reality there is no direct relation between countries and languages. English is not an official language of the United States. Russian is an official language of four countries. Arabic of 27. Basque of none. It's complicated. It's politics. It's not something we should deal with. You keep ignoring that part of my comments. > The "Country code" should be renamed as "region code", as it merely defines > regions. Having a region code does not say you are independent. HG and MO > are Chinese cities, yet they have their own codes. > It doesn't matter how you would call it. See above about politics. > If they have "region code" and the languages are official languages, then > they should be deemed as legitimate language teams. > > Or, can you think of exact reply that does not sound like "your language is > too small to deserve a language team?" > So language needs to be official now? Official of what exactly? Of a specific country? Why not the other one? Who decides? Why this person/organization should decide? The questions are endless. It's not in our best interest to deem languages "legitimate" or not. > The "standard" you mentioned does not accommodate the existing translation. > It does not handle the existing translation like en_GB and es_MX. > These translations exist just fine. I don't have a problem with people translating to es_MX if they want. I just don't think we should use _CC by default, but rather on a case-by-case basis.
Hi, Thank you for all the knowledge and background! I see now there is no problem to keep current format xx (except the languages which needs xx-XX formats), and would like to confirm with FESCO if all developers are happy to use xx.
Sounds good to me. :)
(In reply to Piotr Drąg from comment #18) > > There is a need for an en_GB translation. There is also a need for zh_CN, > zh_TW, pt and pt_BR translations. There is probably a need for a de_CH > translation. There certainly is no need for pl_PL, ru_RU or sv_SE > translations, as pl, ru and sv are sufficient. > > On the other hand, there is a need for pl_PL, ru_RU, ru_UA, sv_FI and sv_SE > *locales*. And that's why they exist. > > Translations and locales are two different concepts, and this is the last > time I repeat that, as I feel we repeated this particular argument enough > times already. No need to repeat that, I know that languages and locales are different concept. And some people do use locale format like "en_GB" and "zh_TW" to specify languages. Consensus ? > Ok, then please compare some other major projects: > > https://git.gnome.org/browse/gnome-shell/tree/po > http://l10n.kde.org/teams-list.php > http://git.xfce.org/apps/mousepad/tree/po > https://git.fedorahosted.org/cgit/anaconda.git/tree/po/LINGUAS > https://github.com/MidnightCommander/mc/tree/master/po (fi_FI.po and > sv_SE.po are leftovers of a Transifex's bug, fixed in 2009) > > Do you start to see a pattern here? I can also come up a list states otherwise. https://www.debian.org/international/l10n/po/ They seem to have all. But anyway, it's Debian. > Almost all of them, if not all, are there because of libgweather, which is a > special case, as it contains locale information not included in glibc. https://www.debian.org/international/l10n/po/es_PY > So language needs to be official now? Official of what exactly? Of a > specific country? Why not the other one? Who decides? Why this > person/organization should decide? The questions are endless. It's not in > our best interest to deem languages "legitimate" or not. If we receive a request that specifically ask for sv_FI, should we accept or reject? If reject, what should we justify ourselves? Anyway, most of my fellow developers support ll if no ambiguation, and actually my scripts can handle both either ll or ll_CC, so I am fine for either. :-)
(In reply to Ding-Yi Chen from comment #17) > (In reply to Göran Uddeborg from comment #16) > The action I purpose is merely a method to prevent Swedish splits into sv > and sv_SE. You also don't want that happen, right? Of course not, but that has rarely if ever been a problem. The action you propose would split sv_SE and sv_FI from each other. THAT is the problem. I believe you when you say it is needed to split Chinese (zh) in different translations for different regions. Why can't you believe me when I say that for Swedish, it is not needed, and doing it would be harmful since it would split up the translation community? (In reply to Ding-Yi Chen from comment #21) > If we receive a request that specifically ask for sv_FI, should we accept or > reject? Accept, of course! But until that actually happens, let us share the common "sv" translations in both sv_SE and sv_FI. Only split a language by region when requested by someone using that language!
(In reply to Göran Uddeborg from comment #22) > Accept, of course! But until that actually happens, let us share the common > "sv" translations in both sv_SE and sv_FI. > > Only split a language by region when requested by someone using that > language! I think we reach consensus here, for the language team that is not already in Fedora, should be created on-request.
(In reply to Ding-Yi Chen from comment #23) > I think we reach consensus here, for the language team that is not already > in Fedora, should be created on-request. Just keep in mind that people requesting new teams might not have the necessary knowledge to make the decision. I'm *not* saying they would be always wrong, I'm just saying that not every translator is a technical type of person and sometimes we need to supervise the process in order to save everyone's time. In GNOME we have the Localization Coordination Team that approves the requests. I wonder if we can resurrect FLSCo for that purpose.
(In reply to Piotr Drąg from comment #24) > Just keep in mind that people requesting new teams might not have the > necessary knowledge to make the decision. I'm *not* saying they would be > always wrong, I'm just saying that not every translator is a technical type > of person and sometimes we need to supervise the process in order to save > everyone's time. In GNOME we have the Localization Coordination Team that > approves the requests. I wonder if we can resurrect FLSCo for that purpose. Currently in Zanata, only admin can add languages, thus it is better to have guideline for admins and applicant to follow. Once FLSCo is revived, they can have representative in Zanata admin team and manage languages.
Hi Ding-Yi Please see attached final list, and create the languages below. * Final list sheet - 84 languages, all languages listed in this sheet. Let's use 'dash' for four digit code. We understand that that there is a little impact to the developers via mapping. * no claim list sheet - 10 languages, the languages highlighted with blue, aka the languages have some translation done previously for anaconda. Please advise when ready. Thanks.
Created attachment 953432 [details] final list
I have created nearly all the languages in final list except kw-uccor, kw-ucrcor, kw-kkcor. I think the convention is some thing like sr@latin So for those language teams, they should be kw@uccor, kw@ucrcor, kw@kkcor.
According to Cornish team, kw@uccor and kw@kkcor are created. The fedora.zanata.org is on-line now. VERIFIED with Zanata 3.5.1 (git-server-3.5.1)