[Chandler-dev] Re: Request for Coments on Chandler
Internationalization / Egg Integration Proposal
bkirsch at osafoundation.org
Tue Jul 25 12:41:06 PDT 2006
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
> 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
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":
> 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:
> 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
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
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
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
> 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
Internationalization Architect/ Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
More information about the chandler-dev