Translation not loaded without running make install

[gunchleoc]

When I play Enigma, all strings show in English, although they have been translated. When I run make install, it works. It would be nice not to have to install though.

Here's a screenshot with language set to gd and "Options" translated in po/gd.gmo as shown by Virtaal:

Enigma Version: HEAD detached at 1.30-alpha, self-compiled
OS: Linux Mint 20 Mate (Ubuntu 20.04-based)

Configure summary:

   Source directory:    .
   Installation prefix: /usr/local
   C++ compiler:        g++ -g -O2 -DENABLE_ASSERT -g -DCXXLUA
   Libraries:           -lcurl -lxerces-c -lpng -ldl 
   Linker options:      
   Languages:		de fr nl it es sv ru hu pt fi uk be el pl cs gd hr sk da
   System enet:		no

[alochmann]

Yes, you are right, thank you for pointing at this issue. It has been this way for so long that I did not even recognize it as the bug it is anymore.

[alochmann]

As a first aid, I added support for different localization paths via command line (commit 110abed ); in conjunction with ./configure you can now install the locales (mo-files) in a separate directory, so you don't have to be logged in as super user:

Do once:
./configure localedir='/absolute/path/locale'

Then each time you want to check translations:
cd po
make install

locales will then be installed to /absolute/path/locale. Choose a directory you have the rights to, like /home/me/enigma/locale or something like this. Start Enigma from the console with

cd ..
./enigma --l10n /absolute/path/locale

You may use a relative path for enigma, but ./configure needs an absolute path.
Unfortunately, you'll have to use the command line argument each time; I'm working on a GUI-solution however, adding the l10n-path as an option in the options menu soon.

I hope this helps a little bit?

Switching between different languages/locales on Linux is problematic as ever. The best solution here is to update gettext/intl in Enigma's source, this will need some days of work and testing. There seems to be a "setlocale" command in gettext since 2009 ... :-)

[gunchleoc]

Thanks for looking into this. I think it's a bit clunky to have it as an option. I don't have any experience with intltool projects though. Maybe you could have a look at other games, e.g. Battle for Wesnoth, 0 AD or Widelands, so that you don't have to reinvent the wheel?

This is the Widelands class that does the setlocale thing, it's cross-platform: https://github.com/widelands/widelands/blob/master/src/base/i18n.cc Main calling point is in https://github.com/widelands/widelands/blob/e3c178b1f93b6afadb18b994b58c03fcebdc5a53/src/wlapplication.cc#L967
We use a different build system though (shell script + CMake).

[alochmann]

This is exactly what I have been doing for the past three days now: Studying the code of other games, and of course of setlocale itself. The results I have till now:

• Supertux, 0 A.D. and several others use tinygettext, a library written by one of Supertux' authors to interpret po-files.
• ScummVM uses a self-built solution to read po-files.
• Simutrans doesn't use po at all, but an html-formatted solution.
• Inkscape is based on glib, which provides wrappers around gettext/libintl. It uses setlocale for numeric values only, and leaves translation of messages to glib, I guess.
• Widelands does use gettext/libintl, and a comment says that its code is inspired by Wesnoth's. I could not yet understand why their code works and ours does not. This is why I'm looking into setlocale right now. Of course there are differences, but I want to understand the code before pasting it into Enigma's. I am particularly puzzled by this line in Widelands' base/i18n.cpp:
  SETLOCALE(LC_MESSAGES, "en_US.utf8"); // set locale according to the env. variables
  How could this possibly lead to loading any other locales than English? I must be missing something ...

[alochmann]

I stand corrected: Wesnoth does not use the standard gettext (like we do), but instead invokes gettext from another library called boost.

I tried to replicate Widelands' solution, but failed. I do not understand where there might be a difference ... except for one thing: Wideland calls upon another sublibrary of boost, which is not directly connected to locales, but which might eventually drag boost's own gettext back in. Right now, this is the only way I can explain how Wideland is able to show translations other than those supported by the system.

I now see two options for us to proceed; an easy one, and a right one.

The easy option would be to just show "Your operating system seems not to support language X. Please try to install it first." whenever a language is selected that is not supported.

The right option would be to implement one of the "larger" solutions the other software projects make use of. I would prefer to keep it as small as possible, and therefore tend to tinygettext or even ScummVM's code, instead of including glib or boost.

The easy option is fast, reasonable, and would not further inflate Enigma's file size. And ... well ... I guess, most users would not find any use in a language that is not already installed on their system anyway ... please correct me, maybe I am missing something. This bug only affects Linux, and only developers like us, who need to see all languages working, to adapt button sizes etc.

You see, I tend to the easy solution, instead of burying another week into this. What do you think? How important is this to you? (If it is important, I will do it.)