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
projects.
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.
Thanks!
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
system.
Cheers,
Markku
-Brian
--
Brian Kirsch
Internationalization Architect/ Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
