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.
Flat files are usually formatted as key<TAB>value1<TAB>...<CR>. I would hate to see people using SPACEs instead of TABs... Also, it's hard to extend format later on since it's pretty rigid. > * Why multiple catalogs per locale? What does this buy us? It seems to > create complexity too, since conflicts can arise. We could provide generic catalog with - OK, Save, Cancel, Your extension version is..., Open,... and help developers with that first hurdle. This would kinda help with the use case PhistucK proposed - exporting Chrome messages. Then developer could have separate catalog with extension specific messages. * This document should propose a specific JavaScript API for > programmatically resolving messages. > Will try to add that soon. > > * 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. Done. > > * 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. > I think I said that Gadgets do that but we wouldn't since we a) don't have where to register them, b) as you said we don't need them if we name files properly. I agree with you, I should probably restate this better in the doc. > * 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. Sounds good. Nick Baum proposed similar approach for local resources. For external resources, we should keep message replacement system. I've split URI replacement section with External/Internal resources. > > I guess this implicitly makes the root folder ALL_ALL. So maybe we > don't need that one? > Right. It's going to become a special case in the code, but it would simplify development process (and it would make _locale/ non-empty folder). > > 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 -~----------~----~----~----~------~----~------~--~---
