Closed Bug 1579747 Opened 5 years ago Closed 5 years ago

incomplete translation in French "i18n-fr" file

Categories

(Thunderbird :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: arnaud.his, Unassigned)

References

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Steps to reproduce:

Since the last update, (ver 68.0) of August 27, Thunderbird messaging is poorly translated, it is mixed between English and French. see the screenshots.

Actual results:

incomplete translation

Expected results:

a complete translation

That's unfortunate, but the bug goes to the French team. The start page may be a different issue. Andrei, please look into the screenshots.

How did you install Calendar/Lightning? Are you sure that's a French version? Have you tried the one from addons.thunderbird.net?

You have four screenshots:

  • Start page
  • Calendar
  • Options which are fully translated
  • Folders.

Folders may be a victim of bug 1575512.

Assignee: nobody → bugzilla.fr
Component: Theme → fr / French
Product: Thunderbird → Mozilla Localizations
QA Contact: benoit.leseul
Version: 68 → unspecified
Attached image Lightning

The calendar is an official extension published by Mozilla.

@Jorg
Given that French is fully localized, I seriously doubt that's their issue. Has anyone checked another language?
https://l10n.mozilla.org/teams/fr

Hi Francesco, thanks for checking. Please refer to my comment #1. Here are the items again:

  • Start page: non-localised page loaded, NI :sancus (which I forgot)
  • Calendar: non-localised add-on used
  • Options which are fully translated: no issue
  • Folders: Bug 1575512.

Eckard, how does the French version look for you?

Assignee: bugzilla.fr → nobody
Component: fr / French → General
Flags: needinfo?(sancus)
Flags: needinfo?(de.berberich)
Product: Mozilla Localizations → Thunderbird
QA Contact: benoit.leseul
Version: unspecified → 68

Untranslated start page is not reproducible for me. Most likely the start page URL has been modified from the default somehow.

A default profile has "https://live.thunderbird.net/thunderbird/start?locale=fr&version=68.0&channel=release&os=WINNT&buildid=20190826194726" for the start page URL in Options->General for the French version, which is correct, and redirects to the french release page.

Flags: needinfo?(sancus)

