Checks/Issues

Locize helps you keep your translations high-quality and consistent by automatically performing a variety of checks. These checks identify potential issues, inconsistencies, and errors in your translations, making it easier to maintain accuracy and streamline your localization workflow.

On this page, you'll find an overview of possible issues, how to resolve them, and how to manage checks in the CAT (Computer-Assisted Translation) interface / Translation Editor.

How checks and issues are displayed

The CAT interface / Translation Editor will show warnings or errors on specific keys. For details, follow the link to the right-hand column for the selected key:

Running all checks for your project

You can run checks for a single segment on the right sidebar or for your entire project on the left side bar in the bulk actions:

In the bulk actions section, checks can be run for all segments or the currently filtered set. In the CAT interface / Translation Editor, checks run for the selected language and namespace.

Check this section in the video to see how Checks/Issues can be used.

Related: The deterministic checks on this page are complemented by Quality Estimation: an AI evaluator that scores the confidence of AI translations. Low-confidence AI translations can be found via the "by AI: needs review" state filter in the editor.

checks/issues part of showcase/demo

Ignoring checks

If a check is not relevant, you can use the eye icon button to ignore an error for a specific segment.

Generally ignoring checks

You can also generally ignore specific checks for your project. Go to your project settings, "EDITOR, TM/MT/AI, ORDERING" tab, and click the "Issues to ignore" section in the "Cat settings" card.

Consistency checks

Some checks, such as consistency checks, are performance-intensive and must be triggered manually.

Issue 220 - not consistent with the translation memory

This issue means another translation in the translation memory was translated differently. You can choose to update the translation for consistency or ignore the issue if the inconsistency is intentional.

Issue 250 - duplicate source value

Another key in your project already uses the exact same source value. This often happens when a generic term (for example "active") is added again as a new key instead of reusing the one that already exists, especially across a shared common namespace. The issue lists the other keys that share the value (up to 10 are shown), so you can reuse one of them and remove the duplicate, or ignore the issue if the keys are intentionally separate (for example when they need different translations depending on context).

Values shared by more than 25 keys are not flagged: reuse at that scale is considered intentional (for example recurring product attributes or badge labels), not an accidental duplicate.

Like the translation-memory check, this is a consistency check, so it is performance-intensive and runs only when triggered manually (for a single segment in the right sidebar, or for all or filtered segments via the bulk actions). Flagged keys appear under the warnings state filter in the editor.

Issue 260 - inconsistent translation of the same source value

Another key with the exact same source value is translated differently in this language (for example one "Save" key translated as "Speichern" while another one says "Sparen"). A term is rarely translated wrong everywhere but often wrong somewhere, so these disagreements are where mistranslations usually hide. The issue lists the other keys together with their differing translations (up to 10 are shown), so you can align them, or ignore the issue where the difference is intentional (the same source value can legitimately need different translations depending on context).

Only keys that are actually translated in the checked language are compared: an untranslated key does not count as a disagreement. Like the duplicate-source check, values shared by more than 25 keys are not flagged, and the check runs only when triggered manually (for a single segment in the right sidebar, or for all or filtered segments via the bulk actions). Flagged keys appear under the warnings state filter in the editor, which you can combine with the language filter to clean up one language at a time.

Check glossary consistency

Glossary checks are also performance-intensive and must be triggered manually. They only work if you have uploaded a glossary file in your settings.

Issue 230 - found forbidden term (glossary)

The translation contains a term that is forbidden in your project's glossary.

Issue 231 - inconsistent terms (glossary)

The segment matches a glossary entry in the source language, but no allowed term was used in the target language.

Check i18n syntax consistency

This check compares source and target translations for matching i18n syntax features (such as interpolation, nesting, etc.).

Issue 240 - detected i18n syntax inconsistency

The translation contains a different number of i18n syntax elements compared to the source.

Miscellaneous checks

Check exists in the source language

Issue 301 - is not found in the source language

The key was only imported into a target language. It is recommended to add the content in the source language as well.

This may also affect your translation statistics and the percentage of translated segments.

Check if the translation is up to date

Issue 302 - the content in the source language changed after translating to this target language

There was a change to the source content. The translation might be outdated or incorrect. Check if the provided translation is still valid.

If the translation is still valid, you can confirm it:

Do not forget to click the SAVE button after clicking CONFIRM.

Check for unused keys

Issue 303 - not used for a long time

This key was reported as used in your running application before, but not within the last year, so it may be safe to remove. It relies on the "last used" usage data you can report with the locize-lastused script or the API, so it only appears for projects that send this information.

