Posted: Sat Dec 15, 2007 3:00 am Post subject: Spelling re-factoring suggestion
First thank you for adjusting spelling module to use Apple Spelling Service.
Anyway, I read from the forums, that it has also created some confusion and problems among users. So I'd like to suggest you to re-factor spelling component into 2 separate lingucomponents -- 1st component implemented by OO.o; 2nd component utilizing Apple Spelling Service. That would allow users to configure from Writing Aids pane which of those two they prefer, users can even configure it lang by lang.
Technically OO.o code already has a support for multiple concurrent lingucomponents and configuration options mentioned above. Only thing needed is to re-factor spelling component itself.
Another thing.
It would be great if there was a possibility to configure mapping between NeoOffice language code and Apple Spelling Service language code, smth like en_CA="Aspell/English (Canada) [w_accents]".
Unfortunately I have no good clean technical solution to suggest here.
Essentially, what you are proposing is to put the OOo's spellchecker first in line to handle spellchecking and I don't understand what problem that solve. The reason we implemented native spellchecking support was because of the continual postings nearly every day that "spellchecking doesn't work". It didn't work because very few languages are supported by the OOo spellchecker and, in many cases, the OOo spellchecker was prone to crashing.
By and large, our native spellchecker implementation caused support issues to immediately drop to a tiny fraction of the original volume. Sure there is the occasional issue with users who have corrupted cocoASpell and SpellCatcherX installations, but these same issues will not go away with your suggestion as the lack of OOo spellchecker's will cause it to merely drop through to our native spellchecker and they will get the same error.
OK. With your suggestion, the answer to the support post changes to "turn off the native spellchecker in the Tools :: Option dialog" instead of "follow these steps to remove your corrupted cocoASpell and SpellCatcherX installation". However, changing the answer really doesn't change the time involved for anyone and, in the current case, the end result is removal of a corrupted system add-on. In contrast, for a majority of our users, disabling the native spellcatcher means disabling spellchecking completely which means we now are back to the original support problem that we had before we had the native spellchecker.
No, I'm not suggesting to put OO.o spelling first in line.
On contrary, if it was up to me, I would set the default configuration as Apple speller enabled and OO.o disabled.
I'm also not referring to corrupted installations.
What I'm suggestion is that releasing two modules instead of one would not force Apple modules, but allow user to fine tune his preferences which spelling module to use and get best out of both.
I think I should also clarify the mapping suggestion. I use a 3rd party spelling for Estonian. Compared to the Hunspell module that comes with NeoOffice, it is much better.
Unfortunately Apple Spellchecker "hub" has limited support for language ID-name mapping, it does not translate "et" nor "et_EE" to "Estonian" in the UI. Therefore the spelling module identifies itself not "et" as it should, but "Estonian". Just to be more user-friendly in UI. It is no problem for any other software, but I can not use this module in NeoOffice unless I hack the language strings inside the module from "Estonian" to "et_EE". I tried to edit dictionary.lst to "DICT et EE Estonian", but it did not solve the issue.
If there was a way to define that for AppleSpell et_EE == Estonian, it would solve the case.
No, I'm not suggesting to put OO.o spelling first in line.
I wasn't clear in my last post so let me try again. If you have two separate spellchecker modules, the OOo code will always force Hunspell first. I found this limitation when I initially implemented the native spellchecker. The only way to get the native spellchecker to be first and still have Hunspell as a fallback was to implement the native spellchecker code as one module.
PRR2 wrote:
I think I should also clarify the mapping suggestion. I use a 3rd party spelling for Estonian. Compared to the Hunspell module that comes with NeoOffice, it is much better.
Unfortunately Apple Spellchecker "hub" has limited support for language ID-name mapping, it does not translate "et" nor "et_EE" to "Estonian" in the UI. Therefore the spelling module identifies itself not "et" as it should, but "Estonian". Just to be more user-friendly in UI. It is no problem for any other software, but I can not use this module in NeoOffice unless I hack the language strings inside the module from "Estonian" to "et_EE". I tried to edit dictionary.lst to "DICT et EE Estonian", but it did not solve the issue.
If there was a way to define that for AppleSpell et_EE == Estonian, it would solve the case.
What you want to do is not possible with Apple's spellchecking service. Apple's spellchecker APIs do not expose any list of installed spellcheckers and even if they did, there is no API to select a specific spellchecker. The only code that can do this is the native spellchecker dialog and all of the code that does that setting is private.
The only API that Apple exposes as to set the current locale. So, if your favorite spellchecker does not register itself with a specific locale or there is another spellchecker already registered to the desired locale, there is no way to set that spellchecker as the one in use via the existing Apple APIs.
Despite the limitations of the Mac OS X spellchecker APIs that I described in my previous post, there is one possible way to get your custom Estonian spellchecker to work with NeoOffice.
If your spellchecker responds to the et_EE locale, you might want to try adding the et_EE locale to NeoOffice using the steps in this NeoWiki article.
No, I'm not suggesting to put OO.o spelling first in line.
I wasn't clear in my last post so let me try again. If you have two separate spellchecker modules, the OOo code will always force Hunspell first. I found this limitation when I initially implemented the native spellchecker. The only way to get the native spellchecker to be first and still have Hunspell as a fallback was to implement the native spellchecker code as one module.
OK, I was not aware of that limitation. In the context of the new information I finally understand why you chose to implement spelling like you did.
About mapping -- it is clearly not NeoOffice fault that Apple half-implements its functionalities. I hope that some future versions of Mac OS Apple engineers will be able to use locale info functions instead of few hardcoded pairs
Anyway, thanks for listening and keep up good work!
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
