Localisation for v1.00

[piponazo]

In #527 and #537 we discussed a lot about localisation stuff just before the 0.27 release.

The only missing point (that was not critical for 0.27) was to provide some API function to change the language at run-time. While this is trivial in other translation systems like the one provided by Qt, it seems a bit more challenging with gettext and libintl. The recommended way according to the gettext documentation is to set the environment variable LANGUAGE to the desired value in the application code.

This piece of code seems to work:

#include <libintl.h>
#include <locale.h>

#define _(STRING) gettext(STRING)

#include <cstdio>
#include <cstdlib>

int main()
{
  // Setting the i18n environment
  setlocale (LC_ALL, "");
  bindtextdomain ("hello", "/usr/share/locale/");
  textdomain ("hello");

  // Example of i18n usage
  printf(_("Hello World\n"));

  setenv("LANGUAGE", "es_ES", 1);

  printf(_("Hello World\n"));

  return EXIT_SUCCESS;
}

--------
13:30 $ ./app 
Hello World
Hola Mundo

The idea would be to have something like Exiv2::loadLocalisation() maybe with a string argument to indicate the language and being able to switch languages at run time.

[phako]

Is there any valid use-case for changing localisation during runtime?

[D4N]

Jens Georg [email protected] writes:

Is there any valid use-case for changing localisation during runtime?

Certainly, you wouldn't want having to recompile exiv2 only because you changed the language of digikam/GNOME/KDE.

[phako]

There is no need to recompile the application, under a normal desktop, LANGUAGE or the corresponding LC_* are set by the DE, you just need to restart the application to change to the "new" language.

i.e.

        setlocale (LC_ALL, "");
        bindtextdomain (GETTEXT_PACKAGE, LOCALEDIR);
        bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");
        textdomain (GETTEXT_PACKAGE);

is usually all you need, together with a helper header that contains the definitions for _() and, ideally, N_() for static strings.

[D4N]

Jens Georg [email protected] writes:

There is no need to recompile the application, under a normal desktop, LANGUAGE or the corresponding LC_* are set by the DE, you just need to restart the application to change to the "new" language.

Ah, didn't know that.

But I think you've answered the question yourself: if you want to change the language and not having to restart the application. (Not really relevant for the exiv2 CLI, but could be useful for a desktop App that uses libexiv2).

[clanmills]

Yes. I've got this on the list for test issues for v1.00 #1550.

[jim-easterbrook]

I've been having some fun localising my Python interface to libexiv2 (v0.26 to 0.27.5) and it seems here is as good a place as any to report my findings. In most cases I use copies of the .mo files, installed in the Python packages directory. The trick to getting this to work was to call Exiv2::exvGettext to initialise it before calling bindtextdomain to set my own path.

The next problem was when using the system installed .mo files (in /usr/share/locale in my case). libexiv2's initialisation computes localeDir relative to the executable path, which is fine for the exiv2 tool but less useful when libexiv2 is used by executables in a different directory. I overcame this by calling bindtextdomain without a dirname to get the system default, then setting it as above.

Could I suggest that libexiv2's initialisation tries the system default path (on those systems that have one) as well as the one computed from the executable path and chooses whichever actually has the .mo files.