Locale settings like LANG LANGUAGE and so on seems to be useless.

[Boldie]

The locale settings from console runs are not respected at all. The gui is still in english.

Steps to Reproduce

1. Set system language to english
2. Ensure correct locale is set in console.
3. Run gourmet from console
4. -> gourmet does not respect locale settings.

Expected Behavior

Language is switched respecting the locale settings.

Current Behavior

Language is still in english.

Possible Solution

??

Environment

• Operating System: Ubuntu 20.04
• Version or commit id: 8af29c8 (master as of today)
• Installed from github

sven@SvensRyzen:~/workspace/gourmet$ locale
LANG=de_DE
LANGUAGE=de
LC_CTYPE="de_DE"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="de_DE"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="de_DE"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

[cydanil]

Thanks, I can't offer a solution just now, but I've made a note of this.

[cydanil]

Out of curiosity, there is a test wheel available here, could you try installing it and check that the application is in German?

Thanks!
Cyril

[Boldie]

Ok, I tried it, but i looks weird:

1. I did a "flatpak install ..." with the package you provided above.
2. I started it with "flatpak run io.github.thinkle.Gourmet"
3. Now I see some log messages,

sven@SvensRyzen:~/Downloads$ flatpak run io.github.thinkle.Gourmet

Note that the directories 

'/var/lib/flatpak/exports/share'
'/home/sven/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

args = Namespace(db_url='', debug=None, debug_file='', gourmetdir='', html_plugin_dir='', thread_debug=False, thread_debug_interval=5.0, threads=False, time=False)
Ignoring duplicate plugin  listsaver found in  /home/sven/workspace/gourmet/build/share/gourmet/plugins/listsaver.gourmet-plugin
Ignoring duplicate plugin  unit_display_prefs found in  /home/sven/workspace/gourmet/build/share/gourmet/plugins/unit_display_prefs.gourmet-plugin
Ignoring duplicate plugin  browse_recipes found in  /home/sven/workspace/gourmet/build/share/gourmet/plugins/browse_plugin.gourmet-plugin
Ignoring duplicate plugin  shopping_associations found in  /home/sven/workspace/gourmet/build/share/gourmet/plugins/shopping_associations.gourmet-plugin
Ignoring duplicate plugin  field_editor found in  /home/sven/workspace/gourmet/build/share/gourmet/plugins/field_editor.gourmet-plugin
... <SNIP> ...
DEBUG:   /home/sven/workspace/gourmet/gourmet/Undo.py: 437 gui_update
DEBUG:   /home/sven/workspace/gourmet/gourmet/Undo.py: 461 Nothing to undo, desensitizing widgets
DEBUG:   /home/sven/workspace/gourmet/gourmet/Undo.py: 429 set_sensitive
DEBUG:   /home/sven/workspace/gourmet/gourmet/Undo.py: 429 set_sensitive
DEBUG:   /home/sven/workspace/gourmet/gourmet/Undo.py: 429 set_sensitive

So gourmet running from flatpak seems to load my development directory. Unfortunately I have no experience with flatpak to know this is an intended behavior or which application code is now running.

Finally I switched my complete system to german language but the only translated button is the "search" button which will become Suchen which is correct.

[jmirabel]

I had the same issue on Ubuntu 18.04. I noticed with dpkg -L gourmet that the translation files are in a LC_MESSAGES directory so I tried this LC_MESSAGES=fr_FR.UTF-8 gourmet and it worked.

[martinp26]

Seeing the same problem on Ubuntu 20.04 with a local dev install in my virtualenv.

LC_ALL=de.UTF-8 LANG=de.UTF-8 LANGUAGE=de.UTF-8 gourmet

does not seem to pipe the desired setting through to gettext. It appears locale_base is computed in settings.py but is never used anywhere (that grep can see).

defaults.py does consider the env variables and correctly imports defaults_de.py and takes various settings from it, but this never makes it to gettext.

Grepping through git log -p --full-diff for locale_base yields this:

af373cb70ca0cd7563eabf10e58740a839e4f6b1
Author: Cyril Danilevski <[email protected]>
Sat Sep 12 13:19:50 2020 +0000

[...]
-try:
-    import elib.intl
-    elib.intl.install('gourmet', settings.locale_base)
-except ImportError:
-    print('elib.intl failed to load.')
-    print('IF YOU HAVE TROUBLE WITH TRANSLATIONS, MAKE SURE YOU HAVE THIS LIBRARY INSTALLED.')
[...]

Was that the point where gettext was set up?

[martinp26]

Dug a bit more.

in settings.py

import gettext
gettext.install('gourmet', 'path/to/build/mo')
print("xxx134", gettext.textdomain())
print("xxx133", _('Recipe Index'))

Does give me a translated string IFF the gourmet.mo file is moved under:

../build/mo/de/LC_MESSAGES/

instead of

../build/mo/de/

However, later in the code, e.g., in gglobals.py this does not work anymore. Here it seems to fall back to ignoring the LC* and LANG* variables. Something seems to reset the gettext setup in between.

[cydanil]

Thanks @martinp26 for your in-depth investigation!
I'm now able to run the application in different locales:

It's a bit hacked together at the moment (that is, works on my machine™), and still requires a bit of work though.