Future plans for SpellChecker?

[hwsoderlund]

Hi, I have just finished implementing spell checking for our product using RadSpellChecker. It works ok. We are however a little disappointed with the lack of good dictionaries. We have used some of the dictionaries available in this thread. Due to our limited language skills we can only comment on the danish and swedish ones, and they are not very good out of the box. I am wondering what your future plans for the component are. We are particularly interested in the following areas:

• Support for NHunspell and OpenOffice dictionaries, like you have for the asp.net RadSpell component.
• Custom providers, like in this example, where you demonstrate using the Google spell check API together with RadSpell. It would be great if we could at least move the spell checking logic to the server side, eliminating the need for 2-3 MB dictionary files to be downloaded to the client for each language that we want to support.
• More advanced support for word combinations. I am unsure of the terminology here, but in the Swedish language we use a lot of combined words, which is not very common in the English language. An English word combination like "lemon pie" consists of two separate words, whereas in Swedish such a word will be combined into a single word. The Swedish word for lemon is "citron" and the word for pie is "paj". But the combined word will be "citronpaj" rather than "citron paj". This causes problems with a lot of spell checking software, including RadSpellChecker. The component will actually suggest that you change "citronpaj" to "citron paj", which is plain wrong. Most spell checking software have word combination rules built into the dictionaries, but it seems that RadSpellChecker only supports dictionaries with a flat list of the allowed words. So my question is: Will you introduce support for more advanced dictionary rules, such as word combinations?

Best regards,
/Henrik

[Andrew]

Hello Henrik,

Thank you for the feedback on the dictionaries for spell-checking. All dictionaries except the en-US one have been prepared and uploaded by by our clients. We do not have that wide language skills either, therefore we have tried to provide an extensible approach for using custom dictionaries.

When it comes to OpenOffice dictionaries, we have considered extending the language support in that direction, but we haven't scheduled a date that the feature will be implemented. The same goes for introducing a customization option for the way word combinations (compound words) should be treated.

I have created a PITS issues which you can use to track our development plans on these matters.
Different file formats for RadSpellChecker: PITS Issue ID: 4162
Public Url: http://www.telerik.com/support/pits.aspx#/public/silverlight/4162

Compound words: PITS Issue ID: 8585
Public Url: http://www.telerik.com/support/pits.aspx#/public/silverlight/8585

If any other question occur, contact us again.

All the best,
Andrew
the Telerik team

[hwsoderlund]

Thanks for that. Good to hear that you are at least considering these features. The only thing you didn't comment on now was custom providers. What about those? It would be really nice to be able to tell our clients that they will be able to tap into the Google spell checking API in the future.

[Iva Toteva]

Hello Henrik,

There is a way to plug-in custom SpellCheckers by implementing the ISpellChecker interface and setting it to the SpellChecker property of RadRichTextBox. This point is included in our online documentation.

However, when it comes to scenarios such as using the Google spell checking API, we have not considered such extensions at this point, because it will take the spell-checking to the server, as opposed to the current client-side implementation. This will most probably cause performance issues due to the fact that requests will have to be transferred via WCF RIA services for each word in the document and will add little value to the feature.

I hope this answers your questions.

Greetings,
Iva Toteva
the Telerik team

[hwsoderlund]

Ok, thanks. I will look into the ISpellChecker interface and see what it can do.

As for the google API, couldn't the issues you refer to be solved with a cross-domain policy file on the hosting server. That would allow the client Silverlight app to communicate directly with the Google server. But I guess it would still complicate things, and I do see your point.

Thank you,
/Henrik

[Iva Toteva]

Hello Henrik,

Thank you for the follow-up. 
We will also research this scenario - if the cross-domain policy allows it and the performance is satisfactory. If that turns out to be the case, we will provide a demo of how this can be done. 

Best wishes,
Iva Toteva
the Telerik team