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
