[
https://issues.apache.org/jira/browse/CB-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977106#comment-13977106
]
Pascale Dardailler commented on CB-4602:
----------------------------------------
The proposed implementation will not improve the consistency if not all
platforms agree on the same implementation. Locale#getISO3Language() in Android
SDK will return "eng" for English, where most people will expect ISO alpha-2
language code (ISO639-1) "en". In addition to this, language preference may
need to distinguish regional dialects (for example, American English vs British
English, Brazilian Portuguese vs Iberian Portuguese...)
It would be better to have each platform return a valid BCP 47 Language Tag
(see http://tools.ietf.org/html/bcp47). This will mean that implementation
could return "zh-Hant" and "zh-Hans" to differentiate Traditional from
Simplified Chinese, "pt-BR" and "pt-PT" to differentiate Brazilian Portuguese
from Iberian Portuguese and same for any language that needs to be
differentiated from the base language. It seems that iOS implementation is the
correct one.
It is recommended that an implementation of this function distinguish regional
dialects or written scripts by adding country subtag or script subtag if
necessary. For example, to distinguish between Portuguese dialects, "pt-BR"
(Brazilian Portuguese) and "pt-PT" (Iberian Portuguese) are commonly used. For
Chinese, an implementation may use "zh-Hans" for Chinese contents written in
Simplified Chinese characters, and "zh-Hant" for Chinese contents written in
Traditional Chinese characters. (Some others may use "zh-CN" to specify Chinese
used in China, which implies the contents is written in Simplified Chinese
characters, and "zh-TW" to specify Chinese used in Taiwan, which implies the
contents is written in Traditional Chinese. Such implementations are also
acceptable.)
The documentation will need to be changed, to simply state that the API returns
a valid BCP 47 Language Tag.
WindowsPhone8 should use CultureInfo.CurrentUICulture.Name, which should be
also BCP 47 language tag expression of preferred language setting.
Android should not return the localized language name.
> 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: Joe Bowser
> 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)
