I'm working on a Qt application that used to be a KDE application. In the old days, I just had to use some syntax like:
KDELANG=de ./my_app
That ran my_app in German, and only my_app. It might not have been KDELANG, but it was some environment variable like that.
I've spent a ridiculous amount of time trying to coax this answer out of Google, and I give up. There must be some way to run a Qt (4.5 if that matters) application in some other language without switching over my entire locale to get there.
I tried it with the KDE game Kolf and
(export LANG=de_DE.UTF-8; kolf)
(export LANG=en_US.UTF-8; kolf)
did the trick for me to switch it into German or English.
I verified it with the QT application qtparted
(export LANG=de_DE.UTF-8; qtparted)
also comes up in German on my English desktop. Obviously I had to install the German language files to get the translated app working.
Just like any other Linux application, Qt applications follow a rather convoluted way how the application message locale is selected: environment variable LANGUAGE is given preference over LC_ALL, LC_ALL over LC_MESSAGES, LC_MESSAGES over LANG (details).
So any one of the following commands works to change the application's locale for messages, as returned by QLocale::system().name():
LANGUAGE=de ./my_app
LANGUAGE= LC_ALL=de ./my_app
LANGUAGE= LC_ALL= LC_MESSAGES=de ./my_app
LANGUAGE= LC_ALL= LC_MESSAGES= LANG=de ./my_app
Notes:
I tested this with Qt 5.12 under Lubuntu 19.10 (means, using the LXQt desktop).
It is entirely up to the Qt application how to adapt to the application locale as returned by QLocale::system(). It may not evaluate QLocale::system() at all, or fail to find its translation files etc..
You can also give the above commands in the form env LANGUAGE=de ./application. The env command has some more options to control which environment its child process will see.
The locale values specified in the environment variables (here de) do not have to correspond to any locale that is installed system-wide and listed in locale -a.
When specifying only a language (like de), Qt will automatically expand it with a default country and return that in QLocale::system().name(), for example de_DE.
When specifying a wrong value (such as xy), Qt will return the default C locale from QLocale::system().name().
OK, it's a long story, but it turns out the translations are, in fact, busted, and that's the whole underlying problem here. The obvious thing I tried first works fine. Since this isn't KDE, I just used plain:
LANG=de ./my_app
Now that I've fixed the bug in the debugging code (oh, the irony) I can plainly see that the translation files (which do exist) aren't getting loaded. Ah. Alrighty then. Carry on. Nothing to see here.
If you are using plasma desktop, install language package from under System Setting -> locale
and run app as follow : KDE_LANG=fr ./appName
fr represents french, you can choose language of your interest.
Related
There is a ncurses6 originally installed in a user home dir, let's say "/home/test", so a test environment was built over this ncurses path, a lot of (in development) apps were compiled and is working now, depending only of the current HOME env variable.
But, because of a purpose beyond our control, we have to change the user home dir. And now it's anything different from "/home/test".
The external apps and ncurses tools still working, we need just point the libraries with LD_LIBRARY_PATH and use a more specific path like we used before for ncurses tools:
LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But now, after changing the user home dir, we need to point also the terminfo database:
TERMINFO=~/bin/ncurses-6.0/share/terminfo LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But, is there any way to make the TERMINFO database path permanent without recompiling and reinstalling the ncurses ? Is it hard code in ncurses during compilation ?
The default values are compiled-in. You can override those with environment variables (TERMINFO is standard, TERMINFO_DIRS is an extension). That's not new with ncurses6 (it predates ncurses4, twenty years ago).
The most practical "permanent" change would be to put the overrides in your shell initialization.
It's possible to modify an ELF binary (there's no checksums), but the resulting path couldn't be longer. It could be shorter, since the strings are null-terminated. Since your example adds to the path, that wouldn't work for you, anyway.
I'm trying to make a bash script that behaves differently based on the terminal program that someone is using (Putty, mobaxterm, etc). Is there any way to retrieve this kind of information from a bash script?
I was searching around online but I was not able to find anything (or I'm just wording it incorrectly, which could be a distinct possibility).
thank you
You need to understand that these are terminal emulators. There is a simple, crude identification function for (most?) modern line terminals (now that's an oxymoron!) but it will return something like vt102 or xterm i.e. whatever the emulator is emulating; not the identity of the program performing this emulation. Incidentally, this is usually used when the session is initiated, and reflected in the value of the $TERM environment variable.
The common way to do this is the environment variable TERM. Try
echo $TERM
That should output the terminal emulator's type, indicating its capabilities. Often, though not always, the value of TERM will be the name of the terminal emulator. For example, xterm may set TERM to xterm, or to xterm-color, depending on configuration.
Note that the user can change this variable, so it may contain something completely different.
That said, if you want to do fancy things with the terminal from a script, you don't need to build support for different terminals by hand. There are various libraries that offer all the usual functions (clear terminal, resize window, change font etc.). The most popular one is terminfo; there are various packages that build on terminfo.
I've been trying to change GNUCash UI language as it's described here: Link
...by running the following command in the terminal:
LANGUAGE=ar_SY LANG=ar_SY gnucash
But it returned the following:
The locale defined in the environment isn't supported. Falling back to
the 'C' (US English) locale
Any solution please?
I think there must be a general way to run a GTK application with a specific language.
tl;dr:
$ LANGUAGE=nl_NL.UTF-8 LANG=nl_NL.UTF-8 LC_ALL=nl_NL.UTF-8 gnucash
(change into the locale codes of your choice)
I know I'm a bit late to the game, but I was also running into issues with languages.
As an extra, I really want to keep my system locale at en_C.UTF-8 / C because the Dutch language prescribes a comma for decimal separator and completely messes with day-to-day programming tasks (especially in LibreOffice). So I need GnuCash to run in 'translation mode'.
Anyway, running
$ LANGUAGE=nl_NL.UTF-8 LANG=nl_NL.UTF-8 gnucash
did not work for me either (just runs in English). Then, I found this link (accessed on Aug 19, 2015) about locale settings in GnuCash.
In the section 'OS dependend tweaking', at the end of the 'Changing the Language on Linux' sub-section, they hinted to also specify the LC_ALL environment variable:
If you can get the graphical interface in the correct language , but you can't get the accounts in the desired locale, you have to add the LC_ALL variable, like in the following example:
LANG=it_IT.UTF-8 LANGUAGE=it_IT.UTF8 LC_ALL=it_IT.UTF-8 gnucash
This does the trick for me:
$ LANGUAGE=nl_NL.UTF-8 LANG=nl_NL.UTF-8 LC_ALL=nl_NL.UTF-8 gnucash
Perhaps this might work for you:
$ LANGUAGE=ar_SY LANG=ar_SY LC_ALL=ar_SY gnucash
There might be a problem in the .po translation files. In that file, the direction should be defined according to this article.
If anybody is interested, a solution that can be used on Mac OS X (Yosemite) is to add these lines in Gnucash (in this case for Italian):
export LANG=it_IT.UTF-8
export LANGUAGE=it_IT.UTF-8
export LC_ALL=it_IT.UTF-8
Following the advice on the above metioned link, these three lines should be added just above this part:
$EXEC "$bundle_contents/MacOS/$name-bin" $* $EXTRA_ARGS
Gnucash is an executable file located inside Gnucash.app that is present in your Applications folder (you should see Gnucash without .app extension). If you select it and in the dropdown menu you click on "Show Package Contents", you will find the Gnucash executable file in /Contents/MacOS folder. You can then modify the file with your preferred text editor.
This is a very specific issue but, based on what I've seen online, a surprisingly common one. I'm on a rather old version of Scientific Linux 5, which is based on Red Hat. I use vim with the Solarized vim color scheme, and my TERM environment variable is usually set to xterm-256color. This worked fine until I started using tmux. On non-empty lines in vim, the color scheme only extended to the end of the document's characters, the remaining whitespace being plain back background.
The stock fix for this in online guides is to set TERM='screen-256color'. However, upon doing this I would get the ominous warning: WARNING: terminal is not fully functional - (press RETURN), when trying to do innocuous things like read man pages. However, everything seemed to be working fine, and the Solarized bug was fixed.
I've found a functional fix - using TERM='xterm-256color' by default and adding this line to my .bashrc:
alias v='function _vim(){ TERM='screen-256color'; vim $1; TERM='xterm-256color'; };_vim'
but it seems like a hack. Anecdotally, I've also set alias tmux='tmux -2', which is a common suggestion with color-scheme-related issues.
I also know that the terminfo screen-256color is available on my machine.
So, really, the main befuddling thing is that, when using TERM='screen-256color', I'm getting those warnings about full functionality when nothing seems to be wrong.
I don't have root access, so ideally any fix suggestions wouldn't need that.
EDIT: I should mention that TERM='screen-256color-bce' gave the same problems as TERM='screen-256color'.
The user's environment is not specified, but likely using bash and less (Scientific Linux 5 does not have more).
The package list on Scientific Linux 5's ftp site, shows ncurses-5.5-24.20060715.src.rpm, which does not include screen-256color (it was added to ncurses in October 2006). That system might have the later terminal database by some post-install change.
An application using termcap would not see this terminal description. Scientific Linux's bash and less programs could have used termcap rather than terminfo. A quick check of the changelog for bash-3.2-21.el5 says
* Fri Feb 1 2008 Miroslav Lichvar <mlichvar#redhat.com> - 3.2-21
- Link with libtermcap
On some systems, a missing termcap entry will cause a warning. But with Scientific Linux 5, the given warning message comes from less, which checks its terminal description (using the termcap interface), to ensure that it can clear the remainder of the current line, the remainder of the screen and the entire screen.
In Scientific Linux 5, the less package is built with ncurses. A problem with less using TERM=screen-256color would be one of these possibilities
the screen-256color entry is not really installed, or
there is some problem with the termcap interface provided by ncurses.
While there were ongoing performance-fixes for the screen program around this time, the former seems the more likely, as seen in this discussion of a poorly-written entry for screen-256color in early 2006: Re: screen-256color terminfo entry?. What I get from reading this is that there was some poorly-written terminal description (not part of ncurses) which produced the problem. By the time it was proposed for inclusion in ncurses (October 2006), the problem had been repaired. In any case, it would have been corrected at that point.
I'm using wine emulator on linux (SliTaz 4.0) and i want to change the wine locale so that the dialogs and messages are displayed in Japanese.
I found this tool http://code.google.com/p/winelocale/ which seems to do the job but I couldn't find a download link anywhere and could not contact the author, so does anybody know how to do that please?
I am not actually certain if this tool (WINELocale) will actually work, so I am open to any suggestions to change the locale of WINE to Japanese.
Thanks
in Ubuntu 13.04 i had to use
LANG="ja_JP.UTF8" wine YourBinary.exe
LC_ALL="ja_JP"
another example to do it ;)
I had to edit /etc/locale.gen and un-comment these two lines:
ja_JP.EUC-JP EUC-JP
ja_JP.UTF-8 UTF-8
After that, I ran locale-gen (as root), and when it finished generating locales simply setting LANG=ja_JP.utf8 worked. The key was generating locale information first, it seems.
Also, if you haven't got any, you'll need to install a japanese font on your system.
My distribution is Debian Sid, if anyone wonders, but I believe this is also what you need to do in Arch and Ubuntu and most other distros.
export LANG="ja_JP"
after this wine changes its locale to japanese, altough remember to install fonts for japanese, otherwise it will look like garbage!
if u close the terminal, the settings for the locale will be lost.
a cleaner way would be:
LANG="ja_JP" winecfg
as example, so only this "process (and childs)" will be affected, remember to use it for wine too like this:
LANG="ja_JP" wine YourBinary.exe
You can also change the locale for all applications via Registry, by setting the LC_ALL environment variable in HKEY_CURRENT_USER\Environment (Right click -> New -> String value).
As others have said, export LANG="ja_JP" should work.
But make sure you have that locale installed, or it won't. How to install it depends on your distribution, but to check whether it is available or not, you can simply run locale -a in a terminal and it will list the locales available for use.
LANG=ja_JP doesn't seem default to utf8 on my machine. (Maybe because it's lower in locale.gen?)
LANG=ja_JP.UTF-8 works.