On Feb 6, 2006, at 12:01 PM, Brian Kirsch wrote:
Hi Ted,
I would add Localization to the Domain Model Discussion.
Specifically, the displayName attribute is ambiguous. Some
displayNames such as "Password" require translation since that
value is displayed to the user. Others such as "Mailed Task" do not
since it is internal to Chandler itself. This leads to confusion
and potential i18n translation bugs in the future.
The first solution is to translate all displayNames in Chandler but
this places a lot of burden on the translator to provide
localization on a large set of text that will never be displayed to
the user.
A better approach is to use a new attribute such as title which is
always localized. If a item appears in the UI then a title
attribute is required. For example, title =_(u"This is translatable
text").
Another nice facet of the title attribute is debugging. If Python
is started in debug mode then Chandler could raise a assert if no
title attribute is implemented for a displayable item. In non-debug
mode Chandler would use the displayName when no title is present.
Added to the comments for bug #1745, which is assigned to m
also a lingering bug from .6 should be factored in to the new
domain model:
Bug 4067: Localization of who, about, and date headers required
Assigned to PJE, but I am now cc:ed
Bryan Stearns wrote:
Ted Leung wrote:
For 0.7 I am taking over the Domain model. Sheila, Mimi and I
talked a bit about known work items related to the domain model.
The notes of our conversation are at <http://
wiki.osafoundation.org/bin/ view/Journal/DomainModelIssues>.
Please let me know if you have other domain model issues that are
not on this list.
Ted,
I think there are bugs for a few of these, which are all issues
for how we expect developers to add Kinds to Chandler:
- We don't have a strategy for how developers will participate in
mixing-in with pim kinds. (the wiki page talks about mentions
supporting use cases - maybe we need some for developer uses of
the domain model?)
- The notion of supporting different types of the "body" attribute
isn't really workable; Note's "body" pretty much needs to win (and
be text) for all pim types (or note bodies will appear and
disappear with stamping)
- Someday mail will be a tenet, and when it becomes one,
Implementing "I want to mail this" by adding MailMessageMixin to
the item's superkinds is too limiting: if the thing you're sending
IS the mail message, you can only mail one item this way, and you
can only mail it once (unless we want to add lots more mechanism
to track multiple sendings of an item). (I bring this up now
because we're talking about how invitations should work.)
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
--
Brian Kirsch - Cosmo Developer / Chandler Internationalization
Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org
----
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
