Alternatives to custom-strings.txt

Discussion of general topics about Mozilla Thunderbird
Post Reply
lab2k1
Posts: 3
Joined: January 18th, 2020, 7:44 pm

Alternatives to custom-strings.txt

Post by lab2k1 »

It looks like TB dropped support for custom-strings.txt some time around v45, as noted here before (http://forums.mozillazine.org/viewtopic ... #p14573033, http://forums.mozillazine.org/viewtopic ... 1&start=15). This appears to trace down to "bug" 1470608 https://bugzilla.mozilla.org/show_bug.cgi?id=1470608. To add to the confusion, mozilla docs still refer to custom-strings.txt, for example https://developer.mozilla.org/en-US/doc ... leOverride, and so do kbs here at mozillaZine such as http://kb.mozillazine.org/IMAP_Trash_folder.

With custom-strings.txt no longer available, what is the recommended way to do simple customizations of localized strings nowadays?
morat
Posts: 6432
Joined: February 3rd, 2009, 6:29 pm

Re: Alternatives to custom-strings.txt

Post by morat »

I tried changing the value of the trash_folder_name pref with a Gmail IMAP account. It doesn't work.

Pref Name: mail.server.server1.trash_folder_name
Old Value: [Gmail]/Trash
New Value: [Gmail]/Rubbish

I tried to override the messenger.properties file using the chrome.manifest file in an extension. It doesn't work.

* chrome.manifest

Code: Select all

+ override chrome://messenger/locale/messenger.properties chrome://tweaks/locale/messenger.properties
* chrome\locale\en-US\messenger.properties

Code: Select all

- trashFolderName=Trash
+ trashFolderName=Rubbish
However, the messenger.properties file is edited when I view the source using the error console.

Code: Select all

(function () {
  var url = "chrome://messenger/locale/messenger.properties";
  document.getElementById("tabmail").openTab("contentTab", {
    contentPage: "view-source:" + url,
  });
})();
Chrome Registration - override
http://developer.mozilla.org/docs/Mozil ... n#override

Reference
http://searchfox.org/comm-central/searc ... older_name
http://searchfox.org/comm-central/searc ... FolderName
http://searchfox.org/comm-central/searc ... properties
User avatar
tanstaafl
Moderator
Posts: 49647
Joined: July 30th, 2003, 5:06 pm

Re: Alternatives to custom-strings.txt

Post by tanstaafl »

lab2k1 wrote:To add to the confusion, mozilla docs still refer to custom-strings.txt, for example https://developer.mozilla.org/en-US/doc ... leOverride, and so do kbs here at mozillaZine such as http://kb.mozillazine.org/IMAP_Trash_folder.
The MozillaZine wiki is currently in read-only mode while waiting for our admin to pay attention to us again. The problem with MDN is that since several technologies are getting deprecated sizable portions are no longer relevant. https://github.com/thundernest and https://developer.thunderbird.net/add-ons/about-add-ons usually have the most up-to-date information.
lab2k1
Posts: 3
Joined: January 18th, 2020, 7:44 pm

Re: Alternatives to custom-strings.txt

Post by lab2k1 »

Thank you both for the followups. Looks like what I thought would be a painless quick hack turned out to open a can of worms, instead ;-)

@tanstaafl The curious thing about custom-strings.txt, however, is that it doesn't appear to have been dropped because of API migration reasons, but rather just because "the code adds a lot of complexity to the string bundle service, and doesn't appear to offer a lot of gain" in someone's judgment (quoted from bug 1470608).

@morat I am parsing that to mean that neither worked in the end, please correct me if I got that wrong. In fact, renaming the Trash folder was what I was toying with as well, though in my case it was for Local Folders not an IMAP account. I cross-posted that more narrow question at https://support.mozilla.org/en-US/questions/1277679.

