>>> 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
needed
+++++ 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
be.
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.
https://bugzilla.osafoundation.org/show_bug.cgi?id=5658
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
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:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
