1728893 - Return receipt panel not show in Dutch

Status: RESOLVED FIXED

(Thunderbird :: Build Config, defect)

Description

[Zoe Martin]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Install TB in Dutch, either TB 91 or Daily. Open the "Return receipt" panel, it's partly English although it is localised:
https://searchfox.org/l10n/source/nl/mail/messenger/preferences/receipts.ftl

If you look at the file in the omni.ja
omni.ja\localization\nl\messenger\preferences\receipts.ftl
you will find the file defective.

Looks like a build issue.

Comment 1

[Rob Lemley [:rjl]]

I suspect this is the result of strings changing content without creating a new ID. (I might be wrong as to the origin of the issue)

receipts.ftl in the nl l10n repo uses "acceskey" instead of "accesskey" in several places. The former might have worked once upon a time, but it no longer does and throws errors during the l10n repack.

[task 2021-09-02T16:07:59.740Z] 16:07:59     INFO -          receipts.ftl
[task 2021-09-02T16:07:59.740Z] 16:07:59     INFO -              ERROR: Missing attribute: accesskey at line 8, column 1 for return-receipt-checkbox
[task 2021-09-02T16:07:59.740Z] 16:07:59     INFO -              ERROR: Obsolete attribute: acceskey at line 10, column 5 for return-receipt-checkbox
[task 2021-09-02T16:07:59.740Z] 16:07:59     INFO -              ERROR: Missing attribute: accesskey at line 14, column 1 for receipt-leave-radio
[task 2021-09-02T16:07:59.740Z] 16:07:59     INFO -              ERROR: Obsolete attribute: acceskey at line 16, column 5 for receipt-leave-radio
[task 2021-09-02T16:07:59.740Z] 16:07:59     INFO -              ERROR: Missing attribute: accesskey at line 18, column 1 for receipt-move-radio
[task 2021-09-02T16:07:59.740Z] 16:07:59     INFO -              ERROR: Obsolete attribute: acceskey at line 20, column 5 for receipt-move-radio
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Missing attribute: accesskey at line 24, column 1 for receipt-return-never-radio
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Obsolete attribute: acceskey at line 26, column 5 for receipt-return-never-radio
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Missing attribute: accesskey at line 28, column 1 for receipt-return-some-radio
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Obsolete attribute: acceskey at line 30, column 5 for receipt-return-some-radio
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Missing attribute: accesskey at line 32, column 1 for receipt-not-to-cc
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Obsolete attribute: acceskey at line 34, column 5 for receipt-not-to-cc
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Missing attribute: accesskey at line 45, column 1 for sender-outside-domain
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Obsolete attribute: acceskey at line 47, column 5 for sender-outside-domain
[task 2021-09-02T16:07:59.741Z] 16:07:59     INFO -              ERROR: Missing attribute: accesskey at line 49, column 1 for other-cases-label
[task 2021-09-02T16:07:59.742Z] 16:07:59     INFO -              ERROR: Obsolete attribute: acceskey at line 51, column 5 for other-cases-label

I locally changed "acceskey" to "accesskey" and reran mach build installers-nl and these errors disappeared, and receipts.ftl looks more like the en-US version.

However, there are a number of other problems just with NL!

messengercompose.ftl:
 0:03.54           -add-attachment-notification-reminder
 0:03.54           ERROR: Missing value at line 79, column 1 for attachment-bucket-count
 0:03.54           ERROR: Obsolete attribute: value at line 81, column 5 for attachment-bucket-count
 0:03.54           ERROR: Obsolete attribute: accesskey at line 86, column 5 for attachment-bucket-count

preferences.ftl
 0:03.55             ERROR: Missing value at line 439, column 1 for type-column-label
 0:03.55             ERROR: Obsolete attribute: label at line 440, column 5 for type-column-label
 0:03.55             ERROR: Obsolete attribute: accesskey at line 441, column 5 for type-column-label
 0:03.55             ERROR: Missing value at line 443, column 1 for action-column-label
 0:03.55             ERROR: Obsolete attribute: label at line 444, column 5 for action-column-label
 0:03.55             ERROR: Obsolete attribute: accesskey at line 445, column 5 for action-column-label

Flod has recently advised me as to how to go about tracking all of these things down. Fixing may take time to get everything though.

