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.
* 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.
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...
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.
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.
Cheers,
Markku
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
