On Jan 9, 2006, at 3:50 AM, Ralf Stephan wrote:
It sounds only so-so as far as a 'fix' goes.
Huh? The problem was application strings were not in the desired language; after it, they were. More importantly, setting LANG did not work.
But even *more* importantly, setting LANG *should* have worked. There is some reason or multiple reasons causing it to not work as expected for you. This is probably the key. Exactly why the documented method isn't working needs to be determined.
For example, how do the standard programs on your box perform with the same conditions? (ls for a non-existent file is an easy test)
That gives me english output as intended. I don't need other locales preinstalled; it even hampers my ability to communicate about error messages, menu items, widget text etc.
So, are you saying that you have one and only one locale installed on your system? And if you check the system directories you see directories with only that?
Which locales are installed on your box?
English as per setting at system install time.
Which English? Only one?
A locale includes things other than just language, so one might have multiple English locales installed. One one current box I happen to have 27 English locales.
try the 'locale' command. On my system "locale -a" will list all public locales.
What LANG/LANGUAGE environment variables do you have set to begin with?
LANG=en_GB.UTF-8 LANGUAGE=en_GB:en
Ahhh... that shows interesting things. Even more interesting is that your LANG setting includes UTF-8, but your LANGUAGE setting does not. That can be the cause of some subtle gotchas under certain circumstances.
Not really. In order to change documentation we want to be sure we're telling people the proper things, not work-arounds and kludges.
Not workarounds? Your are either kidding or opposing my efforts to be helpful on principle or you can't control your control attitude. A bad joke in each case.
No, not a bad joke at all.
Unless one knows *why* a given workaround is needed and *how* it actually is doing something, then it runs the risk of being dangerous. Or cause of more subtle problems than it is worth.
For example, one workaround for Win32 users trying to get English to come up is to go a delete all other translations from their hard drive. This works, but should be more of a last resort. Adding a LANG/ LANGUAGE environment variable setting is a much better solution for those who it works for. In this case, the proper 'fix' is to change the libs (glib and such) to interact properly with the Win32 NLS APIs. Knowing that also tells us that in this specific case a workaround is needed (since we know a core lib is deficient and we can't be calling it in a different manner to get better results), but that we should try to stick to the least invasive/destructive method.
Another somewhat related issue was with file handling of non-ASCII (that is, over 127) characters in filenames. The workaround was to only use pure ASCII in names. However, once the issue was examined, the problems became clear and the simple solution of switching to proper interaction with the Win32 host OS was the proper 'fix' and got things working correctly. So, yes, sometimes a workaround is needed, but usually it's best to investigate why and people gain much more from having a good solution.
And... back to your specific case... it seems that in being 'broken' for your test case Inkscape happened to work the same as other standard programs on your system. In that case, it could be that the proper solution is to install the locale support for your target languages and then perhaps all stock programs and Inkscape will all work correctly. In other words, if Inkscape is behaving in the same manner as standard programs installed on your OS, then the problem might actually lie with your OS config, and not with Inkscape. (And just because there are ways to tickle Inkscape to do other things doesn't in and of itself mean that is the best course of action)