Describe the bug
When I misspell words in a text window, they are not red underlined, and right clicking them does not bring up any corrections.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The word should be underlined red, and right clicking the word should show spelling corrections.
Screenshots

Desktop (please complete the following information):
Additional context
My system language is en_US.UTF-8 (from /etc/locale.conf and $LANG). I have hunspell-en-US installed. /usr/share/myspell/en_US.aff and .dic exist. I've confirmed that this bug exists for me in both the Snap and the RPM packages. I've tried clearing both ~/snap/teams-for-linux/current/.config/teams-for-linux and ~/.config/teams-for-linux .
I've looked at known issues and past bugs for this project, and they seem to apply to other languages and previous versions of teams-for-linux which used different spell check methods.
I've tried running teams-for-linux from command line and didn't see any relevant errors. I'm not specifying the "--rightClickWithSpellcheck" option. I haven't figured what what "yarn start" means, yet.
Have a look at the code in here:
https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/app/browser/rightClickMenuWithSpellcheck.js
I suspect is not picking up the hunspell location
Try settion the env HUNSPELL_DICTIONARIES to the /use/share/myspell and see if it does the job.
Is either that or the getLocale from node is picking up something funny. Sorry but Tuesday's are a busy day for me.
Oh, no worries, I definitely understand being busy. I'm actually quite impressed with your dedication and responsiveness in this project.
I've got version 0.6.7 via Snap now, and still have the issue when running regularly. The HUNSPELL_DICTIONARIES variable is indeed not set.
I tried running with your suggestion two ways:
HUNSPELL_DICTIONARIES=/usr/share/myspell /var/lib/snapd/snap/bin/teams-for-linux
and
export HUNSPELL_DICTIONARIES=/usr/share/myspell
echo $HUNSPELL_DICTIONARIES
/var/lib/snapd/snap/bin/teams-for-linux
But I still did not have any spell check happening.
I'm not sure how to test getLocale.
Not sure if this will be because you are using myspell instead of hunspell.
quick google for hunspell vs myspell says:
Hunspell is based on MySpell and is backward-compatible with MySpell dictionaries. While MySpell uses a **single-byte character encoding**, Hunspell can use Unicode UTF-8-encoded dictionaries.
So I assume they might work but we have only implemented this to work with hunspell.
Not the neatest of solutions but you could try installing hunspell and see if that fixes your issue.
Hmm, I do have hunspell installed, and not myspell. It looks like the Fedora package places the hunspell dictionaries in the myspell directory.
$ sudo dnf repoquery --installed --list hunspell-en-US-0.20140811.1-14.fc30.noarch
/usr/share/doc/hunspell-en-US
/usr/share/doc/hunspell-en-US/README_en_US.txt
/usr/share/myspell/en_US.aff
/usr/share/myspell/en_US.dic
I found the instructions for running from source in CONTRIBUTING.md. I'm going to try that later on today when I get a chance. That'll let me try adding some logging statements in rightClickMenuWithSpellcheck.js to see what getLocale is getting.
great! those console.log statements will appear in the chrome console. So run with yarn start --webDebug
Ok, looks like the problem is that my locale is somehow getting returned as en-US instead of en_US. Here's some things I logged (after I set the HUNSPELL_DICTIONARIES environment variable again):
appLocale = en-US
process.env.HUNSPELL_DICTIONARIES = /usr/share/myspell
Running spellchecker.setDictionary with locale = en-US
And location = /usr/share/myspell
So, even if setDictionary gets called, I guess it doesn't like those options.
I don't know where remote.app.getLocale is getting en-US from. I think I've got my locale set correctly on my system:
$ echo $LANG
en_US.UTF-8
$ cat /etc/locale.conf
LANG="en_US.UTF-8"
It looks like Electron's getLocale uses Chromium's l10n_util, so I might try looking at how that works.
en-US is the IETF standard and en_US.UTF-8 is the ISO 15897 standard.
maybe do like #154 and create a symbolic link. I think is the same issue.
A code change can be done to "force" a locale, that should not be difficult as we can provide that information as a config option. Let me know if you can bypass it with the symbolic link https://github.com/IsmaelMartinez/teams-for-linux/issues/154#issuecomment-510930924
I am surprise as en_US is packaged in the spellchecker package, so it should in theory just work :/
Ok, a symbolic link worked:
ln --symbolic en_US.aff en-US.aff
ln --symbolic en_US.dic en-US.dic
lrwxrwxrwx. 1 root root 9 Aug 17 12:52 en-US.aff -> en_US.aff
-rw-r--r--. 1 root root 3115 Feb 1 2019 en_US.aff
lrwxrwxrwx. 1 root root 9 Aug 17 12:52 en-US.dic -> en_US.dic
-rw-r--r--. 1 root root 539608 Feb 1 2019 en_US.dic
md5-6576c050c31b12b16773241b6d286b1c
HUNSPELL_DICTIONARIES=/usr/share/myspell yarn start --webDebug
md5-9c5c1d0ca93583eee105c9d7da20dfa6
export HUNSPELL_DICTIONARIES=/usr/share/myspell
HUNSPELL_DICTIONARIES=/usr/share/myspell /var/lib/snapd/snap/bin/teams-for-linux
Maybe snaps don't pass variables to children processes or something?
I've got an idea for making the code more robust for my particular situation, without affecting any other situation. I'm going to try a pull request, though I'm not very familiar with how to do that, so forgive me if the process is a little off.
Ok, I've got a pull request here: https://github.com/IsmaelMartinez/teams-for-linux/pull/234
I have put a wee change request in the PR. Thanks for contributing!