[Chandler-dev] is a unified displayName a good thing?

Brian Kirsch bkirsch at osafoundation.org
Thu Apr 20 13:51:28 PDT 2006

 >>> Is a unified displayName a good thing?
I would argue that it is not a good thing and hinders i18n and the 
process of maintaining / regression testing localizations across releases.

 >>> 2. introducing a different attribute and placing that attribute 
only on items whose names actually show through to the UI.
+1 This is a good start.

 >>> 1. ripping out displayName altogether and seeing what we actually 
+++++ 1 This is what needs to happen long term.

The displayName was intended to be a one size fits all attribute for 
User Data "titles" and Meta Data "titles". This metaphor simply does not 
work well in an i18n environment where limitations are better.

One of the biggest issues with displayName is the developer determining 
if content needs to be localized or not. He or she must know every edge 
case on how an Item is used in Chandler to decide if it is displayable. 
And those requirements change over time which places the burden on 
someone to remember that that Item was not localized but now it needs to 

An ambiguous attribute such as displayName is also confusing to third 
party developers who will need to understand  how Chandler does column 
headers etc in order to correctly localize a parcel.

It also puts a lot of burden on QA and myself to constantly be 
monitoring check-ins making sure any new strings introduced are 
correctly localized.

The flip side is developers  may decide to be cautious and even though 
an Item is not currently displayed decide to translate  its displayName 
just in case. This leads to bloated  localization templates (.pot) which 
a volunteer will have to work with and OSAF will have to maintain. In 
short we only want to translate what is displayed no more no less.

I would like to see something more concrete. A specific attribute that 
is only used for UI display. That attribute could even be of a type 
where it alway checks with the translation manager before returning the 
string. This is similar to the LocalizableString type proposed by myself 
and Ken Krugler back in the .5 days.

The point is, if content is rendered in the UI it uses this attribute to 
store localized text. If the attribute in not assigned a value by the 
Item then it is not intended to be displayable. If a non-translated Item 
is displayed in the UI a warning can be printed to the log in debug mode.

Which brings me to my next subject User Data vs. Meta Data and localization.

Basically we are saying Meta Data such as File Menu names etc. need to 
be localized.  User Data which is created and assigned values by the 
user does not need to be localized but does need to be indexed.

Meta Data needs to be refreshable without altering User Data. This is 
apparent in a number of cases. For example, I update my Chandler from .7 
to .8. The Meta Data around the UI  will certainly change resulting in 
alterations to the Repository Data but the User Data I created in .7 
such as Calendar Events, Emails, etc will not change.

Currently, the only way to do a full refresh of  Meta Data is to blow 
away the Repository thus nuking User Data.
This is the basis of bug 5658: Localized UI meta data stored in the 
Repository needs to refreshable without altering User Data.


A Meta Data refresh will also be needed for i18n. When a user upgrades a 
release the localization data will have changed and  needs to be 
reloaded. If we support this case then it is easy to also support 
running Chandler in alternate locales.

For example, I set my Chandler locale to French (fr) but later I decide 
that I would prefer Spanish (es). All that would be required would be 
for Chandler to do a Meta Data refresh just like doing an upgrade. The 
refresh would involve the i18n translation manager loading the new 
Spanish strings from a .po and Items requiring localization querying the 
translation manager. 

This is a rare case, so the additional startup time to refresh the Meta 
Data on a locale switch should be acceptable.

The calendar code thanks to PyICU already supports switching locales.

Pre-populated User Data such as the welcome note, example items etc does 
need to be localized when created.
However, since it is User Data it will not change with a locale switch.

So to sum up a specific attribute is needed in the short term that only 
supports localized display text.

In the long run, we will be better served by deprecating displayName and 
coming up with a better alternative.


Brian Kirsch -  Cosmo Developer / Chandler Internationalization Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105

Ted Leung wrote:

