Closed Bug 402376 Opened 12 years ago Closed 9 years ago

Custom reminder dialog is hardly localizable

Categories

(Calendar :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rimas, Assigned: Fallen)

References

Details

(Keywords: l12y, Whiteboard: [needed beta][has l10n impact])

Attachments

(3 files, 1 obsolete file)

Attached image screenshot
The custom reminder setup dialog is really hard to localize properly. Considering the fact that it tries to generate a sentence from 4 independent strings, it may become a major headache for localizers.

For example, it's translated improperly to lt in 0.7, because of the rules of declension. Correct way to write those sentences would be:
15 minutes before beginning:
   15 min. prieš įvykio pradžią
15 minutes since beginning:
   15 min. po įvykio pradžios

An idea how to adapt Lithuanian to this form has just hit me, and I committed the (hopefully) fixed strings to CVS, however it would be much better if we didn't have to adapt our sentences to the layout of XUL controls. :)
OS: Linux → All
Hardware: PC → All
It's a known issue. See bug 398082 for discussing and bug 359353 and bug 177097
let's make this one block bug #359353 then. :)
Blocks: 359353
Summary: Custom reminder dialog is hardly localizable → [Proto] Custom reminder dialog is hardly localizable
Component: General → Theme
Product: Calendar → Firefox
Target Milestone: --- → Firefox 3
Version: unspecified → Trunk
Oops, sorry, my bad, returning to the right component, awfully sorry about stomping your target milestone, please send hatemail to this address :(
Component: Theme → General
Product: Firefox → Calendar
Target Milestone: Firefox 3 → ---
Version: Trunk → Sunbird 0.7
Version: Sunbird 0.7 → unspecified
We had similar problem in Polish, but we've found the solution:
http://mxr.mozilla.org/l10n/source/pl/calendar/chrome/calendar/calendar-event-dialog.dtd

(look at newevent.before.label and newevent.after.label)
Hey, I don't really understand Polish that good, you know...

Anyway, like I said, I've come up with a workaround for this problem. The thing is that I don't think it's always possible to come up with one.

Recurrence dialog has exactly the same problem when you have to choose e.g. <...|fifth|last> and <...|friday|saturday|day> in a row, and weekdays use a different gender than just a "day" in Lithuanian. And it's even more complex in Italian apparently, because different weekdays use different genders in that language.
(In reply to comment #5)
> Hey, I don't really understand Polish that good, you know...

http://translate.google.com/ :-P

> Anyway, like I said, I've come up with a workaround for this problem. The thing
> is that I don't think it's always possible to come up with one.
> 
> Recurrence dialog has exactly the same problem when you have to choose e.g.
> <...|fifth|last> and <...|friday|saturday|day> in a row, and weekdays use a
> different gender than just a "day" in Lithuanian. And it's even more complex in
> Italian apparently, because different weekdays use different genders in that
> language.

I understand, the same situation we have in Polish language.
Summary: [Proto] Custom reminder dialog is hardly localizable → Custom reminder dialog is hardly localizable
The custom reminder dialog has changed a bit. There are probably similar problems, but I'd appreciate if someone could give a short summary of

* What parts of the dialog are hard to localize?

* What elements have to be switched in which way, to allow localization?
Whiteboard: [feedback?]
(In reply to comment #0)
> 15 minutes before beginning:
>    15 min. prieš įvykio pradžią

In Polish it should be: [15] [minut v] [przed v] [rozpoczęciem wydarzenia v]

> 15 minutes since beginning:
>    15 min. po įvykio pradžios

In Polish it should be: [15] [minut v] [po v] [rozpoczęciu wydarzenia v]

We have two different forms of single word: rozpoczęciem/rozpoczęciu (like pradžią/pradžios in Lithuanian)

Workaround found in Polish:
[15] [minut v] [przed czasem v] [rozpoczęcia wydarzenia v]
[15] [minut v] [po czasie v] [rozpoczęcia wydarzenia v]

We changed "przed" ("before") to "przed czasem" (something like "before the time"), "po" ("after"/"since") to "po czasie" ("after the time"/"since the time"). Now we can use the same form ("rozpoczęcia") in both cases and it sounds OK.

Rimas, are you able to do something similar in Lithuanian?
Hubert: I said I worked it around. I just don't like that I have to.

Philipp: I don't think much has changed. The dialog still makes me compose a sentence from four different parts, and that's tough. IMHO, a step forward would be merging the last two drop-downs to one, like this:

[  before the event starts    v ]
 | after the event starts      |
 | before the event ends       |
 | after the event ends        |
 +---------------------------- +

I think this would make stuff easier for Hubert too.
For me it does not matter (because mentioned workaround sounds quite well in Polish) but I assume that localizers of others Slavic languages have the same problem as you reported.
Rimas, your suggestion sounds reasonable. I might add a splitter to make it more obvious that the first two are about start and the last two are about ending.

I'll whip up a patch for this soon, if someone else wants to step in go ahead, this shouldn't be too hard to solve.
Assignee: nobody → philipp
Whiteboard: [feedback?] → [good first bug]
(In reply to comment #11)
> I might add a splitter to make it
> more obvious that the first two are about start and the last two are about
> ending.

I don't think it's needed. It's just four items after all, pretty straightforward...
Flags: blocking-calendar1.0+
Whiteboard: [good first bug] → [not needed beta][has l10n impact][good first bug]
Attached patch Fix - v1 (obsolete) — Splinter Review
This patch takes care.
Attachment #463962 - Flags: review?(Mozilla)
Comment on attachment 463962 [details] [diff] [review]
Fix - v1

Rimas, I used existing strings here since they had the same English text. Is this ok for your language, or do we need dedicated strings?
Attachment #463962 - Flags: feedback?(rq)
Status: NEW → ASSIGNED
(In reply to comment #14)
> Comment on attachment 463962 [details] [diff] [review]
> Fix - v1
> 
> Rimas, I used existing strings here since they had the same English text. Is
> this ok for your language, or do we need dedicated strings?

sorry, I was AFK. Do you have a screenshot with this patch applied?
Attached image Screenshot - v2
Here's the screenshot. The strings used are the same as when serializing the alarm object, which means the same strings you see in the list view above all the dropdowns. Rimas, is this ok?
Attached patch Fix - v2Splinter Review
This patch fixes what I forgot to remove in v1.
Attachment #463962 - Attachment is obsolete: true
Attachment #464007 - Flags: review?(Mozilla)
Attachment #464007 - Flags: feedback?(rq)
Attachment #463962 - Flags: review?(Mozilla)
Attachment #463962 - Flags: feedback?(rq)
Comment on attachment 464007 [details] [diff] [review]
Fix - v2

Looking at the screenshot, this will work fine for me, thus you have my feedback+.

However, while checking out calendar-alarms.properties, I also started thinking about two things:
1. why we have reminderCustomTitle as a separate string instead of just having some placeholder in all reminderCustomOrigin* strings
2. whether reusing same strings in both the drop-down and the composed sentence is OK or not.

Obviously, copying all those strings to new ones and adding a placeholder to each of them would eliminate both my doubts, but I'm not sure if we really need that – maybe I'm just too paranoid... :)
Attachment #464007 - Flags: feedback?(rq) → feedback+
(In reply to comment #18)

I also never know how paranoid to be about these things.

> 1. why we have reminderCustomTitle as a separate string instead of just having
> some placeholder in all reminderCustomOrigin* strings
Makes sense, I guess this could be changed but since its already in place it probably doesn't hurt, right? If there is a language where the word for the unit is different based on the origin then I'm happy to change it though.


> 2. whether reusing same strings in both the drop-down and the composed sentence
> is OK or not.
Yes, this is what I was wondering about in this bug. If it works for you and Hubert, I guess we'll just keep it this way and wait for complaints. So if anyone reading this bug has doubts, please let us know!

Thanks for your feedback!
(In reply to comment #19)
> Yes, this is what I was wondering about in this bug. If it works for you and
> Hubert, I guess we'll just keep it this way and wait for complaints. 

I'm totally fine with that. :)
(In reply to comment #5)

> Recurrence dialog has exactly the same problem when you have to choose e.g.
> <...|fifth|last> and <...|friday|saturday|day> in a row, and weekdays use a
> different gender than just a "day" in Lithuanian. And it's even more complex in
> Italian apparently, because different weekdays use different genders in that
> language.

I've filed bug 570091 about the gender concordance between ordinal and weekdays for the menulist in the recurrence dialog.
Whiteboard: [not needed beta][has l10n impact][good first bug] → [needed beta][has l10n impact][good first bug]
Whiteboard: [needed beta][has l10n impact][good first bug] → [needed beta][has l10n impact][needs review]
Comment on attachment 464007 [details] [diff] [review]
Fix - v2

>            // Origin
>            let origin
missing ; at end of line.

> -    let relation = document.getElementById("reminder-relation");
> -    let origin = document.getElementById("reminder-origin");
> +    let relationOrigin = document.getElementById("reminder-relation-origin");
>      let absDate = document.getElementById("reminder-absolute-date");
>      let action = document.getElementById("reminder-actions-menulist").selectedItem.value;
> +    let [relation, origin] = relationOrigin.value.split("-");
I'd prefer to have the split statement just below the assignment of relationOrigin. But if it is on purpose, to have the getElementById Lines next to each other, I can live with it.

with at least the first nit fixed 
r=markus
Attachment #464007 - Flags: review?(Mozilla) → review+
Both nits fixed and...

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/c20021375df0>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needed beta][has l10n impact][needs review] → [needed beta][has l10n impact]
Target Milestone: --- → 1.0b3
You need to log in before you can comment on or make changes to this bug.