GNOME Bugzilla – Bug 770403
Glom translations cannot get locale path on Mac OS X
Last modified: 2021-07-05 10:53:11 UTC
Glom try to get the language settings and locales by Glibc and path /usr/share/i18n/locales for Glibc into Glom to access translations. On Mac OS X, the path is /usr/share/locale I tried to set the environment variable to export I18NPATH="/usr/share/locale" but glom will still force using /usr/share/i18n/locales for Glibc DEBUG: User=glom_default_developer_user _is_ in the developer group on the server. Glib::ustring Glom::IsoCodes::get_locale_name(const Glib::ustring &): Could not open (or read) glibc locales directory: /usr/share/i18n/locales/Error: Error opening directory '/usr/share/i18n/locales/': No such file or directory void Glom::ComboBox_Locale::set_selected_locale(const Glib::ustring &): locale not found in list: fr_FR, list size=0 Glib::ustring Glom::IsoCodes::get_locale_name(const Glib::ustring &): Could not open (or read) glibc locales directory: /usr/share/i18n/locales/Error: Error opening directory '/usr/share/i18n/locales/': No such file or directory Glib::ustring Glom::IsoCodes::get_locale_name(const Glib::ustring &): Could not open (or read) glibc locales directory: /usr/share/i18n/locales/Error: Error opening directory '/usr/share/i18n/locales/': No such file or directory void Glom::ComboBox_Locale::set_selected_locale(const Glib::ustring &): locale not found in list: fr_FR, list size=0 Dialog_IdentifyOriginal::load_from_document Glib::ustring Glom::IsoCodes::get_locale_name(const Glib::ustring &): Could not open (or read) glibc locales directory: /usr/share/i18n/locales/Error: Error opening directory '/usr/share/i18n/locales/': No such file or directory void Glom::ComboBox_Locale::set_selected_locale(const Glib::ustring &): locale not found in list: fr_FR, list size=0
Indeed. /usr/share/i18n/locales was hard coded in the source code, which should never have happened. Did the test_iso_codes test work for you, during make check? That should have caught this problem. It does need some other locales (German, for instance) to be installed. This commit should fix it: https://git.gnome.org/browse/glom/commit/?id=7d880162fd6db1900408de1c0f93ba78caf55c5a
Actually, I reverted that because that would get a different path: /usr/share/locale. Does this cause an actual problem in the application? For instance, when choosing "Translations" from the "Developer" menu, do you see a list of languages in the "Target Language" combo box?
By the way, your /usr/share/locale on MacOS is not what we are looking for. We want the actual locale files for the whole system, not just the translations for an application. For instance, this is what we want on Linux: $ more /usr/share/i18n/locales/en_US escape_char / comment_char % % Locale for English locale in the USA % Contributed by Ulrich Drepper <drepper@redhat.com>, 2000 LC_IDENTIFICATION title "English locale for the USA" source "Free Software Foundation, Inc." address "http:////www.gnu.org//software//libc//" I do wonder if we really need to check for the installed locales at all.
Yes it's a problem because the language cannot be recognized and the locales settings are not working well because of this, like the translations for example. The thousands separator is not working and the currency symbol is not set correctly. In French for example, the thousands are separated by a space and the currency symbol is placed after the amount.
Created attachment 336695 [details] Translation settings unavailable.
Created attachment 336696 [details] Locales settings not working well on numbers The locale should be French. - The coma is OK. - No thousands separators. - Wrong position for the currency symbol.
On Mac OS X the locales are managed by softwares in a ~.lproj folder, not by the whole system. /usr/share/locale on MacOS is the equivalent of the $LANG variable settings that can handle the previous described wrong behavior. Which value do you need? I will see if there is an equivalent one.
(In reply to m.rick.mac from comment #5) > Created attachment 336695 [details] > Translation settings unavailable. This message should indeed cause that problem. We need the equivalent of /usr/share/i18n/locales/ . > Locales settings not working well on numbers > The locale should be French. > - The coma is OK. > - No thousands separators. > - Wrong position for the currency symbol. Do you get a different result on Ubuntu Linux? This is really a separate issue.
Yes it does work on Linux with the same version.
Created attachment 336775 [details] Language auto-detection in Xubuntu 15.04
But the locales settings aren't working better in my best.
Created attachment 336776 [details] entering a number before the formatting is applied
Created attachment 336777 [details] The same number with de formatting applied The number format is all wrong: There should have spaces for thousands separators instead of comas. But the coma is right for decimals. As a result, I entered 3 decimals, we don't know they are decimals, they appear like thousands. The currency symbol should be at the end.
(In reply to m.rick.mac from comment #13) > Created attachment 336777 [details] > The same number with de formatting applied Is this on Ubuntu Linux or MacOS? If the numeric formatting seems wrong on all platforms, then that's a different issue. Please file a separate bug about that. If the translations window is not working, only on MacOS, let's use this bug for that issue.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/glom/-/issues/ Thank you for your understanding and your help.