elexis-eu
Spell check
It would be nice to have spell check functionality that knows what language each field is supposed to be. Browsers don't support this natively, so this would have to be done from Javascript.
some contenders (pls. add if you find any):
- https://www.javascriptspellcheck.com/JavaScript_Spell_Check_Features
I've been googling :)
First of, the problem with above mentioned spell checker (javascript spellcheck) is that it is not self hosted, but rather it pings an API to check the spelling. Second of all, it is not really Free to use.
What I would recommend, is to use a very simple WYSIWYG javascript text editor library and pair it up with a local spellchecker. This means, that we have to do some coding to pair the two, but that should not be too hard.
So, there is this library text editor (5kb): https://github.com/fvilers/tiny-editor There are others, but this one I find nice and small.
For the spell checking, we have two options: server side or client side.
If we do it server side then the webpage is leaner, but probably a bit slower for text editing since there will be quite a few API calls to check the spelling. Example python library we could use: https://pypi.org/project/hunspell .
If we do it client side, than the user needs to obtain the dictionary, after that the spellchecking is done very quickly via javascript. Example library: https://github.com/cfinke/Typo.js . The dictionary size for en_US is 240kb (gziped). For comparison: opening a lexonomy page for an empty dictionary already loads 540kb of stuff.
And next question is, are you @michmech ok with adding dependencies such as these into xonomy?
ok, i didn't check in detail :\ but i'll take a step back: operating systems (at least OS X has been for some time) integrate spell checking for applications, and the browsers re-do this - at times separately again... in either case, this comes with some perks: mostly, a personal dictionary. i'm really not convinced to re-implement this once again... (in particular because it does blow up quickly: download multiple dicts, activate, deactivate dicts and the whole feature; personal dictionary / shared dictionary... either way, edit personal dictionary, in particular, delete entries...). long story short: OS X + Safari has multi-ling support, Chrome as well, Firefox uses hunspell internally and can be tweaked to support multiling... do we really need this?
The question is what do we want? I am always looking at how firefox does it and there are these instructions. Which means that if you are regularly working with two different dictionaries in two different languages, than you must change the language all the time. Or even if you do some other job in the same browser that needs a different language spellcheck, you have similar problems.
in particular because it does blow up quickly: download multiple dicts, activate, deactivate dicts and the whole feature; personal dictionary / shared dictionary... either way, edit personal dictionary, in particular, delete entries...
I again have a problem of not having any kind of experience in this area. The only thing I see is that you choose a dictionary (hunspell) for a dictionary (lexonomy) and it is the same for all editors for that lexonomy dictionary, no personal dictionaries and such.
Also in my world, the chosen dictionary is downloaded (and cached) in the background and activated just for that textarea - no deactivations needed.
i found How do I make Firefox spellcheck in multiple languages simultaneously? ... An idea from the very top of my head (if - indeed - firefox uses some hunspell-like-compatible-thing behind the scenes, it might even be easier to build an AddOn for firefox...)
You can merge a few hunspell dictionaries, but is that fine? I mean, then many English typos get through, because they are a valid french word.
My solution would be appropriate in a world, where it would be nice to have a specific language for specific dictionary and have it nicely transparent for end users.
On the topic of the amount of work: I don't think it is that much and if anyone wants an MVP, I could probably do it, but since there are other more pressing issues, I should probably go work on those