localization Shipped
What this lens looks for
Every user-facing string MUST be localizable — flag any hardcoded literal that reaches the UI; strings must live in platform-standard resource files and be referenced through the platform's localization API, never inlined. On Swift, expect String(localized:) (Swift 5.7+) or NSLocalizedString, with strings stored in .xcstrings (Xcode 15+) or .strings; on Kotlin, expect strings.xml resources referenced via R.string.* in code or stringResource() in Compose; on TypeScript, expect an i18n library (react-intl, i18next, FormatJS) with all user-facing strings extracted into message catalogs; on Windows, expect MRT Core with .resw resource files, the x:Uid directive in XAML binding control properties (e.g. x:Uid="SaveButton" maps to SaveButton.Content, SaveButton.AutomationProperties.Name) to resource keys, a Strings/<language-tag>/Resources.resw folder structure (e.g. Strings/en-US/Resources.resw), and code-behind access via Microsoft.Windows.ApplicationModel.Resources.ResourceLoader.
What its verifier checks
No hardcoded user-facing string literals appear in source — every displayed string resolves through a resource file; Swift uses String(localized:) or NSLocalizedString with strings in .xcstrings or .strings; Kotlin uses strings.xml referenced via R.string.* or stringResource(); TypeScript routes all user-facing strings through an i18n library (react-intl/i18next/FormatJS) extracted into message catalogs; Windows uses .resw files with x:Uid binding in XAML, the Strings/<language-tag>/Resources.resw layout, and ResourceLoader for code-behind access.