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: DocSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned 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
  • -unavailable- added by haible (Updated the item)
  • -unavailable- added by johnwcowan (Posted a comment)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 27 Nov 2016 12:11:27 PM UTChaibleCategoryNone=>Doc

    Back to the top


    Powered by Savane 3.1-cleanup1