> This topic came up for discussion in today's platform meeting (Alec  
> also joined us)
> Here's where we seem to be:
> We seem to have agreement that a 'title' attribute which would not be  
> localized (but would be indexed) is necessary
> After that things get fuzzy, due mostly to i18n concerns.   The big  
> place where this has impact is places in the UI where "displayName"  
> data appears - table column headers, detail view field labels, menus  
> and so forth.    We also have a problem related to the ability to  
> switch locales because we currently store the localized version of  
> the strings in the displayName.   There seem to be a lot of issues  
> left to tackle here and we aren't going to try to tackle them for  
> alpha2.    Some of the possible solutions that we discussed included
> 1. ripping out displayName altogether and seeing what we actually needed
> 2. introducing a different attribute and placing that attribute only  
> on items whose names actually show through to the UI.
> We are not going to try doing either of these for alpha2 but we will  
> need to tackle them for i18n reasons, if for no other.   There's also  
> some uncertainty on the exact level of i18n functionality that we are  
> targetting for 0.7 and ultimately 1.0.
> For alpha2, that leaves the introduction of a 'title' attribute on  
> ContentItem as the only active work item.
> Does that sound accurate to people that were in the meeting?
> Is there any additional comment?   If there is not, I am going to  
> start looking at adding a 'title' attribute to ContentItem.
> Ted
> On Apr 18, 2006, at 12:24 PM, Brian Kirsch wrote:
>> >>> So is the rule to display the title in preference to the   
>> displayName?   It seems to me that the only time that displayName  
>> is  really that >>> useful is when the item being displayed is an  
>> attribute  name -- I can imagine localizing that data, I can't  
>> imagine  localizing data
>> >>> entered by the user.    I guess you could have a  displayName  
>> that was "Untitled foobar", which might make some sense  to  
>> localize, >>> except that when display a summary view full of  
>> untitled  items, you' just see a pile of "Untitled foobar" rows.
>> I have always been a strong advocate of reworking the displayName.  
>> However, perhaps we should have a brief meeting or IRC chat to  
>> hammer out the specifics of the change. I want to make sure that  
>> adding the addition attribute 'title' really does meet our  
>> localiztion needs.
>> For example, in previous iterations of adding title with  displayName 
>> the title was going to be the localized field and  displayName the 
>> system field. Having displayName be the localized  field is fine I 
>> just want to make sure everyone is on the same page  and that we 
>> consider the edge cases for localization such as the  'Untitled 
>> Folder' example Ted gave.
>> --Brian
>> Brian Kirsch -  Cosmo Developer / Chandler Internationalization  
>> Engineer
>> Open Source Applications Foundation
>> 543 Howard St. 5th Floor
>> San Francisco, CA 94105
>> http://www.osafoundation.org
>> Ted Leung wrote:
>>> On Apr 17, 2006, at 9:49 AM, Katie Capps Parlante wrote:
>>>> Ted Leung wrote:
>>>>> If you look at Bug 1745: <https://bugzilla.osafoundation.org/  
>>>>> show_bug.cgi?id=1745>, you'll see that there's another issue   
>>>>> related to displayName /  title, which is localization.   I  
>>>>> think  that the localization stuff points to a separate Title  
>>>>> attribute  rather than displayName.   I suppose that you could  
>>>>> even argue  that the two names (title and displayName) are  
>>>>> reversed in their  meanings if you have both of them - title  
>>>>> being the "system" name  for the item and 'displayName' being  the 
>>>>> text that is localized,  indexed, and  presented to the user.
>>>> Hi Ted,
>>>> I don't think your description above is exactly right. The way I   
>>>> see it, a "two different attributes" proposal should look  
>>>> something  like this:
>>>> - Title
>>>>    - typically data entered by the user (e.g. title of an event)
>>>>    - not localized
>>>>    - indexed, this is the attribute you want in end user searches
>>>> - Display Name
>>>>    - system name
>>>>    - typically created by parcels: blocks, events, schema items,  etc.
>>>>    - localized (shows up in columns and other display elements)
>>>>    - not indexed, or indexed separately
>>>> The motivator behind having one "displayName" or  
>>>> "displayAttribute"  was a requirement that *any* item should be  
>>>> able to show up in a  table and have some reasonable "display  
>>>> name". I think we can find  a way to meet this requirement some  
>>>> other way -- the localization  and index issues are clearly more  
>>>> important requirements. Right now  we have no requirement to  
>>>> display blocks in tables, for example.
>>>> +1 for two different attributes btw.
>>> I know Alec was working on a writeup on this topic as well.   Alec,  
>>> I'd be curious to know if Katie's ideas match up with  yours?   If  
>>> this is going to get into alpha2, we are going to  need to come to  
>>> agreement fairly soon.
>>> Ted
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>> Open Source Applications Foundation "chandler-dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
> ----
> Ted Leung                 Open Source Applications Foundation (OSAF)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev

More information about the chandler-dev mailing list