Magnus, if I document the process and mentor is there another developer who can work on the bulk of these? NL is most likely not the only affected language.

Comment 2

[Magnus Melin [:mkmelin]]

Some/all of those strings changed after 91 I think.
Lasana could work on it once you figure out what needs doing.

Comment 3

[Zoe Martin]

receipts.ftl in the nl l10n repo uses "acceskey" instead of "accesskey" in several places.

But that was corrected at TB 90:
https://hg.mozilla.org/comm-central/rev/3b7a8ea09f4289ca720bbfb8858612022145a621#l7.1
It hasn't been corrected here: https://searchfox.org/l10n/source/nl/mail/messenger/preferences/receipts.ftl

Some/all of those strings changed after 91 I think.

Not in receipts.ftl: https://searchfox.org/comm-esr91/source/mail/locales/en-US/messenger/preferences/receipts.ftl

Comment 4

[Rob Lemley [:rjl]]

As I mentioned above, this particular problem was indeed caused by work I did in Bug 1692289. I was unaware of a Fluent "feature": In case of Fluent, you need to update the string ID also when the morphology of the message changes, i.e. attributes are added or removed. reference New IDs probably should have been generated since the acceskey attribute was changed to accesskey. Now that the cause is known, a fix can be worked out.

I ran compare-locales against the tier one locales (de fr ja ja-JP-mac en-GB es-ES it pl ru nl pt-BR) - limiting to a smaller set for now.

Of those 10, 7 show errors:

lang	errors
en-GB	25
es-ES	25
fr	25
nl	25
pl	3
pt-BR	3
ru	25

I'd wager that the locales with 25 errors are going to be the same as I listed above for nl.

It is possible to fix this in Pontoon once you know that the problem exists. It's probably more efficient to do a manual push.

Flod, what do you suggest?

I'll run compare-locales on the rest early next week.

Comment 5

[Rob Lemley [:rjl]]

For that matter, why does compare-locales show these errors but Pontoon doesn't?

Comment 6

[Francesco Lodolo [:flod]]

The only correct way to fix this is to change string IDs, and have string retranslated. There's no way to fix it in Pontoon.

Pontoon doesn't show the warning because the string changed afterwards, and that's not expected.

I'm OK with running a migration, if you provide one, to minimize the impact on localizers.

With that said, I can't stress enough that Thunderbird needs someone to own localization in its entirety, including understanding the processes and limitations, and solving this type of issues.

Comment 7

[Zoe Martin]

Can't you just fix the L10N repository and then refresh Pontoon from there? It's not likely that TB will create 25+ new string IDs, or is it?

Comment 8

[Onno Ekker [:nONoNonO UTC+1]]

I'm not sure where the Pontoon strings are stored, but it shouldn't be too hard to s/.acceskey/.accesskey/ in all locales of receipts.ftl, without the need to change the string ID and having to retranslate everything in all locales.

And if that's not possible, go with Zoe's suggestion and do the substitutes in Mecurial and pull them into Pontoon.

Comment 9

[Magnus Melin [:mkmelin]]

Something like this?

for dir in $@; do #Pass "*/" as an argument if you are working in the l10n-central directory.
  sed -i 's/\.acceskey/.accesskey/g' ${dir}mail/messenger/preferences/receipts.ftl
  sed -i 's/"/“/g' ${dir}/mail/messenger/preferences/receipts.ftl
  sed -i "s/'/’/g" ${dir}/mail/messenger/preferences/receipts.ftl
  hg --cwd=$dir commit -m "Bug 1728893 - fix receipts.ftl .acceskey -> .accesskey and nice quotes"
  hg --cwd=$dir push #update the push command according to the branch and related arguments.
done

Comment 10

[Francesco Lodolo [:flod]]

The "accesskey" change was only one of the issues (i.e. one of the strings that were changed without changing the ID).

Please fix them by changing the IDs, not taking shortcuts.
https://hg.mozilla.org/l10n-central/it/rev/2f5d218dfb8f8dbc50cabee089774283a7b3cc82
https://hg.mozilla.org/l10n-central/it/rev/c089c94269e98df70fbf667d351906e7af448871

These were the fixes I had to make to get rid of 25 compare-locales errors in Italian. Someone can run compare-locales against a locale like French to check them.

Comment 11

