162454 - Internalization & localization tracking bug (Calendar Requirements)

Status: VERIFIED INVALID

(Calendar :: General, defect)

Description

[Ilia]

This is the Calendar Requirements -> Internalization & localization tracking bug

Comment 1

[Ilia]

Internalization & Localization requirements:

a. Character set:
    Calendar must support all the character sets supported by the default/system
font.
    It must support it for all text objects, e.g.: text data(such as event/task
description, people names/addresses, etc.), window titles, widget titles, dialog
boxes, etc.

b. Multiple character sets
    User must have an option of switching the character set at any point into
filling a text data into the Calendar. That means that a text object may be
composed from the characters belonging to the different character sets. 
    That character set switching is better to be done using the procedure,
standard for that GUI environment (such as [Alt][Shift] in Windows) if that
standard procedure is available.

c. BiDi:
    Calendar must support the bi-directional text, including the text direction
change inside the text block, i.e. the LTR number inside the RTL text.
    Again, the bi-directional text must be possible anywhere, where the
"regular" text is possible.

d. ASCII-only text fields:
    Some text fileds, such as the E-mail address, URL, etc. use ASCII character
set only and are RTL only. When filling these fields, Calendar must
automatically perform temporary switch to the appropriate text attributes
without any user intervention. When moving to another fields, the original text
attributes must be restored.

e. Local names & particularities:
    Calendar must support configurability for such items:
    -- Configurable days of week names;
    -- Configurable month names;
    -- First day of the week must be configurable to either day;
    -- Configurable begin & end days of the daylight saving time; 
    -- Configurable menu items, window names, widget titles names.
    All these configurations must be available through some config file(s).
Configuring them from the GUI is not necessary, as long as the config file is of
human-readable text format.

f. Local holidays:
    Calendar must support selecting a national/religious holiday set from the
available list. A number of holiday sets may be selected at once, say US &
Jewish  holidays, holidays for a number of countries e.g. US & France & Germany,
etc.
    Holidays may be treated as either non-working days or events. Say, You may
want to set reminder on some another nation's holiday to send greetings to Your
partners/collegaues/co-workers from that country, while leaving that foreigin
holiday as a normal working day in Your calendar.
    Choice of holiday properites (non-working day, event or both) must be
available from GUI per each specific holiday or per whole holiday set.

f1. Local/religious holidays calculation.
    Some religious holidays aren't occurs at the same day each year, and even
doesn't fit into the "N-th Sunday of that month" scheme. Instead, they are
calculated by a rather complex algorithms. To accomodate this, some API must be
defined in order to attach the holidays calculation modules to the Calendar.
Another option may be to spawn some external program in backgroung once a year,
that re-creates the holidays file. In any case Calendar must have a way to
attach an external holidays calculation module.

Comment 2

[ajbu]

Hi,
Mozilla and Mozilla Calendar will support the UTF-8 characterset, and no other 
(ISO-) sets, all characters entered will be converted to UTF-8, this should 
work for all/most charsets. UTF-8 will replace the 'old' charset, I did read 
RedHat Linux 8.0 will switch to UTF-8 as the default.

> Calendar must support the bi-directional text, including the text direction 
change inside the text block, i.e. the LTR number inside the RTL text.
I don't think UTF-8 supports this, or are there pages that do work with this 
in Mozilla? If Mozilla the Browser can do it, Calendar can.. Calendar's Event 
Title field already uses UTF-8.

> Some text fileds, such as the E-mail address, URL, etc. use ASCII character
set only and are RTL only. 
I don't see any reason to force a limitation to ASCII for those fields? Why 
block users from using Unicode URLS?

For (local) holiday's I feel it would be great if there was a holidays-
webservice outside Calendar. When an (open source) server project is started, 
this might be a good suggestion.

Comment 3

[Mike Potter]

Confirming.

Comment 4

[Ilia]

To ajbu: 
Mozilla supports UTF-8 & Bi-Directional (BiDi) text pretty well.
Some problems are still exist (see bug 150958), but they are clearly marked as
such and hopely will be fixed soon. 
No doubt, Mozilla charsets & BiDi support provide a strong base for the Calendar.
Re-use of that code is natural.

> I don't see any reason to force a limitation to ASCII for those fields? 
> Why block users from using Unicode URLS? 
For best of my knowledge, the non-ASCII mail addresses & URL's pose a number of
serious problems, their usage is not standardized for now, and due to this the
standard character set for these objects is still ASCII only.
The idea came from an annoying feature of M$ Outlook where You have to switch
keyboard character coding a number of times while writing a single mail message,
just because the beast assumes that if You write the message text, say, in
Hebrew (or Russian) You will write the E-mail address in that charset, too ;) .
I'd never encounter the non-ASCII E-mail address, however.

Holidays-webservice is a cool idea indeed,
but what's more important is the ability to pick a number of holiday sets for
the different locales (see f. in my previous post).

Think about an example where 
You working in US (and so the US holidays are the non-working days for You);
You whant to send greetings to the important customers in France and Japan
before *their* holidays;
and You know that Your co-worker Maria will be out of office on Catholic
holidays and Your another co-worker Joshua - on the Jewish ones, so You whant
Your calendar to mark that they are unavailable at that days. 

Comment 5

[Aidas Kasparas]

re, comment #1, item e. It seams that almost all this info (excluding names of
windows) could be taken from system locale.

Comment 6

[Brant Gurganus]

Default QA Contact for Calendar has changed.  If you wish to remain the QA
contact for this bug, feel free to change it back.

Comment 7

[XandreX]

maybe I don't get what a tracking bug is, I though it would be a list of bugs
concerning the topic (here : i18n & l10n).
Here are some nominees (am I at least using the correct term ?) :

*localization*
UTC event times are not converted into local times
  <http://bugzilla.mozilla.org/show_bug.cgi?id=170721>
Z on the end of time stamp ignored. time zone misinterpreted
  <http://bugzilla.mozilla.org/show_bug.cgi?id=188095>

*internationalization*
Problem in reading .ics with entries ending with UTF-8 non-ASCII char
  <http://bugzilla.mozilla.org/show_bug.cgi?id=173039>
Z on the end of time stamp ignored. time zone misinterpreted
  <http://bugzilla.mozilla.org/show_bug.cgi?id=188095>

Comment 8

[Simon Paquet [:sipaq]]

We don't need this tracking bug, because the underlying requirement document is outdated and has therefore been removed.