[Chandler-dev] Re: Request for Coments on Chandler Internationalization / Egg Integration Proposal

[Phillip J. Eby]

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.