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.
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 have an interest in playing and fuxing with prolog, I have installed the swi-prolog and added the repository, just in case anyone is interested on which one commands I used:
% sudo apt-add-repository ppa:swi-prolog/stable
% sudo apt-get update
% sudo apt-get install swi-prolog
How do I actually begin to write prolog codes on my linux machine? for my regular programming I use VIM to write/edit/debug and terminal to compile. Can I use vim to write prolog? How do i compile or use the prolog interpreter(i think that is what it is called)?
Yes, you can use any text editor, incl. VIM. Once you have written a Prolog source file, say, file.pl, you can load it into SWI-Prolog like so:
swipl -s file.pl
This will compile your file and take you to an interactive shell where you can then ask queries against the definitions in your file.
If you want to use your Prolog program in batch mode, you can use:
swipl -s file.pl -t goal
where goal is the goal/query you want to evaluate. Note that in this case you won't be getting the option to ask for alternative solutions.
On Ubunutu, I started off using emacs, which at least does syntax highlighting:
http://www.swi-prolog.org/FAQ/GnuEmacs.html
(2 emacs suggestions on that page ^)
But now I use prolog in anger, I use an Eclipse plugin called PDT:
http://sewiki.iai.uni-bonn.de/research/pdt/docs/v2.1/start
Especially useful is the real-time line by line debug and trace, so you can step into, step over individual predicates, monitor variables names etc.. just like an other real IDE you would find in eclipse.
Probably only worth installing if you're going to use it a LOT, since the install is a lot of work, but it's a great IDE.
But if you like your low level editors like VIM, you will have to use the debug and trace tools built into swi-prolog, see:
http://www.swi-prolog.org/pldoc/man?section=debugger
To work out how the strange and beautiful prolog interpreter works, using a tracer of some kind is a must-have.
I personally use gprolog or swipl in the interpreted environment.
So you write facts and rules in a mydb.pl file, and open the interpreter in the same directory.
Once the prompt shows up you can query
['mydb.pl'].
for loading your database. now you can either see the warnings\errors or start querying from inside the prolog interpreter.
buddy I also use vim to edit prolog code, What I personally do is I save my prolog file with the '.pl' extension, and then on the terminal, I use prolog interactive environment to consult my file
e.g:
To initiate a prolog interactive environment just type On terminal:
prolog
Now that you have entered in SWI-prolog you can use 'consult' i.e pre-defined pseudo-predicates allow one to load Prolog code into a running Prolog interpreter:
?- consult("filename.pl")
that's it!
You can use any text editor to write your code. Just make sure to save your code with the .pl extension like fibo.pl.
After that open the terminal and go to the location where you have saved your code.
After that type prolog
After that write the name of your file without .pl extension and end it with . ['fibo']. and press return
Eg - cd /home/student/14917
prolog
['fibo'].
Here fibo.pl is my program name
I use SWI prolog with Sublime Text on mac. Works really nice. In Sublime Text you just hit cmd - B to run the code, and the output appears in a window within Sublime Text. There is a package for it here.
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.
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.
Let's take an example. When I run:
xkbprint $DISPLAY keyboard.ps
what happens in the system? I would like to know how the X really work because I regularly get nasty error reports such as
Fatal Error: Cannot load geometry for /tmp/launch-NawGIk/:0
Exiting
I know that the X11 was designed in a way that it is easy to extend. But how? How does the X11 protocol work? How do the X extensions work?
Whatever happens, I'm pretty certain it isn't going to be what you expect.
The syntax of xkbprint(1) is
$ xkbprint sourcefile destfile
and sourcefile should be a compiled xkb file. $DISPLAY is going to resolve to something like mymachine:0.0, which isn't a very reasonable file name.
Actually, since you're running a Mac, it's echoing exactly what it's seeing: /tmp/launch-NawGIk/:0 is the special OS/X magic to let launchd run X apps. The error message means that it's not finding a geometry or display in that file. Which is no surprise since there is no file named `/tmp/launch-NawGIk/:0
Try reading the man page, and see if you don't have more luck with a compiled .xkm file.
More generally, if you want a starting introduction to X, try this article.
Man xkbprint says:
The xkbprint comman generates a
printable or encapsulated PostScript
description of the XKB keyboard
description specified by source. The
source can be any compiled keymap
(.xkm) file that includes a geometry
description or an X display
specification.
As Charlie Martin pointed out, xkbprint is misusing your $DISPLAY as a file name. Try specifying the display more precisely, to avoid ambiguity with file name. Try man xhost. Maybe passing simple ":0" will fix the problem?