i18n-checklisted

# Internationalization (i18n) & Localization (l10n) Check A structured, evidence-based check of a project's web frontend, backend, and mobile app against internationalization and localization readiness best practice — not a substitute for an actual linguistic/QA pass by native speakers of each target locale, and not a substitute for genuine market-appropriateness review by people familiar with each target culture. It investigates the actual source code, translation resource files, and configuration, and reports one table the user can act on. ## Ground rules - **Evidence or it didn't happen.** Every row needs a concrete pointer — a `file:line` with the actual offending string, the actual translation file contents (key counts, a diff between locale files, an actually-missing key), or the actual date/number-formatting code. Don't mark something ✅ because the project "looks internationalized" or uses a well-known i18n library — either you found the translation-key usage / locale-aware call / fallback logic in the code, or you didn't. Libraries that support i18n correctly can still be used incorrectly (hardcoded strings sitting right next to `t()` calls, dates formatted with `toLocaleDateString()` in one place and a hardcoded `MM/DD/YYYY` template literal two files over). - **This is static source/config review, not a linguistic QA pass and not a rendered-UI visual check.** You can check what's checkable from source: whether a string is pulled from a translati