names of default folders (Re: [Kolab-devel] autocreate functionalities in cyrus)

[Jeroen van Meeuwen (Kolab Systems)]

On Sunday, November 14, 2010 01:24:29 pm Bernhard Reiter wrote:
> On Saturday 13 November 2010 01:46:22 Jeroen van Meeuwen (Kolab Systems)
> > 2) use any folder annotated correctly but not default per-se (e.g.
> > /vendor/kolab/folder-type event) and possibly ask to choose/confirm the
> > default folder,
> 
> No, in this case the client has to create the event.default folder.
> It could ask to chance one of the existing folders into it, but this can
> get overly complicated.
> 

It can't create a new 'event.default' folder and be spot on if 'event' folders 
exist already. It MUST either ignore the fact there is no default, or ask the 
user to have one of the folders be made the default.

> > 3) create a properly annotated default folder in the English language.
> > 
> > Step 3) is the proper approach because it can then be localized using the
> > client application's l10n settings, which cannot be done if the source
> > language is arbitrary and the target language is arbitrary.
> 
> I believe you are wrong here, any default folder will only exist once,
> e.g. event.default.

That's incorrect, as only one event.default folder SHOULD exist (not CAN 
exist), and one such folder MAY exist for every single account. This means the 
client CAN have thousands of event.default annotated folders.

> So you could easily display it in your local language
> if you wanted to. This way it even is canonical and does not depend on
> several English terms of naming the function itself.

Displaying something, localized or not, is something completely different and 
separate from creating the folder on the IMAP server. I'm not sure how you get 
to align this with function naming, and I'm not sure how you can withdraw 
proper l10n from the equation without ignoring the hundreds of thousands of 
programs that do it already.

1) A folder named "Calendar" on the IMAP server can easily be translated to 
"Kalender".

2) A folder you create named "Privat Kalender" does not have to be 
automatically created.

3) An automatically created folder named "Kalender" cannot easily be localized 
to say "Calendar".

> However I would not do it, if people using this folder work together, they
> must have a convention for this or speak on common language anyway, so
> there is not need to govern this.

Whether there is a convention between the users on shared Calendars is moot if 
the German client you have on your home computer creates "Kalender", whereas 
the English client you have on your office laptop creates "Calendar".

> It would only create more unnecessary
> rules to make English default folder names mandatory.
> 
> (A small argument for keeping the real user names is that regular IMAP
> clients will display them as is and you do not need to keep more
> information.)
> 

"Regular" IMAP clients cannot read/parse or write the Kolab XML format used in 
these folders, so this argument is completely moot.

> > Step 1 and 2
> > will prevent additional folders from being created by accident, and can
> > thus be used to catch legacy scenarios, as well as scenarios in which the
> > client chooses to in fact, effectively, rename the annotated default
> > folder to something no program can translate during it's presentation.
> 
> A single annotation like event.default could be displayed in local language
> much easier. The ability to have your own foldernames for the event.default
> function is a plus.
> 

I suppose I lack the ability to explain the perspective I have on this...

Yes, the ability to FUBAR it all is a plus. My proposition on handling it all 
proper is not mutually exclusive with this plus.

Yes, the annotations will rule the universe. My proposition on handling it all 
proper is not mutually exclusive with annotations.

No, the default created when a client application notices no groupware folders 
exist on the account must NOT be created using a localized name, and must be 
localized on the client using a proper l10n source language.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20101114/c84da367/attachment.html>