Closed Bug 572153 Opened 14 years ago Closed 14 years ago

[zh-TW] No recurrence previews and no saving of task edition when range of recurrence is set to be "Repeat until someday"

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: petercpg, Unassigned)

References

(
URL
)

Details

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

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-TW; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
Build Identifier: http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/1.0b2rc2/win32/

The preivew calendar is not working in the "Edit Recurrence" dialog of "Edit Task".

When user is trying to click OK with "Repeat until:" set, the dialog will not dismiss; if Cancel button is clicked, the dialog will dismiss but the mouse cursor will turn to be busy in Thunderbird. Also, the preview calendar is not working.

Reproducible: Always

Steps to Reproduce:
1. (Add a Calender, and then) Add a Task.
2. Edit the Task, setting "Repeat" to Custom.
3. Set range of recurrence to any time in future.
4. Click OK.
Actual Results:  
a) After step 2 as above, the dates in preview calendar is not shown in bold while the default range of recurrence is set to no end date.

b) After Step 3, when I click OK but nothing was happening; when I click Cancel, the "Edit Recurrence" dialog will dissappear (this is correct), but the mouse cursor will turn to be busy, however the program is working as usual, not frozen.

Expected Results:  
a) Bold dates should be shown in preview.

b) Bold dates in the preview calendar should be shown as per user's setting in "Repeat until".

I've tried to reproduce in zh-TW, zh-CN, en-US, ja locales, however I can only reproduce this bug in zh-TW. 

Only tried in Windows 7 x64 zh-TW and Windows XP x32 zh-TW OSes.
Do you get any error console messages? Could this be a strings issue, i.e do you know if it work with the newest translation files you pushed?

I'm marking this blocking since we should investigate.
Flags: blocking-calendar1.0+
Whiteboard: [needed beta][has l10n impact]
I think there are errors in the strings "yearlyOrder" [1] and "yearlyOrder2" [2] because those strings shouldn't contain other than the string parameters (%x$S) to allow a different order of the elements (menulists, labels etc.) in the dialog.

yearlyOrder=%3$S %1$S æ—¥%2$S
yearlyOrder2=%4$S çš„ %1$S %3$S %2$S

deleting the extra characters "æ—¥" and "çš„", and correcting the typo in the string "repeatDetailsUntil" [3]:

repeatDetailsUntil=發生於從 %2$S 到 %3$S\n的 %4$S 到 %5$S\n%1%$。 ,
                                                          ^^
there aren't errors in the console and everything seems working, but obviously I can't say what is written and if the order of the elements is right.

Maybe similar errors there are in the locales Hebrew and Romanian (though, about the first one, I've probably missed something because there are a lot of strange strings in that file, so there should be something that I don't know):
Hebrew  
http://mxr.mozilla.org/l10n-mozilla1.9.2/source/he/calendar/chrome/calendar/calendar-event-dialog.properties#167
Romanian
http://mxr.mozilla.org/l10n-mozilla1.9.2/source/ro/calendar/chrome/calendar/calendar-event-dialog.properties#257

                                                             
[1] http://mxr.mozilla.org/l10n-mozilla1.9.2/source/zh-TW/calendar/chrome/calendar/calendar-event-dialog.properties#359
[2] http://mxr.mozilla.org/l10n-mozilla1.9.2/source/zh-TW/calendar/chrome/calendar/calendar-event-dialog.properties#365
[3] http://mxr.mozilla.org/l10n-mozilla1.9.2/source/zh-TW/calendar/chrome/calendar/calendar-event-dialog.properties#289
Status: UNCONFIRMED → NEW
Ever confirmed: true
So this sounds like it needs to be fixed in the locale. Could we make the calendar code more robust and be a bit more forgiving if the localization contains an error? (Decathlon, do you have time to look into this in the next 1-2 days?)

This way we are on the safe side if the other locales don't fix the issue in time.

Peter, is it possible to just take out "æ—¥" and "çš„", or does this somehow show up in the UI?
After editing what Decathlon pointed out and reorganizing the structure in some sentences, this bug seems to be fixed now. Can somebody help me test on this?

Commited as http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/zh-TW/rev/696a7344f8f5

Thanks guys.
The same has been reported with Bug 449646 for the 0.9 release but it was decided to not make the dialog more failsafe.
(In reply to comment #2)

> Maybe similar errors there are in the locales Hebrew and Romanian (though,
> about the first one, I've probably missed something because there are a lot of
> strange strings in that file, so there should be something that I don't know):

Both Hebrew and Romanian didn't make it in time for this release, so thats not a problem for now. I did notice that French has the issue though. I'll contact the owner about this problem.

(In reply to comment #5)
> The same has been reported with Bug 449646 for the 0.9 release but it was
> decided to not make the dialog more failsafe.
I think we should at least add a comment, personally I don't have a problem with making it more failsafe. Maybe we could add a cal.WARN() message that the locale is doing something wrong.
IMHO the first thing is a good localization note, because at the moment, reading the comments, those three strings seems like normal strings that have to compose a sentence putting together other strings, instead the goal is completely different.
What it needs is a string explanation, the (true) meaning of every parameter and an explicit warning to avoid adding others strings or characters in the strings.
I confirm that the issue in French can be fixed by removing "le " in front of the two strings. I can't fix it myself for the next few hours, but I forwarded the message to another team member (Cédric) in hope that he can do it. If you need to start new builds earlier you can just take my word that is seems the right thing to do :)

I agree with Decathlon that the current localization note may be misleading. I'm not sure that "ordinal with article" is clear enough, especially with the examples below. At first sight it seemed to imply that the article *should* be included when it's exactly the opposite.

In addition to an explicit warning not to add anything else, I'd suggest changing the description to something like "ordinal prefix, optional article included" (or no mention of an article at all), and adding some delimiters in the examples lines, like this:
# e.g. "[the First] [Saturday] [of] [September]"
Lightning 1.0b2 has been released, should we mark this bug as fixed and file a follow-up bug in case you want to improve localization note / error handling?
Mark as FIXED as 1.0b2 has been released. :)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.