[ 
https://issues.apache.org/jira/browse/CB-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983409#comment-13983409
 ] 

ASF GitHub Bot commented on CB-4602:
------------------------------------

GitHub user mbillau opened a pull request:

    https://github.com/apache/cordova-plugin-globalization/pull/9

    Android should return BCP47 tag, not localized string

    For https://issues.apache.org/jira/browse/CB-4602
    I still want to test the consistency with iOS.
    Return the Locale.getDefault().toString() which according to the Android 
docs [1], contains a two-letter lowercase ISO language code (ISO 639-1) 
followed by an underscore, followed by the two-letter uppercase country code 
(ISO 3166-1). As best I can tell, these two specs (and some more) are what make 
up BCP 47, therefore we should be able to assume that this will always return 
BCP 47 compliant language tags. 
    
    I did notice that sometimes toString() will leave out country or language 
codes if they don't exist. For example, if you set locale to be Locale.CHINESE, 
then you'll get back "zh" - no country code. I'm not sure if this is BCP 47, or 
if there is anything we can do about it.
    
    Finally, since this changes an API, would we have to do a major bump to the 
plugin version number? I thought about deprecating the old code and/or creating 
a new API method but chose against that since this is a bug fix and not a 
feature request. I think the version number should be bumped though...
    
    [1]  http://developer.android.com/reference/java/util/Locale.html
    
    


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/mbillau/cordova-plugin-globalization CB-4602

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/cordova-plugin-globalization/pull/9.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #9
    
----
commit 64734dbd067330a8a787724a8df0a73325c96276
Author: mbillau <[email protected]>
Date:   2014-04-28T19:02:39Z

    Android should return BCP47 tag, not localized string

----


> getPreferredLanguage platform inconsistencies
> ---------------------------------------------
>
>                 Key: CB-4602
>                 URL: https://issues.apache.org/jira/browse/CB-4602
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Android, Plugin Globalization
>    Affects Versions: 2.6.0, 3.0.0
>         Environment: Android
>            Reporter: Jon Whitlock
>            Assignee: Martin Gonzalez
>            Priority: Minor
>
> In;
> https://github.com/apache/cordova-docs/blob/master/docs/en/edge/cordova/globalization/globalization.getPreferredLanguage.md
> "Returns the language identifier string to the successCallback with a 
> properties object as a parameter. That object should have a value property 
> with a String value."
> navigator.globalization.getPreferredLanguage(
>    function (language) {alert('language: ' + language.value + '\n');},
>    function () {alert('Error getting language\n');}
> );
> On Android the function doesn't seem to return an identifier as such, it 
> returns *a string describing the language localised to that language*, e.g. 
> "English" for English or "中文" for Japanese. Naturally this is less than ideal 
> for subsequent string operations, furthermore on that page "Windows Phone 8 
> Quirks - Returns the ISO 639-1 two-letter code for the current language" 
> which is an identifier, and also what I would expect (or an ISO 639-2 code, 
> as per http://www.loc.gov/standards/iso639-2/php/code_list.php)
> Android seems to support 639-2 
> http://developer.android.com/reference/java/util/Locale.html#getISO3Language()
> I have no idea what it returns on other platforms, but to keep client code 
> consistent I guess it would good if this could be normalised in the API.
> Have tested this on v3.0 and 2.6, is the same.
> As an aside, the locale is not really what I want here, as the user may be in 
> the US but have Japanese as their preferred language.
> Thanks,
> jon
> (first go at using Jira, apols if I got something wrong!)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to