Well that is not a bug but a workaround.

There were complaints about the time it takes to display that menu when a large
number of languges (>20) was installed on decent machines. 
Also it was reported that there was a extensive memory usage (if I remember
correctly someone said sth about 500MB) if the word was not found and all
languages got used (their databases instantiated).

Of course such behaviour depends on the machine used and the actual spellchecker
implementation used. It will be somewhat different for OOo spellchecker and SO
spellchecker and for probably other existing spellchecker as well.
But since the behaviour should be decent for all cases it was decided the only
way to have this improved for the next release is to limit the number of
languages being checked. And as quick but obviously somewhat lacking choice the
list was decided to be:
- The UI language listed in the "Tools/Options - Language Settings - Languages"
- The locale listed in the same dialog
- The default Western document languges from the same dialog
- and English US

A better choice is to be implemented later. Maybe already for the first product
patch. I will probably sth be like "all languages already used in the document
should be checked as well" but surely not "all languages available should be
checked" since that is the original source of the problem.

An even better solution would be if we had a small (in respect to code and data
size) tool that would be able to 'guess' the language of a given text without
having to use the spellchecker and using it's likely large databases.
But such a tool we do not have.

TL->SBA: Can you provide the issue number for the above mentioned change we have
applied? I could not find it right now. 
Also FL should have an issue number ready where the future behaviour to be is
addressed. If that could be mentioned here as well it would be nice.

The current solution is not acceptable for Russian users, if they use snapshots
or not localized version, becaise it excludes Russian from the list of searched
languages. 
- The UI language listed in the "Tools/Options - Language Settings - Languages" 
English.
- The locale listed in the same dialog
English UK. This is a workaround of the oldest bug (one of the most voted for by
russian users, mostly within the bug 1820), which was arised again several times
and *ignored* by developers. The problem is that OO doesn't pay much attention
for Widows decimal separator settings. The majority of Russian use dot as
decimal separator. So all the programs read the settings and use dot too. But OO
wants comma. This is not the same as to interprete the dot from the numeric pad
as comma. This is to *use* the same decimal separator as all the other programs
use. I do not understand why did the developers ignore the wish of so many
people. English UK unlike English US allows to use dot and to use the same date
representation as Russian used to - dd.mm.yyyy.
- The default Western document languges from the same dialog
English, of course.
- and English US
English again.

I would made such a workaround: 
- If there are only several languages in dictionary.lst (as I have f.i.) there
is no reason to switch off languages checking. The below items doesn't concern
this case.
- If there are more languages in the file, the user can be asked at the document
opening or new document creation, which languages he wants to be checked
automatically (without direct language assignment for the part of the text).
This dialog can be done as list of checkboxes. The values can be stored with the
document. 
- Also I think there is a very little per cent of people who use more than 3-4-5
languages all of the time. So these most used (or desired) languages can be
remembered in the OO settings. It only requires one more group of checkboxes
with the title: the languages used for automatic spell checking and the items
available both in dictionary.lst and real dictionary files. The user can select
which languages he wants to use and nobody would do it instead of him. And this
workaround is very simply to realize.

TL->FL: Can you please add some comments about this and/or reconsider the new
behaviour to be implemented?
Thanks!

could someone explain the *problem* (I see the comments about workarounds and
locale settings, but I don't see a problem with spellchecking).

Spellchecking works very well for me:
- WindowsXP, german localized (de_CH)
- OOo 1.9.108, german localized
- Default dictionaries + de_DE, de_CH, de_LI, pl_PL installed and enabled

I created a document with paragraphs with de_DE, de_CH, en_US and pl_PL
(charcter format). Spellcheck works correct for all those (words not acceptable
for the paragraph's language are marked as bad).
If I enable "check words in every language", even word with wrong language
setting are marked as OK.

So, behaviour to me is as expected. And this is more or less a user's mistake
(or wrong expectation). 

BTW: UI language setting and locale settings have nothing to do with dictionary
languages. Also the date format has nothing to do with spellchecking.
It seems, different problems are mixed up here. (And I still think, it's simply
wrong expectation)

The previous versions of 1.x and builds of 2.x checked through the installed
dictionaries even if the language is not set or wrong by default. If the
language set was wrong OO suggested to change the language assignment for the
word/paragraph. It didnt' happen if the world was written wrong.

OO M 109 does not check through the installed languages by default. If the
"check in all languages" is enabled OO doesn't suggest to change the language of
the word/paragraph as it has always been before. It has been very useful to
correct the misspelled words. 

So the missed functionality in the current implementation is: to suggest
changing language for the word/paragraph (with the dropdown menu) if it is
assigned wrong and exists in installed dictionaries.

ok, I got it. 
Setting regression keyword, as all users would be affected, where no langpack is
available.

andreschnabel->tl:
could you please point to the issues you mentioned (why this behaviour was
introduced and what is planned to implement) I did a quick search in issuezilla
/ lingucomponent, but didn't find the issues. 

The issue that introduced this new behaviour was issue #32169#.

I do not understand the problem. If you need a "." instead "," as decimal
separator, please exchange/override those in you operating system locals for
Russian instead of changing you OOo locales to English UK. There is no general
problem if no language pack is available for the currently used language.

We will not change the current implementation of determining the language of a
missspelled word, until we have something like a special component saving time
and memory and providing "good" matching results.

BTW issue 1820 is solved and closed.

tl, I'm sorry, but I'm really tired explaining the same things again and again. 

1. I do have dot as decimal separator in my Windows. This is the common
situation for Russian users, at least those concerned with programming. My
Windows has Russian locale. I've written it before.

2. OO has ',' as decimal separator for Russian locale at the same PC. This is
the reason for several problems, including inability to exchange OO spreadsheet
data with any other Windows application via clipboard - they interprete each
other's data as text.

3. The only way I know to have OO used '.' as decimal separator at Russian
Windows is to change the OO locale to English UK as a workaround. Many Russian
users solve the above problem in this way.

The one and only problem is: OO DOES NOT USE SYSTEM DECIMAL SEPARATOR. It reads
its decimal separator from its own setting for the language locale and IGNORES
the system settings. This leads to incompatibility of clipboard data, cvs files,
absence of common interface.

Hi all,

the summary of this issue reads *spellcheck*. And spellcheck has nothing to do
with comma separators. 
This issue has absolutely mixed up comments, so it is useless to keep this one
open an I'll close as invalid.

bigserpent: 
please file a new issue with focus on spellchecking. Set me to cc an I'll
confirm it. (The new comment should include the one from Tue Jun 28 .. that's
the one I think is most propriate)
Please don't mix up again with comma separator with spell checking.

If there are still problems with comma separator, file a second issue for that.
And ask at dev@native-lang and / or dev@qa for help. 

closing this one ... please don't reopen, as the comments are not usable anymore.