[Chandler-dev] Re: Request for Coments on Chandler Internationalization / Egg Integration Proposal

Brian Kirsch bkirsch at osafoundation.org
Tue Jul 25 12:41:06 PDT 2006

Hi Markku,
See comments in line.

Markku Mielityinen wrote:

> Hi Brian,
>> Attached is a proposal for the Egg I18n API as well as how to 
>> integrate the Egg I18n API in to Chandler.
>> The Egg I18n API's intent is to provide an easy and  robust means to 
>> localize Python applications and
>> would be distributed as a separate module / egg from Chandler.
>> The majority of the work detailed in the proposal has already been done.
>> I welcome comments / suggestions on the EggResourceManager API as 
>> well as on my proposal on how
>> to integrate this functionality in to the current Chandler I18n 
>> Architecture.
> I read your proposal and found it to be very good. I was happy to 
> learn that whereas you have made a lot of cool improvements, most of 
> the design ideas that I proposed in my original prototype are still in 
> place, although some of them have been renamed to be more pythonic. 
> Here are some observations that I made from your proposal.
>    * You have kept "all" locale instead of replacing it with "default" 
> locale, as we previously discussed. I think that now that you have 
> removed the distinction between localized and non-localized resources, 
> and I assume that all non-localized resources are now placed in the 
> "all" locale, the name "all" is more intuitive than the name 
> "default". Of course I am not a native English speaker so we should 
> get comments from others as well.

Actually I am open to either approach. I like 'default' since its name 
implies that it is the default if
no other options i.e. localizations are available. However, 'all' ties 
nicely to the common locale environmental
variable 'LC_ALL'.

Does anyone have an opinion or suggestion on this?

>    * I saw no documentation about the direct file access to resources 
> in eggs, which is provided through wx.FileSystem. I think that this is 
> a cool and easy way to access resources and as I assume that this 
> service is still available, I would like to see this part of the 
> documentation/proposal improved. Otherwise, how do you propose we 
> implement HTML and XRC loading from a resource egg? My original 
> proposition, which I now modify to meet your changes, was to use 
> wx.FileSystem to provide an "eggres" file source, which is very 
> similar to "http" and "ftp" file sources that are used for Internet 
> file access. In this case "eggres" just allows direct references to 
> files inside (an/a compressed) egg resources file, which I think you 
> need if you want to have websites, xml based user interfaces, or any 
> other type of files that refer to other files inside the resource.
Actually I did document the use of the wx.FileSystem. I decided since it 
was a wxPython specific addition not to include it in the
EggResourceManager API but instead make it part of the sub-class 
I18nManager. This seemed the best approach for now.

 From the I18nManager section of the proposal:

5. Adding a wx.FileSystem handler for retrieving resources
   defined in HTML or XRC

> This example shows how easy it is to load a website index file 
> "index.html"" from domain "mydomain":
> wx.html.HtmlWindow..LoadPage(u"mydomain#eggres:index.html")
> As we can see, there is no need to use any i18n specific API here...
I am going to play with the syntax a bit for building the URL string. I 
think it can be simplified
and made a little cleaner. But the ability to load resources in an HTML 
Pane or XRC is a great feature
and will be leveraged for sure in Chandler.

> This example shows how you can set up an XRC resource directly above 
> the egg layer; we load a dialog that is described in "myxrcdialog.xrc" 
> in "mydomain" domain:
> wx.xrc.XmlResource(u"mydomain#eggres:myxrcdialog.xrc")
> Again there is no need to use any i18n specific API here...
> In both cases it is worth noting that index.html and myxrcdialog.xrc 
> are not direct filenames but instead resource name keys that are 
> routed to real filenames inside the eggs based on locale settings. 
> This means that we can localize an entire website or XRC resource in a 
> way that is transparent to the coder (see the examples above).
> * It seems that you now agree with my original idea that we should 
> move some low-level implementation from i18n package to "Egg I18n 
> API". I think that this makes the design much more clear and easier to 
> manage in the future.

That was always the intent. The underlying API had to be tweaked though. 
Your proposal if I remember correctly was to get rid or the I18nManager 
and MessageFactories and just use the egg API. My proposal is actually a 
bit different.

I want to keep the current design of the Chandler I18n architecture as I 
think it is just what we need. I went
and molded the egg API in to the EggResourceManager to fit our needs. It 
was always intended that
the Chandler I18nManager would be a container for an underlying 
localization mechanism.

Where ever there was redundency in the current I18nManger and the 
proposed EggResourceManager I
moved the functionality to the EggResourceManager so it can be leverage 
by other Open Source Python

Using MessageFactories and an I18nManager serves a few purposes.

1. It is easier for Chandler developers to use than the underlying 
EggResourceManager API.
2. A number of Chandler specific features can be added such as defaults 
for resources and localization loading.
3. It allows the use of higher level packages such as wxPython and PyICU 
which are not suitable for
    a generic resource loader.
4. It does not tie Chandler to resource loading via eggs. The 
architecture is flexible enough that
    alternate resource and localization loading mechanisms can be added 
with out any changes to the
    external API.

> Good work Brian, you get +1 from me. When do you expect the 
> implementation to be ready? I am anxious to complete my own i18n 
> threads, which require the "Egg I18n API" to be available in Chandler.


I expect to have all the coding done by Friday, write the unit tests on 
Monday, then work with bear to get the changes folded in to our build 

> Cheers,

>    Markku


Brian Kirsch 
Internationalization Architect/ Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105

More information about the chandler-dev mailing list