[Dev] Re: new schema type Python syntax

[Andi Vajda]

Could we please, please, please *not* use _() as this blows away the python 
shell's _ symbol which is conveniently the last value returned (like Lisp's 
*). It makes debugging that much harder.

Thanks !

Andi..

On Thu, 28 Jul 2005, Brian Kirsch wrote:

>
>
>
> Phillip J. Eby wrote:
>
>> At 10:59 AM 7/28/2005 -1000, Brian Kirsch wrote:
>> 
>>> Phillip J. Eby wrote:
>>> 
>>>> At 10:06 AM 7/28/2005 -1000, Brian Kirsch wrote:
>>>> 
>>>>> I am not sure. Using the Text alias is nice since it makes things 
>>>>> simple. I am open to feedback / suggestions on this one.
>>>> 
>>>> 
>>>> 
>>>> The parcel issues should go away soon; John has now joined the "let's use 
>>>> Python instead of parcel.xml" movement, and I don't think there are many 
>>>> other people against it.  When parcel.xml goes away then the file/line 
>>>> issue goes away too, since _("text") can set the parcel (by looking at 
>>>> the __name__ of the module it is called from).
>>> 
>>> 
>>> Great. That makes things much easier.
>>> 
>>> 
>>>> Also, it incidentally means that all localizable strings will be 
>>>> extractable from the Python source.
>>> 
>>> 
>>> Can you go in to more detail on this?
>>> 
>>> What would the advantage be of extracting all LocalizableStrings from 
>>> Python source since we still want to leverage the repository for 
>>> LocalizableString storage.
>> 
>> 
>> Well, since all the strings will *be* in the source, it would be the 
>> obvious place to extract them from, since we'd need to for runtime-only 
>> messages anyway.  So extracting them all from source guarantees none will 
>> be missed, and avoids any redundancy.
>> 
>> Whether you then *put* the strings you extracted into the repository is 
>> entirely orthogonal.  I'm just suggesting that extracting them all direct 
>> from the source is a convenient way to get them for whatever other 
>> processing you want to do, at least once we're not using parcel.xml any 
>> more.
>> 
>> It's fairly easy to extract the strings using the Python 
>> "tokenize.generate_tokens(input_file.readline)" function.  Just loop over 
>> the tokens looking for '_' followed by '(', one or more string/unicode 
>> tokens, and ')'.  Part of the data that's produced by the function is 
>> line/column start+end info for each token, so that's about everything you 
>> need.
>> 
>
> 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))
>
>
> 2. Add an additional argument to _() to specify adding it to the global 
> lookup space. I can then define global messages from any parcel
>
> in my parcel I have something like this:
>
> CANNOT_CONNECT_TO_SERVER = _(u"Unable to connect to server", global=True)
>
>
> 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.
>
>
> The second approach has the advantage of any parcel can define globals. The 
> disadvantage is that the case and typo issues mentioned above come in to 
> play.
>
> 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.
>
> From schema:
> cantConnect = Schema.One(Schema.Text, initialValue=u"Unable to connect to 
> server")
>
> Instance creation:
> dnsError = LocalizableString(u"No host found matching that name")
>
>
> The LocalizableString is the one doing the translation lookup in its 
> __unicode__ method.
>
> def __unicode__(self):
>    return I18nManager.translate(self.itsPath, self.defaultText)
>
>
> Thoughts?
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>