* On 05/18/10 13:18, Steffen Dettmer wrote:
Therefore, any compile-time test that sets a variable HAVE_LINGUA_foo in relation to the languages on the compilation machine will most likely be out-of-date when you copy the executable but not the translation file to a user's machine. Conversely, a translation language not available at configure time might later be written and installed, at which point your executable is already hard-coded not to use it.
That's true. But ion the above situation IMHO you cannot handle this case. IMHO you could only add all possible languages and check, if setting the related locale succeeds. Am I wrong?
I guess an idea is that the application itself shouldn't need to know about the installed locales and the application shouldn't need to have an own preferences dialog, but have some user-global inherited setting. On a modern linux I would expect that the super-GUI has some tool to set that (some `control panel' or so) and/or have a language selection in the login dialog. I could even imagine that the language configuration tool may fetch missing languages from some package repository.
However, if an application really needs to know the available languages, wouldn't there be a way to find out what it installed, for example using readdir(3)?
User always may choose application language by setting environment variables LANG, LC_*. Even on application-by-application basis.
| $ env | grep -E '(LANG|LC_)'
| LANG=ru_RU.UTF-8
| $ date
| вторник, 18 мая 2010 г. 15:02:53 MSD
| $ LANG=de_DE date
| Dienstag, 18. Mai 2010, 15:03:02 MSD
| $
Why reimplement this in the application GUI ? But, if extremely required, I would also propose to build the list of available languages dynamically, at run-time.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
---------------------------
T: +7 916 193-1170 (mobile)
T: +7 903 544-7220 (mobile)
E: andreev@xxxxxxxxx
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
