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.

Just look at the map of languages and countries:
http://www.ethnologue.com/country_index.asp

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
> 


-- 
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella