At 02:23 PM 7/21/2006 -1000, Brian Kirsch wrote:
Hello,
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.
Comments in no particular order:
* getResourceAsString and getResourceAsLines don't document how encoding is
handled; must the underlying resource be ASCII, UTF-8, ...?
* getResourceAsStream claims that it is always a StringIO returned; this
seems like an implementation detail that shouldn't be exposed, and should
instead be described as a "file-like" object per Python convention.
* I would suggest making the default filename use a .ini extension rather
than .info; .info has an existing meaning and .ini more closely reflects
the file format.
* I would like to see a more prescriptive approach to domains. That is,
instead of saying "you can use whatever domain you like", I think we should
tell people what domains to use and precisely how to formulate a domain
string. While this is not an issue for the underlying implementation
(which need only handle mechanism, not policy), I think that a clear domain
policy is essential to making the overall "ecosystem" work and minimizing
the number of decisions that developers have to make and get right.
In any case, you can't *really* use "any unique string" as a domain
name. Based on implementation constraints, the string may not contain:
* line feeds
* closing square bracket ("]")
* double colons ("::")
because these would interfere with parsing of the .ini file. So, I think
we should spell out exactly what you can and can't have, and make inclusion
of the source project name mandatory, adding a dot and another name if the
project includes more than one domain. So if you have a project like
"Chandler-FeedsPlugin", then the domain should be "Chandler-FeedsPlugin",
or if there is more than one domain for the project, you would have
"Chandler-FeedsPlugin.foo", "Chandler-FeedsPlugin.bar", etc.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev