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 calendar.properties dialog.tooltip.attendeePartStat.ACCEPTED has confirmed to attend dialog.tooltip.attendeePartStat.DECLINED has confirmed to not attend dialog.tooltip.attendeePartStat.DELEGATED has delegated the attendance to %1$S dialog.tooltip.attendeePartStat.NEEDS-ACTION still needs to decide whether to attend dialog.tooltip.attendeePartStat.TENTATIVE has tentatively confirmed to attend
There seems to be another batch: imipHtml.attendeePartStat.ACCEPTED imipHtml.attendeePartStat.DECLINED imipHtml.attendeePartStat.DELEGATED imipHtml.attendeePartStat.NEEDS-ACTION imipHtml.attendeePartStat.TENTATIVE
They also seem to occur independently in Calendar (calendar.properties): dialog.tooltip.attendeePartStat.ACCEPTED dialog.tooltip.attendeePartStat.DECLINED dialog.tooltip.attendeePartStat.DELEGATED dialog.tooltip.attendeePartStat.NEEDS-ACTION dialog.tooltip.attendeePartStat.TENTATIVE and lightning.properties imipHtml.attendeePartStat.ACCEPTED imipHtml.attendeePartStat.DECLINED imipHtml.attendeePartStat.DELEGATED imipHtml.attendeePartStat.NEEDS-ACTION imipHtml.attendeePartStat.TENTATIVE
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.
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 dialog.tooltip.attendeeUserType.INDIVIDUAL=%1$S 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?
@MakeMyDay: No, it was a preventive thought only. I wanted "to kill two birds with one stone". :-)
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.
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?
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?
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 <email@example.com> The pre/suffix is meant to characterize the attendee type if suitable.
Ok, in which case that really needs a separator but otherwise it works. If you have Group All Users <firstname.lastname@example.org> that makes Group look like a verb i.e. put all users in a Group. I would suggest Group: All Users <email@example.com> or All Users <firstname.lastname@example.org> (Group) but other than that, I can't see an issue with those in the same way the missing %1$S was a problem.
Created attachment 8708692 [details] [diff] [review] UpdateAttendeeStrings-V1.diff 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 calendar.properties and lightning.properties are now appropriate from your perspective and provide an according feedback?
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.
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] UpdateAttendeeStrings-V1.diff Review of attachment 8708692 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me.
Created attachment 8708834 [details] [diff] [review] UpdateAttendeeStrings-V2.diff Ok, here we go. N.B. The test should pass, although I was able to do a full run yet do to current breakage.
The test passed on try: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=73883a635586