What are your thoughts on just using GRIT? We have experience with it and JavaScript can parse XML just fine.
2009/7/1 Jói <[email protected]>: > > 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 -~----------~----~----~----~------~----~------~--~---
