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.
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
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
