>
> * This document should propose a specific JavaScript API for
> programmatically resolving messages.
>
What do you thing about having a getMsg(key, optional_namespace) function
for JavaScript API (similar to gadgets api)?
So for __MSG_greeting__ script would call getMsg("greeting"), and get
translation for current locale.
Namespace would be necessary only if we go with multiple catalogs.
Any other use cases?
Cira
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?
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
