Closed Bug 621840 Opened 9 years ago Closed 9 years ago

the month name displayed in calendar is in an incorrect form

Categories

(Calendar :: Calendar Views, defect, trivial)

defect
Not set
trivial

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: dariusz.wawer, Assigned: Fallen)

Details

(Whiteboard: [needed beta][has l10n impact])

Attachments

(4 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3

at the top of the calendar (lightning) the name of the month is written like:
"27 Grudzień 2010" where in fact it should be "27 grudnia 2010". It is the same for all other months.
This is a major error and since there are probably hundreds of thousands of users looking at it, they learn it the wrong way. The fix should be simple, since the month form does not vary when the day number changes.

Reproducible: Always

Steps to Reproduce:
1. go into calendar
2. look at the top of the screen
3.
Actual Results:  
27 Grudzień 2010

Expected Results:  
27 grudnia 2010
Assignee: marcoos+bmo → hubert
It works for me. Could you attach a screenshot?
QA Contact: akalla → kstawarz
Attached image date range misspelled
In the past we had an opposite issue. There was "grudnia" in the place where "grudzień" was expected: http://bugs.aviary.pl/show_bug.cgi?id=1531 so I have to be careful with this kind of changes.

I will look for this to figure out what I can do.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It is not a bug in localization.

I cannot change the name of the month because "grudnia 2010" instead of "Grudzień 2010" is displayed in month view.
-> Product: Calendar

Solution:

a) Month view should use month.xx.name from global.dtd (day, week and multiweek views should use month.xx.name from dateFormat.properties)

OR

b) Separate entities should be added for Month view.
Assignee: hubert → nobody
Component: pl / Polish → Calendar Views
Product: Mozilla Localizations → Calendar
QA Contact: kstawarz → views
Version: unspecified → Trunk
Flags: wanted-calendar1.0?
Could you clarify in which cases you need a capital month name and in which not? I'm a bit confused why this needs to be done in the month view but not in the other views.

Also, how does the window title relate?  

