Analysis on the optimal scheme of angularjs globalization (II.)

In the last section we talked about 3 ways to take the current browser Locale in Angularjs, this section we mainly discuss the next angularjs inside the $locale service and with native JS how to get browser Locale, rigorous point of view is to get the current User browser language list or the browser UI language.

First of all we talk about the $locale service in Angularjs, a great overview, it will make people feel the light, but when we read the source code, we will have a bit of disappointment:

' Use strict ';

/**
 * @ngdoc service *
 @name $locale
 *
 @description
 * $locale Service provides localization rules F or various angular components. As of right now the
 * only public API is:
 * * *
 ' id ' – ' {string} ' –locale ID formatted as ' languageid-country Id ' (e.g. ' en-US ')
 * *

The locale service supported by Angularjs so far is still weak, providing only a locale ID format interface. Then back to the originator of native JS, how to get the browser's current language or browser UI language. In fact, the definition of the HTML5 API specification is as follows: window. Navigator. Language Returns a language tag representing the user ' s preferred language.

and specific to implementation, the implementation of each browser is very wild.

Internet Explorer

navigator.languagessorry! Temporarily not supported.

Navigator.userlanguage returns the first user-defined language that can be modified on Internet Options > General > Languages.

Navigator.browserlanguage returns the current browser UI language, which the user cannot modify. Associated with the version of the executable file selected at installation time.

Navigate.systemlanguage returns the language of the current OS.

Firefox

Navigator.language returns the first user-defined language that can be modified on Internet Options > General > Languages.

Safari

Navigator.systemlanguage in Safari. The language definition is system-level and cannot be overloaded.

Chrome

Navigator.language is very firm, not swayed by the user's preferred language, and adheres to the policy of a browser UI language. But to be fair, before writing the chrome plugin, I accidentally found an API that could return a list of user languages, an asynchronous API.

Chrome.i18n.getAcceptLanguages (function (requestedlocales) {

' Requestedlocales ' is an array of strings.

});

Unknowingly night to deep, summed up from the front-end or from the point of view of the JS user preferences of the language information has a certain degree of difficulty, mainly reflected in the lack of API and corresponding implementation of the inconsistency.

In the next section we'll talk about how to get the accept-language and weight information in the HTTP request header, and the differences between the different ways.