[Dev] Re: new schema type Python syntax

[Phillip J. Eby]

At 11:52 AM 7/28/2005 -1000, Brian Kirsch wrote:
>Ok I buy that. What's nice about that to is if all LocalizableString are 
>wrapped in _() then it is easy to tell in a schema definition whether the 
>assignment was a uString or LocalizableString. i.e.
>
>Schema.One(Schema.Text, initialValue = u"This is a UString")
>
>Schema.One(Schema.Text, initialValue = _(u"This is a Localizable String"))
>
>Given all the changes to the parcel / gettext lookup strategy I think it 
>is worth reinvestigating how a message would be registered globally such 
>that any parcel could access it. For example "Can not connect to Server" 
>is generic and should exist as a root message which any parcel can utilize.
>
>Since the _() uses the module (aka parcel) path to find where the 
>translation file is located how would a parcel reference a root level 
>message. The two ideas I can think off of the top of my head are:
>
>1. create all definitions at the parcel root and provide Python variable 
>references to the translations. This is basically what is currently 
>proposed in the i18n spec.
>
>So the root level of the parcel hierarchy would have a definition such as :
>
>CANNOT_CONNECT_TO_SERVER = _(u"Unable to connect to server")
>
>
>A parcel would import the root messages ie.:
>
>import messages
>
>alert(messages.CANNOT_CONNECT_TO_SERVER))

I don't see any reason this has to be restricted to a particular location; 
importing a message constant from any part of the hierarchy would be fine.



>Each approach has advantages and disadvantages.
>
>The first approach has the advantage of only defining the translation 
>once. This prevents parcel developers from typo's and case issues.
>"Unable to connect" and "unable to connect" are treated as two distinct 
>keys by gettext. The first approach has the disadvantage of global 
>definitions only being assignable at the parcel root. This is a bit inflexible.

So, we allow them to be anywhere.  Over time, we'll work out best practices 
for where to put them so that not *everything* exports messages.  It may be 
that we include a 'messages' module in packages, or something of that 
sort.  However, this is more a policy decision than a technical one, and 
there's no need to limit (technically) where messages can be offered.


>Of course the whole reason for having a _() creation short cut was to 
>prevent developers from the burden of having to define simple info and 
>error messages in parcel.xml.
>
>If parcel.xml is going away then do we even need _()? It is simple to 
>define a LocalizableString in Python.

This is what I've been assuming '_' would translate to:

     from i18n import LocalizableString as _

i.e., we don't need gettext to provide '_', and I have been proposing that 
'_()' be implemented as a factory that returns a LocalizableString.