GNOME Bugzilla – Bug 576910
Show 'Language' setting languages in native language
Last modified: 2013-07-05 14:46:00 UTC
GIMP lacks the setting for changing language, but it would be convenient to change interface language from GIMP itself without resolving to system-dependent hacks.
The code for that is even almost there already. Perhaps I can find the time to finish this for the 2.8 release.
These are good news. Thanks.
*** Bug 596961 has been marked as a duplicate of this bug. ***
I have pushed some changes to the git repository now that implement the basic functionality. There are still some things in the UI that should be improved and I hope that I will find the time to finish this. The current state however is fully functional and it certainly helps if it can already get some testing.
Sven, can you describe what is still left to do?
The languages should be listed each in their native language. Otherwise a user who has changed the language setting incorrectly will have a hard time to set it to his/her language. So instead of having all languages translated to the currently set locale, the language chooser in the Preferences dialog should show "Deutsch, English, Français, ...".
*** Bug 613335 has been marked as a duplicate of this bug. ***
I don't think you need to spend more time on this for 2.8, the language codes are untranslated and can be used to find the native language, whatever other language is selected. Moving to Future milestone. We can resurrect it when we have enough time or when we get enough bug reports about it.
http://sourceforge.net/userapps/mediawiki/alex-sh/index.php?title=Downloads GTK+ Runtime Environment provides an excellent tool for language selection. Why GIMP cannot use that tool in its own preferences dialogue?
*** Bug 663268 has been marked as a duplicate of this bug. ***
*** Bug 676958 has been marked as a duplicate of this bug. ***
Created attachment 248275 [details] [review] Show Language settings in itself Hey, this one looked kind of fast to do, so I took on myself to patch this. Each lang is not translated in itself. Waiting for review. :-)
s/not/now
Looks like this would only work if LANGUAGE is set? We can't use getenv() to figure that, we have to use API (I don't have LANGUAGE set here for example).
Why would it work only if LANGUAGE is set? I have tried with LANGUAGE being set and not in my environment. Did you try and it failed? Also what do you mean "we have to use API"? In any case, LANGUAGE is apparently the way to go, being the primary value gettext uses to determine the language to translate to. Cf. http://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html Also this was already what we do to handle translation as far as I can see. See app/language.c
Ehm, I was just reading the code ;) Will shut up and try the patch instead...
Hey Mitch, I'll post here because my new timezone has me having to go to bed soon. Even more to the other side of the world from you than when I was in Japan! :-) Anyway here is our unfinished discussion (apparently you went to work indeed): 17:39 < mitch_> Jehan_Ze1armot: no i just read the code ;) 17:40 < mitch_> back to work here, sorry 17:48 < mitch_> Jehan_Ze1armot: shit works perfectly :) 17:48 < mitch_> Jehan_Ze1armot: do you think we should use the same for the text tool? 17:48 < mitch_> i'm not so sure 17:54 < Jehan_Ze1armot> The text tool? 17:55 < Jehan_Ze1armot> mitch_: do we need to localize things with different lang in the text tool? 17:55 < Jehan_Ze1armot> I may be missing some context here. :-) So does that mean I push this piece of code? And what other text tool-related topic are you talking about which could involve such similar code?
About the text tool, for memory, I copy here the result of the IRC discussion: ----- 19:29 < mitch_> Jehan_Ze1armot: text tool options, at the bottom [...] 19:35 < mitch_> guts feeling is: don't translate in the tool options 19:35 < mitch_> you might be pasting foreign text and just need to set the language to get word breaking right or whatever ----- Conclusion: we leave it as is. :-) And commit on master: commit f6dcde1ee66fda4dfdc063022c4d2e901adb9a71 Author: Jehan <jehan@girinstud.io> Date: Wed Jul 3 11:58:16 2013 +0900 Bug 576910: Show 'Language' setting languages in native language The trick works by temporarily resetting the current locale to localize each language label in its own lang. One exception is English that is equivalent to the "C" code, and we make also some special exception for Chinese where there are very different variant depending on the region. I also ensure the "System Language" string is translated in whatever language is the system actually set to.
Created attachment 248407 [details] Too wide preferences window caused by locale dropdown Since the locale dropdown now lists all locale environment variables the preferences window is now around 2300px wide when you have all the variables set.
Hum weird. I only display the value of LC_ALL there (the system locale). Not all the env variables at all. On my computer, I don't have such a display at all. What is the OS you have this display on please? Maybe this is OS-specific.
Hum weird. I only display the value of LC_ALL there (the system locale). Not all the locale env variables at all. On my computer, I don't have such a display at all. What is the OS you have this display on please? Maybe this is OS-specific.
And also what is the output of `echo $LC_ALL` on a terminal? Because if you have this whole output of all the locale variables there too, that's not how is supposed to be configured LC_ALL (at least not on a UNIX). P.S.: sorry for the previous double post.
My LC_ALL is empty since there isn't one locale that has both English text, ISO 8601 time format, and Finnish everything else. Mixing different locales for different purposes is quite valid. Here's the content of my /etc/default/locale: LANG="en_DK.UTF-8" LC_PAPER="fi_FI.UTF-8" LC_MEASUREMENT="fi_FI.UTF-8" LC_NUMERIC="fi_FI.UTF-8" LC_MONETARY="fi_FI.UTF-8" LC_TIME="en_DK.UTF-8" LC_NAME="fi_FI.UTF-8" LC_ADDRESS="fi_FI.UTF-8" LC_TELEPHONE="fi_FI.UTF-8" LC_IDENTIFICATION="en_DK.UTF-8" LC_ALL=""
Well I didn't say anything about mixing locales. Of course that's not a problem, neither in general nor for GIMP. That's what these env variables are for. I notice though that some of your locales are different from what is shown in your screenshot (for instance LC_NUMERIC). Not that I know why. Also you did not answer me: what is your OS? Obviously it looks like a UNIX (path with slashes). But which one?
Yes I noticed that something had generated a ~/.pam_environment which overrode some of the locale settings. This is on Linux.
Well I have no idea what's the problem and I don't really want to spend too much time on it. I thought it was a nice idea to show the locale for the system language so that you can choose it knowing what you'll get. In any case, your output value is definitely something wrong, so I don't want to process this kind of thing. I'll just have to think of something else. So I propose either: 1/ to remove this [locale] part for the System Language (anyway we can assume that most users would probably know their own locale). 2/ to show some controlled value. For instance, if we can look up the localized lang name from the locale, then we display the lang name. Otherwise not. For instance: "System Language (English)". That's not that consistent with the other langs, but anyway the System Lang is a particular item in the list from the start, and at least lang names are controlled values (we can't have anything crazy in there). Both are quite easy fixes I can do. P.S.: I've lived for a year in Denmark (Ålborg!), so I know English is really well spoken by anyone over there; but I had no idea there was an official subcode for Denmark English. Funny.
I would suggest only searching LANGUAGE, LANG, and LC_ALL in that order until one is found and then list only that one. If none of those exist then just say System language.
I can't search for LANGUAGE. This is the way we are able to localize GIMP differently from how the user set one's system actually, by setting LANGUAGE to another value (hence force gettext to localize in this other lang). So LANGUAGE at this point of the program may not be the original system one. Anyway maybe let's just forget about this. I went overboard by adding this locale value to the system lang. That was unnecessary and not asked in the current report. I will just revert this part and it will just say "System Language" (localized in itself if possible still). How it that?
That sounds good, go ahead :)
commit fc873cd6c338be329c13e8b5da5cee1ad8a700a5 Author: Jehan <jehan@girinstud.io> Date: Fri Jul 5 23:38:10 2013 +0900 Bug 576910: Show 'Language' setting languages in native language Showing the current system locale between square brackets in the "System Language" item was causing some issues on some systems (showing some very weird and long value). This was mostly a cosmetic change anyway with limited gain. Let's just get rid of it. The main part of the feature (each language displayed in itself) is still there.