[Dev] Domain model meeting

[Ted Leung]

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