Only keys that were reported as used at least once and then went quiet are flagged. Keys that were never reported are treated as unknown (they may simply not be covered by your usage tracking), so they are not flagged here; you can still find them via the "usage never reported" option in the editor's last-used filter. Always review before removing to avoid accidental data loss.

Like the consistency checks, this runs only when triggered manually (for a single segment in the right sidebar, or for all or filtered segments via the bulk actions).

Check if an overridden value (tenants, branches) is unnecessary

Issue 305 - unnecessary override when value equals value in source project

You can remove unnecessary overrides because the values in the tenant or branch, as well as the value in the parent project, are all equal. Use the matching bulk action under "misc" to remove all of these values at once.

Check max characters length

issue 310 - is longer than the defined max characters

In the source language, a max length is defined for this sentence, and the provided translation is too long.

Check for dangerous markup

Issue 312 - potentially dangerous markup

The value contains markup that could execute code when your application renders translations as HTML: <script>/<iframe>-class tags, event-handler attributes (onclick=…), javascript: or data:text/html URLs, or srcdoc attributes. These are reported as errors: if you render translations without escaping (for example dangerouslySetInnerHTML, v-html, or i18next with escapeValue: false), a translator account could otherwise inject executable content into your application.

The check also warns when a translation adds markup that the source text never had, since that is how injected markup usually starts. If your target languages legitimately add markup (rare), ignore the issue for those segments or the whole check.

This check runs on source and target languages alike, so a compromised source value is caught too. Detection does not block saving: the review workflow and member roles remain the primary protection against malicious content.

Linguistic checks

These checks compare the translation text itself against the source and run automatically, like the syntax checks. They are locale-aware by design: CJK fullwidth punctuation and brackets count as equivalents, dropping a terminal period is accepted as zh/ja style, French spacing before !?;: is never flagged, locale number formats (1,000.50 vs 1.000,50) and Eastern Arabic digits compare as equal, and languages without letter case are skipped by the case check. All linguistic issues are warnings; use the ignore options above if one does not fit your content.

Issue 401 - terminal punctuation differs

The translation ends with different punctuation than the source (for example a dropped trailing colon or question mark). For Spanish, a sentence ending in ? or ! is also expected to contain the inverted ¿/¡ mark.

Issue 402 - first-letter case differs

The translation starts with a different letter case than the source. Only sentence-like values are compared (headline fragments and list labels legitimately differ per language), and conventions such as German noun capitalization are respected.

Issue 403 - numbers differ

A number that appears in the source is missing from (or different in) the translation. Locale formats, Eastern Arabic and fullwidth digits, and 12h/24h time conversions ("9pm" → "21 Uhr") are treated as equal. Digits inside interpolation placeholders are ignored.

Issue 404 - bracket counts differ

The translation has different bracket counts ()[]{} than the source (fullwidth CJK brackets counted as equivalents). Brackets added by the translation when the source has none (for example zh clarifications like （FPS）) are not flagged.

Issue 405 - unbalanced brackets

The translation contains an unclosed or mismatched bracket while the source is balanced (a mirrored emoticon like :( in both is fine).

Issue 406 - whitespace issues

The translation contains doubled spaces, or its leading/trailing spaces differ from the source (relevant for values that are concatenated in your application). Non-breaking spaces used by French typography are never counted as doubles.

Issue 407 - repeated word

The translation contains the same word twice in a row ("the the"). Legitimate doublings such as French reflexives ("nous nous …") or German article sequences are excluded, and languages written without spaces are skipped.

Issue 408 - special characters differ

Characters like © ® ™ ° § appear in the source but not the translation (or vice versa). Currency symbols and & are deliberately not compared: $100 → 100 USD and & → "and"-words are correct localization.

Issue 409 - URL count differs

The translation contains a different number of URLs than the source (both visible text and link attributes are counted). A changed URL is accepted: localized links legitimately differ.

Issue 410 - HTML tags differ

The translation's HTML tags (including react-i18next component tags like <0>…</0>) do not match the source: a tag is missing, added, or broken. A broken tag usually renders as literal text for your users.

File checks

Invalid Nesting

issue 420 - gets nested into another string

This issue exists if there is a key eg. key.nested that would be nested into another key key. The result in a JSON export would then be:

{
  "key": "value"
}
// or
{
  "key": {
    "nested": "value"
  }
}

So you would lose one of the keys in your export. To solve this issue rename one of the keys.

Check array size

issue 430 - check for array issue

The key is in form key.10001 which leads to exporting as an array (eg. in the JSON format). Having such a key would result in the creation of an array with the given number. This check asserts array sizes stay in a limited size (below 100).

You can avoid the conversion of the content to an array by providing a key that has a non-numeric end like key.aString.