joplin
joplin copied to clipboard
laurent22
Desktop: Add support for multi-language spell check
Forum threads about this:
- Multi-language spell checker?
- Per-note language tag for spell checking
- Per-note spell checker setting
Electron nativity support multiple languages for spell check, it takes array of language names.
Modified spellChecker.language setting to be an array instead of
string, so it can store multiple languages.
Changed radio buttons to be checkboxes in spell checker menu to chose multiple languages.
Changed function to displaying name of the language in the UI, so it can show multiple language codes.
Changed function that stores last selected languages, not it will always store enabled languages, even if overall language count is more than 5.
Made passing language name optional to the function that adds word to the dictionary, since Electron don't need it.
The change that I don't feel great about is this hack to the setting parser, so it can change currently stored string to the array.
// Hack to transform existing string values of spellChecker.language to array.
if (key === 'spellChecker.language' && typeof value === 'string') return [value];
But I didn't find better way to change it. If the maintainers don't like this kind of hack, please advice how to better resolve it.
Is that a common thing to support multiple languages? Do you have any example of app that supports this?
Is that a common thing to support multiple languages? Do you have any example of app that supports this?
Firefox:
It looks like LibreOffice supports per-paragraph spellcheck (but I only have one language installed for it):
Google Chromium also supports multiple languages:
Brilliant, thanks for checking @personalizedrefrigerator. I was wondering if there was a better way to support multiple languages, such as per-note language, but if it's common to have this it makes sense for us to support it too.
Is that a common thing to support multiple languages? Do you have any example of app that supports this?
All browsers that based on Chromium support it. Also many apps that based on Electron, if we take only note taking apps, Obsidian and Simple Notes support it.
The change that I don't feel great about is this hack to the setting parser, so it can change currently stored string to the array.
We have an object called defaultMigrations in Setting.ts - can it be used in this particular case? Or can defaultMigrations be upgraded so that it supports this case?
If not, or if it's too complicated, don't worry for now. Maybe if we have more such cases, we'll implement a proper migration path.
The change that I don't feel great about is this hack to the setting parser, so it can change currently stored string to the array.
We have an object called
defaultMigrationsin Setting.ts - can it be used in this particular case? Or candefaultMigrationsbe upgraded so that it supports this case?If not, or if it's too complicated, don't worry for now. Maybe if we have more such cases, we'll implement a proper migration path.
Can't really use defaultMigrations, since it's desined to change user setting, only if the user never touched the setting before. Here we want to take the value that user set, and migrate it to the new type.
If you want, I can create a method that will migrate user setting to the new setting. For example, now we have spellChecker.language and we want to depreciate it in favor of new setting spellChecker.languages. The method could check if the new setting exist, and if not take user value from the old setting, and apply it to the new, transforming it to the new type.
If you want, I can create a method that will migrate user setting to the new setting. For example, now we have spellChecker.language and we want to depreciate it in favor of new setting spellChecker.languages. The method could check if the new setting exist, and if not take user value from the old setting, and apply it to the new, transforming it to the new type.
Yes let's do that. It seems cleaner to leave the old setting as it is and create a new one. It means we also keep the db backward compatible. So yes if you could do what you described that would be great.
If you want, I can create a method that will migrate user setting to the new setting. For example, now we have spellChecker.language and we want to depreciate it in favor of new setting spellChecker.languages. The method could check if the new setting exist, and if not take user value from the old setting, and apply it to the new, transforming it to the new type.
Yes let's do that. It seems cleaner to leave the old setting as it is and create a new one. It means we also keep the db backward compatible. So yes if you could do what you described that would be great.
Created a new method for that.
All good now. Thanks a lot @antontkv for adding this and @personalizedrefrigerator for reviewing! There was one last conflict which I could fix from here.