[Chandler-dev] Re: Request for Coments on Chandler
Internationalization / Egg Integration Proposal
Phillip J. Eby
pje at telecommunity.com
Mon Jul 24 11:10:11 PDT 2006
At 02:23 PM 7/21/2006 -1000, Brian Kirsch wrote:
>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.
More information about the chandler-dev