Don't get me wrong, I want this fixed, but I need some more insight :) Setting blocking+, it should be an easy one.
Flags: wanted-calendar1.0? → blocking-calendar1.0+
Whiteboard: [needed beta][has l10n impact]
Polish language is a bit more complicated than english and nouns come in different forms depending on the context in which they are used (http://en.wikipedia.org/wiki/Declension). The form used in the place highlighted in the screenshot is incorrect. I guess it would be difficult to explain this to non-declension-native-language-speaker.

Generally, if you ask "what date is it?", the answer should use the "XX grudnia" instead of "XX grudzien". Otherwise it's gramatically incorrect.

Window title has the correct form.

There's also the possiblity that I misunderstood your comment. If it doesn't make sense you may wait for Hubert's answer or ask for further clarification.
I misunderstood the issue a bit, but your explanation helps me a bit. So would it be sufficient to add a new string for *all* views only?

In general, this sounds like an issue that l10n tooling might mitigate. I imagine something similar to PluralForm.jsm to take care of declension. Until thats in place, lets fix it with an extra string.
Whiteboard: [needed beta][has l10n impact] → [needed beta][has l10n impact][needs feedback]
It depends how you would like to add new string "for *all* views only".

Note that day view and month view display correct form today. I need to have two separate forms:
1. Day view, week view and multiweek view
2. Month view

Generally: Each time when we have month name and number together I need to use genitive case for month name (which has different form in Slavic languages).

Day view: 18 stycznia 2011 --> correct (I guess that it has been taken from OS)
Week view: 16-22 Styczeń 2011 --> SHOULD BE: 16-22 stycznia 2011
Multiweek view: 16 Styczeń - 12 Luty 2011 --> SHOULD BE: 16 stycznia - 12 lutego 2011
Month view: Styczeń 2011 --> correct
Attached patch Fix - v1 (obsolete) — Splinter Review
This patch takes care by providing alternate strings when printing a month together with a year. Hubert, does this suffice to allow you to translate correctly? I'd appreciate feedback.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #506392 - Flags: review?(bv1578)
Attachment #506392 - Flags: feedback?(hubert)
Whiteboard: [needed beta][has l10n impact][needs feedback] → [needed beta][has l10n impact][needs review]
Comment on attachment 506392 [details] [diff] [review]
Fix - v1

Technically - it works OK and now I am able translate it correctly (feedback+), however the localization note is a little bit confusing.

Maybe I should add additional clarification here.

+# LOCALIZATION NOTE (monthInYear.*.name):
+# Used for display of Month-dates like 'December 2008'
+# Some languages, e.g. polish, need to use a differ
ent declension here.
+#    %1$S will be replaced with the year

In case you mentioned we use basic form (so it is not "different declension"):
December 2008 => Grudzień 2008
December => Grudzień

We need different declension in these cases:
[1-31] December 2008 => [1-31] grudnia 2008
[1-31] December => [1-31] grudnia
Attachment #506392 - Flags: feedback?(hubert) → feedback+
Hmm so maybe we should do this a bit differently then. Could you go through the following cases and check which require a different form than the basic form?

http://mxr.mozilla.org/comm-central/source/calendar/locales/en-US/chrome/calendar/calendar.properties#518

I think it would be good to add Month name strings for those cases, i.e

month.12.name = Grudzień
...

month.12.withDay.name = grudnia
...

Do you agree this makes more sense? I think it will allow more flexibility and not require specific changes each time.
(In reply to comment #12)
> Hmm so maybe we should do this a bit differently then. Could you go through the
> following cases and check which require a different form than the basic form?
> 
> http://mxr.mozilla.org/comm-central/source/calendar/locales/en-US/chrome/calendar/calendar.properties#518

> # LOCALIZATION NOTE (monthInYear):
> # used for display of Month-dates like 'December 2008'
> #    %1$S will be replaced with name of the month
> #    %2$S will be replaced with the year
> monthInYear=%1$S %2$S

BASIC FORM (Grudzień 2008)

> # LOCALIZATION NOTE (dayIntervalInMonth):
> # used for display of intervals in the form of 'March 3 - 9, 2008'
> #    %1$S will be replaced with name of the month of the start date
> #    %2$S will be replaced with the day-index of the start date
> #    %3$S will be replaced with the day-index of the end date
> #    %4$S will be replaced with the common year of both dates
> dayIntervalInMonth=%1$S %2$S – %3$S, %4$S

DIFFERENT FORM: 3-9 marca 2008

> # LOCALIZATION NOTE (dayIntervalBetweenMonths):
> # used for display of intervals in the form 'September 29 - October 5, 2008'
> #    %1$S will be replaced with name of the month of the start date
> #    %2$S will be replaced with the day-index of the start date
> #    %3$S will be replaced with name of the month of the end date
> #    %4$S will be replaced with the day-index of the end date
> #    %5$S will be replaced with the commmon year of both dates
> dayIntervalBetweenMonths=%1$S %2$S – %3$S %4$S, %5$S

DIFFERENT FORM: 29 września - 5 października 2008

> # LOCALIZATION NOTE (dayIntervalBetweenYears):
> # used for display of intervals in the form 'December 29, 2008 -
> January 4, 2009'
> #    %1$S will be replaced with name of the month of the start date
> #    %2$S will be replaced with the day-index of the start date
> #    %3$S will be replaced with the year of the start date
> #    %4$S will be replaced with name of the month of the end date
> #    %5$S will be replaced with the day-index of the end date
> #    %6$S will be replaced with the year of the end date
> dayIntervalBetweenYears=%1$S %2$S, %3$S – %4$S %5$S, %6$S

DIFFERENT FORM: 29 grudnia 2008 - 4 stycznia 2009

> # LOCALIZATION NOTE (datetimeIntervalOnSameDateTime):
> # used for intervals where end is equals to start
> # displayed form is '5 Jan 2006 13:00'
> #    %1$S will be replaced with the date of the start date
> #    %2$S will be replaced with the time of the start date
> datetimeIntervalOnSameDateTime=%1$S %2$S

It depends what we use here - short form (Jan) or full month (January)
SHORT FORM: 5 Jan 2006 13:00 => 5 sty 2006 13:00
DIFFERENT FORM: 5 January 2006 13:00 => 5 stycznia 2006 13:00

> # LOCALIZATION NOTE (datetimeIntervalOnSameDay):
> # used for intervals where end is on the same day as start, so we can
> leave out the
> # end date but still include end time
> # displayed form is '5 Jan 2006 13:00 - 17:00'
> #    %1$S will be replaced with the date of the start date
> #    %2$S will be replaced with the time of the start date
> #    %3$S will be replaced with the time of the end date
> datetimeIntervalOnSameDay=%1$S %2$S – %3$S

It depends what we use here - short form (Jan) or full month (January)
SHORT FORM: 5 Jan 2006 13:00 - 17:00 => 5 sty 2006 13:00 - 17:00
DIFFERENT FORM: 5 January 2006 13:00 - 17:00 => 5 stycznia 2006 13:00 - 17:00

> # LOCALIZATION NOTE (datetimeIntervalOnSeveralDays):
> # used for intervals spanning multiple days by including date and time
> # displayed form is '5 Jan 2006 13:00 - 7 Jan 2006 9:00'
> #    %1$S will be replaced with the date of the start date
> #    %2$S will be replaced with the time of the start date
> #    %3$S will be replaced with the date of the end date
> #    %4$S will be replaced with the time of the end date
> datetimeIntervalOnSeveralDays=%1$S %2$S – %3$S %4$S

It depends what we use here - short form (Jan) or full month (January)
SHORT FORM: 5 Jan 2006 13:00 - 7 Jan 2006 9:00 => 5 sty 2006 13:00 - 7 sty 2006 9:00
DIFFERENT FORM: 5 January 2006 13:00 - 7 January 2006 9:00 => 5 stycznia 2006 13:00 - 7 stycznia 2006 9:00

> # LOCALIZATION NOTE (datetimeIntervalTaskWithoutDate):
> # used for task without start and due date
> # (showed only in exported calendar in Html format)
> datetimeIntervalTaskWithoutDate= no start or due date

No month name.

> # LOCALIZATION NOTE (datetimeIntervalTaskWithoutDueDate):
> # used for intervals in task with only start date
> # displayed form is 'start date 5 Jan 2006 13:00'
> # (showed only in exported calendar in Html format)
> #    %1$S will be replaced with the date of the start date
> #    %2$S will be replaced with the time of the start date
> datetimeIntervalTaskWithoutDueDate=start date %1$S %2$S

It depends what we use here - short form (Jan) or full month (January)
SHORT FORM: start date 5 Jan 2006 13:00 => początek: 5 sty 2006 13:00
DIFFERENT FORM: start date 5 January 2006 13:00 => początek: 5 stycznia 2006 13:00

> # LOCALIZATION NOTE (datetimeIntervalTaskWithoutStartDate):
> # used for intervals in task with only due date
> # displayed form is 'due date 5 Jan 2006 13:00'
> # (showed only in exported calendar in Html format)
> #    %1$S will be replaced with the date of the due date
> #    %2$S will be replaced with the time of the due date
> datetimeIntervalTaskWithoutStartDate=due date %1$S %2$S

It depends what we use here - short form (Jan) or full month (January)
SHORT FORM: due date 5 Jan 2006 13:00 => koniec: 5 sty 2006 13:00
DIFFERENT FORM: due date 5 January 2006 13:00 => koniec: 5 stycznia 2006 13:00
 
> I think it would be good to add Month name strings for those cases, i.e
> 
> month.12.name = Grudzień
> ...
> 
> month.12.withDay.name = grudnia
> ...
> 
> Do you agree this makes more sense?
> I think it will allow more flexibility and
> not require specific changes each time.

I agree, it will be the best solution.
Comment on attachment 506392 [details] [diff] [review]
Fix - v1

Reading comment #13, only the string "monthInYear" needs a "basic form" different from the other cases and the patch works in that way.
If no further strings need to change, for me it's r+, once corrected the comment in the localization note as suggested by Hubert in comment 11.

Instead, if you want to use the different string names:

    month.12.name = Grudzień
    ...

    month.12.withDay.name = grudnia
    ...

others changes have to be done, if I've correctly understood.
All the strings listed in comment 13 with "different form" should be composed by using the new strings month.*.withDay.name.
E.g, the following should change:
http://mxr.mozilla.org/comm-central/source/calendar/base/src/calDateTimeFormatter.js#278
in order to change the composition of the strings: 
  dayIntervalBetweenYears
  dayIntervalBetweenMonths
  dayIntervalInMonth
but also others need to change.
Attachment #506392 - Flags: review?(bv1578) → review+
What you've mentioned is totally correct, sorry for not retracting that review request. We've decided to do it a bit differently.
Attached patch Fix - v2 (obsolete) — Splinter Review
How does this work out for you? Do you think the method is clear enough so its easy to understand for everyone?
Attachment #506392 - Attachment is obsolete: true
Attachment #509256 - Flags: feedback?(hubert)
Comment on attachment 509256 [details] [diff] [review]
Fix - v2

For me it is clear. There are few small issues but generally it is OK (feedback+)

>diff -r 01d2a5828a81 calendar/locales/en-US/chrome/calendar/dateFormat.properties
>--- a/calendar/locales/en-US/chrome/calendar/dateFormat.properties	Tue Feb 01 23:20:55 2011 +0100
>+++ b/calendar/locales/en-US/chrome/calendar/dateFormat.properties	Thu Feb 03 00:12:33 2011 +0100
>@@ -36,6 +36,52 @@
> #
> # ***** END LICENSE BLOCK *****
> 
>+# In case you are looking for the note about different declensions on date
>+# formats, here it is. If your language doesn't use differnt declensions of

Misspelling - "different"

>+# month names, you shouldn't have much work. Just leave the .monthFormat

Maybe we should  use "*.monthFormat" instead of ".monthFormat"?

>+# string on "nominative" and the string month.*.name will be filled in.
>+#
>+# If you need a different form for a string, you can change the 
>+# .monthFormat

Maybe we should  use "*.monthFormat" instead of ".monthFormat"?

>to a differnt value. Supported values are currently:

Misspelling - "different"

>+#    nominative (default), genitive
>+# The modified month name form will then be filled in accordingly. If this
>+# system does not suit your needs, please file a bug!
>+
>+# LOCALIZATION NOTE (month.*.genitive):

It should be: # LOCALIZATION NOTE (month.*.name):

>+# Some languages require different declensions of month names.
>+# These values will be used if .monthFormat

Maybe we should  use "*.monthFormat" instead of ".monthFormat"?

> is set to "nominative" or in places
>+# where using a different declension is not yet supported.
>+# LOCALIZATION NOTE (month.*.genitive):
>+# Some languages require different declensions of month names.
>+# These values will be used if .monthFormat

Maybe we should  use "*.monthFormat" instead of ".monthFormat"?
Attachment #509256 - Flags: feedback?(hubert) → feedback+
Attached patch Fix - v3Splinter Review
Thanks for the comments! I've fixed the issues you've mentioned, requesting review for the code changes.
Attachment #509256 - Attachment is obsolete: true
Attachment #509587 - Flags: review?(bv1578)
Comment on attachment 509587 [details] [diff] [review]
Fix - v3

Nice and flexible.

>+     formatMonth: function formatMonth(aMonthNum, aBundleName, aStringBase) {
>+        let monthForm = cal.calGetString(aBundleName, aStringBase + ".monthFormat") || "nominative";
>+
>+         if (monthForm == "nominative") {
>+            // Fall back to the default name format
>+            monthForm = "name";
>+         }
3 spaces indentation for three lines inside formatMonth().

If comments about localization notes are right, according to comment #17, for me it's r+.

Do the following strings:
  datetimeIntervalOnSameDateTime
  datetimeIntervalOnSameDay
  datetimeIntervalOnSeveralDays
  datetimeIntervalTaskWithoutStartDate
require some kind of differentiation? (They have month and day number together).
On my system they are in local form even with non locale version of Lightning and Thunderbird, are they selected by the OS?
Attachment #509587 - Flags: review?(bv1578) → review+
(In reply to comment #19)
> Do the following strings:
>   datetimeIntervalOnSameDateTime
>   datetimeIntervalOnSameDay
>   datetimeIntervalOnSeveralDays
>   datetimeIntervalTaskWithoutStartDate
> require some kind of differentiation? (They have month and day number
> together).
These strings insert fully formatted dates, which use one of the other formats. On systems which support it, the system date formatting service is used. I don't think this needs any extra handling. If the OS translates this correctly (and the OS is localized), then you should get the right strings.



Thanks for the review!
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/41f1a1134ae2>
-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Backported to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/b1abb37f1c96>
a=philipp
Target Milestone: Trunk → 1.0b3
Whiteboard: [needed beta][has l10n impact][needs review] → [needed beta][has l10n impact]
Verified on Lightning pl (1.9.2 and trunk).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.