[SOLVED] Non working email dictionary - SM 2.53.9 (FreeBSD)

[trevoz]

This was an upgrade from 2.49.5 to 2.53.9 by building from source on FreeBSD.

I appeared to have no English dictionary and every more than one letter word has a red squigly line under it. Argh!

So, I installed a legacy .xpi file for "British English Dictionary (Marco Pinto) 3.0" which shows up in Add-ons Manager > Dictionaries.

About:config shows "spellchecker.dictionary en-GB"

The Spell button in Email is now activated and gives me a choice of English (GB) or English (US). Whichever one I choose, I still end up with the red squiggly lines under every more than one letter word. Spell offers no suggestions for the supposedly mispelled words.

Code: Select all

/home/trev/.mozilla/seamonkey/emxxhXXX.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries contains:

-rw-r--r--  1 trev  wheel   7.9K  1 Sep 15:05 README_en_GB.txt
-rw-r--r--  1 trev  wheel    32K  1 Sep 15:05 en-GB.aff
-rw-r--r--  1 trev  wheel   1.1M  1 Sep 15:05 en-GB.dic

Edited to add: I also have in /usr/local/lib/seamonkey/dictionaries:

Code: Select all

-rw-r--r--  1 root  wheel   3.0K 18 Feb  2020 en-US.aff
-rw-r--r--  1 root  wheel   563K  8 Aug 23:01 en-US.dic

Help

[Edited subject line to make clear this is NOT Linux or a Linux distribution, but the FreeBSD operating system hailing from Berkeley long before Linux was invented ]

[trevoz]

Rather than starting from my twm menu in X Window I started SeaMonkey from an xterm and when, eg starting a new forum post, these errors are received:

Code: Select all

Document http://forums.mozillazine.org/posting.php?mode=post&f=40&sid=9fb565534e5112effb841492eb4e46f3 loaded successfully
error: /home/trev/.mozilla/seamonkey/emxxhXXX.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries/en-GB.aff: cannot open
error: /home/trev/.mozilla/seamonkey/emxxhXXX.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries/en-GB.dic: cannot open
error: /home/trev/.mozilla/seamonkey/emxxhXXX.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries/en-GB.aff: cannot open

which makes little sense to me because I can open those files without trouble with vi or more. Their permissions are fine as are those of every directory in the path.

Changing to the (builtin global) US dictionary also yields:

Code: Select all

error: /usr/local/lib/seamonkey/dictionaries/en-US.aff: cannot open
error: /usr/local/lib/seamonkey/dictionaries/en-US.dic: cannot open
error: /usr/local/lib/seamonkey/dictionaries/en-US.aff: cannot open

[trevoz]

Trussing the SeaMonkey process:

Code: Select all

access("/home/trev/.mozilla/seamonkey/emxxh52l.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries",F_OK) = 0 (0x0)
fstatat(AT_FDCWD,"/home/trev/.mozilla/seamonkey/emxxh52l.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries",{ mode=drwxr-xr-x ,inode=236211,size=5,blksize=131072 },0x0) = 0 (0x0)

The directory is accessible (ie permissions ok)

Code: Select all

open("/home/trev/.mozilla/seamonkey/emxxh52l.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,012706050) = 21 (0x15)

The directrory can be opened.

Code: Select all

access("/home/trev/.mozilla/seamonkey/emxxh52l.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries/en-GB.aff",F_OK) = 0 (0x0)

The en-GB.aff file is accessible.

Code: Select all

close(21)                                        = 0 (0x0)

File descriptor 21 (the directory that was opened) closed.

But later:

Code: Select all

error: /home/trev/.mozilla/seamonkey/emxxh52l.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries/en-GB.aff: cannot open
write(2,"error: /home/trev/.mozilla/seamo"...,130) = 130 (0x82)
error: /home/trev/.mozilla/seamonkey/emxxh52l.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries/en-GB.dic: cannot open
write(2,"error: /home/trev/.mozilla/seamo"...,130) = 130 (0x82)
error: /home/trev/.mozilla/seamonkey/emxxh52l.default/extensions/marcoagpinto@mail.telepac.pt/dictionaries/en-GB.aff: cannot open
write(2,"error: /home/trev/.mozilla/seamo"...,130) = 130 (0x82)

[trevoz]

Here's the code from filemgr.cxx where, as far as I can tell, the failure occurs:

Code: Select all

FileMgr::FileMgr(const char* file, const char* key) : hin(NULL), linenum(0) {
  in[0] = '\0';

  myopen(fin, file, std::ios_base::in);
  if (!fin.is_open()) {
    // check hzipped file
    std::string st(file);
    st.append(HZIP_EXTENSION);
    hin = new Hunzip(st.c_str(), key);
  }
  if (!fin.is_open() && !hin->is_open())
    fail(MSG_OPEN, file);
}

and from hunzip.hxx:

Code: Select all

#define MSG_OPEN "error: %s: cannot open\n"

But wny?

[Frank Lion]

So, I installed a legacy .xpi file for "British English Dictionary (Marco Pinto) 3.0" which shows up in Add-ons Manager > Dictionaries.

That version will not work as it is a WebExtension type extension, that will install but will not work in SeaMonkey.

You need the 2.68 version of British English Dictionary (Marco Pinto)

This is not your fault, as the listing https://addons.thunderbird.net/en-GB/se ... src=search clearly states that it will work with SeaMonkey, but that listing is wrong.

You can always check extensions with WinRar, etc and if there is no install.rdf in there, then it will not work with SeaMonkey.

I also suggest you get the Test addons.thunderbird.net extension, version 1.0 that makes it really easy to see which old versions are actually WebExtensions in the Version History of an extension.

[frg]

You can also unpack the dictionary *.dic and the *.aff rules and put it into the SeaMonkey\dictionaries directory. Will be picked up then. Mozilla took away this option with a later release but we still keep it. Aor just add the install.rdf from the older version to the new xpi.

[trevoz]

Thanks for your response.

I did install the earlier version but it updated to the later version. It still appears under "Dictionaries" and not "extensions" which is where web extension version show up even though not operable.

I also have an Australian dictionary installed from a 2014 xpi which shows up under Dictionaries too. It also does not work when set to be the dictionary used. As a result, I do not believe it is a failure to install a legacy rather than web extension dictionary version.

In any event, the "built-in" US dictionary also fails as outlined above in the same manner.

[trevoz]

The solution to get spell checking working was to add:

ac_add_options --enable-system-hunspell

to the configuration, something that wasn't necessary for 2.53.8.1.