[WG: I18N & L10N] Having a locale as default for others in the same language
Jean-Francois Leveque
jean-francois.leveque at upmc.fr
Fri Jul 11 02:10:14 PDT 2014
This is my opinion and the other contributors to the fr_FR locale are
getting this mail to be able to give more information and their opinion
if they want.
I've changed the title of this thread because it wasn't about es_MX anymore.
I welcome opinions of others that are actively providing translations.
I might be repeating myself, please forgive this way of explaining my
point of view from different angles.
I can understand that the default locale in Sakai is mostly the en_US
locale, even if parts of the code that have been written in other
English-speaking countries might be in those countries English locale.
French from Canada and France a really different, using one as default
for the other would, in my opinion, be a mistake. 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.
Let me give you another example of how bad having a locale of one
language used as the default for other locales of the same language.
Both zh_CN and zh_TW are Chinese locales but the Cross-Strait relations
(http://en.wikipedia.org/wiki/Cross-Strait_relations) might not be good
enough to choose one instead of the other as default for both.
If one locale coverage is not good enough, the best solution might be to
make it unavailable in the default settings of Sakai instead of making
users believe their locale is covered and giving them what is mostly
another locale. Users from one locale will be knowingly be using a
locale different from theirs and be more forgiving, I think.
On 2014-05-29 8:29 GMT-07:00 Neal Caidin mentioned a "major regression
in that Mexican Spanish". https://crowdin.net/project/sakai-cle shows a
coverage of 32% for Spanish, Mexico. I think it's small enough to
deactivate it, "hide the es_MX translations" as Neal has written it. I
think copying es_ES to es or es_MX is a bad idea as the Spanish have
decided and I've written above for other locales. Matthew Jones did a
comparison with English, the issue with US English is quite different,
it's only mostly the default language.
A proof of default not being completely en_US is the default has
overrides in en_US
(./profile2/bundle/src/resources/ProfileApplication_en_US.properties,
./profile2/util/src/java/org/sakaiproject/profile2/util/messages_en_US.properties
and ./metaobj/metaobj-tool/tool/src/bundle/messages_en_US.properties)
and also in en
(./jsf/jsf-widgets/src/java/org/sakaiproject/jsf/bundle/pager_en.properties
and ./entitybroker/mocks/src/java/describe-prefix_en.properties) while
there are 3 en_ZA, 5 en_AU and 120 en_GB files.
If we set a standard on minimum coverage (or any other mean) before
making a locale available in the preferences, this doesn't hinder
integrating translations that don't have enough coverage (or other
parameter to a good enough value) and institutions that want to use
those locales can still do and decide whether they prefer English or a
different country's locale for their language as default when they've
not provided a translation. They could even integrate part of the other
locale translation in their locale if they think it's fine and give it
back to the community. I think not giving them the choice is a bad idea.
I hope think explains why I'm against making one locale the default of
others for the same language and how I think we should work this out.
Jean-Francois is managing the fr_FR translation with Frederic and Eric
and knows about nobody else managing the French translation of another
locale, even if we've had contributions from Canada and Pearson in the past.
Questions are also welcome.
Le 10/07/2014 22:29, Matthew Jones a écrit :
> Yeah, that's what would happen. I guess I never paid attention to the
> lack of an _fr base. I think we'd want to pick one of them (whichever is
> more complete) as the base, and the either the _FR or _CA would be the
> variants. Likely the _CA represents Quebec French?
>
> Spanish was more noticeable since we only had an _es in 2.9.x and it was
> removed which broke the Colombian and Mexican variants completely. Where
> it looks like 2.9.x has both a partially complete fr_FR and fr_CA. (And
> there are a lot more Spanish java locales than French)
>
> Maybe Jean-Francois or whoever is managing the French translations has
> some additional insight.
>
>
>
> On Thu, Jul 10, 2014 at 3:36 PM, Sam Ottenhoff <ottenhoff at longsight.com
> <mailto:ottenhoff at longsight.com>> wrote:
>
> Sorry for picking up an old-thread, but I'm still confused on this
> issue. It looks to me like we no longer have just FR translations,
> we have fr_FR and fr_CA. Example:
>
> login/login-tool/tool/src/bundle/auth_fr_FR.properties
> login/login-tool/tool/src/bundle/auth_fr_CA.properties
>
> This approach seems totally wrong to me, but I'm not an i18n expert.
> Why is fr_FR not the default here so there is just an
> auth_fr.properties?
>
> So if I want to create a single override for Belgium-French, then I
> would just make one file with one line for fr_BE. With the way it
> is setup now, I would need to copy every single fr_FR into fr_BE!
> Can someone explain?
>
> --Sam
>
>
>
> On Thu, May 29, 2014 at 6:55 PM, Steve Swinsburg
> <steve.swinsburg at gmail.com <mailto:steve.swinsburg at gmail.com>> wrote:
> >
> > Agreed, there needs to be a base for all major languages that we
> support. I would like to know the reasons behind moving from es to
> es_ES, seems a backwards step in context of how locale resolution
> works.
> >
> > If they are kept in sync then fine but there needs to be a base
> to cater for fallback.
> >
> > Cheers
> > Steve
> >
> > sent from my mobile device
> >
> > On 30/05/2014 2:16 AM, "Matthew Jones" <matthew at longsight.com
> <mailto:matthew at longsight.com>> wrote:
> >>
> >> I honestly would say that's this it's unacceptable to have no
> default es language. What you're saying is the same as if the US
> community said that we wanted to move all of the English
> translations from en to en_US and then have no default fallback
> language at all in Sakai. That just doesn't make any sense at all
> and it wouldn't happen. As it would break also break people who are
> overriding Australia, Canada, New Zealand, South Africa and UK.
> >>
> >> It just isn't a good solution for the community.
> >>
> >> If you could somehow change how java does the fallback to go
> es_* -> es_ES -> es then that sounds okay, but I don't know how to
> do that.
> >>
> >>
> >> On Thu, May 29, 2014 at 12:00 PM, Miguel Carro Pellicer
> <miguel at educlever.es <mailto:miguel at educlever.es>> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> All the spanish community voted to move from "es" to "es_ES" in
> order to avoid conflicts and maintain locales separately, that's why
> we have done the changes.
> >>>
> >>> Miguel.
> >>>
> >>> El 29/05/2014 17:49, Matthew Jones escribió:
> >>>
> >>> Right, the java locale fallback would be to go
> >>>
> >>> es_MX -> es -> en
> >>>
> >>> So without an es the text is just appearing in English. I'd
> personally be happy with either keeping es_ES in sync or just making
> your files from es_ES the default as es and not having an es_ES
> variation. You could still select es_ES from the translation menu in
> preferences but it would just immediately fallback to es. That would
> eliminate having to do changes twice at least. Whatever you decide
> though.
> >>>
> >>> I think it would be good just in-case other Spanish countries
> like es_CO, es_PR or es_AR, etc decide they also want to support a
> language with only slight variations, for instance. :)
> >>>
> >>>
> >>> On Thu, May 29, 2014 at 11:38 AM, Diego del Blanco Orobitg
> <diego.delblanco.sakai at gmail.com
> <mailto:diego.delblanco.sakai at gmail.com>> wrote:
> >>>>
> >>>> Hi:
> >>>>
> >>>> As now Spanish (from Spain) is "es_ES" and not "es" (as some
> time ago), when there is not "es_MX" it uses the default (that is
> english) . I think before that "es_MX" searched for "es" when there
> is not "es_MX" file (please, if I'm wrong someone can correct me).
> >>>>
> >>>> So, maybe other solution can be duplicate all the "es_ES"
> files to "es" and have it as basis for all the spanish translations.
> better than mix es_ES with es_MX becuase if we do that, México
> people won't know what is missing or not to translate
> >>>>
> >>>> The problem can be to maintain "es" and "es_ES" because we
> will need to do changes twice... or always duplicate files when we
> change in "es_ES"...
> >>>>
> >>>>
> >>>> 2014-05-29 8:29 GMT-07:00 Neal Caidin <neal.caidin at apereo.org
> <mailto:neal.caidin at apereo.org>>:
> >>>>
> >>>>> Hi i18n,
> >>>>>
> >>>>> I found a major regression in that Mexican Spanish in 10.0
> mostly shows
> >>>>> English, except for a few places.
> >>>>>
> >>>>> https://jira.sakaiproject.org/browse/SAK-26268
> >>>>>
> >>>>> FYI - the team is working quickly to get out an 10.0-RC01
> (like in the
> >>>>> next day or so) , and while i18n issues are not normally
> considered
> >>>>> blockers, it would be nice to get this one fixed ASAP.
> >>>>>
> >>>>> One option could be to hide the es_MX translations in 10.0
> until it is
> >>>>> fixed.
> >>>>>
> >>>>> I guess another could be to copy es_ES (Spain) over to es_MX
> , except
> >>>>> for the few es_MX properties that exist.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Thanks,
> >>>>> Neal
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Neal Caidin
> >>>>> Sakai Community Coordinator
> >>>>> Apereo Foundation
> >>>>> neal.caidin at apereo.org <mailto:neal.caidin at apereo.org>
> >>>>> Skype me! (but let me know in advance for the first
> interaction) - nealkdin
> >>>>>
> >>>>> _______________________________________________
> >>>>> i18n mailing list
> >>>>> i18n at collab.sakaiproject.org
> <mailto:i18n at collab.sakaiproject.org>
> >>>>> http://collab.sakaiproject.org/mailman/listinfo/i18n
> >>>>>
> >>>>> TO UNSUBSCRIBE: send email to
> i18n-unsubscribe at collab.sakaiproject.org
> <mailto:i18n-unsubscribe at collab.sakaiproject.org> with a subject of
> "unsubscribe"
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> ***************************************
> >>>> Diego del Blanco Orobitg
> >>>> Spain & LATAM Regional Manager (ANI Sakai)
> >>>> Apereo LATAM Representative (Apereo Foundation)
> >>>>
> >>>> P: (+34) 653 683 489 <tel:%28%2B34%29%20653%20683%20489>
> >>>> E: ddelblanco at anisakai.com <mailto:ddelblanco at anisakai.com>
> >>>> Sk: ddelblanco.ani
> >>>> ***************************************
> >>>>
> >>>> _______________________________________________
> >>>> i18n mailing list
> >>>> i18n at collab.sakaiproject.org <mailto:i18n at collab.sakaiproject.org>
> >>>> http://collab.sakaiproject.org/mailman/listinfo/i18n
> >>>>
> >>>> TO UNSUBSCRIBE: send email to
> i18n-unsubscribe at collab.sakaiproject.org
> <mailto:i18n-unsubscribe at collab.sakaiproject.org> with a subject of
> "unsubscribe"
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> i18n mailing list
> >>> i18n at collab.sakaiproject.org <mailto:i18n at collab.sakaiproject.org>
> >>> http://collab.sakaiproject.org/mailman/listinfo/i18n
> >>>
> >>> TO UNSUBSCRIBE: send email to
> i18n-unsubscribe at collab.sakaiproject.org
> <mailto:i18n-unsubscribe at collab.sakaiproject.org> with a subject of
> "unsubscribe"
> >>>
> >>>
> >>> --
> >>>
> >>> Miguel Carro Pellicer
>
> >>> IT Consultant - Elearning solutions
> >>>
> >>> Phone: +34 - 686266485 <tel:%2B34%20-%20686266485>
> >>> Email: miguel at educlever.es <mailto:miguel at educlever.es>
> >>>
> >>> No me imprimas si no es necesario. Protejamos el medio ambiente
> >>>
> >>>
> >>> AVISO LEGAL: El contenido de este mensaje de correo
> electrónico, incluidos los ficheros adjuntos, es confidencial y está
> protegido por el artículo 18.3 de la Constitución Española, que
> garantiza el secreto de las comunicaciones.
> >>> Si usted recibe este mensaje por error, por favor póngase en
> contacto con el remitente para informarle de este hecho, y no
> difunda su contenido ni haga copias.
> >>> *** Este mensaje ha sido verificado con herramientas de
> eliminación de virus y contenido malicioso ***
> >>> Este aviso legal ha sido incorporado automáticamente al mensaje.
More information about the i18n
mailing list