gecko-dev/intl/locale/LocaleService.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

175 строки
5.9 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode:nil; c-basic-offset: 2 -*- */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef mozilla_intl_LocaleService_h__
#define mozilla_intl_LocaleService_h__
#include "nsIObserver.h"
#include "nsString.h"
#include "nsTArray.h"
#include "nsWeakReference.h"
#include "mozILocaleService.h"
namespace mozilla {
namespace intl {
/**
* LocaleService is a manager of language negotiation in Gecko.
*
* It's intended to be the core place for collecting available and
* requested languages and negotiating them to produce a fallback
* chain of locales for the application.
*
Bug 1348042 - Refactor LocaleService to operate in server-client mode. r=Ehsan,qdot LocaleService serves two main functions. It is a central place for all code in the engine to learn about locales, but it also does the language negotiation and selection. The former is relevant in all processes, but the latter should only be performed by the "main" process. In case of current Desktop Firefox, the parent process is the one performing all the language negotiation, and content processes should operate in the "client" mode. In Fennec, there's a Java app on top of Gecko which should work as a "server" and then all processes, including parent process of Gecko is merely a "client" for that. This refactor finalizes this duality making it easily configurable to define in which mode a given LocaleService operates. The server-client model allows all clients to stay in sync with the server, but operate transparently for all callers just returning the right values. In order to initialize LocaleService in the client mode in child process with the right locales I'm adding the list of app locales to the XPCOMInitData, and then fire LocaleService::SetAppLocales in the child process initialization. In order to keep the list up to date, I'm adding intl:app-locales-changed to the list of observed topics, and when triggered, I send the updated list to the child process, which updates LocaleService::SetAppLocales with the new list. MozReview-Commit-ID: K9X6berF3IO --HG-- extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
2017-03-26 08:09:45 +03:00
* Client / Server
*
* LocaleService may operate in one of two modes:
*
* server
* in the server mode, LocaleService is collecting and negotiating
* languages. It also subscribes to relevant observers.
* There should be at most one server per application instance.
*
* client
* in the client mode, LocaleService is not responsible for collecting
* or reacting to any system changes. It still distributes information
* about locales, but internally, it gets information from the server
* instance instead of collecting it on its own. This prevents any data
* desynchronization and minimizes the cost of running the service.
*
* In both modes, all get* methods should work the same way and all
* static methods are available.
*
* In the server mode, other components may inform LocaleService about their
* status either via calls to set* methods or via observer events.
* In the client mode, only the process communication should provide data
* to the LocaleService.
*
* At the moment desktop apps use the parent process in the server mode, and
* content processes in the client mode.
*
* Locale / Language
*
* The terms `Locale ID` and `Language ID` are used slightly differently
* by different organizations. Mozilla uses the term `Language ID` to describe
* a string that contains information about the language itself, script,
* region and variant. For example "en-Latn-US-mac" is a correct Language ID.
*
* Locale ID contains a Language ID plus a number of extension tags that
* contain information that go beyond language inforamation such as
* preferred currency, date/time formatting etc.
*
* An example of a Locale ID is `en-Latn-US-x-hc-h12-ca-gregory`
*
* At the moment we do not support full extension tag system, but we
* try to be specific when naming APIs, so the service is for locales,
* but we negotiate between languages etc.
*/
class LocaleService final : public mozILocaleService,
public nsIObserver,
public nsSupportsWeakReference {
public:
NS_DECL_ISUPPORTS
NS_DECL_NSIOBSERVER
NS_DECL_MOZILOCALESERVICE
/**
* List of available language negotiation strategies.
*
* See the mozILocaleService.idl for detailed description of the
* strategies.
*/
static const int32_t kLangNegStrategyFiltering = 0;
static const int32_t kLangNegStrategyMatching = 1;
static const int32_t kLangNegStrategyLookup = 2;
Bug 1348042 - Refactor LocaleService to operate in server-client mode. r=Ehsan,qdot LocaleService serves two main functions. It is a central place for all code in the engine to learn about locales, but it also does the language negotiation and selection. The former is relevant in all processes, but the latter should only be performed by the "main" process. In case of current Desktop Firefox, the parent process is the one performing all the language negotiation, and content processes should operate in the "client" mode. In Fennec, there's a Java app on top of Gecko which should work as a "server" and then all processes, including parent process of Gecko is merely a "client" for that. This refactor finalizes this duality making it easily configurable to define in which mode a given LocaleService operates. The server-client model allows all clients to stay in sync with the server, but operate transparently for all callers just returning the right values. In order to initialize LocaleService in the client mode in child process with the right locales I'm adding the list of app locales to the XPCOMInitData, and then fire LocaleService::SetAppLocales in the child process initialization. In order to keep the list up to date, I'm adding intl:app-locales-changed to the list of observed topics, and when triggered, I send the updated list to the child process, which updates LocaleService::SetAppLocales with the new list. MozReview-Commit-ID: K9X6berF3IO --HG-- extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
2017-03-26 08:09:45 +03:00
explicit LocaleService(bool aIsServer);
/**
* Create (if necessary) and return a raw pointer to the singleton instance.
* Use this accessor in C++ code that just wants to call a method on the
* instance, but does not need to hold a reference, as in
* nsAutoCString str;
* LocaleService::GetInstance()->GetAppLocaleAsLangTag(str);
*/
static LocaleService* GetInstance();
/**
* Return an addRef'd pointer to the singleton instance. This is used by the
* XPCOM constructor that exists to support usage from JS.
*/
static already_AddRefed<LocaleService> GetInstanceAddRefed() {
return RefPtr<LocaleService>(GetInstance()).forget();
}
Bug 1348042 - Refactor LocaleService to operate in server-client mode. r=Ehsan,qdot LocaleService serves two main functions. It is a central place for all code in the engine to learn about locales, but it also does the language negotiation and selection. The former is relevant in all processes, but the latter should only be performed by the "main" process. In case of current Desktop Firefox, the parent process is the one performing all the language negotiation, and content processes should operate in the "client" mode. In Fennec, there's a Java app on top of Gecko which should work as a "server" and then all processes, including parent process of Gecko is merely a "client" for that. This refactor finalizes this duality making it easily configurable to define in which mode a given LocaleService operates. The server-client model allows all clients to stay in sync with the server, but operate transparently for all callers just returning the right values. In order to initialize LocaleService in the client mode in child process with the right locales I'm adding the list of app locales to the XPCOMInitData, and then fire LocaleService::SetAppLocales in the child process initialization. In order to keep the list up to date, I'm adding intl:app-locales-changed to the list of observed topics, and when triggered, I send the updated list to the child process, which updates LocaleService::SetAppLocales with the new list. MozReview-Commit-ID: K9X6berF3IO --HG-- extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
2017-03-26 08:09:45 +03:00
/**
* This method should only be called in the client mode.
*
* It replaces all the language negotiation and is supposed to be called
* in order to bring the client LocaleService in sync with the server
* LocaleService.
*
* Currently, it's called by the IPC code.
*/
void AssignAppLocales(const nsTArray<nsCString>& aAppLocales);
void AssignRequestedLocales(const nsTArray<nsCString>& aRequestedLocales);
/**
* Those two functions allow to trigger cache invalidation on one of the
Bug 1348042 - Refactor LocaleService to operate in server-client mode. r=Ehsan,qdot LocaleService serves two main functions. It is a central place for all code in the engine to learn about locales, but it also does the language negotiation and selection. The former is relevant in all processes, but the latter should only be performed by the "main" process. In case of current Desktop Firefox, the parent process is the one performing all the language negotiation, and content processes should operate in the "client" mode. In Fennec, there's a Java app on top of Gecko which should work as a "server" and then all processes, including parent process of Gecko is merely a "client" for that. This refactor finalizes this duality making it easily configurable to define in which mode a given LocaleService operates. The server-client model allows all clients to stay in sync with the server, but operate transparently for all callers just returning the right values. In order to initialize LocaleService in the client mode in child process with the right locales I'm adding the list of app locales to the XPCOMInitData, and then fire LocaleService::SetAppLocales in the child process initialization. In order to keep the list up to date, I'm adding intl:app-locales-changed to the list of observed topics, and when triggered, I send the updated list to the child process, which updates LocaleService::SetAppLocales with the new list. MozReview-Commit-ID: K9X6berF3IO --HG-- extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
2017-03-26 08:09:45 +03:00
* three cached values.
*
* In most cases, the functions will be called by the observer in
* LocaleService itself, but in a couple special cases, we have the
* other component call this manually instead of sending a global event.
*
* If the result differs from the previous list, it will additionally
Bug 1348042 - Refactor LocaleService to operate in server-client mode. r=Ehsan,qdot LocaleService serves two main functions. It is a central place for all code in the engine to learn about locales, but it also does the language negotiation and selection. The former is relevant in all processes, but the latter should only be performed by the "main" process. In case of current Desktop Firefox, the parent process is the one performing all the language negotiation, and content processes should operate in the "client" mode. In Fennec, there's a Java app on top of Gecko which should work as a "server" and then all processes, including parent process of Gecko is merely a "client" for that. This refactor finalizes this duality making it easily configurable to define in which mode a given LocaleService operates. The server-client model allows all clients to stay in sync with the server, but operate transparently for all callers just returning the right values. In order to initialize LocaleService in the client mode in child process with the right locales I'm adding the list of app locales to the XPCOMInitData, and then fire LocaleService::SetAppLocales in the child process initialization. In order to keep the list up to date, I'm adding intl:app-locales-changed to the list of observed topics, and when triggered, I send the updated list to the child process, which updates LocaleService::SetAppLocales with the new list. MozReview-Commit-ID: K9X6berF3IO --HG-- extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
2017-03-26 08:09:45 +03:00
* trigger a corresponding event
*
* This code should be called only in the server mode..
*/
void RequestedLocalesChanged();
void LocalesChanged();
/**
* This function keeps the pref setting updated.
*/
void WebExposedLocalesChanged();
/**
* Returns whether the current app locale is RTL.
*/
bool IsAppLocaleRTL();
static bool LanguagesMatch(const nsACString& aRequested,
const nsACString& aAvailable);
Bug 1348042 - Refactor LocaleService to operate in server-client mode. r=Ehsan,qdot LocaleService serves two main functions. It is a central place for all code in the engine to learn about locales, but it also does the language negotiation and selection. The former is relevant in all processes, but the latter should only be performed by the "main" process. In case of current Desktop Firefox, the parent process is the one performing all the language negotiation, and content processes should operate in the "client" mode. In Fennec, there's a Java app on top of Gecko which should work as a "server" and then all processes, including parent process of Gecko is merely a "client" for that. This refactor finalizes this duality making it easily configurable to define in which mode a given LocaleService operates. The server-client model allows all clients to stay in sync with the server, but operate transparently for all callers just returning the right values. In order to initialize LocaleService in the client mode in child process with the right locales I'm adding the list of app locales to the XPCOMInitData, and then fire LocaleService::SetAppLocales in the child process initialization. In order to keep the list up to date, I'm adding intl:app-locales-changed to the list of observed topics, and when triggered, I send the updated list to the child process, which updates LocaleService::SetAppLocales with the new list. MozReview-Commit-ID: K9X6berF3IO --HG-- extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
2017-03-26 08:09:45 +03:00
bool IsServer();
private:
void FilterMatches(const nsTArray<nsCString>& aRequested,
const nsTArray<nsCString>& aAvailable, int32_t aStrategy,
nsTArray<nsCString>& aRetVal);
void NegotiateAppLocales(nsTArray<nsCString>& aRetVal);
void InitPackagedLocales();
virtual ~LocaleService();
nsAutoCStringN<16> mDefaultLocale;
nsTArray<nsCString> mAppLocales;
Bug 1348042 - Refactor LocaleService to operate in server-client mode. r=Ehsan,qdot LocaleService serves two main functions. It is a central place for all code in the engine to learn about locales, but it also does the language negotiation and selection. The former is relevant in all processes, but the latter should only be performed by the "main" process. In case of current Desktop Firefox, the parent process is the one performing all the language negotiation, and content processes should operate in the "client" mode. In Fennec, there's a Java app on top of Gecko which should work as a "server" and then all processes, including parent process of Gecko is merely a "client" for that. This refactor finalizes this duality making it easily configurable to define in which mode a given LocaleService operates. The server-client model allows all clients to stay in sync with the server, but operate transparently for all callers just returning the right values. In order to initialize LocaleService in the client mode in child process with the right locales I'm adding the list of app locales to the XPCOMInitData, and then fire LocaleService::SetAppLocales in the child process initialization. In order to keep the list up to date, I'm adding intl:app-locales-changed to the list of observed topics, and when triggered, I send the updated list to the child process, which updates LocaleService::SetAppLocales with the new list. MozReview-Commit-ID: K9X6berF3IO --HG-- extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
2017-03-26 08:09:45 +03:00
nsTArray<nsCString> mRequestedLocales;
nsTArray<nsCString> mAvailableLocales;
nsTArray<nsCString> mPackagedLocales;
nsTArray<nsCString> mWebExposedLocales;
Bug 1348042 - Refactor LocaleService to operate in server-client mode. r=Ehsan,qdot LocaleService serves two main functions. It is a central place for all code in the engine to learn about locales, but it also does the language negotiation and selection. The former is relevant in all processes, but the latter should only be performed by the "main" process. In case of current Desktop Firefox, the parent process is the one performing all the language negotiation, and content processes should operate in the "client" mode. In Fennec, there's a Java app on top of Gecko which should work as a "server" and then all processes, including parent process of Gecko is merely a "client" for that. This refactor finalizes this duality making it easily configurable to define in which mode a given LocaleService operates. The server-client model allows all clients to stay in sync with the server, but operate transparently for all callers just returning the right values. In order to initialize LocaleService in the client mode in child process with the right locales I'm adding the list of app locales to the XPCOMInitData, and then fire LocaleService::SetAppLocales in the child process initialization. In order to keep the list up to date, I'm adding intl:app-locales-changed to the list of observed topics, and when triggered, I send the updated list to the child process, which updates LocaleService::SetAppLocales with the new list. MozReview-Commit-ID: K9X6berF3IO --HG-- extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
2017-03-26 08:09:45 +03:00
const bool mIsServer;
static StaticRefPtr<LocaleService> sInstance;
};
} // namespace intl
} // namespace mozilla
#endif /* mozilla_intl_LocaleService_h__ */