But "Tools - Language - For x" offers "More..". Isn't that what you meant by "Other"?

No. I know that function (though I find it rather useless as it just points at the extensions site rather than help user pull directly from some repo).

The point is that since I have already installed the English (UK) and Gaelic UI and spellcheckers, I should consequently be offered (at least) English (UK) and Gaelic by LO for setting the language of a document and proofing. But I'm being offered Gaelic and Welsh, which is just not right. I have not installed anything Welsh. And why is it hiding/not offering English (UK) even though it's installed?

In MS Office there is similarly erratic behaviour when it comes to setting the document language. Even if I turn off this feature, it will consistently set the document language to languages which I did not set as default. MS Office for some arcane reason seems to communicate with the keyboard setting and over-ride my "Do not detect document language automatically" setting. I discovered this because I bastardized the de-LUX keyboard to build myself a keyboard for typing phonetic symbols (so I can do my normal typing in en-GB or de-DE but then just hit a shortcut to de-LUX to get system wide access to phonetic symbols without having to pick them off a character map). With the annoying side effect that MS Word in particular keeps resetting any document to de-LUX. Even if I've manually selected a paragraph and set it to en-GB or gd-GB.

So I think LO is doing some "unauthorised" pinging around for locales and overrides user settings.

Aha.. for me it doesn't open extensions site, but either character or paragraph formatting dialogs or the language options dialog.

