This issue seems more like a feature request and hence marking it as untriaged.

Thanks !

I'm agree with that.
Also in general I can try to implement it by my own, but I'm not sure if I need to recreate it as a feature request or something like that?

I'm not sure if we actually want to do this or not, given that you can always fetch the _locales/<locale name>/messages.json file and get an entry from it using JSON.parse; see here for example code:

https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/Dpx7SCbINe4/7V6KLfSyAgAJ

Certainly providing an API for this is more convenient, but I don't know that it's actually that common a use case that it would be worth it to have. (This is the first request I can recall hearing for it). 


+cc some other folks who might have an opinion one way or the other

It just doesn't make sense to use chrome i18n api in this case because json file format is inconvenient to use from your code. The only thing I can use it for is to detect which locale in user's browser is set. That's it. I don't want to load the locale file in each part of my extension manually (options page, browser action, content script...).

From my point providing possibility to set locale using api would be realy useful. It is not a good approach to limit user with a specific locale which is set in the browser, it is good to use browser's locale by default but not as the only option.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Supporting specified locale for i18n.getMessage is very valuable not only for developers but also for users.

For example, developers.google.com, www.google.com, Android app, iOS app, all these web sites or mobile apps user can change their language, no matter what the default OS language or web browser's language settings. User's choice is the highest priority.

Although I don't have the exact number, a large percentage of people use multiple languages. For example, many people can read and write English, but English is not their native language.

About i18n, user should can select which language to use in the site or app, instead of everything on the OS/Browser use the same language.

About chrome.i18n api, it could supply a locale parameter for getMessage. A more common situation is that user set the default locale for this app/extension, then all getMessage return this locale message. Thus chrome could supply a i18n.setDefaultLocale(locale) api. In addition, sometime user would like a different locale to display at a specific place, like format Date and Time that has very rich choices for different locale. In this situation user may use a specified locale for date and time. In conclusion, i18n has many complicated places, so supplying flexible apis is useful not only for developers but also for users. Since chrome already provides chrome.i18n api, use it is the best choice instead of going to build another plan by extension developers.