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=.
