Add British, Canadian, and Australian English

[krassowski]

Closes #17. Notes:

• the dictionaries are now in the repository and no longer downloaded each time from the Internet. This should save some bandwidth and allow to use the spellchecker when working offline.
• you can change the language from the statusbar; I imagine that having a command in the palette would be a nice addition in the future.
• It is easy to add more languages! I went with the most obvious variations of English from Hunspell/SCOWL as those are well established and have straightforward licences (BSD, so same as the extension itself); other licences ((L)GPL*) would be probably ok, but if anyone needs another language they should be easily able to do so building upon this work :)

[krassowski]

I think that we could use tokens so that each language is an "extension" of its own. This would allow to easily install extra dictionaries from the extension manager. For example, to install Spanish language, one would do jupyter labextension install jupyterlab-dictionary-spanish or install it from the GUI.

[jangenoe]

I like the approach that dictionaries are only downloaded once (to enable working offline), preferably with an update on request. I would however not make a different extension for every language, as you seem to suggest. I would implement in a settings file

• a repository where to download languages

• a selection which languages to be downloaded.

The settlings file would comprise predefined "https://www.jsdelivr.com/" and "en_US" but any user would be able to add the languages as he prefers, when available in a repository.

[krassowski]

This is important feedback! Are you aware of such a repository?

I see that what you suggest may seem more natural (this was my initial idea), but:

• this would not be straightforward as the extensions do not have direct access to the file system (the files are loaded by webpack; saving notebooks is implemented by a websocket communication to a python server and you would not want to have to install a server extension just to handle downloading the dictionaries; you would also need to restart webpack to serve the newly downloaded dictionaries)
• one would need to implement updates functions
• one would need to make sure the URLs ("database") remains accessible
• such database needs to exist and pointing an extension to it should not violate its terms of service

Thus I believe that utilising the existing mechanism of extensions is the way forward as:

• extension manager handles updates
• once it's published, it will not disappear
• you can fulfill dictionary license requirements by having the appropriate legal texts in each of the extensions rather than complicated licenses set (or maybe even interactions) in a single repository
• it is straightforward to deliver the files to the browser using existing webpack mechanisms

[krassowski]

Also, language pack as a package/extension seems a common and established practice, e.g. in Firefox, Debian/Ubuntu and many others. Granted sometimes it comes with a user interface concealing this implementation detail - and this is something that I would say may be worth considering - it should be easy to instruct the extension manager to install new dictionary extension.

[jangenoe]

I was more considering the approach as described here for the notebooks.

But I agree that one extension for every language would be more straightforward for the users and could enable more dedicated maintenance for each individual language.