[Dev] Domain model meeting

[Brian Kirsch]

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