4 years ago
4 years ago


(Reporter: fios, Assigned: MakeMyDay)


Lightning 4.7
Dependency tree / graph



(1 attachment, 1 obsolete attachment)

The following strings cannot be localized without a %1$S placeholder for the subject in many locales, because the subject may have to be in a non‑initial position i.e.
James has confirmed to attend
in our locale MUST be
Has confirmed James that will he take part

All in

has confirmed to attend

has confirmed to not attend

has delegated the attendance to %1$S

still needs to decide whether to attend

has tentatively confirmed to attend
There seems to be another batch:

They also seem to occur independently in Calendar (


Component: Untriaged → General
Product: Thunderbird → Calendar
If placeholders are representing numbers, plural rules should be enabled.
Hmm unfortunately we are too late in cycle to change this for 45 unless we do late-l10n this short before the next merge. MakeMyDay, can you take a look at this?

If we do have to do late-l10n, we could possibly slip in some more strings for that patch MakeMyDay didn't have time to complete before the merge but wanted to have in 45.
Flags: needinfo?(makemyday)
I would say late changes, otherwise I (and other locales) will have to leave these untranslated until the next cycle.
Each finally displayed text is composed out of the attendee's name and three strings, e.g.

dialog.tooltip.attendeeRole.REQ-PARTICIPANT=%1$S is a required participant and %2$S.
dialog.tooltip.attendeePartStat.ACCEPTED=has confirmed to attend

would render to (given the attendee is James here):

James is a required participant and has confirmed to attend.

We have 100 possible combinations in each of the two files, so some way to combine this dynamically seems to be appropriate.

Michael B., can you propose a suitable notation for this from a localizers perspective based on example strings?

Michael W., the placeholders are not reperenntig numbers, are you referring to anything specific?
Flags: needinfo?(milupo)
Flags: needinfo?(makemyday)
Flags: needinfo?(fios)
@MakeMyDay: No, it was a preventive thought only. I wanted "to kill two birds with one stone". :-)
Flags: needinfo?(milupo)
Ah in which case I totally mistranslated these. I don't think that will work well across languages, in the main because some languages will have to construct the "has confirmed to attend" around (i.e. some to the left and some to the right of %2$S and since there can be ACCEPTED, DECLINED, DELEGATED etc, that won't work across all the possible options.

I would suggest splitting this into two sentences.
dialog.tooltip.attendeeRole.REQ-PARTICIPANT=%1$S is a required participant at this event.
dialog.tooltip.attendeePartStat.ACCEPTED=%1$S has confirmed he/she will attend.

Or words to that effect. It's a little tautologous but it avoids a whole raft of really tortured translations.
If you want it to be less tautologous, you could start the second sentence with "Good news/Unfortunately/However... which means the second sentence does not start with James.
Flags: needinfo?(fios)
Thank you. Please consider that attendeeUserType strings like 

dialog.tooltip.attendeeUserType.ROOM=Room %1$S

may also have a pre/sufix. So replacing the first placeholder in the attendeeRole string with that is safe from your perspective?
Flags: needinfo?(fios)
Room/Group etc? The way I read the tooltips, I read this to mean "Room 101" and stuff like that but perhaps not. Can you give me an example of how Room %1$S translates in a full composed string for the end user?
Flags: needinfo?(fios) → needinfo?(makemyday)
This is either a name or an emaul address (if no name is available). An example can be a distribution list resolving to all users like: Group All Users <>

The pre/suffix is meant to characterize the attendee type if suitable.
Flags: needinfo?(makemyday)
Ok, in which case that really needs a separator but otherwise it works. If you have
Group All Users <>
that makes Group look like a verb i.e. put all users in a Group. I would suggest
Group: All Users <>
All Users <> (Group)

but other than that, I can't see an issue with those in the same way the missing %1$S was a problem.
Assignee: nobody → makemyday
Posted patch UpdateAttendeeStrings-V1.diff (obsolete) — Splinter Review
Patch, untested so far, due to current test bustage. Philipp, I'll request a review once this is done and I got feedback from the localizers.

@localizers: Can you please check wether the modified strings in and are now appropriate from your perspective and provide an according feedback?
Attachment #8708692 - Flags: feedback?(milupo)
Attachment #8708692 - Flags: feedback?(merikes.lists)
Attachment #8708692 - Flags: feedback?(fios)
It looks good to me now. Minor niggle "has confirmed to attend" is not great English. "has confirmed attendance" or "has confirmed they will attend" would be better.

Similarly: has confirmed to not attend > has confirmed they will not attend

has delegated the attendance to %1$S > not "the"

Sorry, it never occurred to me to check for English style & grammar when I reported the bug.
Attachment #8708692 - Flags: feedback?(fios) → feedback+
Thank you. I'll go with the following now:

%1$S has confirmed attendance.
%1$S has declined attendance.
%1$S has delegated attendance to %2$S.
%1$S still needs to reply.
%1$S has confirmed attendance tentatively.

If there's no further objection to this until tonight, I'll update the patch accordingly to get this reviewed and checked in asap.
Comment on attachment 8708692 [details] [diff] [review]

Review of attachment 8708692 [details] [diff] [review]:

Looks good to me.
Attachment #8708692 - Flags: feedback?(merikes.lists) → feedback+
Ok, here we go.

N.B. The test should pass, although I was able to do a full run yet do to current breakage.
Attachment #8708692 - Attachment is obsolete: true
Attachment #8708692 - Flags: feedback?(milupo)
Attachment #8708834 - Flags: review?(philipp)
Attachment #8708834 - Flags: review?(philipp)
Attachment #8708834 - Flags: review+
Attachment #8708834 - Flags: approval-calendar-aurora+
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.8
Target Milestone: 4.8 → 4.7
Version: unspecified → Lightning 4.7
You need to log in before you can comment on or make changes to this bug.