cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Billau (JIRA)" <>
Subject [jira] [Commented] (CB-4602) getPreferredLanguage platform inconsistencies
Date Tue, 29 Apr 2014 16:07:18 GMT


Mike Billau commented on CB-4602:

I made some changes to the implementation above. I found out that Java 7 implements a method
called Locale#toLanguageTag(), so I followed that as much as possible. I pushed up a new branch
to the globalization plugin because there are a few other changes that we are in the process
of making, so we will just commit to that branch and then bump the major version once.

Somehow git reverted some of the previous changes (changing new Long() to Long.valueOf), so
I'll figure out why and fix that.

> getPreferredLanguage platform inconsistencies
> ---------------------------------------------
>                 Key: CB-4602
>                 URL:
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Android, Plugin Globalization
>    Affects Versions: 2.6.0, 3.0.0
>         Environment: Android
>            Reporter: Jon Whitlock
>            Assignee: Mike Billau
>            Priority: Minor
> In;
> "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
> Android seems to support 639-2
> 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

View raw message