bugGNU gettext - Bugs: bug #47838, Confusing "main dialect"...

 
 

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

bug #47838: Confusing "main dialect" statement for $LANGUAGE

Submitter:  None
Submitted:  Tue 03 May 2016 04:07:20 PM UTC
   
 
Category:  Doc Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Tue 03 May 2016 04:43:29 PM UTC, comment #1: 

In addition, the notion of a "main dialect" is an invitation to politically motivated disputes.  Which is the "main dialect" of English, en_GB (by history) or en_US (by population)?  Does it matter that most of the rest of the anglophone world aligns in most respects with en_GB?

In BCP 47 the meaning of a primary language subtag unqualified by a region subtag is simply "the specified language, regional variant not given".  For some languages including English and Portuguese, there are no neutral variants and implementers must choose, but specifying "en" signals a willingness to accept any variety of English.

Suggested text:

In the LANGUAGE environment variable, but not in the other environment variables, ‘ll_CC’ combinations can be abbreviated  as ‘ll’ to denote an unspecified regional variety of the language, or (in some cases) a variety of the language which is not regionally identifiable.  This is dependent on the presence of MO files for the specified domain.

John Cowan <johnwcowan>
Tue 03 May 2016 04:07:20 PM UTC, original submission:  

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 zh_CN.

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

Anonymous

 

(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 (Updated the item)
  • -email is unavailable- added by johnwcowan (Posted a comment)
  •  

    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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-27 haible CategoryNone Doc

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code