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)
Calendar
General
Tracking
(Not tracked)
VERIFIED
FIXED
0.9
People
(Reporter: thorsten.fritz, Assigned: hubert+bmo)
Details
Attachments
(2 files, 2 obsolete files)
51.06 KB,
image/png
|
Details | |
28.22 KB,
patch
|
sipaq
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 2•18 years ago
|
||
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.
Comment 3•18 years ago
|
||
(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).
Comment 4•18 years ago
|
||
(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'.
Comment 5•18 years ago
|
||
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
Comment 7•16 years ago
|
||
Taking.
Severity: normal → trivial
Status: NEW → ASSIGNED
Version: Trunk → unspecified
Updated•16 years ago
|
Status: ASSIGNED → NEW
Flags: wanted-calendar0.9?
Updated•16 years ago
|
Flags: wanted-calendar0.9? → wanted-calendar0.9+
Assignee | ||
Comment 8•16 years ago
|
||
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
Comment 9•16 years ago
|
||
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 10•16 years ago
|
||
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-
Assignee | ||
Comment 11•16 years ago
|
||
(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?
Assignee | ||
Comment 12•16 years ago
|
||
Attachment #326223 -
Attachment is obsolete: true
Attachment #327024 -
Flags: review?(bugzilla)
Comment 13•16 years ago
|
||
(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 14•16 years ago
|
||
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.
Assignee | ||
Comment 15•16 years ago
|
||
(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.
Assignee | ||
Comment 16•16 years ago
|
||
Comment 17•16 years ago
|
||
> > (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.
Assignee | ||
Comment 18•16 years ago
|
||
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.
Comment 19•16 years ago
|
||
Not for Portuguese
Comment 20•16 years ago
|
||
(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...)
Comment 21•16 years ago
|
||
(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."
Assignee | ||
Comment 22•16 years ago
|
||
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)
Comment 23•16 years ago
|
||
(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.
Assignee | ||
Comment 24•16 years ago
|
||
(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)
Assignee | ||
Comment 25•16 years ago
|
||
(In reply to comment #24) > I'll open a new bug (this bug regards additional entities only) Bug 443722.
Comment 26•16 years ago
|
||
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.
Assignee | ||
Comment 27•16 years ago
|
||
(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 28•16 years ago
|
||
Comment on attachment 328054 [details] [diff] [review] Patch 0.3 r=sipaq Sorry for the late review.
Attachment #328054 -
Flags: review?(bugzilla) → review+
Comment 29•16 years ago
|
||
Patch checked in to HEAD and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 30•16 years ago
|
||
Verified on latest Lightning pl - 1.8 branch and trunk (build 2008071408).
Status: RESOLVED → VERIFIED
Comment 31•16 years ago
|
||
Checkin note has a wrong bug nr. - 352213 instead of 352513
Updated•16 years ago
|
Target Milestone: --- → 0.9
You need to log in
before you can comment on or make changes to this bug.
Description
•