Closed Bug 352513 Opened 18 years ago Closed 16 years ago

Localizability issues with newevent.recurrence.every.label in calendar.dtd

Categories

(Calendar :: General, defect)

defect
Not set
trivial

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: thorsten.fritz, Assigned: hubert+bmo)

Details

Attachments

(2 files, 2 obsolete files)

In german, we need different translations for
<!ENTITY newevent.recurrence.every.label    "Every:" >
For daily recurrences the translation is "Jeden", but for weakly it must be "Jede", for monthly "Jeden" and for yearly "Jedes".

A solution could be to have different entitys like:
newevent.recurrence.every.daily.label
newevent.recurrence.every.weekly.label
newevent.recurrence.every.monthly.label
newevent.recurrence.every.yearly.label

Probably other languages might have the same problem.
Nominating for blocking 0.3
Flags: blocking0.3?
Isn't 'Alle' an adequate German translation that matches all cases?

We already passed date for StringFreeze so no changes should be made unless absolute necessary.
(In reply to comment #2)
> Isn't 'Alle' an adequate German translation that matches all cases?
no, unfortunately not. the correct translation is indeed "Jede(n/s)" depending on the subject (week,month,etc).
(In reply to comment #3)
Ok. I was just looking at the context it is used in. It's written before the textbox and for me 'Alle [__2] Jahre' sounds better than 'Jedes [__2] Jahre'.
We're in string freeze now, so this can not be taken for 0.3.

I agree that this is ugly, but by no means a real showstopper. This will have to wait until 0.5
Flags: blocking0.3? → blocking0.3-
Target Milestone: --- → Sunbird 0.5
Not going to make the 0.5 train.
Target Milestone: Sunbird 0.5 → ---
Taking.
Severity: normal → trivial
Status: NEW → ASSIGNED
Version: Trunk → unspecified
Status: ASSIGNED → NEW
Flags: wanted-calendar0.9?
Flags: wanted-calendar0.9? → wanted-calendar0.9+
Attached patch Patch (obsolete) — Splinter Review
I have also added month names, moved strings to a new file (we have sun-calendar-event-dialog-recurrence.xul, but we have not a file sun-calendar-event-dialog-recurrence.dtd) and cleaned out entities names. There are no changes in en-US interface.

In Polish language I cannot use month.X.name, because we have declension for month names, for example:
January = styczeń
January, 1st = 1 stycznia ("1 styczeń" or "styczeń, 1" are incorrect)
First Sunday of January = Pierwsza niedziela stycznia
Assignee: nobody → hubert
Status: NEW → ASSIGNED
Attachment #326223 - Flags: review?(bugzilla)
Trunk has a jsm called PluralForm (see http://developer.mozilla.org/en/docs/Localization_and_Plurals#Developing_with_PluralForm) which could be useful for such a case. Maybe we could just put this into calUtils.js
Comment on attachment 326223 [details] [diff] [review]
Patch

>Index: mozilla/calendar/locales/jar.mn
>===================================================================
>RCS file: /cvsroot/mozilla/calendar/locales/jar.mn,v
>retrieving revision 1.24
>diff -u -8 -p -r1.24 jar.mn
>--- mozilla/calendar/locales/jar.mn	21 May 2008 14:05:35 -0000	1.24
>+++ mozilla/calendar/locales/jar.mn	23 Jun 2008 00:02:04 -0000
>@@ -19,11 +19,12 @@ calendar-@AB_CD@.jar:
>     locale/@AB_CD@/calendar/preferences/alarms.dtd  (%chrome/calendar/preferences/alarms.dtd)
>     locale/@AB_CD@/calendar/preferences/categories.dtd  (%chrome/calendar/preferences/categories.dtd)
> *   locale/@AB_CD@/calendar/preferences/connection.dtd  (%chrome/calendar/preferences/connection.dtd)
>     locale/@AB_CD@/calendar/preferences/general.dtd  (%chrome/calendar/preferences/general.dtd)
>     locale/@AB_CD@/calendar/preferences/preferences.dtd  (%chrome/calendar/preferences/preferences.dtd)
>     locale/@AB_CD@/calendar/preferences/timezones.dtd  (%chrome/calendar/preferences/timezones.dtd)
>     locale/@AB_CD@/calendar/preferences/views.dtd  (%chrome/calendar/preferences/views.dtd)
>     locale/@AB_CD@/calendar/sun-calendar-event-dialog.dtd	(%chrome/prototypes/sun-calendar-event-dialog.dtd)
>+    locale/@AB_CD@/calendar/sun-calendar-event-dialog-recurrence.dtd	(%chrome/prototypes/sun-calendar-event-dialog-recurrence.dtd)

I don't think that adding a new file here is the right way to go. 

And even if it were, the new file should live in chrome/calendar and not in chrome/prototypes as it is planned to obsolete this directory and move everything in it to chrome/calendar.

In addition, I don't think that it is the right way to rename all the affected entities, even in cases where this is not necessary at all. That just makes it harder for localizers to fix their localizations IMO.

The route you are walking on is okay, but I would prefer a much less invasive patch.

r- for now, but I'm looking forward to an updated patch.
Attachment #326223 - Flags: review?(bugzilla) → review-
(In reply to comment #10)

> I don't think that adding a new file here is the right way to go. 

Each xul file should has separate dtd file. It is standard in browser and toolkit and it is easier for localization.

> And even if it were, the new file should live in chrome/calendar and not in
> chrome/prototypes as it is planned to obsolete this directory and move
> everything in it to chrome/calendar.

I agree, I don't know why we still put those files in prototypes directory. I have added a new file to the same place as sun-calendar-event-dialog.dtd.

> In addition, I don't think that it is the right way to rename all the affected
> entities, even in cases where this is not necessary at all. That just makes it
> harder for localizers to fix their localizations IMO.
> 
> The route you are walking on is okay, but I would prefer a much less invasive
> patch.

OK.

> r- for now, but I'm looking forward to an updated patch.

I'll create a new one.

(In reply to comment #9)
> Trunk has a jsm called PluralForm (see
> http://developer.mozilla.org/en/docs/Localization_and_Plurals#Developing_with_PluralForm)
> which could be useful for such a case. Maybe we could just put this into
> calUtils.js

Great idea, but I see one problem. Now we have the same code for MOZILLA_1_8_BRANCH and trunk (calendar directory). Do we want to break this rule?
Attached patch Patch 0.2 (obsolete) — Splinter Review
Attachment #326223 - Attachment is obsolete: true
Attachment #327024 - Flags: review?(bugzilla)
(In reply to comment #11)
>> I don't think that adding a new file here is the right way to go. 
> 
> Each xul file should has separate dtd file. It is standard in browser and
> toolkit and it is easier for localization.

I agree, but now is not the right time to do it. We're just three weeks away from the 0.9 string freeze. It's probably better if we do this early on in the 1.0 cycle. Can you file a followup-bug for that? You're welcome to take that as well :-)

> (In reply to comment #9)
>> Trunk has a jsm called PluralForm (see
>> http://developer.mozilla.org/en/docs/Localization_and_Plurals#Developing_with_PluralForm)
>> which could be useful for such a case. Maybe we could just put this into
>> calUtils.js
> 
> Great idea, but I see one problem. Now we have the same code for
> MOZILLA_1_8_BRANCH and trunk (calendar directory). Do we want to break this
> rule?

Not yet. We can do it after 0.9 is out and we're developing solely on the trunk again.
Comment on attachment 327024 [details] [diff] [review]
Patch 0.2

>Index: mozilla/calendar/locales/en-US/chrome/prototypes/sun-calendar-event-dialog.dtd
>===================================================================
>
> [...]
>
>+<!ENTITY event.recurrence.pattern.yearly.month.1.name        "January" >
>+<!ENTITY event.recurrence.pattern.yearly.month.2.name        "February" >
>+<!ENTITY event.recurrence.pattern.yearly.month.3.name        "March" >
>+<!ENTITY event.recurrence.pattern.yearly.month.4.name        "April" >
>+<!ENTITY event.recurrence.pattern.yearly.month.5.name        "May" >
>+<!ENTITY event.recurrence.pattern.yearly.month.6.name        "June" >
>+<!ENTITY event.recurrence.pattern.yearly.month.7.name        "July" >
>+<!ENTITY event.recurrence.pattern.yearly.month.8.name        "August" >
>+<!ENTITY event.recurrence.pattern.yearly.month.9.name        "September" >
>+<!ENTITY event.recurrence.pattern.yearly.month.10.name       "October" >
>+<!ENTITY event.recurrence.pattern.yearly.month.11.name       "November" >
>+<!ENTITY event.recurrence.pattern.yearly.month.12.name       "December" >

I understand why you are duplicating all the strings from global.dtd here. Does the same reason not hold for weekdays? If yes, we should duplicate those strings here as well and stop including global.dtd in the xul file.
(In reply to comment #14)

> I understand why you are duplicating all the strings from global.dtd here. Does
> the same reason not hold for weekdays? If yes, we should duplicate those
> strings here as well and stop including global.dtd in the xul file.

Oh, I have forgotten about weekdays. In Polish language weekdays from global.dtd are OK here. But maybe some localizers need separate entities for this.

Also we have two places in sun-calendar-event-dialog-recurrence.xul where months names occur:
<menupopup id="yearly-month-ordinal-menupopup"/>
<menupopup id="yearly-ordinal-menupopup"/>

It is possible that for some languages we need separate entities for both dropdown lists. CC: calendar-l10n.
> > (In reply to comment #9)
> >> Trunk has a jsm called PluralForm (see
> >> http://developer.mozilla.org/en/docs/Localization_and_Plurals#Developing_with_PluralForm)
> >> which could be useful for such a case. Maybe we could just put this into
> >> calUtils.js
> > 
> > Great idea, but I see one problem. Now we have the same code for
> > MOZILLA_1_8_BRANCH and trunk (calendar directory). Do we want to break this
> > rule?
> 
> Not yet. We can do it after 0.9 is out and we're developing solely on the trunk
> again.
My idea was not to break the cross-commit rule, but rather to put the pluralforms stuff into calUtils on both branches. That way we can use it now and when we switch to trunk or decide to break the cross-commit rule, we can get rid of the code and use it from toolkit or whereever.


Question to localizers: do you need different entities for weekdays in Edit Recurrence dialog window (Recurrence pattern > Repeat annually)? Now this window uses entities from global.dtd.
Not for Portuguese
(In reply to comment #18)
> Question to localizers: do you need different entities for weekdays in Edit
> Recurrence dialog window (Recurrence pattern > Repeat annually)? Now this
> window uses entities from global.dtd.

YES, this would be great, really.

Actually, I think the annual recurrence subdialog should be redesigned. Even in English, the phrase "Every: __1__ year(s), Every __27__ June" looks awkward. I think, it would make much more sense to say "Every __1__ Year(s), on __27__ of June". Also, the English order of words (e.g. "Every Fourth Friday of June" or even "27 June") isn't suitable for all languages (e.g. it should be "Every June Fourth Friday" and "June 27" in Lithuanian). It would be great if the order of localizers could change this order.

A (hopefully) possible implementation would be to simply define a localizable string, such as: "Every %1$S %2$S of %3$S" where these %x$S's would be replaced with appropriate widgets. This would allow localizers to arrange all these choices in the best order for their locale.

(Hope this comment is understandable. I somehow don't feel like I could express my ideas properly today...)
(In reply to comment #20)
> It would be great if the order of localizers could change this order.

Oops, I meant "It would be great if localizers could change this order."
Attached patch Patch 0.3Splinter Review
I've added separate entities for each dropdown list.

(In reply to comment #21)
> (In reply to comment #20)
> 
> Oops, I meant "It would be great if localizers could change this order."

I am not sure how to do it. Similar problem was in Firefox's places and that problematic feature in places was... removed. So I suggest implement simply patch and log a new bug regarding widgets order.
Attachment #327024 - Attachment is obsolete: true
Attachment #328054 - Flags: review?(bugzilla)
Attachment #327024 - Flags: review?(bugzilla)
(In reply to comment #22)
> I am not sure how to do it. Similar problem was in Firefox's places and that
> problematic feature in places was... removed. So I suggest implement simply
> patch and log a new bug regarding widgets order.

Actually, something like this is already implemented in Views pane in Sunbird Settings dialog, where the list of weekdays is arranged depending on users first day of the week setting.
(In reply to comment #23)
> Actually, something like this is already implemented in Views pane in Sunbird
> Settings dialog, where the list of weekdays is arranged depending on users
> first day of the week setting.

In View page elements are in the same box - I have a patch for Recurrence pattern -> Repeat monthly. 

But you need to change order in Recurrence pattern -> Repeat annually, where elements are in different boxes. I'm working on this. I'll open a new bug (this bug regards additional entities only)
(In reply to comment #24)
> I'll open a new bug (this bug regards additional entities only)

Bug 443722.

This patch should be integrated before we have the ui String freeze. But browsing over the patch I found that most of the required resources are available in global.dtd and I don't see a need to duplicate them.
(In reply to comment #26)
> But browsing over the patch I found that most of the required resources are
> available in global.dtd and I don't see a need to duplicate them.

English version doesn't need these duplicates, but look at the comment 8, comment 14, comment 18 and comment 20.

Comment on attachment 328054 [details] [diff] [review]
Patch 0.3

r=sipaq
Sorry for the late review.
Attachment #328054 - Flags: review?(bugzilla) → review+
Patch checked in to HEAD and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Verified on latest Lightning pl - 1.8 branch and trunk (build 2008071408).
Status: RESOLVED → VERIFIED
Checkin note has a wrong bug nr. - 352213 instead of 352513  
Target Milestone: --- → 0.9
You need to log in before you can comment on or make changes to this bug.