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

Submitted by:  None
Submitted on:  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

 

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

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