Well, yes and not. If I click onto the language display area and select More, it takes me to the dialogue where I can change the font associated with a language (which won't fix my problem), font effects, margins and so on. Not relevant to the problem.

Language > Set language for paragraph > More also takes me to the same menu.

And I did muddle something up in my brain. The I mixed it up with the Tools > Language > Get more dictionaries online menu, which takes you to the extentions site which isn't great.

Either way, my problem remains. Though it's in a different mood today. Welsh has disappeared and German-Luxemburg has appeared. If I start typing in gd-GB (my default document language), en-US is suddenly offered as a language I can choose. But there seems to be no way I can force it to en-GB even though that's the only UI language and proofing dictionary I have installed. I'm beginning to consider tearing my hair ;)

(In reply to Michael Bauer from comment #4)
> Well, yes and not. If I click onto the language display area and select
> More, it takes me to the dialogue where I can change the font associated
> with a language (which won't fix my problem), font effects, margins and so
> on. Not relevant to the problem.

Hmm.. for me, the "Language" dropdown changes the actual language of the text and you can see the change in the status bar.

Yes I'm sure it does but I can only change it to a language LO is SHOWING me in that menu and right now, that's (depending on the mood of LO), en-US, gd-GB, de-LUX or cy-GB. But *NOT* en-GB the language I actually want and which I have installed. I cannot select a language it's not showing me. That's precisely my problem :)

Created attachment 119946 [details]
Screenshot showing the language dropdown

Here is what I see. You only have a couple in that list?

But I don't need to change the association of specific fonts with specific languages. All of the languages in question use the Latin alphabet so I should be able to change between the languages (in my case en-GB and gd-GB) without having to change default font associations. It's not like I need to tell it to use Arial Unicode so I can write in Burmese or something.

And it still does not explain why it offers me German (Lichtenstein) and Gaelic but not English (UK). And/Or en-US which I have neither as a keyboard not a proofing language.

Created attachment 119947 [details]
screenshot showing unexpected language offering

(In reply to Michael Bauer from comment #8)
> But I don't need to change the association of specific fonts with specific
> languages. All of the languages in question use the Latin alphabet so I
> should be able to change between the languages (in my case en-GB and gd-GB)
> without having to change default font associations. It's not like I need to
> tell it to use Arial Unicode so I can write in Burmese or something.
> 
> And it still does not explain why it offers me German (Lichtenstein) and
> Gaelic but not English (UK). And/Or en-US which I have neither as a keyboard
> not a proofing language.

But my screenshot is not about changing the association of specific fonts with specific languages. It does the same as the selection menu in your screenshot.

Errr right. I mean, thank you for pointing that out but I think I will continue keeping this bug open because that must be the most un-intuitive menu in LO. I have done multi-lingual wp for over two decades and this is really not practical.

The menu I screenshotted should show the languages I installed for UI/proofing, always. But perhaps most importantly, that Fonts tab needs a complete overhaul because if you label something Fonts and put a font dropdown next to font size and a languages dropdown, that suggest this is some sort of font-to-size-to-language mapping for defaults. There is literally nothing on that tab that suggests to a user who isn't a LO developer that this is the place they can manually set the language for a document, section or paragraph.

And it needs a tickbox for "Do not automatically detect my document language". Because it clearly gets it wrong badly, otherwise why suggest en-US over my installed preference of en-GB?

That probably means it's more of a UI bug though than linguistic, that one I'm not sure of.

I agree. Let's ask the design team, if they would like to tackle making all this more intuitive.

Created attachment 119967 [details]
Spellcheck example

It works for me as expected. Right-click an unknown word offers me the option to set the language for document/paragraph (is properly related to the style)/selection (direct formatting), with German as my default and English as the installed option. When I go to Tools > Options > Language Settings > Languages and change the default to French there is eventually a third option in this spellcheck menu (although French is not installed what is indicated by the blue checkmark icon). Guess installing another dictionary does the same. Perhaps https://forum.openoffice.org/en/forum/viewtopic.php?f=74&t=16512 also helps you.

What I agree with is the weird place for language at the font section. And I dislike the context menu, which offers me to change spellchecking only for unknown words. That makes it necessary to use Tool > Language for selections or when a dictionary is not installed (the French example).

PS: Nice to see you here as well, Michael. :-)

Hi Heiko :) which reminds me I need to bring the other translation up to speed.

Right-click context menu on a word is also not behaving as it should for me. If I do that, (I typed bluefin) it offers me Gaelic (my default) and Icelandic. No idea where THAT is coming from but the more we look at the, the more it looks like there is some autodetect feature which gets itself terrible confused and starts overriding the sensible defaults (installed UI languages of LO, installed proofing extensions).

Still happens in 5.1 version.
Extension languages are not offered by default.
With certain highlighted words, it will offer you a correct language with a wrong name like Catalan or Gaelic, but often you are unable to change the language of the text at all.

(In reply to Michael Bauer from comment #14)
> Right-click context menu on a word is also not behaving as it should for me.
> If I do that, (I typed bluefin) it offers me Gaelic (my default) and
> Icelandic. No idea where THAT is coming from […]

If it is from any help, it comes from libexttextcat. :-)

(In reply to frostwyrm333 from comment #15)
> Still happens in 5.1 version.
> Extension languages are not offered by default.

Anything that UX can do here? Removing for now.

Just to confirm this is still a problem in 6.3.4.2 (x64) (attaching screenshot), today I've been offered en-US, Rumantsch and Irish (the last two I have neither as a proofing language in LO or Office or as a keyboard layout, goodness knows where LO is pulling them from) - but still not en-GB.

This is one of the reasons why I'm still not using LO as my main office suite, I just can't work with software that takes such a haphazard approach to setting the language of text and prefers to second guess the user on a word by word basis (yes, type another word, get offered a new language).

Created attachment 158190 [details]
Screenshot of LO still offerent anything but what I expect

I'm now being offered Gaelic, Faroese and German (only Gaelic and German are language I actually have proofing installed for) and again, I have no idea where Faroese is coming from. The language I actually wanted to select for the whole document, en-GB, isn't being offered.

Right click brings up the Paragraph menu but there no longer seems to be an option to set the language even via that convoluted route.

If I right click on a mis-spelled word, I can set the language for the paragraph - though it now offers me Gaelic, German and Interlingua.

I also don't get why I can't set the language 
- when spellchecking is turned off. A user may want to set the language but not use spellchecking. Or I may want to set a language for which there is no proofing extension but I don't want to document in to be set to the wrong language.
- for the entire document, it's either shoddy UI language if "Paragraph" means the whole document or tedious to have to do this paragraph by paragraph.

There's probably some well-meant automatic thing going on but it's badly broken for anyone not using LO in en-US.

Given the high frequency with which this issue must occur for many users, I'm dismayed at the lack of attention this is getting. It's been 7 months...

Still the same, paste a piece of English text, I'm being offered German, Spanish (not even installed) and Gaelic.

Eike, can you please shed some light on this issue? 

UI/UX-wise I think bug 103036 is the way to go.

Six years on, the only way I can reliably change the document or section language in LO is by opening the document in MS Office, changing the document language and then going back to LO.

Talk about making a KEY usability bug a priority ...

(coming across this due to a new notification).

(In reply to Heiko Tietze from comment #23)
> Eike, can you please shed some light on this issue? 
Not really. I don't know the implementation of that status bar dialog nor what languages it finds worth to be picked up.

I can only say that selecting text and clicking More... in the dialog and assigning a language from the Font tab *does* work and changes the language of the selection. Similar for Paragraph. It also works to change "Default Languages for Documents" in Tools -> Options -> Language Settings -> Languages, including "For the current document only". I don't know why MS-Office would be needed for that..

Can someone please explain to me how associating a font with a language is supposed to work please unless you're a monolingual who only ever types in the one language? So let's say I associate Times New Roman with Scottish Gaelic and write "Tha cat air a' phlaide". Dandy. Now in the next paragraph I type "The cat on the blanket is an old Gaelic song" followd by a long essay on this topic in English in Times New Roman. Pray, how am I supposed to get that spell-checked in *English* when TNR is now tied to Gaelic and the only languages that menu at the bottom is showing are random languages you can get LO in but not languages you've got spell checkers installed in?

Even if we stick to monolingual documents, that doesn't work, because someone might write an essay in German but then in another document, using the same font, a job application in Spanish. Then what?

At the moment, the only way - without having to resort to this incredibly clumsy font association thing - I can change the proofing language of a word/paragraph/selection is by opening it in MS Office, changing the locales as required and the going back to LO. Bizarrely, once I've done that, LO is ok with whatever selection I've made. It just refuses to allow me to set them within LO.

The locale - in terms of the proofing language - for a word/paragraph/selection should be modifiable for the end user without having to resort to click contortions and in an intelligent way i.e. the top proofing locales suggested should be those for which dictionaries are installed. Not some random selection.

(In reply to Michael Bauer from comment #26)
> Can someone please explain to me how associating a font with a language is
> supposed to work please unless you're a monolingual who only ever types in
> the one language? So let's say I associate Times New Roman with Scottish
> Gaelic and write "Tha cat air a' phlaide". Dandy. Now in the next paragraph
> I type "The cat on the blanket is an old Gaelic song" followd by a long
> essay on this topic in English in Times New Roman. Pray, how am I supposed
> to get that spell-checked in *English* when TNR is now tied to Gaelic and
> the only languages that menu at the bottom is showing are random languages
> you can get LO in but not languages you've got spell checkers installed in?

Not tied to the font, but to the direct character formatting or character style or paragraph style.

That is still bonkers. The locale tag (or whatever it is) of text shouldn't hinge on fonts, formatting or style. When was that ever a good idea? ;)

Some background on the language tag are here [1]. The point is that complex layouts like Korean require special glyphs and RTL fonts have a different reading direction, for example. 

That's not the way to distinguish between Gaelic and English, of course, where you have to define explicitly what language to use. You can do this for the whole paragraph or just characters. Create dedicated styles for the languages you need.

No idea what causes the "erratic behavior" on auto detection. The reported issue is also not easy to reproduce. And more generally, I see no way to reliably detect the correct language.

[1] https://docs.microsoft.com/en-us/typography/opentype/spec/languagetags

(In reply to Heiko Tietze from comment #29)
> Some background on the language tag are here [1]. The point is that complex
> layouts like Korean require special glyphs and RTL fonts have a different
> reading direction, for example.

<shrugs> I write a lot of Cantonese, so I'm aware of the complexities of getting the right font locale variants under Unicode. And yes, Microsoft isn't great at obeying the default locale font setting.
BUT the point is that while having a working default locale font setting is great, that is NOT the right place to also govern the locale setting for a particular section of text.

> That's not the way to distinguish between Gaelic and English, of course,
> where you have to define explicitly what language to use. You can do this
> for the whole paragraph or just characters. Create dedicated styles for the
> languages you need.

The point is, I CANNOT do this for the whole paragraph or just characters. Not without going through huge contortions. Something that is SUCH a common event for users working in more than one language, this should require two clicks at the most. Not having to work your way through the default locale font settings or having to create dedicated styles. That's just NOT user friendly for such a basic common issue. 


> No idea what causes the "erratic behavior" on auto detection. The reported
> issue is also not easy to reproduce. And more generally, I see no way to
> reliably detect the correct language.
> 
> [1] https://docs.microsoft.com/en-us/typography/opentype/spec/languagetags

I'm not buying that. I'm no programmer as you well know but while I understand auto-detection can get things wrong (Microsoft does, often enough, even when this feature is turned off) but I cannot imagine it's impossible to weigh detection towards either a) installed dictionary and/or LO UI languages or b) user choice via settings. Not suggesting Tibetan when your LO UI language is French and you have French, Spanish and English dictionaries installed but not Tibetan cannot be impossible to do.

If the request is to make auto detection work reliably we have to wait for experts/volunteers.

If you think that manually picking the language has room for improvements we can discuss this. I don't understand why you cannot change the paragraph/character style - okay, writing a dictionary where you have to switch from one language to the other every second word... And if you have a valid use case, is there a solution that wont bother average users?

(In reply to Heiko Tietze from comment #31)
> If the request is to make auto detection work reliably we have to wait for
> experts/volunteers.

Perhaps we could invite some? 
 
> If you think that manually picking the language has room for improvements we
> can discuss this. I don't understand why you cannot change the
> paragraph/character style - okay, writing a dictionary where you have to
> switch from one language to the other every second word... And if you have a
> valid use case, is there a solution that wont bother average users?

I have no research data on this but my experience with being sent other peoples documents is that 9 out of 10 people don't use styles because they are either unfamiliar with the concept or find them too cumbersome for short documents where you don't want to spend time defining a style but may wish to change the font or indeed write in a different language. Styles are really useful for something large, like writing a book or dictionary (and I do use them for those) but if I'm writing a letter and just want to use a different para spacing or font, there's no point in faffing about with styles, you just change it ad-hoc as you'll most likely never use that configuration again.

So styles as a default path to setting the proofing locale are a) not realistic when considering the default behaviour of everyday users and b) not quick enough.

MS Office has a *really* simple and intuitive way which we could emulate:
1 open a doc and type somethimg, Word will try and guess the language, same as LO
2 if it guesses wrong, in Word you just single left click at the bottom of the window where the locale is indicated (with or without selecting text). That brings up a list of locales (the top 4 are those with dictionaries installed, the rest is an alphabetical list of ALL locales Word supports from Afrikaans to Yoruba). Click on the one you want, click ok, done.

2 is where LO fails. I think it's trying to do the wrong thing, because if you click on the locale, it does try to bring up a list of locales but the way in which it chooses the 2-3 locales is broken. However it chooses those is at least partly broken.

For an easy fix (to my mind), the locale suggestions should be limited to installed proofing dictionaries and (if different) the LO UI locale (as some locales have a localized UI but no proofing).

A slightly more complex fix would be to then fix the "More" option that appears in that window to bring up NOT the font settings but a list of locales/languages like Word does where you can simply do an ad-hoc selection of the locale/language for a document or selection without having to resort to styles or font associations.

Here's an easy challenge: open a blank document in Word and one in LO. Type a random selection of characters. Now try to set the language of that selection to Yoruba and time yourself. I bet it takes you a LOT longer to do that in LO compared to word. (with a document open in word with a word pre-typed, it takes me 7:86 seconds to set that word to Yoruba. In LO, after 15 seconds, I'm still wondering if I should click More or Set Paragraph Language > More and even longer wondering why both of those options bring up the Font menu)

Recte:
* I think it's trying to do the RIGHT thing

(In reply to Heiko Tietze from comment #29)
> Some background on the language tag are here [1].
> [1] https://docs.microsoft.com/en-us/typography/opentype/spec/languagetags
Those 3-4 letter "Language System Tags" are only a thing with OpenType fonts and completely unrelated to BCP 47 / RFC 56546 language tags, except that they sometimes share a letter or two.
Best erase it from memory in this context.

If you want to learn about language tags as we use them:
https://erack.de/bookmarks/D.html#Language_Tags

However, that's not really related to the problem here, except that we use language tags for language and locale attribution.

Much of the confusion why the Language list even sits beside the font options probably results from the fact that most people do not have CJK and CTL enabled, otherwise they would get two or three font sections with each a language correlated. Of course language is not a font attribute, despite that the dialog may look like it would suggest that. The reason it is like it is again is ..haha.. MS-Word.. also there is the Western/CJK/CTL distinction. Now what it actually is good for is that if one types text of CJK or CTL mixed with "Western" (or rather non-CJK and non-CTL), then the text's language determines which font to use.

Additionally the font preview may change according to the language selected if it uses a different script. However, with the "Western" languages this currently happens only for Greek (and Irish;) and with CJK for Chinese vs Japanese. That would probably need more sensible short preview texts, Lorem Ipsum in other scripts doesn't make sense.. I didn't dig deeper.

If there wasn't this correlation between language/script and font to be used then the Language list(s) could be independent, but would lose the font preview. If one uses only "Western" then just view it as both, the three font attributes to be set for the selection, and the language to be set for the selection, without dependency.

So what does that mean in terms of fixing the impractical approach to changing the language of a specific bit of text or document in LO?

(In reply to Michael Bauer from comment #36)
> So what does that mean in terms of fixing the impractical approach to
> changing the language of a specific bit of text or document in LO?

Why is it impractical to select characters and double-click a character style from the sidebar or be in a pragraph and double-click a paragraph style or pick it from the formatting toolbar?

(In reply to Buovjaga from comment #37)

> Why is it impractical to select characters and double-click a character
> style from the sidebar or be in a pragraph and double-click a paragraph
> style or pick it from the formatting toolbar?

To repeat myself:
a) few people use styles, especially for shorter documents and even for longer ones, they are rarely in evidence. I proofread a LOT of texts for submission to medical journals, maybe 5% use styles, the rest have ad-hoc formatting applied, even to stuff like headings. They take both time and expertise to use whereas the text size menu and/or bold/italic direct formatting are visibly there, easy and quick to use. No wonder most people just hit pt 14 and bold underline instead of a heading style. It may not be the way word processing software is intended to be used, but it's the reality of how people use it. We can claim the moral high ground and ignore that, or we can try and make it work for as many users as possibly (as far as the proofing language issue goes, I'm NOT suggesting we dump styles). 

b) it's counter-intuitive. Especially with the document/text language displayed at the bottom of the window, nobody who isn't a LO dev will go looking in the *styles* for a way to change the language their text is proofed in. It's like telling your mom who's baking you a cake that the flour is in the garage freezer. It may be the place where you keep your flour and in some ways perhaps not a bad place for it but it's a) a long way from the kitchen and b) not the place anyone goes looking for flour, not when you have a kitchen larder...

Setting the language via statusbar has been criticized many times, see bug 143366, bug 116158 - bug 107288 (all NAB/WF) and bug 114178. 

Whatever we do, it will be wrong in some scenarios. Either it shows the document's language and fails on the paragraph level or vice versa. The average user might want to set a language per document but even a bit advanced users apply it per paragraph. And the actual information is on the current character. So the only clear solution here is to prohibit changing the language at the statusbar.

So you're seriously suggesting that offering me Tibetan but not the proofing languages I have installed (English/Gaelic/German) is intended and desirably behaviour? No wonder it's so hard to take FOSS seriously at times...

And those bugs you linked don't criticize the ability to set the language from the status bar, they criticize the INability to do so i.e. the fact that instead of being able to set it from the bar, it brings up the font menu.

We're clearly going round in circles, with normal users pointing out this is broken and the devs claiming it isn't and that it's intended behaviour. Is there some sort of an escalation procedure within LO where we can take an issue to a wider audience to get input from people who aren't 10 devs who understand how this is theoretically supposed to work?

This bug has gone a long way from "the status bar menu displays odd languages to select from" to criticizing all things around language and font attribution. Can we please get back to the original problem? No one is going to read 42 comments anyway. Thank you.

Gladly but it seems everyone is pointing the finger somewhere else. All I (and I would imagine any sane user) want is for the menu at the bottom not to show random languages but those relating to the user's installed proofing languages and UI locale.

See bug 139185 comment 4 for a code pointer (and explanation).

I tried to debug this language status menu, and here is my findings so far:

The code that populates the language menu is LanguageSelectionMenuController::fillPopupMenu() in:
https://git.libreoffice.org/core/+/refs/heads/master/framework/source/uielement/langselectionmenucontroller.cxx#160

Which in turn calls FillLangItems() which is responsible for selecting what language items to show:
https://git.libreoffice.org/core/+/refs/heads/master/framework/source/fwi/helper/mischelper.cxx#57

The code seems to add:
1. current language of the text selection
2. system language
3. ui language
4. guess language based on the text selection (seems to use libexttextcat)
5. keyboard language (I think this works in Windows only)
6. all languages used in the document

and in each of these (expect of 1) the language is only added if it makes sense for the script.

These all seems reasonable to me. Now the question is what other criteria we want to use for adding languages?

Created attachment 188072 [details]
MS Word languge window

What MS Word is doing does not seem to be so sophisticated either, on a mix Chinese/English document it shows a dialog with all languages, and it selects 6 languages 3 of them are useless as they for different scripts than the text and won’t be applied when selected (Arabic, Chinese, and Persian). It seems to base the selection on the locales of the system or some other thing I’m not sure about (for example it shows Swiss even though it does not seem to have spell checking for it).

May be one improvement we can borrow from MS Word it to use a window instead of a menu, so it can always show all languages instead of only the selected ones, so regardless of how we guess the most sensible ones the user can always find a suitable languages without having to click more.

I now see that Mike already provided the code pointers in Comment 44. Probably this need some UX input as well.

UX was involved earlier, with not much to add.

The issue why Welsh is offered for Gaelic. It should be clear why languages are offered, ideally user-definable per checkbox with some sane preset.

(In reply to Heiko Tietze from comment #48)
> UX was involved earlier, with not much to add.
> 
> The issue why Welsh is offered for Gaelic. It should be clear why languages
> are offered, ideally user-definable per checkbox with some sane preset.

I’m inquiring specifically about:

> May be one improvement we can borrow from MS Word it to use a window instead
> of a menu, so it can always show all languages instead of only the selected
> ones, so regardless of how we guess the most sensible ones the user can always
> find a suitable languages without having to click more.

But if the current behavior is deemed acceptable/working as designed, then there is no point in keeping this issue open.

The current behaviour is not acceptable. End users require a simple way of being able to control the languages offered for proofing. At the moment, it's a) a lottery which languages are offered b) there is no way of fixing this other than theoretically through some really complicated thing via the font settings.

Whatever LO's best guess mechanism is for producing the current offering, fine, but when the user clicks on the bottom bar which brings up the current best guesses and they're wrong, there should be a new menu than users can access, let's call it Select Proofing Languages where the user can select (a simple tick box list of the locales LO can offer) and restrict the proofing languages they want to be offere i.e. if I go into that menu and select Gaelic, English and German, then LO should stop offering me Tibetan and Cherokee just because it things I'm writing in Cherokee for some odd reason.

(In reply to ⁨خالد حسني⁩ from comment #49)

The problem here is awful results from libexttextcat. Especially on small text length. Despite "working as designed", the resulting menu is unacceptably wrong. And possibly because of those wrong results, some results that could make sense from your list in comment #45 do not get into the resulting menu (just a guess, didn't check this code) - because e.g. all languages from the document are not always shown, even if match the script, and would be much better than what libexttextcat suggests.

(In reply to Mike Kaganski from comment #51)
> (In reply to ⁨خالد حسني⁩ from comment #49)
> 
> The problem here is awful results from libexttextcat. Especially on small
> text length. Despite "working as designed", the resulting menu is
> unacceptably wrong. And possibly because of those wrong results, some
> results that could make sense from your list in comment #45 do not get into
> the resulting menu (just a guess, didn't check this code) - because e.g. all
> languages from the document are not always shown, even if match the script,
> and would be much better than what libexttextcat suggests.

If libexttextcat guessing is not usually useful, we can drop that part. But showing languages that don’t match the selected script is useless, since they won’t be applied if user clicks on them (you can’t set CTL text English or Western text Arabic, LO just won’t let you do that).