Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | spellcheck doesn't search through other installed languages | ||
---|---|---|---|
Product: | Infrastructure | Reporter: | bigserpent <alexander.v.rabtchevich> |
Component: | Website general issues | Assignee: | issues@lingucomponent <issues> |
Status: | CLOSED NOT_AN_OOO_ISSUE | QA Contact: | issues@lingucomponent <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | andre.schnabel, frank.loehmann, issues, nesshof, stefan.baltzer, thomas.lange |
Version: | current | Keywords: | oooqa, regression |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
bigserpent
2005-05-18 08:23:22 UTC
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. |