On Wed, Jul 1, 2009 at 11:12 AM, Erik Kay<[email protected]> wrote: > 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.
I don't think it's the same. For autoupdate, we only need to parse the XML so that we can pick a few fields out of it. For i18n, we need to actually use the XML later, at runtime. We don't want to convert it to some other format because we also need to handle the --load-extension case, where we won't want to convert to an intermediate format. This means we need to sanitize the XML, more like what we do with the manifest today. So we'd need to serialize it to some intermediate format and send it back to the browser process. We already have a way to do this for JSON -- I'm just saying we'd need to do something similar for XML. - a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
