Whoops, we forgot to include chromium-extensions. Forwarded conversation Subject: Extensions i18n Design Doc Draft ------------------------
From: *Nebojša Ćirić* <[email protected]> Date: 2009/6/29 To: Chromium-dev <[email protected]> Cc: "Jungshik Shin (신정식, 申政湜)" <[email protected]>, Aaron Boodman < [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 ---------- From: *PhistucK* <[email protected]> Date: Mon, Jun 29, 2009 at 10:19 PM To: [email protected] Cc: Chromium-dev <[email protected]>, "Jungshik Shin (신정식, 申政湜)" <[email protected]>, Aaron Boodman <[email protected]> How about extending this support and also adding an option to use native Chrome strings that are in use in the actual program so extension developers could benefit from your own translations and corrections in the appropriate cases? ☆PhistucK 2009/6/30 Nebojša Ćirić <[email protected]> > > > ---------- From: *Nebojša Ćirić* <[email protected]> Date: Tue, Jun 30, 2009 at 8:49 AM To: PhistucK <[email protected]> Cc: Chromium-dev <[email protected]>, "Jungshik Shin (신정식, 申政湜)" <[email protected]>, Aaron Boodman <[email protected]> We could probably expose them as __chrome_MSG_some_chrome_message__, but will wait for initial review to decide that. Thanks for the input, Cira ---------- From: *PhistucK* <[email protected]> Date: Tue, Jun 30, 2009 at 8:54 AM To: Nebojša Ćirić <[email protected]> Cc: Chromium-dev <[email protected]>, "Jungshik Shin (신정식, 申政湜)" <[email protected]>, Aaron Boodman <[email protected]> But now when I come to think about it, the Chrome strings are changing sometimes, added or removed.This could pose a problem. Unless you want to start a new ground rule - all of the strings must be maintained from now on and never be removed - only added. ☆PhistucK ---------- From: *Erik Kay* <[email protected]> Date: Tue, Jun 30, 2009 at 11:15 AM To: [email protected] Cc: Nebojša Ćirić <[email protected]>, Chromium-dev < [email protected]>, "Jungshik Shin (신정식, 申政湜)" < [email protected]>, Aaron Boodman <[email protected]> In general, this is a bad plan. The translated strings are designed to be used in a particular context, and while the words themselves might make sense in multiple contexts in one language, the same wouldn't be true for another. Encouraging people outside of the project to make the call about when it makes sense to use a string in a different context or not is going to be extremely error prone. Erik ---------- From: *Aaron Boodman* <[email protected]> Date: 2009/6/30 To: Nebojša Ćirić <[email protected]> Cc: Chromium-dev <[email protected]>, "Jungshik Shin (신정식, 申政湜)" <[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? wdyt? - a 2009/6/29 Nebojša Ćirić <[email protected]>: ---------- From: *Glen Murphy* <[email protected]> Date: Tue, Jun 30, 2009 at 12:02 PM To: [email protected] Cc: [email protected], Nebojša Ćirić <[email protected]>, Chromium-dev < [email protected]>, "Jungshik Shin (신정식, 申政湜)" < [email protected]>, Aaron Boodman <[email protected]> To reinforce Erik's point - even within the team, we try to avoid reusing strings from one context in another for this very reason. ---------- From: *Jungshik Shin (신정식, 申政湜)* <[email protected]> Date: Tue, Jun 30, 2009 at 1:13 PM To: Aaron Boodman <[email protected]> Cc: Nebojša Ćirić <[email protected]>, Chromium-dev < [email protected]> Hi cira, Thank you for getting things going :-) 2009/6/30 Aaron Boodman <[email protected]> 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 ---------- From: *Aaron Boodman* <[email protected]> Date: 2009/6/30 To: "Jungshik Shin (신정식, 申政湜)" <[email protected]> Cc: Nebojša Ćirić <[email protected]>, Chromium-dev < [email protected]> 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. 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. 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 -~----------~----~----~----~------~----~------~--~---
