GNOME Bugzilla – Bug 680876
Making some of the iso-codes data available through high-level functions
Last modified: 2018-05-24 14:24:03 UTC
Applications often need to display the name of a language. For example the en_US code corresponds to the name "English (United-States)". There are two parts: the language (English), and the country (United-States). It makes sense to be able to get the two names separately. The language should always exist, but the country is optional. To be more convenient, it also makes sense to have the full name, with the country in parentheses. I think that's the common way to display it. So the API would consist of these functions, or similar names: pango_language_get_language_name() pango_language_get_country_name() pango_language_get_full_name() The iso-codes can be used for the implementation. More precisely, ISO-639 for the language names, and ISO-3166 for the country names. gtkhtml has an implementation for fetching the names from the iso-codes: http://git.gnome.org/browse/gtkhtml/tree/components/editor/gtkhtml-spell-language.c
Sébastien, I don't want these in Pango. You need the names, and their localizations too. That's exactly what the iso-codes package is about. Pango has no translatable strings, and I prefer to keep it so. Does that make sense? Perhaps GTK+ can do something? The roort of the problem is that we don't have a locale system in GNOME (like, say, ICU).
(In reply to comment #1) > Sébastien, I don't want these in Pango. You need the names, and their > localizations too. That's exactly what the iso-codes package is about. Pango > has no translatable strings, and I prefer to keep it so. > > Does that make sense? I thought PangoLanguage was the right place, since it represents a language. But pango is about text layout and rendering, not about i18n data. So it makes sense, yes. > Perhaps GTK+ can do something? The roort of the problem is that we don't have > a locale system in GNOME (like, say, ICU). Or in GLib? Making some of the iso-codes data available through high-level functions.
Reassigning to glib to decide.
I don't know; whats wrong with dgettext("iso_639", "French") dgettext("iso_3166", "France") ? Wrapping those in g-prefix functions doesn't really add any value for you. But it does add maintenance and dependency burden for the glib maintainers.
Here the purpose is to go from "fr_FR" to "French (France)". Translating "French" and "France" is indeed not the difficult part. What is less obvious is to get those names in the first place. The iso-codes is actually XML files (to be parsed) containing pieces of information like: <iso_639_entry iso_639_2B_code="fre" iso_639_2T_code="fra" iso_639_1_code="fr" name="French" /> <iso_3166_entry alpha_2_code="FR" alpha_3_code="FRA" numeric_code="250" name="France" official_name="French Republic" /> Libraries generally deals with the iso codes (fr_FR), while users prefer names like "French (France)".
FWIW, gnome-desktop also has an implementation for this in https://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-languages.c
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/580.