"Found Actions". When a potential error is identified the following actions should be available:
Ignore current instance of identified error
Ignore all occurrences of identified error
Replace current instance of identified error with auto-suggestion or user supplied word
Replace all instances of identified error with auto-suggestion or user supplied word
Replace all instances of all identified errors with auto-suggestions or user supplied word
Save identified error as new dictionary entry
Save current instance of identified error as ITS annotation
Save all instances of identified error as ITS annotations
Save all instances of all identified errors as ITS annotations
User can spellcheck only the current active translation. When a potential error is found the "Found Actions" are available.
User can spellcheck all translations in the whole document. When a potential error is found the "Found Actions" are available.
Dictionary language is configured from target language attribute of File element.
All available language dictionaries are shipped with Ocelot.
In relation to the spelling.txt file: Naturally enough there is many of them, one for each language and they reside in the same folder as the relevant Hunspell dictionary. Per this support thread it is not possible to interact with this file through the API or directly whilst LT is running but perhaps there's a cludge.
Thanks, nice research. I wonder if it's possible to rebuild the dictionary.
I'm pasting in some questions from Aaron with responses (as I'm able) inline:
The ticket mentions saving errors as ITS annotations; what is the intended UI for doing this? I ask because the dialog mock up didn’t have a button for this.
Good point, this was lost in the screenshot. I assume the idea was that unresolved errors are encoded as ITS for later handling. So do we need a "Treat as error" button?
PR: see new image "spelling.png" Add ITS just adds annotation for the current found instance and Add ITS All adds annotations for all instances of that word. The locQualityIssueErrorType attribute value should be "spelling" and the locQualityIssueErrorSeverity value should be whats set in the spinner.
If the dialog is not modal then there is some complexity to deal with: unlike with the LQI Grid dialog (which Phil mentioned as an example), the dialog and the table cell will represent different views of the same data, so they need to be synchronized, and some care needs to be taken to ensure that changes to one don’t have surprising effects on the other.
I note that Word “pauses” spellcheck when the dialog loses focus, and “resuming” it essentially seems to start over (which seems a bit of a cheat making it “almost modal”). I think following this model should make things a lot easier; is that acceptable?
This seems like a reasonable compromise to me, but I want to see what Phil thinks.
You describe the process as “incremental”, but I assume that the LT spellchecking logic is run on all segments up front, and all issues are highlighted at once throughout the document (like the Find and Replace dialog hits). Is that right?
Yes, that's fine.
PR: Yes, fine.
I’d like to reuse the Find and Replace highlighting system. That means that navigating spelling issues does not open segments for editing (this helps with the synchronization complexity mentioned earlier), and also that highlighting does not need to be shown if the user opens the segment for editing.
This sounds ok to me.
You said "closing the dialog stops the process”; does this discard spellcheck highlights? My gut says it will be simpler to discard them, except perhaps for issues persisted as ITS annotations.
I think it won’t be realistic to “learn” words (as opposed to ignoring them). Even assuming there was a public API, looking at the source for LT’s SpellingCheckRule, it claims to distinguish between ignored and learned words, but it actually puts them all in the same set and does not seem to consult the set for suggestions at all.
It sounds like the only way to 'learn' the word is to add it to that spelling.txt file. So this may just not be practical until LT gets improvements.
In Phil’s dialog, what does “Learn Replace” do?
Good question – ? Given that the bottom row for the other buttons are global versions of the top row, my guess is that it's "Learn this word + Replace all instances of this error".
PR: Yes, my original intention was "Learn this word + Replace all instances of this error" but in retrospect if the learnt word appears again you can just use Replace All then.
Thanks for the comments, everyone.
Regarding "Learn Replace": I would assume that once a word has been learned, all other instances of that word would no longer be considered errors. In other words "Learn" would do what you called "Learn Replace", and there would be no single-instance "Learn".
I agree so have removed the Learn Replace button in the updated dialog design captured in spelling.png.