Closed Bug 471386 Opened 16 years ago Closed 16 years ago

Implement category numbers for language independent categories

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: pander, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5
Build Identifier: Sunbird 0.9 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18pre) Gecko/20080917 

Currently the categories are implemented as CSV string in calendar.categories.names which is set to:

Anniversary,Birthday,Business,Calls,Clients,Competition,Customer,Favorites,Follow up,Gifts,Holidays,Ideas,Issues,Miscellaneous,Personal,Projects,Public Holiday,Status,Suppliers,Travel,Vacation

Certain calendars which are shared with people speaking different languages should be able to store a category language independent.

I would like to propose the following implementation. Create the following strings:

calendar.categories.names which is set to:
  Anniversary,Birthday,Business,...

calendar.categories.names_i18n which is set to your local language:
  Trouwdag,Verjaardag,Zakelijk,...

calendar.categories.custom which is set to:
  0,1,2,...

The latter string is the one that the user can control. If the user want's to remove '1', then Birthday (or the localised translation) will not appear in the categories the user can choose from.

If the user imports a calendar with events of category '1', Sunbird is able to look up as a fallback in calendar.categories.names and translate it via calendar.categories.names_i18n when needed.

When the user adds new categories, it should not be possible to add numbers, strings beginning with numbers or containing numbers should be allowed. When the users adds a category that exists in calendar.categories.names_i18n, the number that was removed by the user before, should be restored in calendar.categories.custom When no localisation is used, this lookup should be done via calendar.categories.names.

Note that it is important not to go directly via calendar.categories.names when being in a localised setting because of translations that mean something else and are in fact custom new categories and do not refer to the underlying English names that have been removed by using the translated version.

Example:
User is working in Dutch language and removes Verjaardag, then 1 is removed from calendar.categories.custom, but if the user adds Birthday, Birthday should be added to calendar.categories.custom.

If the user working in English language, after removing Birthday and adding Birthday, the 1 should be restored.

Also offer a button in preferences that restores all deleted default categories and removes custom categories which actually reside in the default set. It should prompt for all events to also update the category in the internal representation/storage to the number.

This latter part (internal renaming to numbers without restoring deleted defaults) should also be run when upgrading. Perhaps many users added a category that is now available in the default set. It is better to upgrade the calendar because this will result in correct translation if the user shares the calendar with another user in another language.

The above improvement allows for a fail safe and upgradable language independent category management and presentation. Implementing this will improve localisation in shared calendars.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Note that calendar.categories.names and calendar.categories.names_i18n are not allowed to be changed by the user, not even via advanced configuration.
While I do see the motivation for this bug and agree it would be nice if these names could be i18nized, think of the application compatibility here: Lets say I have a remote ics calendar that is accessed from lightning, iCal.app, and evolution users. The latter user groups would see a bunch of events with categories "1" and "2", not anything localized, which doesn't make any sense at all to them.
I agree that this would essentially break category compatibility with other apps using the .ics format. Recommending WONTFIX because of that.

Your call, Philipp!
Hmm, yes you have a point there. Can you leave this open, perhaps a scaled down or alternate version of my proposal is a valid solution regarding also external clients. I'll come back on this.
I could imagine that a default set of e.g. English category names is used in the ics files. The translated category names are used for display purposes only.

How do other applications (e.g. iCal.app or Evolution from above) handle this? Do they write translated category names into the ics files? Do they use a generic set of categories with different display names?
I guess they simply don't support that. I wouldn't recommend to use mixed category translations but stick to plain 2445; I second Simon in WONTFIX.
To continue on Stefan's idea, how about this:

Consider the following three strings:

calendar.categories.names_original which is set to:
  Anniversary,Birthday,Business,...

calendar.categories.names_original_i18n which is set to your local language:
  Trouwdag,Verjaardag,Zakelijk,...

calendar.categories.names which is set to:
  Anniversary,Birthday,Business,...
this is the one (like now) that is used for choosing by the end user.

When the application starts up and detects internationalisation, it will
translate all the strings via calendar.categories.names_original and
calendar.categories.names_original_i18n.

The user is free to change everything in calendar.categories.names like is the
case now. When the users reverts to the original list, the user will get the
original list, and in case of localisation, the translated version.

The categories will be saved as string so it works correctly with other
external calendar clients.



Second part:

As an extra option, default true when internationalisation is installed, the 
categories (perhaps of read only calenders only) which can be translated back
via calendar.categories.names_original to
calendar.categories.names_original_i18n so they can be represented in the
calendar views in the translated/localised string.

E.g. If a user would import a read-only holiday calendar and an event is
categorised as "Public Holiday", in a localised version of Sunbird, the user
would see "Feestdag".
Sounds like a good idea in general, it might be a quite fragile feature though. Also it might create a wierd user experience, since some category names are translated on export and others are not.

I'd like to get some opinions from localizers here.
The issue of what to export has to be solved anyway. The following unwanted scenarios exist:

- If you export always English, other people in the same non English country (in your native audience) with other calendar clients also configured for non English will see English, which you perhaps not intended and is confusing when discussion the same calendar i.e. over the phone.

- If you export non English, other people in another county (in your international audience) have the same problem with other calendar clients.

Since there is no way of finding out how the end user will export and import calenders, best thing would be to have some options per calender on how to export these. Perhaps with an intelligent default (English, but localised when Sunbird is being used localised).

So I would suggest an intelligent preconfigured setting per calender with good help text.
For me this sounds like an awfully complicated and very fragile solution to a very minor problem, that is better solved on the user- than on the application side.

Users with a localized app will surely use their localized categories, but for non-English users, which use an English version, things start to get complicated since they can either choose to sue the built-in categories or define new ones in their language of choice.

Also this feature doesn't map at all to user-defined categories. You would have to add a language attribute to each user-defined category, which would add additional complexity to our category creation UI for very little gain.

All in all, I'm not at all convinced that this is a sensible idea. Marking WONTFIX for now. I/We would however reconsider this, in case a patch, which implements your proposed feature is presented here in this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Perhaps it is good to examine Google Calendar, iCal and other applications ans ask their i18n development team what they think about this.
You need to log in before you can comment on or make changes to this bug.