[Francesco Lodolo [:flod]]

(In reply to Francesco Lodolo [:flod] from comment #10)

These were the fixes I had to make to get rid of 25 compare-locales errors in Italian. Someone can run compare-locales against a locale like French to check them.

Additional note: these I caught because they were producing warnings in compare-locales (lack of attributes, terms, etc). I think it's safe to assume that there are more of these changes.

Comment 12

[Lasana Murray]

Attachment: Bug 1728893 - Update fluent names of strings that were changed. Follow up to bug 1692289. r=mkmelin

Comment 13

[Zoe Martin]

Is that the way to go? This will cause retranslation of all those strings in all locales, including the ones that aren't broken. And since localisers might not even see the relationship with the previous string, it may cause different re-translations. Wasn't the plan to fix the L10N repos directly? Besides, if this lands in TB 94, how does it fix TB 91 ESR?

Comment 14

[Rob Lemley [:rjl]]

Per comment 10, creating new IDs is the preferred fix. Then uplift. This ensures that we don't create more corruption with a script that doesn't quite work.
As for retranslation, we need to communicate the relationship to old strings to the translators so they're aware.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d1242681a9fb
Update fluent names of strings that were changed. Follow up to bug 1692289. r=mkmelin

Comment 16

[Óvári]

Can you please advise if this issue fixed for Thunderbird 91 ESR for the Hungarian locale? Thank you

Comment 17

[Rob Lemley [:rjl]]

(In reply to Óvári from comment #16)

Can you please advise if this issue fixed for Thunderbird 91 ESR for the Hungarian locale? Thank you

Not fixed in esr91 yet.

In order to see this fixes on 91, the general policy for uplifting is that the fix goes through at least one beta. If this is uplifted to 93.0b4 (September 28), we can verify the fix on locales that have translated the new strings. (Hungarian is one of them.) Then we could potentially uplift for 91.2.0, scheduled for October 5. l10n-changesets on c-esr91 will also need repinning to pick up the translations of the new strings.

Comment 18

[Rob Lemley [:rjl]]

Comment on attachment 9240551 [details]
Bug 1728893 - Update fluent names of strings that were changed. Follow up to bug 1692289. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: Portions of Thunderbird are not translated when they should be
Testing completed (on c-c, etc.): Verified the return receipt dialog is translated on Thunderbird Daily from 2021-09-22 (Hungarian)
Risk to taking this patch (and alternatives if risky):
Medium risky. The strings are already not appearing in English and can't really get much worse than that.

As of now, 18 locales have translated the replacement strings, Dutch is one of those. There may be more by time the build happens early next week.

Comment 19

[Wayne Mery (:wsmwk)]

Comment on attachment 9240551 [details]
Bug 1728893 - Update fluent names of strings that were changed. Follow up to bug 1692289. r=mkmelin

[Triage Comment]
Approved for beta

Comment 20

[Rob Lemley [:rjl]]

Thunderbird 93.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/40de341bc2b7

Comment 21

[Rob Lemley [:rjl]]

Comment on attachment 9240551 [details]
Bug 1728893 - Update fluent names of strings that were changed. Follow up to bug 1692289. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: Portions of Thunderbird are not translated when they should be
Testing completed (on c-c, etc.): Verified the return receipt dialog is translated on Thunderbird Daily from 2021-09-22 (Hungarian)
Risk to taking this patch (and alternatives if risky):
Medium risky. The strings are already not appearing in English and can't really get much worse than that.

Note to uplifter, need to repin l10n-changesets.json.

Comment 22

[Wayne Mery (:wsmwk)]

Comment on attachment 9240551 [details]
Bug 1728893 - Update fluent names of strings that were changed. Follow up to bug 1692289. r=mkmelin

[Triage Comment]
Approved for esr91

Comment 23

[Rob Lemley [:rjl]]

Thunderbird 91.2.0:
https://hg.mozilla.org/releases/comm-esr91/rev/79de824011b8

Comment 24

[Rachel Martin]

(In reply to Rob Lemley [:rjl] from comment #21)

Note to uplifter, need to repin l10n-changesets.json.

And you will need to keep doing so since not all locales have caught up, most notably, German, Spanish (Spain):
https://searchfox.org/l10n/search?q=return-receipt-checkbox-control&path=