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

Reply via email to