Skip to content

docs(LC0091): describe compiler-parity obsolete handling #191

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Arthurvdv merged 1 commit into from
Sep 27, 2026
Merged

docs(LC0091): describe compiler-parity obsolete handling #191

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion content/docs/analyzers/LinterCop/LC0091.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ linkTitle = 'LC0091'
severity = 'Warning'
category = 'Design'
codeAction = false
ignoreObsolete = true
ignoreObsolete = false
+++

Properties like Caption and ToolTip, as well as Label variables, are translatable by default — the compiler generates a unique translation ID for each one. For users in other locales to see translated text, each ID must have a matching `<trans-unit>` entry in the project's XLIFF files. When the entry is missing, empty, or still marked `needs-translation`, those users see raw source-language text instead: a caption that should read *Programnavn* in Danish displays as *Program Name*.
Expand Down Expand Up @@ -67,9 +67,13 @@ For extension objects, translation IDs are generated relative to the translation
The rule does not trigger when:

- The label or property has `Locked = true`. This is the intended mechanism for text that should remain in the source language — API field names, technical identifiers, or format strings.
- The caption belongs to a table or field with `ObsoleteState = Removed`, or to a field inside such a table. The compiler locks these trans-units and drops them from the generated XLIFF, so no translation is expected.
- The element sits inside an object with `ObsoleteState = Moved`. The compiler does not visit a moved object at all.
- No XLIFF files exist in the `Translations/` directory.
- The project manifest does not include `"TranslationFile"` in the `features` array.

Elements with `ObsoleteState = Pending` are still reported. The compiler only locks trans-units for `Removed` tables and fields, so a pending caption keeps its `translate="yes"` entry in the XLIFF and needs a translation until it is removed. Label variables and report labels inside an obsolete object are reported as well, whatever the object's state: the compiler never locks a label because of its containing object, only because of the label's own `Locked = true`. A label left behind in a removed table keeps appearing in the translation file until it is locked or deleted.

When a translatable property cannot use `Locked` but should remain untranslated, suppress with a pragma:

{{< highlight al >}}
Expand Down
Loading