Quoting Chris Leonard (cjlhomeaddr...@gmail.com):
These examples are indeed the most common exceptions. Let's add my
experience about them.
> 1)
> en, en_US and en_GB are commonly found because
> a) there are a number of distinct spelling differences (orthography)
> that you do not see with Spanish.
> b) the burden of maintaining the "translations" is actually quite minimal.
> In Gnome, there is even a PERL script that takes a first pass at this
> for you, with pretty good results.
The main problem here is deciding about the *original*
strings. Depending on the maintainer of the software, they're either
en_US, en_GB or, most often en_airport (the same English I'm writing
right now...:-)).
Standardi{z|s}ing on one of both (not to mention en_AU, en_ZA, etc.)
is always a good idea, but requires a quite good knowledge of English,
most often available to native speakers only.
In Debian, we try to standardize on en_US when we can (indeed, when we
have someone reviewing the texts). Not because it's better or
whatever, but mostly because it seems to be the most widely used, so
that requires less modifications. We eve have a debian-l10n-english
mailing list aimed at encouraging eviews of texts, with a few
volunteers trying to help package maitnainers, documentation writers,
our publicity team, etc. to get good texts out.
And, nearly always we don't have any en_GB translation. Probably
because the often very technical texts we have do not require this.
> 2)
> zh_CN and zh-TW are in fact quite different, you never see just zh (in
> my experience). When present, both zh_CN and zh-TW typically get
> well maintained. Occasionally one will also see zh_HK, but it is less
> common.
Those both are indeed different variations in *written* forms of the
Chinese language*s* (Simplified, used mostly in mainland China and
Traditional used in Taiwan, Hong-Kong, Singapore, etc.). Actually we
should use zh@simplified and zh@traditional (modifiers) rather than zh_CN for
Simplified and zh_TW for Traditional (country variants).
Using country variants instead of modifiers for Chinese is common
practice (we used it in Debian) but actually bad practice as it leaves
people using zh_GK or zh_SG out of the game (they have to add zh_TW as
alternative in their locale settings).
>
> 3)
> pt_PT and pt_BR are very frequently found. I don't know the
> distinctions well, but when present, they both get well maintained.
Yet another difference established by common practice. Indeed,
Brazilian is different enough from Portuguese to nearly warrant its
own ISO code, which would make things better.
Most software use pt.po and pt_BR.po files. A mistake would be using
pt_BR and pt_PT as "continental" Portuguese is also used in former
Portuguese colonies and there are locales for some of them.
>
> 4)
> Occasionally one will see de_DE and de_CH, although much more rarely,
> and generally with much less completeness on de_CH
I've seen very few of these and I often try to discourage them. From
what I heard of German and Swiss fellows, the difference is more is
spoken language than written one.
The same stands for French, where the written language is standardized
over French-speaking countries with few enough variants (the most well
known is the way to say 7x, 8x, 9x numbers, between France and
Belgium/switzerland).
>
> 5)
> fa and fa_AF seems to be an important distinction as well (Iranian
> Persian vs Afghani Dari).
I have not enough experience about these. In Debian we have a few
Persian translations and all of them us "fa".
Another common variant case is bn_IN and bn_BD. I'm having very hard
times understanding if that's for real reasons of for political
reasons. Unfortunately, politics often enters such things and
everything related to languages and countries becomes sensitive one
day or another.
My last story about this are the two variants of Serbian : ekavian and
ijekavian. I still remember a meeting at last Debian conference (in
Banja Luka, Republika srpska, part of federation of Bosnia and
Herzegovina) where I was dropped into something that was looking like
Dayton negotiations in the 90's, between Serbs from Serbia and Serbs
from Republika Srpska. Both wanted to do their own work and, believe
me, you really don't want to be in the middle of this..:-)
As a result, we now have "sr.po" translations for Serbian"ekavian"
(the form used in Serbia) and sr@ijekavian for "ijekavian" (the form
used in the Serb part of Bosnia). My proposal to use sr_BS was
completely ruled out by locals....for political reasons (even though
they are part of Bosnia, they don't feel like this). My proposal to
use "bs" (Bosnian) which is also existing was also ruled out even
though "bs" is actually exactly s...@ijekavian....but only used by
people in the "muslim" part of Bosnia. The conclusion of this meeting
was "Welcome to the Balkans".
Interesting game, isn't it?
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Translate-pootle mailing list
Translate-pootle@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/translate-pootle
