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.
Related
I've tried to install Monodevelop-Stable on Arch-Based Linux ( Manjaro ) and i'd fault 3 times, it wasn`t possible to build from Github sources or from AUR or Flatpak, so i decided to use monodevelop-stable-bin also from AUR, but when i tried to run my app , i got this problem
"$(MSBuildBinPath)\Microsoft.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk (MSB4019)
Another words:
"MonoDevelop/7.0/MSBuild/2472_1/Microsoft.Csharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk (MSB4019)
But i have in my directory:
Microsoft.Csharp.Crosstargetting.targets
Notice , that this answer also wasn`t helpful:
this one
Question is indeed so popular on the internet , but i still haven`t found an answer , and i need some help
I have the same problem, I talked a bit more in detail in this answer, but the short of it is that, for now, it seems that there is no way to use Monodevelop on Arch based systems.
I recommend using a Ubuntu based distro for programming (there are many other similar problems with Arch). There Monodevelop should work just fine.
Of course, you can try to use other IDEs, like JetBrains Rider (I haven't personally tested it) or just use text editors with appropriate extensions, like VSCode or Atom.
I've had a break from programming the last two years and want to start up again. Right now I'm using a Windows computer, but my work and compiler is on my Linux computer.
My question is:
Is it possible to move my entire emacs work environment from Ubuntu to Windows 10? I did some changes in emacs back in the days that I got used to and would love to continue like that on my Windows computer.
Briefly...
The most important things to copy are your ~/.emacs.d directory and your init file (see C-hig (emacs)Init File for the different filenames this might have, or check with C-hv user-init-file).
See C-hig (emacs)Windows HOME regarding where the .emacs.d directory should live on your Windows system.
Note the comments in that Info node on the site-lisp directory as well, in case you've been using elisp libraries in there (possibly without realising), as they can form part of your Emacs configuration as well.
Any byte-compiled elisp (.elc files) should remain compatible so long as you're moving to an equal-or-newer version of Emacs (which sounds likely in this case). Natuarally things do change between releases, though, and it's possible to encounter incompatibilities when upgrading, but I wouldn't worry about that in advance -- try the latest version first, and if you run into problems that you can't solve (which shouldn't be very likely), you can always install the version of Emacs you were originally using.
I want to view some ansi-art on the linux local-console. (my setup:raspberry pi3 / newest raspbian - no x11)
i've tried many different settings in raspi-config, dpkg-reconfigure console-setup, /etc files, environment vars but i had no luck yet. do i need a special pcf font to get it working?
a reliable way to enable it for remote terminals would also be great.
thanks in advance
It depends on what your data uses (see chart). Codes 0..31 are a problem unless you have a program that can map those codes to a printable value (as noted in Why does showconsolefont have different output in tmux?, the showconsolefont program does this mapping of 0..31).
Most of the usable fonts for the Linux console are "psf" fonts: having a header which tells which Unicode values each glyph corresponds to. Using that, along with a known character set (cp437), you could convert the data or "play" it using an application which knows how to do this:
You could convert it using iconv or recode, or
The line-drawing (128..255) could be done using luit in a UTF-8 console.
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.
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.