Localisation for v0.27

[clanmills]

I've had an offer from an engineer in Catalonia to deal with localisation of Exiv2 into Catalonian. I hope he'll deal with that for both Exiv2 v0.26 (for digicam) and v0.27.

http://dev.exiv2.org/boards/3/topics/3204

I hope Toni will deal with Localisation for all languages for v0.27.

I've never been involved with localisation in the past when it was built with autotools. I'll review po/CMakeLists.txt and ensure that everything is OK. And I'll update README.md and releasenotes/platform/ReadMe.txt to cover this.

I hope the localization in v0.27 RC2 will be based on v0.26 (including Toni's Catalonian). By v0.27 RC3, I hope to have Toni's new files in all languages.

[cgilles]

I introduced myself translations in Exiv2 10 year ago, and offered the translated file in French.

The conversion of translated PO (program object) to MO (machine object) work as expected with CMake.

The rule to :

• create a PO file in new language from template PO file.
• translate PO files

... are exactly the same than for KDE projects.

New PO file are just need to be add in git repository and installed at compilation time. It just few line of cmake code to patch.

Gilles Caulier

[piponazo]

@cgilles Could you point me to some good tutorial resource about this localization system?

I tried the following:

cmake -DEXIV2_BUILD_PO=ON -DCMAKE_INSTALL_PREFIX=localFolder ../
make
make install

The MO files get generated and installed, but I do not know what do do to switch the language of the application (I guess that I would need to setup some environment variable).

[cgilles]

The variable LOCALE is dedicated for that : https://www.shellhacks.com/linux-define-locale-language-settings/ From a temoinal locale settings you can switch to another one, restart your console application and check the changes. Gilles Le jeu. 8 nov. 2018 à 16:27, Luis Díaz Más <[email protected]> a écrit :

…

@cgilles <https://github.com/cgilles> Could you point me to some good tutorial resource about this localization system? I tried the following: cmake -DEXIV2_BUILD_PO=ON -DCMAKE_INSTALL_PREFIX=localFolder ../ make make install The MO files get generated and installed, but I do not know what do do to switch the language of the application (I guess that I would need to setup some environment variable). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#527 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACd9eMv02cvUk2USfB7cAYhxH694_b8oks5utE1sgaJpZM4YShOq> .

[clanmills]

@piponazo As always, Gilles is correct. The .mo files are installed in {prefix}/share/

-rw-r--r--  1 root  wheel  76917  8 Nov 17:02 ./locale/vi/LC_MESSAGES/exiv2.mo
-rw-r--r--  1 root  wheel  578159  8 Nov 17:02 ./locale/sv/LC_MESSAGES/exiv2.mo
-rw-r--r--  1 root  wheel  466681  8 Nov 17:02 ./locale/ms/LC_MESSAGES/exiv2.mo
...

I can use them with exiv2 v0.26 without trouble. The environment string is LC_ALL=language_REGION It doesn't seem to be working with v0.27, although I haven't investigated.

543 rmills@rmillsmbp:~/gnu/exiv2/v0.26 $ exiv2
exiv2: An action must be specified
exiv2: At least one file is required
Usage: exiv2 [ options ] [ action ] file ...

Manipulate the Exif metadata of images.
544 rmills@rmillsmbp:~/gnu/exiv2/v0.26 $ env LC_ALL=fr_FR exiv2
exiv2: Une action doit être spécifié
exiv2: Au moins un fichier est nécessaire
Utilisation : exiv2  [ options ] [ action ] fichier ...

Manipulation des métadonnées EXIF issues des images.
545 rmills@rmillsmbp:~/gnu/exiv2/v0.26 $ env LC_ALL=es_ES exiv2
exiv2: Se debe especificar una acción
exiv2: Se requiere un archivo al menos
Uso: exiv2 [ opciones ] [ acción ] archivo ...

manipular los metadatos Exif de las imágenes.
546 rmills@rmillsmbp:~/gnu/exiv2/v0.26 $

[piponazo]

I already managed to understand how the localisation work with Exiv2 and I found few issues in the way we were enabling the i18n support and with the paths were to look for the .MO files.

I should be able to fix the situation soon 😉

[cgilles]

There is a point to talk here about local support through the library with a client application.

Under all KDE aGUI application, you can switch to another language independently than system locale. For the curious, it's in Help menu.

So i can run digiKam in French with a host system running in English for ex. This is very powerful. The digiKam bundle include all translation files (.MO) to be able to switch to another language (around 40 langues).

When this kind of operation is done, the application must be restarted and a new instance use the new language... excepted all string taken from Exiv2 which still in English.

So my question is : there is a a method to force the library to use a specific language at run time ?

Gilles Caulier

[piponazo]

@cgilles I made a quick test with a hello work application and this works:

#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

I found the information here.

This looks to me like something that should be done in the application level and not at the library (Exiv2) level. Would be reasonable for digiKam to call setenv with the language selected in the preferences?

[cgilles]

I think no.

Typically, if you change the locale settings for the whole application, this change a lots of rules, as char encoding, number formatting, date, etc... and this will introduce dysfunctions of course.

In KDE framework, the locale is managed in application space only, for the case that talk previously, because the famous option in Help menu override the locale settings provide by the system (or the desktop in case of GUI)

This is why it permit to run a single application in French, where the rest of the system is in English.

This mechanism is managed on low level by KDE framework, not by the application (which use the framework of course). In fact the menu action run something in KDE framework which switch the application language. There is probably a settings save somewhere as in all cases, the application need to be re-started.

So, yes, in digiKam case running Exiv2, it's delegate to the application to get this settings, and to pass it to Exiv2. Actually, nothing is done in this way and whole application switch to French but Exiv2 strings still in English. This is not homogeneous but not critical of course.

Gilles Caulier

[piponazo]

I am not totally sure, but it seems that the environment variable LANGUAGE is used to only set messages languages and it should not affect to the other things you mentioned:

• https://superuser.com/questions/392439/lang-and-language-environment-variable-in-debian-based-systems
• https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html#The-LANGUAGE-variable

I also wondered if the call to setenv("LANGUAGE", "es", 1); was modifying the value of the environment variable outside of the application scope. I did a quick experiment locally and it seems that it only changes the value in the scope of the application.

I would propose you to give a try to this approach once I fix the localisation issues on master. It is the way recommended by the gettext documentation. I am happy to try other approaches if somebody finds them.

[cgilles]

ok, i will investigate Gilles Le ven. 9 nov. 2018 à 14:15, Luis Díaz Más <[email protected]> a écrit :

…

I am not totally sure, but it seems that the environment variable LANGUAGE is used to only set messages languages and it should not affect to the other things you mentioned: - https://superuser.com/questions/392439/lang-and-language-environment-variable-in-debian-based-systems - https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html#The-LANGUAGE-variable I also wondered if the call to setenv("LANGUAGE", "es", 1); was modifying the value of the environment variable outside of the application scope. I did a quick experiment locally and it seems that it only changes the value in the scope of the application. I would propose you to give a try to this approach once I fix the localisation issues on master. It is the way recommended by the gettext documentation <https://www.gnu.org/software/gettext/manual/html_node/gettext-grok.html>. I am happy to try other approaches if somebody finds them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#527 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACd9eHt9ZTvykENyhhEs24sVRWXLxc1oks5utYALgaJpZM4YShOq> .

[clanmills]

@piponazo This is very good work. I think Gilles is correct and libexiv2 should keep out of the localisation business as it is a process matter.

However we have about 40 sample applications and it will be useful to load our translation files easily from exiv2.cpp and other samples with a simple call such as Exiv2::loadLocalisation() without the need to mess with EXV_this_and_that.

Incidentally, I found your example very helpful and summarised it:

// Tutorial http://www.labri.fr/perso/fleury/posts/programming/a-quick-gettext-tutorial.html
//
// Build the code:
// $ make -B hello LDFLAGS=-lintl

// Generate pot (template)
// $ mkdir -p  po
// $ xgettext --keyword=_ --language=C --add-comments --sort-output -o po/hello.pot hello.c

// Generate french po (translation)
// $ mkdir -p po/fr
// $ msginit --input=po/hello.pot --locale=fr --output=po/fr/hello.po
//
// Edit po/fr/hello.po "Hello World" => "Bonjour le monde"
//
// Generate mo        (messages)
// $ mkdir -p fr/LC_MESSAGES/
// $ msgfmt --output-file=fr/LC_MESSAGES/hello.mo po/fr/hello.po

// Run
// $ env LC_ALL=fr_FR ./hello
//
#include <stdlib.h>
#include <stdio.h>
#include <libintl.h>
#include <locale.h>

#define _(STRING) gettext(STRING)

int main()
{
	// Setting the i18n environment
	setlocale (LC_ALL, "");
	bindtextdomain ("hello", getenv("PWD"));
	textdomain ("hello");

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

	return EXIT_SUCCESS;
}

[clanmills]

Luis and I have worked together to resolve localisation issues for 0.27RC2. #535 I believe everything is documented and working correctly. Which leaves two questions which were the focus of this issue when it was opened:

1. Will Toni provide Catalonian in time to go on RC2?
2. Will Toni provide updated .po files which include the new exceptions and other v0.27 strings.

I don't intend to slip the schedule for Exiv2 if these files are not available as we will have "dot" releases of Exiv2 v0.27 in 2019 and 2020. I expect the "dot" releases to be quarterly, however I don't have a schedule at present.

The current v0.27 schedule is:

Exiv2 v0.27 RC2 Friday 16 November 2018
Exiv2 v0.27 RC3 Friday 07 December 2018
Exiv2 v0.27 GM Friday 28 December 2018

[cgilles]

The *.po for all languages need to be updated by a developer.
cmake must be configured to handle translation files.
When you run make, all source codes are parsed, and all *.po files are updated locally. The developer commit changes to git.

Note that also the .pot template file is also updated. It must be used for new translations.

For the Catalan translations, you need to patch cmake to handle this language and create a new dedicated .po file. This file will include all strings created from scratch to translated. Add the new file to git.

The translator checkout the code with new .po file, and it can start to translate and send an update later to developer.

i hope that all is clear...

Gilles

[clanmills]

Thank You, @cgilles

I've documented Localisation in README.md. I believe the document covers everything you've mentioned. @piponazo has done very good work on our CMake and C++ code to ensure that Localisation builds and works correctly.

I expect to release v0.27 RC2 on schedule tomorrow 2018-11-16. http://exiv2.dyndns.org Feedback welcome.

[cgilles]

yes, i will include this version in next digiKam bundles.... Q: you point me to exiv2.dyndns.org... I forget something in Exiv2 history ? There is already www.exiv2.org ? Why this puzzle ? Best Gilles Le jeu. 15 nov. 2018 à 18:05, Robin Mills <[email protected]> a écrit :

…

Thank You, @cgilles <https://github.com/cgilles> I've documented Localisation in README.md. I believe the document covers everything you've mentioned. @piponazo <https://github.com/piponazo> has done very good work on our CMake and C++ code to ensure that Localisation builds and works correctly. I expect to release v0.27 RC2 on schedule tomorrow 2018-11-16. http://exiv2.dyndns.org Feedback welcome. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#527 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACd9eH6-UGQyeUF7waRE1L9b8P55yqmMks5uvZ7JgaJpZM4YShOq> .

[clanmills]

Exiv2 v0.27 RCs are being published on exiv2.dyndns.org. The future of exiv2.org remains to be determined.

I have write access to exiv2.org, however I don’t have ownership. I am concerned that exiv2.org could die without warning and I would not be able to do anything about it as it’s hosted on AWS. I am not the owner. We had such an incident in July. Luckily, Amazon repaired the site from backup. The site was down for about 7 days.

Exiv2.dyndns.org is a mac mini sitting on my desk. I have 100% control. It also runs the Jenkins buildserver.

A user has offered to host exiv2.org on their servers. I will investigate that in the next few weeks when the work-load to reach Exiv2 v0.27GM decreases.

[clanmills]

Great News. Toni has sent me his translation. Thanks!
ca.po.zip

[piponazo]

The Catalonian .po has been already added to master, and I created #549 to not forget about the remaining stuff for future releases of exiv2. I'll close this issue now.

[clanmills]

@cgilles Thank you very much for your contributions to fixing exiv2 v0.27 RC1. You've been very helpful.

The Team has a "Slack" for private conversations. About 90% of our correspondence is public on GitHub (and/or Redmine). When it comes to discussing schedules, servers and non code/bug matters, it's better to have a conversation and publish our conclusion. There's a "general" channel which is visible to the whole team and private one-to-one channels.

If you send me an email: [email protected] I will send you an invitation to join us on Slack. https://slack.com