© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
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/
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.
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/
'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:/