Summary
Key Takeaway: Use a language‑independent identifier instead of relying on the human‑readable category string. This makes queries work across localized schemas.
Root Cause
The schema stores category as a localized display value. When a model is created in a non‑English locale, the property definitions use the translated term, so a literal search for "Identity Data" fails.
Why This Happens in Real Systems- Localization pipelines replace display strings but keep the underlying identifiers unchanged.
- The REST API returns the display name, not a canonical code.
- Consumers often perform direct string matches without normalization.
Real-World Impact
- Queries break on multilingual models.
- Debugging requires manual mapping tables.
- Production pipelines become brittle when new locales are introduced.
Example or Code“`javascript
// Use the canonical category identifier instead of the localized label
const CATEGORY_ID = ‘identityData’; // defined once in a shared enum
const propDef = schema.attributes.find(p =>
p.fam === ColumnFamilies.Source &&
p.categoryId === CATEGORY_ID &&
p.name === ‘Type Name’
);
## How Senior Engineers Fix It
- Store a **fixed identifier** (e.g., `categoryId` or a numeric enum) alongside each attribute definition. - Translate only for UI; keep the identifier immutable.
- Query using the identifier, optionally fallback to localized label if identifier is missing.
## Why Juniors Miss It
- They assume UI strings are stable across releases.
- They perform direct string comparisons without checking for a stable identifier.
- Documentation often highlights the display name, overlooking the underlying code.