I believe I speak for all non-English people, we write in our native language then switch to English to insert a foreign word to our documents and the spell checker highlights it as incorrect.
It shouldn't be hard to implement, words in one language can be spellchecked using said language, changing and typing on a different layout changes the spellchecker to that language.
Steps to Reproduce:
1. Write using one layout
2. Select spellchecker's language to match the layout
3. Change layout to write a word in a different language
foreign words get highlighted as incorrect
foreign words get detected and checked for spelling errors appropriately
User Profile Reset: Yes
This was observed using Greek and English
Do you use Linux or macOS maybe? Because this feature is implemented in Writer many years ago, and on Qt recently, but not on other integrations: tdf#108151.
I meant to write: implemented on Windows many years ago, and on Qt recently.
Created attachment 184104 [details]
How it is intended to be on Windows:
- with Options->Language Settings->Languages->Ignore system input language *disabled*,
- and switching keyboard layout / system input language (Alt+Shift on my system)
(In reply to Mike Kaganski from comment #3)
> Created attachment 184104 [details]
> A screencast
> How it is intended to be on Windows:
> - with Options->Language Settings->Languages->Ignore system input language
> - and switching keyboard layout / system input language (Alt+Shift on my
I wasn't aware this feature could be OS depended and also potentially not enabled by default, I ll check the settings when I get back on my computer. I ve used libreoffice on windows like a year ago but recently switched to arch Linux with kde plasma, thanks I ll write an update later~
(In reply to Michail from comment #4)
> I wasn't aware this feature could be OS depended
(In reply to Michail from comment #0)
> It shouldn't be hard to implement
:) It *is* hard to implement, when the OS does not tell programs which language is used when typing. On Windows, there is an API for that, and as mentioned, LibreOffice uses it since forever (and before it, the feature was implemented in OOo time). However, Linux only sends key codes / character codes, without a language context (or at least, we still don't know how to get that information from system); and when the program gets a character "a" from system, it can't decide if the character belongs to English, or Spanish, or Czech, or ... - see bug 100762 comment 6 and below.
Maybe the last comment there could be useful on Gnome - no idea, a Linux developer might tell. Jan-Marek and Caolan are CCed there.
well maybe it can partially work for some languages that have unique characters.
greek looks like this αβγδεζηθικλμνξοπρστφχψω, non of them are the same to the Latin alphabet even if they look similar at least lower case not sure if A and Α are considered the same despite α and a being different.
A single-language function is not a solution for LibreOffice. There are very few languages having that property; Latin, Cyrillic, CJK, Arabic, ... - I'd guess that 99% people on the planet use alphabets with subsets of characters shared with other languages.
Of course, *if* an interested developer decides to implement a hack for Greek, patches are welcome.
> Of course, *if* an interested developer decides to implement a hack for
> Greek, patches are welcome.
On a sidenote, I dd love to contribute but despite knowing a lot about programming I have no idea where to start with actual software that "real people" use, they don't teach practical things in my university.
(In reply to Michail from comment #8)
> I dd love to contribute
https://wiki.documentfoundation.org/Development has some stuff to get started. As mentioned at https://www.libreoffice.org/community/developers/, you are welcome to join our development channel; we have people who help new developer, including introduction interviews, videocalls and such things.
Commit 9d96088c2832b681ae079b29cbc977231674ad52 could be a starting point for this task as a code pointer; different backends implement Window::GetInputLanguage differently, and a default implementation could use your selective script support idea.
(In reply to Mike Kaganski from comment #9)
> different backends implement Window::GetInputLanguage differently
... or rather, implement different overrides of SalFrame::GetInputLanguage, used in Window::GetInputLanguage.