How to use the [Multiple] option for "Language"?

For me it is the norm to write multi-lingual documents, and constantly explicitly setting the language for paragraphs or word sequences is a nuisance. Chrome was for a while able to set multiple languages for spell-checking, without having to manually switch between the two.

Now recently I noticed that an entry “[Multiple]” has appeared in the language selection, but I can’t quite make sense of what it actually does. There doesn’t seem to be an option to specify which languages are in “multiple”.

How is this feature used?

To be honest, I don’t know and have never used it.
But I have a guess.
For example, if you download LibreOffice in English, several other languages and dictionaries are installed in the package.
Or you can do a custom installation.
So it could refer to what is installed.


https://wiki.documentfoundation.org/Videos/LibreOffice_6-4_Installing_under_Windows_10#Custom

1 Like

Release Notes 24.8 :

Although it was already possible to type their ISO 639-2 codes by hand, “[Multiple]” (mul) and “[Undetermined]” (und) are now listed at the top of language lists (along with “[None]”, zxx). (Eike Rathke, Red Hat) tdf#160256


multiple

1 Like

That’s apparently not it, see this text sample and what gets marked:


With [Multiple] selected as the language, nothing gets marked as incorrect, including complete garbage.

So it looks like “[Multiple]” isn’t really a feature, but more a compatibility thing to support a standard.

I also noticed, that when doing an active spell check, the language “[None]” is selected, which explains why it effectively disables spellchecking.

Net insight: [Multiple] isn’t useful for spellchecking and LibreOffice doesn’t have any form of automatic multilanguage spellchecking support.

https://bugs.documentfoundation.org/show_bug.cgi?id=160256

It has a semi-automatic feature for thousands of similar tasks, however, ignored by the majority of users. I’s called “Styles”.

2 Likes

“Multilanguage spellchecking support” is a fiction (or, rather, the only reasonable multilanguage spellchecking support is to allow applying different languages to different parts of text, which is implemented in LibreOffice perfectly). A single language must be applied to a word, always. If it is not applied, that’s not a word of a spellcheckable language. Everything else may be appropriate in Web / Signal, but not in Writer.

People switch languages in their mind; they imagine, that it’s equally easy for others to recognize that. No, the opposite task is basically unsolvable; and it should be a muscle memory to do something on your keyboard, when you switch languages in your mind. It is easy on systems with reasonable multi-language input support (I talk Windows here), which allows users (but unfortunately, doesn’t demand) to set up input languages, which applications may recognize. Users who use scripting systems with different alphabets, usually already benefit from that - they need to switch the input languages explicitly anyway, and Writer knows, when you type English, and when it’s Hebrew. But for people who speak, say, English + Italian, it’s “normal” even on Windows, to have a single input language, and type without any switching - thus, defeating all means how a program can know your data language. On systems with absent means how programs can learn input language (e.g., GTK), users are left on their own about how to tell apps what language they use.

The language is not a “formatting” (from a semantical point of view; the internal implementation doesn’t matter): it’s an essence of a word/phrase; without it, a sequence of bytes is not a word, but just a meaningless data. tdf#151290 has all reasons.

And therefore, having styles for languages is wrong.

I am already using it. For instance I usually assign the language “[None]” to the “Variable” character style and all text and paragraph styles used for source code, since they usually contain expressions that are not valid words.

It does sort of work to define a “English” character style. But then I might also need “English (emphasized)”, “English (strong)”, etc. Which for convenient workflows I also have to define as document specific entries in “Menu Bar > Styles” or hotkeys. A lot of setup compared to defining the root language of the document as “English or German”, if it were possible. Which would still use Styles.

Setting the language through styles is a godsend for some aspects, but for multilingual documents it is not much less cumbersome than just setting the character style manually each time.

On part I disagree. If it works well for professional Emails, why should it not work for documents written in writer?

It is extremely common when talking about technical tasks to freely use English nouns in an otherwise German sentence. Explicitly switching language on a word by word basis is cumbersome enough, that making spell checking a bit more heuristic seems like a quite reasonable trade-off.

Usually my trade-of is instead to disable automatic spell checking while writing, which I really would rather not.

