On Tue, Jun 30, 2009 at 1:13 PM, Jungshik Shin (신정식, 申政湜)<[email protected]> wrote: > I like this way of avoiding having to ALL_ALL. On the other hand, stowing > away all the resource files somewhere below root might be a good idea ? > Maybe not because existing extensions have them in the root and we don't > want to be incompatible with them.
To me it seems elegant that if you don't do any i18n at all, then you'll store your resources in the root, and they will therefore be in ALL_ALL. > Here are a couple of questions: > Can the string replacement be applied to CSS stylesheets as well? Related to > it is how to deal with RTL "layout". Perhaps, it's asking too much to expect > (external) extension developers to have separate CSS entries with 'dir=rtl'. > What does Google Gadget do for RTL UI? It'll be also interesting to see > what Fx extensions localized to RTL languges do. There is a whole section in the doc that cira linked on bidi. It seems crazy complicated, and I don't have any opinions until I digest it more. > Going a little bit tangential although still related, I wonder if we have to > expose some i18n apis for formatting date, time, region/language names. > Exposing them can prevent the inconsistency between Chrome and extensions > when it comes to formatting. It can also save some translation needs for > extensions. (how about plural formatting? aha.. it's a bit tough) I feel like we should at least try to get these things added to the web platform before diving off on an extension API. The right place for these kind of APIs would be in JavaScript I think. - a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
