__MSG_*__ macro would be more helpful while creating some static html.
- Thangaraju R On Nov 11, 1:17 am, Aaron Boodman <a...@chromium.org> wrote: > We need to have basic i18n for extensions for the stable release, but > our constraints are: > > a) Time is tight > b) We should not slow down Chrome startup (eg by loading message > catalogs early in startup) > c) We should not do something that is incompatible with our eventual i18n > vision > > Here is a proposal that I think meets these constraints: > > 1. Use the same message catalog layout we had before (_locales > directory, one JSON catalog per locale, we find them by crawling the > directory structure). This means we will be forward compatible. > > 2. Support i18n in text fields of the manifest (name, description, > browser and page default titles, browser action default badge). These > fields cannot be internationalized by developers any other way, so we > need to support this at a minimum. > > 3. Support chrome.i18n.getMessage(). This allows developers to i18n > the rest of their extension manually. > > Implementation notes: > > In order to avoid slowing down Chrome startup, I think we need to > store the manifest in the preferences already localized. So basically, > somewhere during extension installation, we need to localize the > manifest and store it that way. Whenever the current locale in Chrome > changes, we must re-localize from the version stored on disk. > > chrome.i18n.getMessage() is spec'd to be synchronous, which seems very > useful. In order to support this, it means that we must load the > message catalogs before the extension process is started. > > Thoughts? > > - a -- You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to chromium-extensi...@googlegroups.com. To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
