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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
