Start a new topic

Resources > Abbreviations > Scan project for abbreviations: also find things like NVWA, and CJIB?

Hi Igor,

Is there any way to make Resources > Abbreviations > Scan project for abbreviations also find stuff like NVWA, and CJIB?

This would be very useful as I always do a scan of the complete project before starting, looking for any abbreviations that might cause trouble along the way.


1 person likes this idea

OK, that's what I've been doing so far, as a work-around. The issue is that the spell-checker is non case-specific, so by adding an abbreviation to the spell-checker, it will diminish it's "power" to detect potential spelling mistakes. For instance:

(english source) UN

(italian target) ONU

issue: by adding onu to the spell-checker, the spell-checker will stop detecting typos for its related word "uno", a very common word meaning "one".

Then, if your abbreviations have the translation in the target language and you wish to have them ignored by the spell-checker, you also need to add them to the spell-checker dictionary. 

1 person likes this

Add them to the glossary as non-translatables even if they appear in target and not source? So non-translatables would be a non-language specific "glossary", is that what you mean?

> How should I solve this?

Try adding such words to the glossary as non-translatables to ignore them by the spellchecker.

Igor, you say that these kinds of abbreviations are non-translatables, and ok with that, but: non-translatables should then appear in target, whereas almost all abbreviations (at least in my work experience) have a translation to target. For instance: NATO/OTAN, UN/ONU, etc. However, they will be marked as wrong spellings in target. So much so that I'm still not using the spell checker function accordingly, because it detects a much higher proportion of abbreviations than of "normal" words. How should I solve this? (consider that abbreviations might be similar to normal words, so I wouldn't want to add abbreviations to the dictionary, to then miss the spell-check on those words; I also would like to add them to a glossary — and it would be cool if it were case-sensitive for them — in order to perform term consistency checks at the end)

1. Thanks!

2. Bedankt!

3. Gracias!

1. Yes, for regular expressions only.

2. Yes. It is available in the Filter menu in the latest update.

3. We need to distinguish between Non-translatable segments and fragments.

1 person likes this

Hi Igor, two questions, well three:


1. Do you need to add the pipe character when adding things to the Non-translatable fragments list? So: |\b[A-Z]{2,4}\b or \b[A-Z]{2,4}\b

2. Can we also have: Resources > Non-translatable fragments > Scan project for Non-translatable fragments

3. Rename "Non-translatable fragments" to "Non-translatables"?



Cool, thanks Igor!

A small RFE, can we also have:

Resources > Non-translatable fragments > Scan project for Non-translatable fragments


Yes, try the following regex:


It will catch upper-case words with minimum 2 characters but no more than 4.

Thanks guys, yes, I realise this now.


So it looks like I need a regex in Resources > Non-translatable fragments to catch this stuff.

Scanning abbreviations is to determine the points in segments where CafeTran performs automatic joining, so your two examples do not fit into this category. They are rather non-translatables fragments which are handled via Resources > Non-translatable fragments.

1 person likes this

Have a look in the old Google group, if I remember correctly the necessary regular expressions (hi Hans!) for non-translatables have been discussed there.

Login to post a comment