On Sat, 7 Jan 2006, Bob Jamison wrote:

Date: Sat, 07 Jan 2006 08:47:06 -0600 From: Bob Jamison <rwjj@...127...> To: robgebhart@...1139..., inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] WEBFORM Language

Robert GEBHART wrote:

...

Message from Inkscape submission form

Please note, that the submitter may not read this list. CC your answer to the submitter

name: Robert GEBHART email: robgebhart@...1139...

submitted the following:

Enter your message or news here. Is Inkscape available to run in English? I have no trouble using it in German -- it's just thar my Windows XP is in English, and so is all the Inkscape supportive material that I see. Thanks! RG

You can easily change the language that Inkscape normally runs on your computer by setting the LANG variable to something else. Occasionally I run it in Russian or Italian just for fun. Try putting this in a batch file in your Inkscape directory:

set LANG=en_US inkscape.exe

Another approach is to move/remove all the language files (.po) and then the default (American) text strings will show through.

I've seen this kind of request before but I continue to be a little surprised by how many people want to use programs in English without changing the the rest of their system.

If you are having problems with the translation please do file requests and suggestions as to how wording to be improved. If things are difficult to understand in other languages it might help indicated places where things could be made easier to understand, adn therefore easier to translate in a clear way.

Thanks for using Inkscape

Sincerely

Alan Horkan

On Sat, 7 Jan 2006, Jon A. Cruz wrote:

Date: Sat, 7 Jan 2006 21:38:20 -0800 From: Jon A. Cruz <jon@...18...> To: Alan Horkan <horkana@...44...> Cc: robgebhart@...1139..., Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] WEBFORM Language

On Jan 7, 2006, at 7:51 PM, Alan Horkan wrote:

...

I've seen this kind of request before but I continue to be a little surprised by how many people want to use programs in English without changing the the rest of their system.

If you read his request, you'll see that his Windows XP *is* in English, but it seems that Inkscape is showing up in German instead of English. I think this is just another case where GTK+ apps do not interoperate properly with Win32 locale settings. It's a known issue, and mainly works correctly for those who tweak settings (environment variables, etc) on their Windows systems to mirror Unix practices.

So it would appear that the user *did* change the rest of their system, but Inkscape didn't properly follow.

With the address ending in .ch I assummed he was in Switzerland. If his locale was set to en-CH it could have some interesting results.

I wouldn't be suprised if GTK wasn't very smart about locales like en-CH or other unusual combinations. I'm not sure why but I have a feeling the locales strings are crudely checked against a list of matching strings (xx-XX or xx_XX) rather than broken down into language (xx) and region (XX).

(I use en-IE but more often than not I get American spellings even when I'd expect things to fallback to British ones. I know things could/should be better but I've only ever had the patience to scratch the surface of it. Maybe someday I'll take a proverbial crowbar to glib and see if I can improve the fallbacks.)

In his post, he seems to have indicated a good reason to want to run Inkscape in English

To be clear I dont question many users have valid reasons for wanting to change the locale but given how often this problem comes up I wonder if there might be a better way to tackle it, but that isn't Inkscapes problem.

Sincerely

Alan Horkan

Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/

You can easily change the language that Inkscape normally runs on your computer by setting the LANG variable to something else. Occasionally I run it in Russian or Italian just for fun. Try putting this in a batch file in your Inkscape directory:

set LANG=en_US inkscape.exe

And I keep telling people that it's not LANG but LANGUAGE that sets application-wide language... (not locale)

ralf

On Jan 8, 2006, at 1:13 AM, Ralf Stephan wrote:

And I keep telling people that it's not LANG but LANGUAGE that sets application-wide language... (not locale)

Where does that work, and where is that documented?

'LANG' is all throughout standard man pages on many OS's, but I've not yet seen 'LANGUAGE'. Explicit documentation on it would probably help understand the subtleties. (last I saw, LANGUAGE was an application-specific thing that they could treat however they liked)

(Also... at the moment, LANG and LANGUAGE both fail to make any difference on my OS X setup, but that's probably a different issue)

On Jan 9, 2006, at 12:34 AM, Ralf Stephan wrote:

...

Where does that work, and where is that documented?

Where it works: here on Ubuntu, when I say export LANG=de and start inkscape, I get (inkscape:8421): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. with no result. But using export LANGUAGE=de (after reboot or on another terminal) all is working expected.

Also ask ACSpike or Ted Gould: they could solve their problems only with LANGUAGE.

It sounds only so-so as far as a 'fix' goes.

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) Which locales are installed on your box? What LANG/LANGUAGE environment variables do you have set to begin with?

I don't care about documentation of it but google gave me http://www.gnu.org/software/gettext/manual/html_node/gettext_155.html wherefrom it seems that it has something to do with priority?

Yes, I had seen the same. But I'd also seen where its purpose is slightly different and is intended to hold a list of possible choices, instead of a single one. Then there are other references that state it's application specific.

I hope this setles the matter. Please also update inkscape's documentation in this regard.

Not really. In order to change documentation we want to be sure we're telling people the proper things, not work-arounds and kludges.

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)

Ralf Stephan <ralf@...748...> writes:

...

Where does that work, and where is that documented?

Where it works: here on Ubuntu, when I say export LANG=de and start inkscape, I get (inkscape:8421): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. with no result. But using export LANGUAGE=de (after reboot or on another terminal) all is working expected.

Try one of

LANG=de_DE inkscape LANG=de_DE.UTF-8 inkscape

The available locales are listed in

/etc/locale.gen (Breezy and before) /var/lib/locales/supported.d/* (Dapper)

Cheers, Colin

On Jan 10, 2006, at 2:02 AM, Ralf Stephan wrote:

But this makes sense. I don't want a locale, I just want to switch to a different application language, of which I happen to know that it's installed. I fail to see that anything is wrong with the behaviour of my system, and it does what I want.

Ahhh... but there's the problem.

This is the post-DOS era. Most developers count on the OS doing at least some of the heavy lifting. And most users who want an app to run in a different language want it to actually be functional. Usually that means counting on the OS or standard libs to do their fair share, and not re-implementing that in the application code. In turn, most who've implemented it have cleaned things up to work for many different languages. So when an applications wants to do things in a particular language, they make a standard call and count on the system to handle things for them.

In turn, these system libraries have often broken things down to be data-driven and/or extendible at runtime. They often then collect up the bits needed to run in a certain way and call that a 'locale'.

I certainly don't want to system-wide install the de locale just to have a peek at the German inkscape translation.

Then you can't count on anything working. Though there is a very minimal subset of things that might work, getting an application to "come up in a certain language" usually needs support from the OS and underlying libs. Collation is one of the first things that poses a problem. If any sort of list is to be presented as part of a UI, programs *should* be doing things properly, which in turn most often requires a given language be configured.

Now, if the only thing you want is to peek at the translations, there are quite a few tools out there to do so (Inkscape uses standard things for that), and you can run any of those. On the other hand, if you want the application to actually come up using a specific language for its user interface, then you're at the point of needing to have proper support installed or just live with things being half broken.

Remember, at a minimum you need the OS and Libs to have fonts installed that have the glyphs needed for the target language. And then the OS and libs need to be able to access those glyphs (not always an easy thing even just a few years ago). Luckily, if the language is German and your normal language is English, then you probably have most German glyphs installed already. But if you wanted to look at Japanese, it just wouldn't work. Unfortunately, though fonts themselves have now become easy to install user-side, "language" support itself has not, as most who have need of seeing things in a different language also usually have need of also being able to list things and work on them, and thus begrudge them a tiny directory or .NLS file.