While snooping around, I realized that overriding localized strings is precisely what language packs do (https://addons.thunderbird.net/en-US/th ... age-tools/). I wonder if an extension could maybe use the same technique to override just a few strings here and there, rather than having to provide a complete translation. Granted, that feels like killing a fly with a sledgehammer, but would still be better than hacking the hardcoded strings inside omni.ja directly.
morat
Posts: 6432
Joined: February 3rd, 2009, 6:29 pm

Re: Alternatives to custom-strings.txt

Post by morat »

I tried to override the composeMsgs.properties file. It works fine.

* chrome.manifest

Code: Select all

+ override chrome://messenger/locale/messengercompose/composeMsgs.properties chrome://tweaks/locale/composeMsgs.properties
* chrome\locale\en-US\composeMsgs.properties

Code: Select all

- chooseFileToAttach=Attach File(s)
+ chooseFileToAttach=Cowabunga
I guess the chrome registration override trick doesn't work with cpp files.

Reference
http://searchfox.org/comm-central/searc ... rect=false
http://searchfox.org/comm-central/searc ... rect=false
lab2k1 wrote:use the same technique to override
A dictionary extension for TB 68 doesn't use the chrome.manifest file.

I doubt you can override stuff in TB 68 using the manifest.json file.

manifest.json
http://developer.mozilla.org/docs/Mozil ... ifest.json
http://developer.mozilla.org/docs/Mozil ... ctionaries
lab2k1
Posts: 3
Joined: January 18th, 2020, 7:44 pm

Re: Alternatives to custom-strings.txt

Post by lab2k1 »

Interesting, thanks. I guess the issue with the latter could be timing. The default language must be loaded pretty early during startup, since most extensions would expect it to be available when *they* load. However, this also means it's too late for an extension to override language defaults by the time it gets loaded. Except, of course, for language packs which do precisely that.

For a quick test, I downloaded the en-US language pack (not dictionary) from https://addons.thunderbird.net/en-US/th ... ack-thund/ and edited chrome\en-US\locale\en-US\messenger\messenger.properties.

Code: Select all

- trashFolderName=Trash
+ trashFolderName=Rubbish
I also replaced the root manifest.json with the following.

Code: Select all

{
  "languages": {
    "en-US": {
      "chrome_resources": {
        "messenger": "chrome/en-US/locale/en-US/messenger/" 
      }, 
      "version": "200120"
    }
  }, 
  "applications": {
    "gecko": {
      "id": "altTrash@example.org", 
      "strict_min_version": "68.0", 
      "strict_max_version": "68.*"
    }
  }, 
  "langpack_id": "en-US-x-alt-trash", 
  "version": "68.0.200120", 
  "name": "Alt Trash", 
  "manifest_version": 2, 
  "author": "example.org", 
  "description": "Alt Trash (en-US)"
}
I then zipped up manifest.json and the entire directory chrome\en-US\locale\en-US\messenger (without subdirectories) into altTrash.zip. My TB v68.4.1 installed it fine as an extension (listed, however, under Languages on the Addons page, not under Extensions), and after restarting 'Trash' was duly displayed as 'Rubbish'.

Key here looks to be the "langpack_id" entry in the manifest file. Without it, the extension still installed fine but then got listed on the regular Extensions page (not under Languages), and 'Trash' remained displayed as 'Trash'. What (else) "langpack_id" is doing I can't tell, since I don't see it listed in the official docs at https://developer.mozilla.org/en-US/doc ... ifest.json.

I don't know that it's possible to cut the payload from the entire directory down to one single .properties file. The page at https://firefox-source-docs.mozilla.org ... l10n-merge appears to hint the answer is negative.
The chrome registry in Gecko doesn’t support fallback from a localization to en-US at runtime. Thus, the build needs to ensure that the localization as it’s built into the package has all required strings, and that the strings don’t contain errors. To ensure that, we’re merging the localization and en-US at build time, nick-named l10n-merge.
Assuming the above works without ill side effects, it would be cheaper than hacking the global omni.ja since it is far lighter, and is a per-profile easily reversible change. Yet, it would still be subject to continual maintenance and updating whenever new TB releases change any of the messenger\* files. That's a lot of work for overriding one line in one .properties file, which used to be a lot easier with the now retired custom-strings.txt file.
morat
Posts: 6432
Joined: February 3rd, 2009, 6:29 pm

Re: Alternatives to custom-strings.txt

Post by morat »

That's too much trouble I think...

P.S.

You could hackishly change the folder name with the userChrome.css file.

Code: Select all

/* Thunderbird userChrome.css */

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

#folderTree > treechildren::-moz-tree-image(folderNameCol, isServer-true, serverType-none) {
  list-style-image: url("example.svg") !important;
  -moz-image-region: auto !important;
  height: 16px !important;
  width: 96px !important;
}
#folderTree > treechildren::-moz-tree-cell-text(folderNameCol, isServer-true, serverType-none) {
  color: transparent !important;
}
Reference
http://searchfox.org/comm-central/sourc ... erPane.css

* example.svg (create file in chrome folder)

Code: Select all

<svg height="16" width="96" xmlns="http://www.w3.org/2000/svg">
  <text x="0" y="16" fill="red">Example</text>
</svg>
or

Code: Select all

<svg height="16" width="96" xmlns="http://www.w3.org/2000/svg">
  <image height="16" width="16" href="data:image/png;base64,..."/>
  <text x="24" y="16" fill="red">Example</text>
</svg>
:mrgreen:
Post Reply