Hi cira, Thank you for getting things going :-) 2009/6/30 Aaron Boodman <[email protected]>
> Thanks for sending this out, I'm excited to see i18n happen for > extensions. Here are some thoughts: > > * I think it makes sense to use a flat file for the message > definitions. They don't have any structure, they are just a list of > name/value pairs. Each line could just be of the form > <key><space><message>. I could also see us using JSON, as we use it in > many other places, but it is a bit overkill. JSON also has the problem > that quotes have to be escaped. > > * I like your idea for the placeholder syntax. > > * Why multiple catalogs per locale? What does this buy us? It seems to > create complexity too, since conflicts can arise. > > * This document should propose a specific JavaScript API for > programmatically resolving messages. > > * The locale directory should be "_locale". There has been some debate > on the team about this, but I'm going to go on the record today with > the fact that I think all our special directories and files in the > extension should be prefixed with underscore, and we should not allow > user files to be prefixed with underscore. This sets up forward > flexibility for ourselves by giving us a namespace we can add things > to later. > > * I noticed that in the Gadgets API, there is a convention for naming > the catalogs but you also have to register them explicitly in the XML. > I don't think you should have to do this for extensions. There should > be a convention for the names of the files, end of story. So if you > name someting en_US, or en_ALL, that is its locale. Having to also > register it is dorky, I think. > > * On resource URLs, I don't think it is useful to have each locale > "implement" each URL. I'd rather have something where resource URLs > get overloaded implicitly. So if an HTML file references "foo/bar.gif" > and the current locale is "en-us", and you have an en-us folder, and > it contains a foo subfolder with a 'bar.gif', it gets used instead of > any resource that is in the root. > > I guess this implicitly makes the root folder ALL_ALL. So maybe we > don't need that one? 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. 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. 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) Jungshik > > > > wdyt? > > - a > > 2009/6/29 Nebojša Ćirić <[email protected]>: > > Hi all, > > I have initial draft for extensions internationalization effort. Take a > > look > > at > http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/i18n > > Regards, > > Nebojsa Ciric > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
