El dt 01 de 02 de 2011 a les 07:28 +0000, en/na Gunnar Hjalmarsson va
escriure:
> On 2011-01-31 12:02, David Planella wrote:
> > I'm not sure how you can detect the main dialect (afaik, there is no
> > place where it says that es_ES or de_DE is the main one),
>
> Good point. Considering the para in the gettext docs I quoted in bug
> 700213, I first thought that the gettext package includes such info, but
> I failed to find it. Instead I created a 'home made' file which maps
> certain languages with their "main dialects":
> /usr/share/language-selector/data/main-countries
>
There is no way a list like that can be kept manually in such a file
withouth in-depth knowledge of all languages represented. If this
information were possible to accurately be defined, it should live in
the iso-codes package, which already contains a lot of information about
languages and countries, along with their translations.
What would you do in the case of English for example? What would be the
main country, the UK or US? Or Persian, should we take Iran or
Afghanistan?
> I created it for a slightly different purpose (setting LC_MESSAGES), but
> this bug report made me realize that the file may be useful also when
> generating lists of language options.
>
> > so I'd say we should show all translations present, even if they
> > don't have a country code.
> >
> > In this particular case, we'd show:
> >
> > es
> > es_MX
> > es_PR
>
> In addition to the issue in bug 700213 (assuming I'm right...), there
> are more subjective reasons why I personally would prefer a slightly
> different solution. What you suggest implies that the UI would sometimes
> show both an 'es' and an 'es_ES' option, which may be confusing to
> users, and hence should be avoided.
>
There is no es_ES language, neither in /usr/share/locale nor
in /usr/share/locale-langpack, although I'm not sure this can be
extrapolated to all languages.
However, what I see is that there is always at least an 'll' code, i.e.
there is no situation where there are only 'll_CC' codes for a language.
In any case, it's a tricky problem. Just a couple of cases to illustrate
it:
zh <- I don't know what that is
zh_CN <- Simplified Chinese
zh_TW <- Traditional Chinese, a different locale
gl <- Galician
gl_ES <- Galician, as spoken in Spain
es <- Spanish, as spoken in Spain
(es_ES) <- Non-existent
es_MX <- Spanish, as spoken in Mexico
> Instead, as soon as there are translations in more than one dialect of a
> language available, I'd prefer to include the country in all the options
> for that language. So in this case I think we should show:
>
> es_ES
> es_MX
> es_PR
>
> Please note that all those options will make gettext look for
> translations under .../es unless found under respective country specific
> directory.
>
> Only when there are no translations in other directories but
> /usr/share/locale/es and /usr/share/locale-langpack/es, showing just
> 'es' is preferable IMO.
>
> > Since otherwise, in the current form, users are being forced to use
> > "es_MX" or "es_PR", as "es" alone is not shown.
>
> Indeed. A solution to this bug does require a modification of the code;
> great that you catched the issue so fast.
>
> Since there is a gdm merge proposal with similar code changes in
> pipeline, I modified it in accordance with the model I'm arguing for
> above. Please feel free to install the development gdm package for Natty
> to check out its behavior.
> https://launchpad.net/~gunnarhj/+archive/language-menus
>
El dt 01 de 02 de 2011 a les 07:28 +0000, en/na Gunnar Hjalmarsson va language- selector/ data/main- countries
escriure:
> On 2011-01-31 12:02, David Planella wrote:
> > I'm not sure how you can detect the main dialect (afaik, there is no
> > place where it says that es_ES or de_DE is the main one),
>
> Good point. Considering the para in the gettext docs I quoted in bug
> 700213, I first thought that the gettext package includes such info, but
> I failed to find it. Instead I created a 'home made' file which maps
> certain languages with their "main dialects":
> /usr/share/
>
There is no way a list like that can be kept manually in such a file
withouth in-depth knowledge of all languages represented. If this
information were possible to accurately be defined, it should live in
the iso-codes package, which already contains a lot of information about
languages and countries, along with their translations.
Just look at the map of languages and countries: www.ethnologue. com/country_ index.asp
http://
What would you do in the case of English for example? What would be the
main country, the UK or US? Or Persian, should we take Iran or
Afghanistan?
> I created it for a slightly different purpose (setting LC_MESSAGES), but
> this bug report made me realize that the file may be useful also when
> generating lists of language options.
>
> > so I'd say we should show all translations present, even if they
> > don't have a country code.
> >
> > In this particular case, we'd show:
> >
> > es
> > es_MX
> > es_PR
>
> In addition to the issue in bug 700213 (assuming I'm right...), there
> are more subjective reasons why I personally would prefer a slightly
> different solution. What you suggest implies that the UI would sometimes
> show both an 'es' and an 'es_ES' option, which may be confusing to
> users, and hence should be avoided.
>
There is no es_ES language, neither in /usr/share/locale nor locale- langpack, although I'm not sure this can be
in /usr/share/
extrapolated to all languages.
However, what I see is that there is always at least an 'll' code, i.e.
there is no situation where there are only 'll_CC' codes for a language.
In any case, it's a tricky problem. Just a couple of cases to illustrate
it:
zh <- I don't know what that is
zh_CN <- Simplified Chinese
zh_TW <- Traditional Chinese, a different locale
gl <- Galician
gl_ES <- Galician, as spoken in Spain
es <- Spanish, as spoken in Spain
(es_ES) <- Non-existent
es_MX <- Spanish, as spoken in Mexico
> Instead, as soon as there are translations in more than one dialect of a locale/ es and /usr/share/ locale- langpack/ es, showing just /launchpad. net/~gunnarhj/ +archive/ language- menus
> language available, I'd prefer to include the country in all the options
> for that language. So in this case I think we should show:
>
> es_ES
> es_MX
> es_PR
>
> Please note that all those options will make gettext look for
> translations under .../es unless found under respective country specific
> directory.
>
> Only when there are no translations in other directories but
> /usr/share/
> 'es' is preferable IMO.
>
> > Since otherwise, in the current form, users are being forced to use
> > "es_MX" or "es_PR", as "es" alone is not shown.
>
> Indeed. A solution to this bug does require a modification of the code;
> great that you catched the issue so fast.
>
> Since there is a gdm merge proposal with similar code changes in
> pipeline, I modified it in accordance with the model I'm arguing for
> above. Please feel free to install the development gdm package for Natty
> to check out its behavior.
> https:/
>
-- la.wordpress. com ca/dplanella / www.twitter. com/dplanella
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanel
www.identi.