A recent thread suggests the currently recommended hack to specify the GUI language:
Hacking a desktop shortcut is nice for those who are comfortable in doing such things, but I wouldn’t regard this user friendly.
It would be a good thing if the general settings in Gramps would provide a choice of GUI language.
A second language option could be the language of terminology used in reports, graphs and other output. This would allow a user to generate reports in a third language, which will come in very handy when exchanging information with family abroad.
If necessary the app could download a missing dictionary from the repository.
the MSWindows-oriented PortableApps group asks why Gramps doesn’t use some opportunities to adapt more transparently. (The PortableApps also installs all available languages and allows … somewhat … easier overrides to language selection.)
It notes Reports having different languages selector
it argues that the command line interface (and shortcut hacking options) do not pass the “usable by Aunt Martha” test
I wonder if it isn’t time for Gramps to adopt a Language selection icon too?
@SNoiraud just greatly improved the language selection menu generated by the Narrative Report. Its Language menu now shows the choices labeled in the Currently selected language and labeled in their native tongue. But the Hamburger’s parent menu is labeled “Language” in the current language. The menu would benefit from a “language” icon that needs no translation.
We automatically detect the GUI language setting from the desktop environment.
This is what most of our users want.
It would be fairly easy to add a language selector in the preferences. We could populate it with the list of languages that we have translations for. Changing the setting would require a restart. At start-up we would read the setting and use it as an override in the same way that we already use the LANGUAGE environment variable.
However, providing a language selector would imply that no other configuration is required, and that is not the case.
Then it will work. I can see the Dutch translations. However, I get a warning from Gtk telling me that it can’t recognise the locale. I’m not sure what impact this has, but if I wanted to work with Dutch then I would configure the locale on my system.
Yes. You may also want to configure a locale to provide a default date format.
For Dutch, you may want to choose between “nl_NL.utf8” and “nl_BE.utf8”. In fact you will need to set the LANG environment variable for the spell checker (gspell), because it doesn’t recognise the LANGUAGE environment variable.
The forum post discusses the concept of “locale” in the context of configuring software for different languages and cultural settings. Here’s a simplified explanation:
A locale is a combination of settings that define how software should adapt to the user’s language, region, and cultural conventions. It includes preferences like date formats, currency symbols, and text encoding. For example:
nl_NL.utf8: Dutch as spoken in the Netherlands.
nl_BE.utf8: Dutch as spoken in Belgium.
Key Points from the Forum Post:
LANGUAGE vs. Locale Warning: Running LANGUAGE=nl Gramps.py sets the interface language to Dutch but may trigger a warning because it doesn’t fully configure all locale settings (e.g., date formats). This is why setting a complete locale (e.g., nl_NL.utf8) is recommended for consistency1, 2, 5.
Environment Variables:
LANGUAGE: Specifies the language for messages but doesn’t handle broader cultural settings.
LANG: Defines the default locale for all settings unless overridden.
LC_* Variables: Allow customization of specific aspects like dates (LC_TIME) or messages (LC_MESSAGES)2, 5, 8.
Practical Impact: If you don’t configure a full locale, some features (like spell checkers) might not work correctly because they rely on LANG or LC_* variables rather than LANGUAGE.
This highlights that while LANGUAGE can change the interface language, setting a proper locale ensures full compatibility with regional conventions and system tools1, 7
Perhaps we have a user proficient in FontForge? It seems like combining the 2 glyphs from a (compatibly licensed) open source font would be straightforward.
Then an embeddable “Genealogy” fontface could be used for this?
(And expanding the embeddable font family to include custom Genealogical symbols could free us of the platform and font family idiosyncrasies in that Preferences option.)
): U+1F4AC
): U+1F170