1658363 - TB 78 German locale (de): Several untranslated English menus but translated on l10n-central: Compose editor context/Edit menu (Cut, Copy, Paste, etc.: textActions.ftl), pill context menu (messengercompose.ftl)

Status: RESOLVED DUPLICATE of bug 1657221

(Thunderbird :: General, defect)

Description

[Peter]

Attachment: Screenshot 1: Compose editor, German context menu with English menus

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Write an eMail. Click on page using right mouse button to ad or delete something etc.

Actual results:

You get a window in English and in German

Expected results:

This should all be in German

Comment 1

[Thomas D. (:thomas8)]

Thank you, Peter! Confirming per screenshot of comment 0.
On which version of TB have you seen this?

Comment 2

[Thomas D. (:thomas8)]

Wayne, ideas for product/component of this?
Might depend on the actual cause? (toolkit/editor/localization)

Apart from that, what's the right product/component for regular localization bugs in specific localizations (like a word translated wrongly)?

Comment 3

[Andreas]

It's at least in version 78.1.1. As far as I found missing translations in the compose editor, it affects the Edit menu (Bearbeiten), the right click menu and the number of attachments in the attachment pane (to see this, you have to attach at least 1 file).

There is also a related question in the support forum:
https://support.mozilla.org/en-US/questions/1298361

Comment 4

[Wayne Mery (:wsmwk)]

Peter, are you using the htmledit addon?

Comment 5

[Peter]

Wayne, no, I don't

Comment 6

[Wayne Mery (:wsmwk)]

Assuming Peter is not Andreas, then we have three people reporting the same issue.

Does it only happen if you have an attachment? Or have text selected? How about after Help > Restart with addons disabled?

Comment 7

[Magnus Melin [:mkmelin]]

Thomas, could you investigate this further?

Comment 8

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #7)

Thomas, could you investigate this further?

Installed and tested 78.1.1 (64-Bit) DE.
Confirming this bug exactly as described, new profile, default config, no addons.

Affected:

text-action-undo
text-action-redo
text-action-cut
text-action-copy
text-action-paste
text-action-select-all
attachment-bucket-count and some others

Not affected:

text-action-delete in Edit menu

Items without German translation are mostly part of toolkit:
https://searchfox.org/comm-central/source/mozilla/toolkit/locales/en-US/toolkit/global/textActions.ftl

Then, it appears that messengercompose.ftl has not been translated except for the first item (remove-address-row-type-label), as all subsequent (visible) translations are missing, like pill context menu etc.:
https://searchfox.org/comm-central/source/mail/locales/en-US/messenger/messengercompose/messengercompose.ftl

Comment 9

[Thomas D. (:thomas8)]

on l10n-central, DE translations of messengercompose.ftl are complete:
https://hg.mozilla.org/l10n-central/de/file/tip/mail/messenger/messengercompose/messengercompose.ftl

So where do they go from there?

Comment 10

[Thomas D. (:thomas8)]

on l10n-central, textActions.ftl also completely translated
https://hg.mozilla.org/l10n-central/de/file/tip/toolkit/toolkit/global/textActions.ftl

Comment 11

[Thomas D. (:thomas8)]

Attachment: Screenshot 2: German pill context menu with English menus

Comment 12

[Richard Marti (:Paenglab)]

Francesco, could you help to find why probably wrong, or outdated, translations are packaged?

Comment 13

[Francesco Lodolo [:flod]]

Sorry, I don't have cycles to dig into this. A couple of things to check:

• Don't look at the tip of the German repositories, look at the changeset you're using to package the German build (l10n-changesets.json). Are those strings translated in that changeset?
• Is Nightly fully translated?

If Nightly is translated, you likely need to use more recent changesets to build.

Comment 14

[Magnus Melin [:mkmelin]]

I think the revisions just needed to be updated yes. Since half an hour (bug 1657221) we're now using rev a050b0eaec0a for "de" on 78.2 (candidates). https://hg.mozilla.org/l10n-central/de/file/a050b0eaec0a/mail/messenger/messengercompose/messengercompose.ftl

So all good now I think. Thanks for investigating.

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

These strings from textActions.ftl are still in English in the 78.2.0 RC1 build. Do strings belonging to comm and the ones belonging to mozilla-central/beta/release require different signoffs with the latter missing?

Comment 17

[Alex Ihrig [:Thunderbird_Mail_DE]]