(In reply to Jorg K (GMT+2) from comment #5)

Hi Francesco, thanks for checking. Please refer to my comment #1. Here are the items again:

  • Start page: non-localised page loaded, NI :sancus (which I forgot)
  • Calendar: non-localised add-on used
  • Options which are fully translated: no issue
  • Folders: Bug 1575512.

Eckard, how does the French version look for you?

In my French macOS version of Thunderbird 68.0 (without installing any additional language packs) everything is localized correctly:
options (preferences), menus, folders, Lightning calendar, account manager, address book, ...etc.
Could this be a Linux problem?
I doubt that this bug is related with bug 1575512 which I opened recently. BTW I'm going to write an update to bug 1575512 since I've found a possible suspect.

Flags: needinfo?(de.berberich)

You're using a fully-packaged build, I would expect Linux to use en-US + language pack. So… bug 1469678?

It is installed on Archlinux if it could help.

(In reply to arnaud from comment #9)

It is installed on Archlinux if it could help.

The Start page has a Archlinux issue, it's not a translation issue as you can see here :
https://bugs.archlinux.org/task/63658

In Preferences, the welcome page is set to :
https://live.thunderbird.net/thunderbird/start?locale=fr&version=68.0&channel=release-cck-archlinux&os=Linux&buildid=20190904015918

channel=release-cck-archlinux
and not what it should be to display the right page in french : channel=release

"-archlinux" is added by packaging, but I don't know if "-cck" Thunderbird related or Archlinux related.

See Also: → 1575512

Solved : It's a permissions issue. Delete/rename ~/.thunderbird/xxxxxxxx.default-release/permissions.sqlite and reload TB.

Solved: by deleting the file, I found a complete translation.

Is deleting the permissions.sqlite file a lasting solution for those of you who have tested it ? Even after successively adding several remote content exceptions via the "Preferences" drop-down menu in the message header, thus modifying the newly created permissions.sqlite file ?

Since I found this workaround of deleting (or replacing) this file six days ago, I already have "consumed" a dozen permissions.sqlite files. My latest file has been "working" for three days and just got corrupted a few minutes ago ....
After replacing it with the back-upped file from yesterday the folder names are again localized correctly!

Unfortunaly, I confirm that it's not a durable workaround. Sometime the bug comes again and I don't know why. I did try too chmod 640 permissions.sqlite but no stable effect.

Why would localisation have anything to do with permissions.sqlite? Does this only happen for French? I haven't see any reports for other languages.

Flags: needinfo?(francesco.lodolo)

It' seems that German users have the same issue .
https://forum.manjaro.org/t/thunderbird-68-in-frenglish/102907/9?u=lemust83.

(In reply to Jorg K (GMT+2) (reduced availability 14-19 of Sept.) from comment #18)

Why would localisation have anything to do with permissions.sqlite? Does this only happen for French? I haven't see any reports for other languages.

In the similar bug 1575512 I have shown the same issue in the en-US version of TB 68 with German de.xpi language pack installed
https://bugzilla.mozilla.org/show_bug.cgi?id=1575512#c6

(In reply to Jorg K (GMT+2) (reduced availability 14-19 of Sept.) from comment #18)

Why would localisation have anything to do with permissions.sqlite? Does this only happen for French? I haven't see any reports for other languages.

Sorry, that requires a knowledge and understanding of our infrastructure beyond mine. The only thing I can think of is that deleting that file forces a cache rebuild, if that's the case starting with -purgecaches should have the same effect (see bug 1564998 for Firefox).

Flags: needinfo?(francesco.lodolo)

When the computer restarts the problem comes back

Hmm, reading through bug 1564998, and as indicated in comment #21, affected users should try the -purgecaches command line option.

I'm eager to try but which is the equivalent -purgecaches command line option for macOS ?
And why would deleting of the file permissions. sqlite induce a cache rebuild ?

(In reply to Eckard Berberich from comment #24)

I'm eager to try but which is the equivalent -purgecaches command line option for macOS ?

Replace Firefox with Thunderbird in path and command
https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

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

(In reply to Eckard Berberich from comment #24)

I'm eager to try but which is the equivalent -purgecaches command line option for macOS ?

Replace Firefox with Thunderbird in path and command
https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Thank you! I know how to open the profile manager via the Terminal. I'm using four different TB versions with separate profiles and every version launches the profile manager on startup.
Unfortunately the command line /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin -purgecaches doesn't work for me (doesn't correct the non-localization of my folders).
=>> See screen shot

Hmm. I installed a Spanish version and ran it on I profile that had just been run with an English version.

Looking at the folders, I see: Bandeja de entrada, Borradores, Plantillas, Enviados, Papelara. Back to the English version, all back to English. Back t the Spanish version, all back to Spanish.

I just want to see how bad the problem really is. Looks like an average user won't be hit by it. Anyway, I'll try French next.

I installed a French version, all standard folder names are in French now. That's all tried with an x64 version on Windows 10 x64.

Should I try a language pack next?

I really don't know what to do with this bug, but if all localised versions were broken, we'd have a lot more complaints by now.

(In reply to Jorg K (GMT+2) (reduced availability 14-19 of Sept.) from comment #29)

I installed a French version, all standard folder names are in French now. That's all tried with an x64 version on Windows 10 x64.

Should I try a language pack next?

Yes, without installing one or more language packs you can't reproduce the issue I describe in bug 1575512 (sorry to discuss it here, I would have preferred to answer in the bug report I filed almost a month ago).
• It would be better to create a new profile
• Install the English en-us.xpi and/or German de.xpi (or any other) language packs
• toggle the values of the preferences intl.multilingual.downloadEnabled and intl.multilingual.enabled from false to true
• go to Options (Preferences) > Advanced > General > Language, choose English (United States) or German as the GUI language and restart TB
• set several "allow remote content from ...." preferences in message header
• change language and restart TB as often as possible and verify localization of the folder names ..... until they stay in French although you chose English or German.

(In reply to Jorg K (GMT+2) (reduced availability 14-19 of Sept.) from comment #18)

Why would localisation have anything to do with permissions.sqlite? Does this only happen for French? I haven't see any reports for other languages.

It also happens for German.

It seems that giving read-only permissions to permissions.sqlite is a temporary workaround solution:
chmod -w permissions.sqlite

Can someone find the regression range?

I'll try to write up some STR for Alice.

Before I do that: Has anyone see the issue on Windows? Surely chmod -w permissions.sqlite is not for Windows. I also don't understand who changing the permissions on a SQLite database (which will most likely destroy other functionality) would be related to localisation.

I moved all the duplicates that clearly refer to non-localised folders to bug 1575512. That bug is showing some action now.

I'm closing this here since the four items listed in comment #1 work apart from the folders.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: