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. - a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
