On Wed, Jul 1, 2009 at 11:34 AM, Aaron Boodman <[email protected]> wrote:
> 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. Fair enough. I guess all I was saying is that we're going to be doing sandboxed parsing of XML already. Rewriting it as part of that work doesn't seem like a large addition. Erik --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
