bugGNU gettext - Bugs: bug #58362, Fallback for locales/languages...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58362: Fallback for locales/languages with modifiers

Submitter:  Gunnar Hjalmarsson <gunnarhj>
Submitted:  Tue 12 May 2020 09:39:20 PM UTC
   
 
Category:  End-user / runtime Severity:  3 - Normal
Item Group:  None Status:  Not a Bug
Privacy:  Public Assigned to:  haible
Open/Closed:  Closed

Wed 13 May 2020 10:17:31 AM UTC, comment #4: 

Fair enough.

And thanks for the tip about the recode-sr-latin program. In case of gnome-desktop it won't be necessary; there is a complete sr@latin translation in Ubuntu. I'd better pass that to upstream. Still good to know.

Gunnar Hjalmarsson <gunnarhj>
Wed 13 May 2020 08:40:46 AM UTC, comment #3: 

The combination of $LC_ALL (empty or unset), $LC_MESSAGES (sr_RS.UTF-8@latin), $LANG (irrelevant since LC_MESSAGES is set), and $LANGUAGE (empty or unset) means that you requested the translation for the sr_RS.UTF-8@latin locale.

> The message catalogue /usr/share/locale/sr@latin/LC_MESSAGES/gnome-desktop-3.0.mo does not include any translation of "Latin", which makes gettext pick the translation from /usr/share/locale/sr/LC_MESSAGES/gnome-desktop-3.0.mo. I would have expected it to use the msgid string instead.


This is a feature. The assumptions are that
1) Since a translation for Serbian in Serbia is not available, a translation for Serbian generically will do,
2) Since a translation with Latin alphabet [for the particular message] is not available, a translation for any alphabet will do, Cyrillic in this case.

The reasoning behind these "will do" assumptions is that in practice, most readers will understand the output: Serbs in the Kosovo will understand Serbian from Serbia and vice versa, and the Cyrillic alphabet should still be familiar to most people talking Serbian.

Note: For the special case of the Latin Serbian locale, GNU gettext contains a program 'recode-sr-latin' that helps in preparing a Latin message catalog from a Cyrillic one. You use it like this:

msgfilter -i sr.po -o sr@latin.po recode-sr-latin

To apply it on a .mo file, use a pipe with msgunfmt first and msgfmt at the end:

msgunfmt sr/LC_MESSAGES/package.mo | msgfilter recode-sr-latin | msgfmt -o sr@latin/LC_MESSAGES/package.mo


Bruno Haible <haible>
Group administrator
Wed 13 May 2020 12:28:09 AM UTC, comment #2: 

This is the complete locale:

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=sv_SE.UTF-8
LC_TIME=sv_SE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=sv_SE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=sv_SE.UTF-8
LC_NAME=sv_SE.UTF-8
LC_ADDRESS=sv_SE.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_MEASUREMENT=sv_SE.UTF-8
LC_IDENTIFICATION=sv_SE.UTF-8
LC_ALL=

Hey, you are the second person within an hour who asks for my locale. I'd better work on my credibility. ;)

Gunnar Hjalmarsson <gunnarhj>
Tue 12 May 2020 11:09:09 PM UTC, comment #1: 

Please, can you also show $LANG and $LC_ALL ?

Bruno Haible <haible>
Group administrator
Tue 12 May 2020 09:39:20 PM UTC, original submission:  

Incidentally I made this observation:

$ echo $LANGUAGE

$ echo $(LC_MESSAGES=sr_RS.UTF-8@latin gettext -d gnome-desktop-3.0 'Latin')
Латиница

Or in English: The message catalogue /usr/share/locale/sr@latin/LC_MESSAGES/gnome-desktop-3.0.mo does not include any translation of "Latin", which makes gettext pick the translation from /usr/share/locale/sr/LC_MESSAGES/gnome-desktop-3.0.mo. I would have expected it to use the msgid string instead.

Is this intentional or a bug?

Gunnar Hjalmarsson <gunnarhj>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by gunnarhj (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-13 haible StatusNeed Info Not a Bug
        Assigned toNone haible
        Open/ClosedOpen Closed
    2020-05-12 haible StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code