Closed Bug 317607 Opened 14 years ago Closed 13 years ago

For minimonth should be used localization language and not OS language

Categories

(Calendar :: Sunbird Only, defect)

Sunbird 0.3a1
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: milupo, Unassigned)

References

Details

(Keywords: intl)

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; hsb-DE; rv:1.7.6) Gecko/20050319
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; hsb-DE; rv:1.7.6) Gecko/20050319

I prepared an Upper Sorbian language pack for Sunbird 0.3 Alpha1. The minimonth left is always sgown in German that is the language of my OS. This applies to the orginal English Sunbird, too.
I tested it also with the Polish zip build. The same result.

Reproducible: Always



Expected Results:  
Minimonth language should correspond to the localization language.
The minimonth was changed in Bug 260120 to use code like date.toLocaleFormat("%B") to get the month names and weekday names.  The reason for that change was to get date/time picker widgets that could be used in toolkit, for XForms.  For toolkit, they wanted controls that didn't have to be localized and instead relied on the operating system for localization.

The dates displayed in the rest of the application also rely on the operating system, so if the date format is not numerical, you will see non-localized dates everywhere.

How are dates handled in thunderbird/seamonkey in your locale?

Internationalization issue: should mozilla apps be localizable to locales other than the operating system current locale?  Historically they have been, but date formatting is a special case.  
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
OS: Windows ME → All
Hardware: PC → All
Version: unspecified → Sunbird 0.3a1
(In reply to comment #1)
> The dates displayed in the rest of the application also rely on the operating
> system, so if the date format is not numerical, you will see non-localized
> dates everywhere.
I think every application should be completely localizable. Numerical dates should use the correct format common for certain country. Month names and day names and their abbreviations should be in the language of the application. A similar problem are common controls lik Open File, Save File and Print which use the OS language, too. But this is another subject. 
The minimonth of the calendar extension 2005-01-11, afaik the recent version, uses the localized month and day names. I copied the its datepickers folder to Sunbird, repacked the calendar.jar, and it works in Sunbird, too.

> How are dates handled in thunderbird/seamonkey in your locale?
Unfortunately there's the same problem.
 
> Internationalization issue: should mozilla apps be localizable to locales other
> than the operating system current locale?  Historically they have been, but
> date formatting is a special case.  
Yes, of course. Like Upper Sorbian there are a lot of minority languages they don't have a localized OS. But you can localize applications. That localization remains, however, unperfect if there are simply adopted the OS preferences. 

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
*** Bug 353819 has been marked as a duplicate of this bug. ***
Will be lovely if we can spend some time to localize minimonth before next release.
Keywords: qawanted
No QA really needed on this, the issue is well-defined.  Here is a suggestion to resolve the issue: Perhaps when there is a difference in language between the OS and the application, the minimonth (and other related components) should use the application language instead of the OS langauge.
Keywords: qawanted
Flags: blocking-calendar0.5?
(patch -l -p 1 -i file.patch)

Patches Minimonth to use UILocale localized dateFormat.properties strings if they are available for month and weekday names, else falls back to Date.toLocaleFormat for operating system format.

Patches goToDateDialog to load calendarUtils.js so the date picker there also uses the UILocale strings.

Minimonth previously used UILocale for strings, so most locales already have the necessary strings. 

Expected result:
For each minimonth (date tab; go-to-date dialog; event dialog start date, event dialog end date, todo dialog due date; event dialog repeat-until date)
  In english the month names should be the same full month names.
  The weekday headers should become 1-letter abbreviations, such as
  M T W T F S S  if the week starts on Monday.
  (If I missed datepicker somewhere that shows 2-letter abbreviations,
   that probably means it's in a dialog that needs to load calendarUtils.js)



(Trivia:  minimonth has changed filenames several times so the versions using UILocale strings are not in the history for minimonth.xml [due to limitation of CVS: renaming loses history].  Previous file names include minimonth.xbl and calendar.xbl; before that it was in datepicker/datepicker-overlay.xul
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/calendar/resources/content/datetimepickers/minimonth.xbl
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/calendar/resources/content/datepicker/Attic/datepicker-overlay.xul
)
Attachment #253099 - Flags: first-review?(ctalbert.moz)
(patch -l -p 1 -i file.patch)

Once previous patch is checked to verify no missed datepickers, this patch makes en-US locale appear as before, so overall there should be no UI change, at least for en-US.
Attachment #253101 - Flags: first-review?(ctalbert.moz)
Comment on attachment 253099 [details] [diff] [review]
v1 patch minimonth to use UILocale strings for month and day abbrevs, falling back to OS locale

Sorry it took me so long to get to this...

>@@ -219,7 +225,14 @@
>             var i, j;
>             tempDate.setDate(tempDate.getDate() - (tempDate.getDay() - this.weekStart));
>             for (i = 0; i < header.childNodes.length; i++) {
>-              dayList[i] = tempDate.toLocaleFormat("%a")
>+              // if available, use UILocale days, else operating system format
>+              try { 
Extra space after this {

>+              } catch (e) { 
Extra space after this {

Besides those two nits, this looks good. Tested on windows.
Attachment #253099 - Flags: first-review?(ctalbert.moz) → first-review+
Comment on attachment 253101 [details] [diff] [review]
v1 patch en-US weekdays abbrevs: S M T W T F S -> Su M Tu W Th F Sa

Looks good
Attachment #253101 - Flags: first-review?(ctalbert.moz) → first-review+
Duplicate of this bug: 369957
(patch -l -p 1 -i file.patch)

Nit addressed.  Description in comment #7.
Attachment #253099 - Attachment is obsolete: true
Attachment #254642 - Flags: second-review?(jminta)
Comment on attachment 253101 [details] [diff] [review]
v1 patch en-US weekdays abbrevs: S M T W T F S -> Su M Tu W Th F Sa

2r?: Please find description of attachment 253101 [details] [diff] [review] in comment #8.
Attachment #253101 - Flags: second-review?(jminta)
Comment on attachment 254642 [details] [diff] [review]
v2 patch minimonth to use UILocale strings for month and day abbrevs, falling back to OS locale

+                calGetString("dateFormat", "month."+ (month+1)+ ".name");

Operators like + should have spaces on both sides of them.

r2=jminta with that.
Attachment #254642 - Flags: second-review?(jminta) → second-review+
Attachment #253101 - Flags: second-review?(jminta) → second-review+
(patch -l -p 1 -i file.patch)

Nit addressed.
Attachment #254642 - Attachment is obsolete: true
Patch checked in.
  calendar/resources/content/goToDateDialog.xul: 1.4 -> 1.5.
  calendar/resources/content/datetimepickers/minimonth.xml: 1.12 -> 1.13
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070214 Calendar/0.4a1
Status: RESOLVED → VERIFIED
Flags: blocking-calendar0.5?
Comment on attachment 253101 [details] [diff] [review]
v1 patch en-US weekdays abbrevs: S M T W T F S -> Su M Tu W Th F Sa

I think, this patch wasn't checked in before marking this bug fixed.
(In reply to comment #18)
> (From update of attachment 253101 [details] [diff] [review])
> I think, this patch wasn't checked in before marking this bug fixed.
> 
reopened awaiting check in
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to comment #19)
> > (From update of attachment 253101 [details] [diff] [review] [details])

Checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Verified using Thunderbird 2.0pre (20070227) + Lightning 0.5pre (2007022803) and en-US/de/ru Sunbird 0.5pre (20070228)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.