Date: Sat, 26 Jul 2014 22:08:03 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: locale fallback option On Sat, Jul 26, 2014 at 11:46:31PM +0200, Wermut wrote: > Hi > > I just read, that you committed the basic locale code and about the > musl firsts and thought of one thing that I would really like to see > in a modern implementation. > > Problem: User A speaks a language "xyz" and lives in country "AB". So > he will set the relevant locale environment vars to "xyz_AB". The > problem is, that the language "xyz" is only spoken by a minority of > people and the translation of the software in his language is often > not complete or non existend. The result is, that user A will have to > read the most strings in plain english, because this is the standard > fallback. Because our user A is a member of a minority, he knows also > the language "ts" which is also spoken in "AB", but he does not know > any english. > > Status quo: Because the translation "xyz_AB" is not really complete, > the user A gives up, is frustrated and sets his locale to "ts_AB". > > What really should be possible: User A sets the locale "xyz_AB" and > sets "ts_AB" as a fallback for definitions and strings not available > in "xyz_AB". Only if a string is not defined in either "xyz_AB" or > "ts_AB", the hardcoded english string is shown to him. > > This would require, that the locale definition would accept something > like LANG=xyz_AB:ts_AB What you're asking for is roughly possible with GNU gettext and the LANGUAGE environment variable. See: https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html This does not facilitate partial translations with fallback to a different language, but does facilitate the situation where only some apps have the user's preferred language and others only have a more widely-used language. I think we should support the exact same thing in musl's internal gettext. Whether we should support fallbacks in the LC_* variables for the locale too is an open question, but I don't think there's any reason at all to consider "partial translations" with fallback to a different language for locales. The number of messages is just so small (and not going to significantly increase) that it really doesn't make sense to have partial translations. Fallbacks kind of make sense, but you can always choose a language that libc actually has for the _locale_, then put the list of application languages in the LANGUAGE variable, so I'm not clear on how fallbacks would let you do anything you couldn't otherwise do or make it significantly easier. Does this make sense? Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.