In 78.2.0 RC1 build (not the pre-build):

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #16)

These strings from textActions.ftl are still in English in the 78.2.0 RC1 build. Do strings belonging to comm and the ones belonging to mozilla-central/beta/release require different signoffs with the latter missing?

Not only textActions.ftl, but also from messengercompose.ftl (the same as in the screenshots no. 1 and 2).

Comment 18

[Alex Ihrig [:Thunderbird_Mail_DE]]

This revision / changelog is used in 78.2.0 RC-1:
https://hg.mozilla.org/l10n-central/de/rev/bb4315bebcedd81388a91cd78ba6a03969619d66

The chronologically following checkin / revision is ignored:
https://hg.mozilla.org/l10n-central/de/rev/2f346846f995f942b61562fed125b0cc98e82a13

This can be proofed in all relevant dialogs in Account manager, preferences and so on.

Comment 19

[Alex Ihrig [:Thunderbird_Mail_DE]]

Offtopic info to Sebastian as a result of reading the diffs:

A word ("werden") is missing at the end of the firrst sentence in am-smime.dtd:

<!ENTITY e2eIntro.description "Zum Senden von verschlüsselten oder digital unterschriebenen Nachrichten muss eine Verschlüsselungs-Technologie eingerichtet. Dies kann entweder OpenPGP oder S/MIME sein.">

Comment 20

[Magnus Melin [:mkmelin]]

Are you using the latest localized version? NOT a lang-pack? Note that lang packs from earlier versions can be a problem since their compatibility is set for the major version. https://hg.mozilla.org/l10n-central/de/file/bb4315bebcedd81388a91cd78ba6a03969619d66/mail/messenger/messengercompose/messengercompose.ftl looks translated to me, no?

Re sign-offs: I think 78.2 is using the 80 sign-offs.

Comment 21

[Alex Ihrig [:Thunderbird_Mail_DE]]

