[Dev] Interationalization Schema Update

[Brian Kirsch]

Aloha,
Earlier today a group of use met to go over i18n changes needed to the 
Chandler schema.

The result of the discussion was to create a new alias schema.Text. This 
alias would accept either LocalizableString or UString types.

All attributes which are currently of type String would be migrated to 
the new schema.Text type. If an attribute of type schema.Text is passed 
a LocalizableString it indicates the content needs translation. If it is 
passed a UString then the content does not require translation.

The schema.Text type will raise an error if assigned either a Python 
unicode or str object. It only accepts LocalizableString's and UString's.

The new LocalizableString type which was going to be represented as a 
Kind would now be represented as a Repository struct.
This change will improve performance and offer compatibility with the 
schema.Text alias.

So how will Chandler benefit from this change?

Lets take the Item Collections on the Sidebar. There are two types of 
collections:

1. Chandler collections All, In, and Out which will require translation
2. User created collections which can be any Unicode value and will not 
require translation

Both these types use the displayName attribute to hold the UI 
displayable name. Going forward the displayName attribute will be of 
type schema.Text. The All, In, and Out collections would assign to 
displayName a LocalizableString since the names "All", "In", and "Out" 
will change based on the locale Chandler is running in. User created 
collections would assign to displayName a UString containing the Unicode 
collection name the user entered.

This approach is extremely flexible and can be implemented with little 
disturbance to the current Chandler content model.

A con to this approach is this flexibility will make enforcement of i18n 
difficult. Developers can assign UString's to schema.Text attributes 
that in reality do require translation and should be 
LocalizableString's. Using the testing method defined in the Chandler 
i18n proposal of doubling the length of all LocalizableString's will 
make this mistake apparent.  If any UI textual element is not doubled in 
length with a freshly built Repository then a developer has made an 
assignment error which needs to be corrected.

Andi Vajda has already started implementing the UString, 
LocalizableString (struct), and Text types.


Also a side note from the meeting, John Anderson asked if Phillip Eby 
would take a look at the current Chandler content model and suggest ways 
reduce its complexity.



-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