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

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.

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

Thanks guys, yes, I realise this now.


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

Yes, try the following regex:


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

Cool, thanks Igor!

A small RFE, can we also have:

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


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"?



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

1. Thanks!

2. Bedankt!

3. Gracias!

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)

> How should I solve this?

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

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?

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

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".

Login to post a comment