[WG: I18N & L10N] Having a locale as default for others in the same language

[Gao Jun]

May be this is tradeoff between end-users and translators.

To Chinese, there are four locales defined in Java 7. They are 
zh_CN(Mainland China), zh_TW(Taiwan), zh_HK(Hongkong), zh_SG(Singapore). 
As far as I know, zh_CN and zh_SG are similar to each other (Simplified 
Chinese), while zh_TW and zh_HK are similar to each other (Traditional 
Chinese).

Many people can read both Simplified Chinese and Traditional Chinese 
while only some people can write both of them. So, I think many 
Chinese-speaking Sakai user will prefer to see 
(Simplified/Tranditional)Chinese instead of English. Since Sakai is 
mostly used in higher education, I think even more end-users can read 
both Simplified and Tranditional Chinese.

But still not all of the people can read both styles. And, English 
education is very common in Chinese-speaking area, in universities and 
colleges, almost all Sakai end-user can read English. Frankly speaking, 
may be some users will prefer English to the other Chinese style, and 
even some of them can only read English.

So, in the Chinese case, to end-users, having a default zh language may 
be a good idea to many users, not having a default zh language may be a 
'worse' idea but can fit 'more' users.

In the other hand, as the translator of most zh_CN properties files. I 
think having a default zh language is not necessary. It's very easy to 
copy zh_CN files to zh_SG, or zh_TW to zh_HK. Translator can just edit 
the file to change what they need.

And while I want to check if I have translated 'all' properties file, 
it's easy to see how long to go 100% translated with the l10n-stats tool.

Above is the situation of Chinese, hope these information will help.


Cheers,
Gao Jun


? 2014?07?11? 22:23, Matthew Jones ??:
> I would agree with Sam,
>
> There are 5 countries that have a French specific locale setting and 
> all are in Europe; Belgium, Switzerland and Luxembourg. [1] I'd have 
> to guess all of those countries would take fr_FR over fr_CA but if 
> they took fr_FR as it was, they would also have to accept date 
> formatting (which may or may not be the same) as well as currency and 
> other internal formatting. Or they'd have to take their fr_* setting 
> and have it fall back to English since there is no fr available instead.
>
> This was the problem with es, but it was worse because there are 20 es 
> countries, and they for sure have more non language variations and 
> significantly more overlap with (most likely) es_ES. I think the same 
> could be said for Arabic as well.
>
> I don't have any investment in French specifically either (as I did 
> with Spanish), and maybe nobody from the French speaking areas of 
> Belgium or Switzerland want to run Sakai, but if I was voting, I'd say 
> that fr_FR is a better fallback for everyone (fr_CA) included that 
> English. And to accomplish that without an fr fallback seemed to be a 
> technical challenge. I'm personally happy with fr_FR being the default 
> Sakai fr language. Just as I'm happy with en_US being the default 
> Sakai en language. (And es_ES being the default Sakai es language)
>
> I think those are just decisions that need to be made without trying 
> to compromise on minimum coverage. Maximum coverage with individual 
> overrides is easier. ;)
>
> [1] 
> http://www.oracle.com/technetwork/java/javase/javase7locales-334809.html
>
>
> On Fri, Jul 11, 2014 at 9:49 AM, Sam Ottenhoff 
> <ottenhoff at longsight.com <mailto:ottenhoff at longsight.com>> wrote:
>
>
>         French from Canada and France a really different, using one as
>         default for the other would, in my opinion, be a mistake.
>
>
>
>     Absolutely.  So my next question would be, what about French from
>     Belgium and French from Switzerland?  I assume they would want to
>     use fr_FR as a base with a few country-specific overrides, no?
>
>         When there was only fr_CA available in Sakai, my users were
>         uncomfortable with it. I suppose it would be the same the
>         other way around if fr_FR becomes the default. I would gladly
>         create a shared fr locale if I had fr_CA owners who could meet
>         with the fr_FR team to agree on shared part of the
>         translation, but none are available AFAICT.
>
>
>     I don't understand why fr_CA owners need to be involved at all.
>      If fr_CA doesn't keep their translation up to date, they get
>     English text as a fallback currently, right?  Is fr_CA so distinct
>     that English text is a better fallback than French?
>
>     I don't have investment in this area.  It just seems like this is
>     bad policy.
>
>     --Sam
>
>
>
>
>
> _______________________________________________
> i18n mailing list
> i18n at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/i18n
>
> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/i18n/attachments/20140712/d91e3815/attachment-0001.html