Closed Bug 162454 Opened 18 years ago Closed 14 years ago
Internalization & localization tracking bug (Calendar Requirements)
This is the Calendar Requirements -> Internalization & localization tracking bug
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.
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.
Assignee: mikep → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
re, comment #1, item e. It seams that almost all this info (excluding names of windows) could be taken from system locale.
Default QA Contact for Calendar has changed. If you wish to remain the QA contact for this bug, feel free to change it back.
QA Contact: colint → brantgurganus2001
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>
We don't need this tracking bug, because the underlying requirement document is outdated and has therefore been removed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.