Enable gettext translation for glade dialogs.

[kurisuke]

Glade dialogs created by Gtk.Builder use the C library gettext
interface. To enable localization for this interface, use setlocale /
bindtextdomain from the python locale module.

For a detailed explanation see: https://stackoverflow.com/questions/10094335/how-to-bind-a-text-domain-to-a-local-folder-for-gettext-under-gtk3

[multani]

I actually removed the call to locale.bindtextdomain in 2c533b3 because of the problem reported in #67.

The comment I was looking into in Python's documentation was the following:

Python applications should normally find no need to invoke these functions, and should use gettext instead. A known exception to this rule are applications that link with additional C libraries which internally invoke gettext() or dcgettext(). For these applications, it may be necessary to bind the text domain, so that the libraries can properly locate their message catalogs.

It looks like I was wrong and I should have used locale.bindtextdomain for Gtk to get the correct locales. Still, it seems it doesn't work on OS X and I can't test this as I don't have access to this plateform. I'll see with the guys from #67, or if you have an idea on this...?

[kurisuke]

Thanks for pointing me to the issue, I totally overlooked this.
Unfortunately, I don't have access to OSX either.

Regarding your quote from the Python docs:
It seems the bindtextdomain() function ist actually not provided by the OSX libc, which seems to be perfectly acceptable behaviour, as it is specific to GNU gettext.. I will update this push request to check whether the function is actually available in the locale module (hasattr).

[multani]

Thanks, I appreciate the comments you wrote!

So, I finally had a tried and I'm not convinced:

• if I use the code in master (so without your fix), all the UI seemed to be translated, ie. LANG=fr_FR.UTF-8 ./run-sonata gets me a French Sonata. However, this only works if the catalog file has been correctly compiled for this lang, ie. only if sonata/share/locale/fr/LC_MESSAGES/sonata.mo exists. These files get generated when you execute setup.py:

$ python3 setup.py             
Generating sonata/share/locale/ar/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/be/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/ca/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/cs/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/da/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/de/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/el_GR/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/es/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/et/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/fi/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/fr/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/it/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/ja/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/ko/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/nl/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/pl/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/pt_BR/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/ru/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/sk/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/sl/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/sv/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/tr/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/uk/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/zh_CN/LC_MESSAGES/sonata.mo
Generating sonata/share/locale/zh_TW/LC_MESSAGES/sonata.mo
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: no commands supplied

although I recognized it's probably less than ideal and not really documented. Could you have been running in this case where the correct locale file doesn't exist?

• also, running Sonata with your patch and an unsupported locale now crashes:

$ LANG=foo ./run-sonata                      
Traceback (most recent call last):
  File "./run-sonata", line 23, in <module>
    sonata.launcher.run()
  File "/home/jon/projects/sonata/sonata/sonata/launcher.py", line 126, in run
    locale.setlocale(locale.LC_ALL, '')
  File "/usr/lib/python3.4/locale.py", line 592, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

I don't think it should :)

[kurisuke]

I didn't test for unsupported locales! Good idea to check for it :)

Actually, it seems to be even more complicated:

• Glade strings are only translated if the locale is supported by the C library. You can check supported locales by locale -a.
• Python strings (handled by the gettext module) will always be translated if the .mo file is installed with sonata, even if the language is not supported by the C library.

So if a locale is not supported by the C library, but the catalog file is installed with sonata, we will have a mix of languages in the UI.
E.g. on my system I don't support fr_FR.UTF-8 with libc, but if I start sonata with fr_FR.UTF-8 ./run-sonata, I will get all UI in french except the Glade dialogs, which are untranslated.

I see two possible ways to handle this:

1. Do nothing. Any translated strings are better than no translated strings. try for an exception and pass in the except block
2. When the locale.setlocale() call fails, call gettext.install() to provide the _() function, but don't point it to the translation files: localedir=None. So all strings in the application will be left untranslated.

What do you think?

[multani]

On Tue, Mar 03, 2015 at 01:37:13PM -0800, Peter Helbing wrote:

I didn't test for unsupported locales! Good idea to check for it :)

Actually, it seems to be even more complicated:

• Glade strings are only translated if the locale is supported by the C library. You can check supported locales by locale -a.
• Python strings (handled by the gettext module) will always be translated if the .mo file is installed with sonata, even if the language is not supported by the C library.

So if a locale is not supported by the C library, but the catalog file is installed with sonata, we will have a mix of languages in the UI.
E.g. on my system I don't support fr_FR.UTF-8 with libc, but if I start sonata with fr_FR.UTF-8 ./run-sonata, I will get all UI in french except the Glade dialogs, which are untranslated.

Yeah, you are right, good catch!

I see two possible ways to handle this:

1. Do nothing. Any translated strings are better than no translated strings. try for an exception and pass in the except block
2. When the locale.setlocale() call fails, call gettext.install() to provide the _() function, but don't point it to the translation files: localedir=None. So all strings in the application will be left untranslated.

I would say the second on looks better to me - at least it makes things
coherent. I tried running the first one with unsupported locales on my
system, and it definitively looks weird with half the UI translated.

If you decide to go this way, can you also log the problem so at least
an user running Sonata from the command line knows that something went
wrong?

[kurisuke]

I agree with you :)
I updated the pull request accordingly (added a new commit) and also added an error print.

[multani]

I did some updates on your last patch (I moved out of the exception handler the code which wasn't related to the exception, and I changed the usage of print() with logger.error()), but thanks for investing most of it!