Quality checks and glossary

Two things keep a translation honest: the automatic checks that catch mechanical mistakes, and the glossary that settles what a term is called. Both live at workspace level and apply to every project in it.

Automatic checks

Ownlate compares the translation against its source and reports what it finds. The check runs in the editor’s QA tab as you work, and on demand over the API.

Check	What it means
missing_interpolation	A placeholder present in the source is absent from the translation
extra_interpolation	The translation contains a placeholder the source does not have
missing_html_tag	An HTML tag from the source occurs fewer times in the translation
extra_html_tag	The translation has more of a tag than the source does
trailing_whitespace	The translation ends in whitespace
same_as_source	The translation is character-for-character the source text
forbidden_term	A glossary term marked forbidden occurs in the translation
custom_regex	One of your own rules matched

Placeholders are recognised in three shapes, which covers every common i18n library:

{name}      {{count}}      ${user}      %s   %d   %i   %f   %g

HTML tags are compared case-insensitively and by count, so swapping <b> for <B> is fine while dropping one of two <br> is not.

Note

The checks report; they do not block. Saving, submitting and approving all work with issues outstanding — the point is to put them in front of the reviewer, not to make the translator fight the tool. A hard requirement belongs in your review process, not in the editor.

Your own rules

Workspace → QA rules holds regular expressions that are checked against the translation text alongside the built-in list.

Field	Notes
Name	Up to 100 characters, for you to recognise it
Pattern	A regular expression, up to 500 characters. Lookahead and lookbehind are supported.
Message	What the translator is shown when it matches, up to 500 characters
Severity	error or warning — a label on the rule
Projects	Leave empty to apply the rule to every project, or list the project IDs it applies to

A rule matches when the pattern occurs in the translation. Write patterns for what must not appear: two spaces in a row, a straight quote where the language wants a typographic one, a currency symbol on the wrong side of the number.

A pattern the engine cannot compile is skipped rather than raising an error on every segment, so a typo in one rule never stops the rest from working.

Glossary

The glossary is the workspace’s terminology. Each entry belongs to one source language and describes one term.

Field	Meaning
term	The word or phrase in the source language
definition	What it means here — the disambiguation a translator needs
translations	The preferred translation per target language
partOfSpeech	noun, verb, adjective or other
caseSensitive	Whether Apple and apple are the same term
forbidden	Marks a term that must not appear in translations

How it shows up while translating

When a segment is open, Ownlate looks for glossary terms in its source text and highlights the ones it finds. Hovering a highlight shows the definition and the preferred translation for the language being worked on, so the decision is made once, in the glossary, rather than again in every string.

Terms marked forbidden are checked the other way round: they are looked for in what the translator typed, and reported as a forbidden_term issue. This is how you keep a competitor’s brand name, a deprecated product name or a word your style guide bans out of your product.

Choosing what goes in

A glossary that lists every noun is ignored; a glossary of thirty entries is read. Good candidates:

• Product and feature names, with a note on whether they are translated at all.
• Words your industry uses in a specific sense — a ticket, a board, a release.
• Terms with several plausible translations, where consistency matters more than the choice itself.
• Anything you have already corrected twice in review.