[Dev] I18n LocalizableString update

[Brian Kirsch]

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 Bytes


In 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. Text

Unicode 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