[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gettext] [bug #47838] Confusing "main dialect" statement for $LANGU

From: anonymous
Subject: [bug-gettext] [bug #47838] Confusing "main dialect" statement for $LANGUAGE
Date: Tue, 03 May 2016 16:07:21 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36


                 Summary: Confusing "main dialect" statement for $LANGUAGE
                 Project: GNU gettext
            Submitted by: None
            Submitted on: Tue 03 May 2016 04:07:20 PM UTC
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any



In the gettext documentation, section 2.3.3, the document says:

> In the LANGUAGE environment variable, but not in the other
> environment variables, ‘ll_CC’ combinations can be abbreviated
> as ‘ll’ to denote the language’s main dialect. For example, 
> ‘de’ is equivalent to ‘de_DE’ (German as spoken in Germany), 
> and ‘pt’ to ‘pt_PT’ (Portuguese as spoken in Portugal) in this
> context.

However, this documentation does not reflect an actual prerequisite of this
abbreviation, that the MO files for the specified domain need to be in the
directory ${TEXTDOMAINDIR}/<lang>/LC_MESSAGE. This can confuse developers if
they happened to the full locale code for such languages.

colord’s MOs are available in both it and it_IT. Removing colod.mo from 'it'
and setting $LANGUAGE to 'it' can be confusing.

This description also made me believe that setting LANGUAGE=zh will give

PS: It seems that LANGUAGE can also accept some paths. Will that be in the


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]