Hello,With the current changes to the architecture as well as some issues that have cropped up, the Chandler translation mechanism is going to be changing.
Originally a LocalizableString type was defined that would perform on the fly translations when converted to unicode.
The motivation for this type was: 1. It could be leveraged in parcel.xml and Python schema easily 2. It would allow Chandler to switch language / locales on the fly.By implementing the __unicode__ method on LocalizableString it was thought, wx would be smart enough to handle the conversion of LocalizableString to unicode for display. This turned out not to be the case. To work around this developers need to manually cast the LocalizableString to unicode i.e. unicode(_("This is translatable text")). This is less than ideal.
So with the removal of parcel.xml and given the casting issues with wx, it is better to have in-line translations that return unicode rather than LocalizableStrings. The one disadvantage of this approach is Chandler no longer be able to dynamically switch locales on the fly.
But I think this trade off is worth it. So here is the proposed change: 1. No more LocalizableString type 2. No more Text alias 3. UString renamed to either Unicode or Text (See below for more details) 4. BString renamed to BytesIn the schema example below, the _() method returns a translated unicode string for the current locale Chandler is running under. This translation is stored in the Repository as a Unicode or Text type (again see below for more details).
>>> from i18n import OSAFMessageFactory as _
>>> schema.One(schema.Unicode, _("this is translatable Text"))
Switching to a different language would require Chandler to reload its
parcels.
In Python code such as wx Dialogs, _() method would return a translated unicode string for the current Chandler locale as well. This translated unicode string can be used directly by wx and any other API expecting unicode.
>>> from i18n import OSAFMessageFactory as _ >>> import wx>>> wx.MessageDialog(parent, _("This is the translated message"), _("this is a translated caption), wx.OK | wx.ICON_INFORMATION)
The proposed simplification will make developers lives easier and result in a cleaner API overall for Chandler.
Unicode vs. Text ==============Currently, There are two types UString and LocalizableString. UString contains unicode text and LocalizableString contains the defaultText key to use for translation. There is an Alias named Text that accepts either a UString or a LocalizableString. This allows a Kind to determine whether an attribute requires translation on an instance by instance basis. If the instance attribute requires translation assign its Text alias a LocalizableString otherwise assign it a UString.
The LocalizableString and Text alias will be deprecated with the proposed change which leaves UString. This type will be for User displayable text and will replace the soon to be deprecated String type.
So what to name this type? The two suggestions currently floating around other than UString are: 1. Unicode 2. TextUnicode is nice cause it is straight and to the point and will be easily understandable by developers familiar with what Unicode is.
Text on the other hand is a bit simpler for the beginning developer to understand but is not descriptive on the types it accepts.
For example, passing a Python str to a proposed Text type will raise an error on Repository commit since the type only accepts unicode.
So the question is do we go with a descriptive (Unicode) or simplistic (Text) approach.
Your feedback is welcomed, -Brian -- Brian Kirsch - Email Framework Engineer Open Source Applications Foundation 543 Howard St. 5th Floor San Francisco, CA 94105 (415) 946-3056 http://www.osafoundation.org _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