(In reply to Magnus Melin [:mkmelin] from comment #20)

Are you using the latest localized version? NOT a lang-pack?

Absolutely new, clean test-profile created in 78.2.0 RC1 build

And BTW: There are still no lang-packs for the 78 version series, so it wouldn't be possible to have this as a reason for our issue ;-)

Comment 22

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

(In reply to Alex Ihrig [:Thunderbird_Mail_DE] from comment #19)

Offtopic info to Sebastian as a result of reading the diffs:

A word ("werden") is missing at the end of the firrst sentence in am-smime.dtd:

<!ENTITY e2eIntro.description "Zum Senden von verschlüsselten oder digital unterschriebenen Nachrichten muss eine Verschlüsselungs-Technologie eingerichtet. Dies kann entweder OpenPGP oder S/MIME sein.">

String got removed in comm-esr78.

Comment 23

[Alex Ihrig [:Thunderbird_Mail_DE]]

How is it possible (for me) to see the latest changes checkins for the german l10n on the different branches / repos? At the moment I only know about https://hg.mozilla.org/l10n-central/de/ But there I cant differ which revision is used for which branch / repo.

Comment 24

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

There is https://hg.mozilla.org/releases/comm-esr78/file/tip/mail/locales/l10n-changesets.json - it's unknown to me if https://hg.mozilla.org/releases/mozilla-esr78/file/tip/browser/locales/l10n-changesets.json is also relevant for the non-comm folders.

Comment 25

[Alex Ihrig [:Thunderbird_Mail_DE]]

Hmm, I can grab the revision and do what exactly to see a similar thing like pushlog or the file hierarchy in l10n files related to this revision in mercurials web interface? Is there a simple workflow process to read and follow your l10n checkins (according to specific branch / repo) without cloning the revisions locally?

As you know, I've provided the l10n the first years of Thunderbird including checkins in mercurial, but it seems the process is much more complicated now. To follow the en-US locale changes is no problem because of having en-US in the normal branches / repos.

Comment 26

[Magnus Melin [:mkmelin]]

I can verify those menus show in English with the German 78.2.0 candidates.
But looking in the omni.ja file shipped with that, messengercompose.ftl is correctly localized.

So the problem is that for whatever reason, the right locale is not picked up for use.

messengercompose.ftl is one of the sync loaded Fluent files, maybe that has something to do with it?
https://searchfox.org/comm-central/rev/689a37ca900cfb1f45f6b83f1c8e258103ad026e/mail/components/compose/content/MsgComposeCommands.js#64

Gandalf, any ideas?

Comment 27

[Magnus Melin [:mkmelin]]

^^

Comment 28

[Alex Ihrig [:Thunderbird_Mail_DE]]

Okay, maybe I've recognized it correctly: In mercurial I can display the shortlog, changelog and files with the corresponding revision. For example:

https://hg.mozilla.org/l10n-central/de/log/55da970f485c

or

https://hg.mozilla.org/l10n-central/de/file/55da970f485c

Which should be the correct revision for comm-esr78 at the moment / 78.2.0 RC builds.

And sorry Magnus for writing the offtopic things here, but at the moment I'm interested in being able to follow and understand the process as the former german localizer.

Comment 29

[Francesco Lodolo [:flod]]

I would say you're falling back to English because you are loading a lot of FTL files, and some are completely missing in the locale (bug 1464156).
https://searchfox.org/comm-central/rev/689a37ca900cfb1f45f6b83f1c8e258103ad026e/mail/components/compose/content/messengercompose.xhtml#67
https://hg.mozilla.org/l10n-central/de/file/default/mail/messenger/openpgp/

Comment 30

[Magnus Melin [:mkmelin]]

Thanks, looks like this is indeed bug 1464156. Doesn't look like that has any quick solution.
Is it enough if the actual FTL files are added (but empty) by localizers, to avoid that problem?

Comment 31

[Francesco Lodolo [:flod]]

(In reply to Magnus Melin [:mkmelin] from comment #30)

Thanks, looks like this is indeed bug 1464156. Doesn't look like that has any quick solution.
Is it enough if the actual FTL files are added (but empty) by localizers, to avoid that problem?

Yes. For Firefox I have scripts that I run periodically to work around the issue, especially when new files are added and loaded on startup :-(

Comment 32

[Alex Ihrig [:Thunderbird_Mail_DE]]

So these "scripts" maybe should be run on all locales to add empty placeholder files for all missing FTL files in the l10n repack process, to avoid such problems.

Comment 33

[Alex Ihrig [:Thunderbird_Mail_DE]]

In Bug 1586984 Francesco wrote that the script adds the missing files (only) to locales, which are represented in pontoon. Porting this script could be a solution, but it seems to ignore all locales which are not represented on pontoon. In case of Thunderbird, german l10n is not on pontoon.

Comment 34

[Francesco Lodolo [:flod]]

(In reply to Alex Ihrig [:Thunderbird_Mail_DE] from comment #33)

In Bug 1586984 Francesco wrote that the script adds the missing files (only) to locales, which are represented in pontoon. Porting this script could be a solution, but it seems to ignore all locales which are not represented on pontoon. In case of Thunderbird, german l10n is not on pontoon.

It's not that simple. Writing the script is trivial (I already have a local copy), the problem is running it:

• It requires access to Pontoon's admin interface to temporarily suspend sync for all hg projects, and to increase resources in Heroku
• It requires HG access to l10n repos

I can run such a script if someone wants me to, but it might require a couple of days, since work is not exactly calm these days.

Comment 35

[Magnus Melin [:mkmelin]]

Since it's more a problem on what is actually included in the shipped jar file, maybe such a script could be added to the l10n packaging process? So that it would check all en-US fluent files, and if there's none for the locale, just add a dummy empty file to it.

Comment 36

[Magnus Melin [:mkmelin]]

For the very short term fix, if you have the script maybe you can upload it somewhere so that at least localizers who know about the problem can run it over their repository.

Comment 37

[Francesco Lodolo [:flod]]

(In reply to Magnus Melin [:mkmelin] from comment #35)

Since it's more a problem on what is actually included in the shipped jar file, maybe such a script could be added to the l10n packaging process? So that it would check all en-US fluent files, and if there's none for the locale, just add a dummy empty file to it.

I'm not sure that's a good idea. Falling back makes sense if most of the translations are missing, and the build system wouldn't know about it.

(In reply to Magnus Melin [:mkmelin] from comment #36)

For the very short term fix, if you have the script maybe you can upload it somewhere so that at least localizers who know about the problem can run it over their repository.

We moved localizers away from HG repositories, and most of them don't have access anymore (I'm aware of only 4 locales using it consistently, and maybe as many using it periodically for things like updating dictionaries).

Given these repositories are used for other projects, including Firefox, I'd very much like for things to stay the same.

As I said, I can run the script this week, but you'll still need to delay 78.2 and rebuild RC, if you want to ship these changes.

Comment 38

[Magnus Melin [:mkmelin]]

Thanks, 78.2.0 already shipped, but we expect to do a 78.2.1 in about a week. 78.2.0 is manual download only.

Comment 39

[Magnus Melin [:mkmelin]]

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

I'm not sure that's a good idea. Falling back makes sense if most of the translations are missing, and the build system wouldn't know about it.

Sure, but that is exactly what it isn't doing atm. Missing one file containing maybe only a few strings will make all of the Fluent files for that window fall back to en-US, so e.g. missing one file with 9 strings can make 900 existing translations fall back to en-US.

Comment 40

[Francesco Lodolo [:flod]]

(In reply to Magnus Melin [:mkmelin] from comment #39)

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

I'm not sure that's a good idea. Falling back makes sense if most of the translations are missing, and the build system wouldn't know about it.

Sure, but that is exactly what it isn't doing atm. Missing one file containing maybe only a few strings will make all of the Fluent files for that window fall back to en-US, so e.g. missing one file with 9 strings can make 900 existing translations fall back to en-US.

And that's why there's a bug on file. I don't think it should be fixed at build level, just because it's a lot easier, the right place to fix it is in the l10nregistry.

I'll run the script before EOW, and report back in the bug when I do.

Comment 41

[Francesco Lodolo [:flod]]

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

I'll run the script before EOW, and report back in the bug when I do.

This is done, e.g. for German
https://hg.mozilla.org/l10n-central/de/rev/25b8b51d709737b87c48118294785e64c76b8e11

Comment 42

[Alex Ihrig [:Thunderbird_Mail_DE]]

The issue is still in german 78.2.1 candidate build 1

Comment 43

[Francesco Lodolo [:flod]]

(In reply to Magnus Melin [:mkmelin] from comment #38)

Thanks, 78.2.0 already shipped, but we expect to do a 78.2.1 in about a week. 78.2.0 is manual download only.

(In reply to Alex Ihrig [:Thunderbird_Mail_DE] from comment #42)

The issue is still in german 78.2.1 candidate build 1

While I don't see a tag for it in https://hg.mozilla.org/releases/mozilla-esr78, it looks like 78.2.1 was released, but the l10n bits were not updated
https://hg.mozilla.org/releases/mozilla-esr78/log/default/browser/locales/l10n-changesets.json

Comment 44

[Alex Ihrig [:Thunderbird_Mail_DE]]

Sorry, but the subject annoys me.

As a former translator of the program, I am ashamed that we publish such releases and as a supporter I pull my hair out.

We run after the Firefox release cycle with such crap, even though those releases make absolutely no sense to users. It's frustrating to keep telling people that all of this is necessary because of the common code base with Firefox.

So please, don't enable the automatic updates, until this problem is technically or automatically by build process fixed, to prevent having this problem again and again in future releases because of the migration process to FTL files.

Comment 45

[Alex Ihrig [:Thunderbird_Mail_DE]]

Maybe a note in release notes would be helpfull, to inform users about the know problem and additionally to ask them to not try to install any language pack, to prevent them from suffering other / later problems because of the lang packs.

Comment 46

[Magnus Melin [:mkmelin]]

Sorry bumping the l10n changeset slipped through 78.2.1. Will get it for 78.2.2 though.

Comment 47

[Alex Ihrig [:Thunderbird_Mail_DE]]

It's not against you and the others. It is the dependent situation of Firefox and the unpredictable problems for Thunderbird that is lagging behind with such things and then running into problems.

Comment 48

[Rob Lemley [:rjl]]

The changes are included in 78.2.2. Bug 1657221 comment 9.

Comment 49

[Alex Ihrig [:Thunderbird_Mail_DE]]

Comfirm fixed in 78.2.2 build-1

Comment 51

[Thomas D. (:thomas8)]

This bug about German localization depends on bug 1657221 but is claimed to be fixed by (and be a duplicate of) crash bug 1655627. They don't look related in any way, and I can't find any mention of this bug in the other. Is it not duplicated against the wrong bug number? Otherwise, can someone drop a short explanation here?

Comment 52

[Rob Lemley [:rjl]]

Sorry, looks like a copy paste error.