Sorry to jump in a bit late. I'm really glad to see i18n of extensions being addressed so early on. I have a couple of high-level comments on the format used for the catalogs, based on my experience writing GRIT.
It's likely that whatever file format is used will end up as a source file for localization, since most extension authors will just use our format directly rather than generating it from some more fully-featured format. To this end, the format should include at least the following: a) A way to add a description of the message for translators (some kind of attribute that is empty by default); someone already mentioned this. b) A way to distinguish between two messages that are textually the same, but have separate meanings, e.g. "Open" (as a verb) and "Open" (as an adjective). An attribute of the message that is empty by default is ideal. I would keep this separate from the description attribute, as this facilitates calculating a message ID as a hash over the message contents plus the 'meaning' attribute (this is a useful approach to avoid translating each message more than once, see how it is used in GRIT). c) A way to demarcate bits of the message that should not be translated - generally these are called "placeholders" but that conflicts with how that term is currently used in the document. It's important to do this, otherwise translators are going to receive messages that contain "code" bits that shouldn't be translated, and which will cause errors in the running program if they are incorrectly translated. Consider for example a message like "Hello $USER$, how are you?" and the implications if the translator translates $USER$. Ideally, you could use a format such as XML which allows the extension author to mark any piece of text as a placeholder, but for a simpler approach compatible with more formats, you could require a specific format for non-translateables, e.g. $SOMETHING$ and/or printf-style format specifiers. For more ideas on the resource format, you could look at GRIT's .grd format or at http://xml.coverpages.org/xliff.html for inspiration. Both are probably more complex than what we'd like to have for extension message catalogs, and so as long as the format supports the things I mentioned above, I believe it should be fine. Finally, keep in mind that messages may contain embedded line-breaks, so it's good to have a format that supports this naturally. Cheers, Jói On Jun 30, 8:01 pm, Aaron Boodman <[email protected]> wrote: > On Tue, Jun 30, 2009 at 4:58 PM, Nebojša Ćirić<[email protected]> wrote: > >> * This document should propose a specific JavaScript API for > >> programmatically resolving messages. > > > What do you thing about having a getMsg(key, optional_namespace) function > > for JavaScript API (similar to gadgets api)? > > So for __MSG_greeting__ script would call getMsg("greeting"), and get > > translation for current locale. > > Namespace would be necessary only if we go with multiple catalogs. > > sgtm. I think chrome.i18n.getMessage("greeting") would fit better with > our other APIs. > > - a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