See: I speak Russian. And on my system, I have both English and Russian keyboard layouts set up. It is normal to me to switch between English and Russian keyboards when writing a sentence like what you are describing (just with Russian in place of German). And you know what? The small technical difference - the need to switch keyboard layout, because there is no Russian letters on English layout - makes it easily into my muscle memory (to press Shift+Alt every time I switch), and becomes natural; and then I don’t have problem with that; and accidentally, Writer knows when I write English or Russian.

And knowing all that, if I wanted to use English and German, I would also set up a separate input in system; and use the same Shift+Alt every time I switch English and German in my mind - even though the keyboard layouts were the same. And that would let Writer to know it perfectly. And accidentally, that would also let you later select all English words in your writing, and e.g. italicize them…

But fighting against the system the way as you are trying to is common mostly among exclusive Roman-script users, just because they usually don’t even know about features that are used commonly by others…

And no, “professional emails” is a different category. “Find if this word may possibly be valid in any of these different languages” is almost as fuzzy as “allow any garbage”.

This concept (a) does not translate well to German/English keyboards though, (b) nor does it even exist on Linux.


(a) German keyboards with English text. Since the layouts are very similar, with only a few letters differing, German keyboards never have an English layout printed, unlike most Cyrillic keyboards I’ve seen, which commonly have the Latin letters on them. However, all non-alphanumeric symbols are in different positions. Especially since some keys don’t even exist between a US English QWERTY and a German QWERTZ layout.

So using an English software layout to write English text on a German hardware keyboard would be possible, but incredibly annoying. Thankfully, Windows allows to freely combine hardware layouts and languages, so that’s possible. But because it mostly doesn’t matter, since the keyboard layout is the same now, it is very easy to forget and end up with a mixture of languages in a document. Given that most PowerPoint files I collaborate on have their entirely English text set to German language, the most common solution seems to be to just turn off spell checking…

But that’s on Windows which at work I use exclusively due to needing full PowerPoint compatibility occasionally.


(b) On Linux. On Linux the keyboard has a layout assigned. That’s it. But there is no such thing as an input language; That one is left entirely to the program. So there is no way to switch between input languages on the fly and frankly, I am glad about it for the most part. On Windows it usually just ends up messing up the language of documents, especially since programs still second-guess the user quite often (most commonly in MS Office due to misconfigured templates, that use English text but inherit German as the document language from the PC of the template creator).

So effectively on Linux, language management is left entirely to the program.


Workaround. While writing this I found out that there is a menu bar entry that covers this. Tools > Language > For Selection / For Paragraph etc. Or with the keyboard (assuming English as interface language): Alt + T, G, F, E. Sadly, it doesn’t seem possible to assign this to hotkeys.

Wrong on both parts.

a. You are not required to have a different keyboard layout, to set up a separate input language with possibly the same layout. And about forgetting - well, it’s just a matter of creating a habit. You can’t expect anyone - even if that anyone is AI - to guess it always correctly from incomplete data; the proper way is not expect correct guessing, but provide correct data.

b. Yes the support is not as good on Linux; but (1) e.g. it is already available on qt5 integration there; and (2) on other integrations, it’s a question of users demand.

As to shortcuts: there is always a macro way, assigning DF with the language.

menu:Tools>Options>Languages>“Default Western” plus option “Current document only”.

Then you may store the resulting document as a template.
For some document where I typed a German text with English original quotes, I set up a second paragraph style based on “Block Quotation” with English language, so I could write or paste-special some quoting, then the translation and continue with text body style. Spell checking and typographic quotes work as expected.
For a bi-lingual document based on a 2-column table layout (languages side-by-side), I would do the same with a variant of para style “Table contents”.

uss

How does this work? When I toggle keyboard layout, Writer simply types the other set of characters.

@Villeroy note that this requires OS (DE) to report the input language. And at this moment, this only works on Windows and qt5. I assume, that you are on Linux?

Or is your question simply about how it is implemented? As said, this comes from OS /DE, where this information is available. The only question is to have ways to get it from there; and it’s sad when this is not deemed important by the OS / DE devs.

Have you tried? I mean recording a macro and assigning it to keyboard shortcuts…
(applying the change directly to registrymodifications.xcu also seems to work).

OK, I’ll have a look next time when I visit a Windows box. My personal desktop is Gnome.