Start a new topic

Feature: scan for candidates for non-translatables en give suggestions for regex

And now for something very complicated to code but very easy to use for the Anwender:

A feature to scan for candidates for non-translatables en give suggestions for regexing them.

Of course we already have this:


Defining non-translatables before you actually start translating, has the advantage that automatic placing of surrounding tags (tags surrounding these non-translatables) will be optimised. Thus saving time, increasing your productivity, in an ever changing world, where DeepL C.S. is having negative effects on the amount of offered work and prices per unit.

Another advantage of scanning your source text on beforehand, is that you can mask brand names, product names, product types etc. before you start sending any info to the internet (MT etc.). You could hide geographical names like towns (create a list with towns where your clients are). You could create a regex for postal codes or for your towns and the corresponding postal codes. You could create a regex for street names plus numbers. Luckily, these are often listed on the title or following pages of your source document. And you only have to add them once to your non-translatables glossary. With each new assignment, you’ll have to add less NTs. Your source texts will start looking all purple, which of course is a nice colour. Heck, the more purple fragments you have, the less typing you’ll have to do yourself. There are many words that have no rhyme in the English language. "Orange" is only the most famous. Other words that have no rhyme include: silver, purple, month, ninth, pint, wolf, opus, dangerous, marathon and discombobulate.
Login to post a comment