I've added new section for "Message format" - not finalized yet.Also changed format of the message container to be more extensible (separate attributes for comment, message, and type).
Thanks for suggestions, Cira P.S. I am going on a vacation today and won't be able to answer questions/suggestions for next 3 weeks. 2009/7/1 Jói <joi.sigurds...@gmail.com> > > I think it probably makes sense to use a format simpler than the .grd > format for extension developers, at least most of them. Mostly so as > not to scare them off i18n by something that might appear "big" at > first. > > You could still use GRIT to do translations of extensions, we did this > for Google Desktop gadgets where we had a fairly simple resource > format for gadgets, and then added a parser and generator to GRIT so > that the simpler format could be used as an input to GRIT and GRIT > could output translated versions of the English source file. > > Cheers, > Jói > > > On Jul 1, 10:17 am, Evan Martin <e...@chromium.org> wrote: > > 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 <joi.sigurds...@gmail.com>: > > > > > > > > > > > > > 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 athttp://xml.coverpages.org/xliff.htmlfor 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 <a...@chromium.org> wrote: > > >> On Tue, Jun 30, 2009 at 4:58 PM, Nebojša Ćirić<c...@chromium.org> > 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
