On Wed, Jul 1, 2009 at 10:56 AM, Aaron Boodman <[email protected]> wrote:
> > 2009/7/1 Jói <[email protected]>: > > 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). > > Good point. > > > 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. > > So I think this is what Cira meant by "sprintf" in his original > document. However, I have to admit I'm not crazy about that. It seems > like overkill. I prefer something simpler like $SOMETHING$. > > > 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. > > I realized that for the message format, there is one other consideration: > > We cannot parse untrusted JSON or XML in the browser, so we will need > to do this in a sandboxed process. We already have a nice mechanism > for doing this with JSON, but we'd have to come up with something new > for XML. We're already planning to do sandboxed XML for extension autoupdate, so we could depend on that too. Erik --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
