On Wed, Jul 1, 2009 at 11:12 AM, Erik Kay<erikkay <at> chromium.org
> On Wed, Jul 1, 2009 at 10:56 AM, Aaron Boodman <aa <at> chromium.org
>> 2009/7/1 Jói <joi.sigurdsson <at> gmail.com
>> > 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
>> > 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.