I'd like an 'ignore all' option during spellchecking. (As opposed to the 'add to dictionary' option we currently have [unless I've misunderstood])
The point being, that often words (e.g. company names) are acceptable in specific projects, but shouldn't be added to the dictionary, as they shouldn't be accepted in other projects.
Alternatively, if this is what we already have, then I want an 'add to custom dictionary' option.
One other thing on spell-checking - it would be great if the list of incorrectly spelt segments during QA would automatically update after confirming the validity of a word marked by CafeTran as misspelt. (i.e. all other segments listed solely because they contain the word which has just been accepted would drop off the list).
>That turned into a bit of a shopping list.
Don't worry, CafeTran's feature agent will pop in soon.
BTW: Are you sure that Hunspell supports the features that you request? That would be your first thing to check.
Igor's a magician but he cannot break iron with his bare hands.
If, by "Ignore all", you mean turning off the spell-checker for the given project, you can do it in Project Configuration > Preferences > Spell-Checker box as you create a new project. Also, note that non-translatable fragments from the list (e.g. company names) are ignored by the spell-checker.
Then select and add such a product name to non-translatables to have it ignored by the spell-checker.
> Or are non-translatables project-specific?
Yes, they can be made project-specific if you create a separate glossary of non-translatables just like the regular glossary.
These non-translatables glossaries usually do what they were designed for, so I have quite a lot of them now already.
There is, however, the case where you have/want to change the case of a non-translatable in the target. Then the spelling of the non-translatable isn't ignored.
Hence my request to look into the possibilities to make these non-translatables glossaries (can't we come up with a nicer name?) really ignoring case.
IK: Yes, they can be made project-specific if you create a separate glossary of non-translatables just like the regular glossary.
In that case, why not add the non-translatables to the Project file? That should have the highest priority, so there can't be any problems.
I admit I don't use non-translatable glossaries at all because I think they're complete bull.
You can even add a non-translatable entry to the Project Glossary by preceding the entry with the ! character to distinguish it from regular entries.