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

[Bernhard Reiter]

On Sunday 14 November 2010 22:16:44 Jeroen van Meeuwen (Kolab Systems) wrote:
> 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.

The client SHOULD notify the user, but it MUST create an event.default
folder for the account it operates on. (This holds for each account it 
operates on.) 

> > > 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.

When operating in Kolab mode, each IMAP account MUST have one event.default
folder. So if you start on an account that does not, the client MUST create
it or stop using it in Kolab mode. (The matter might be different it we 
thing about non-Kolab specific server which do not offer annotations, but this 
would be a completely different proposal, I am currently defending the current 
design.)

> > 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.

The Kolab design was specific to the task at hand.
As explained above there is always one event.default folder per Kolab IMAP 
account. If someone would want to display a localized named for this folder 
it can be easily done. I could be done easier than using a fixed string as the 
basis, because the event.default annotation is more stable than a string in 
several client implementations.

In this specific situation I believe that not translating any folder name that 
users can choose is an even better solution. The users just create or rename 
the folder to the name they like in their local language. 


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

Yes, it could be done.

It is slightly less stable and unique, against having
INBOX/oh/Calendar being the default
or some (non Kolab, but regular IMAP) client that renamed the folder to 
something else.

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

(True, though I fail to see the connection. In a suggestion to solve the 
"privat" flag issue, I suggested to create event.default.private, but I am not 
sure if you are referring to this proposal.)

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

If that folder "Kalender" had an event.default annotation you could easily
display that in your local language.

> > 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".

If there is an INBOX/Kalender event.default folder, my English client will use 
this. (This is how it currently works in the reference clients and e.g. Kolab 
e35.)

> > 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.

Kolab Server is also an email server. So people using IMAP only email 
applications are to be expected. Users could rename the folders with them.

> > > 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.

Which ability to FUBAR do you mean precisely here?

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

Please explain in which usage situations the current way of handling it is 
suboptimal.

> 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.

See above, please present an example that is not covered well in usage
by the current design.

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Germany Coordinator: fsfeurope.org. Coordinator: Kolab-Konsortium.com.
Intevation GmbH, Neuer Graben 17, Osnabrück, DE; AG Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner