What problem does it solve? Maintaining a bilingual (ES/EN) Next.js site with next-intl 4 and Sanity localeString/localeText fields involves many non-obvious conventions: which strings belong in messages JSON versus Sanity, how to query localized fields with fallbacks, and how to avoid cryptic build and migration errors. This Skill captures all of those project-specific rules so changes to translations, pages, and schemas stay consistent. ## Core Features & Use Cases - Content placement policy: Defines exactly which strings live in messages/*.json (a11y labels, ICU plurals, generic errors) versus Sanity singletons (editorial copy), preventing misplaced translations. - Implementation patterns: Provides copy-ready patterns for adding UI strings, creating locale-aware pages with setRequestLocale, and converting Sanity schema fields to localeString/localeText with triple-coalesce GROQ projections. - Troubleshooting guides: Documents fixes for Sanity MCP patch conflicts, Next 16 middleware-to-proxy rename, and Turbopack cache desync causing 500 errors. - Use Case: When adding a new bilingual page or making a Sanity field translatable, follow the documented patterns to update schemas, queries, messages, sitemap, and Studio language filtering without breaking either locale. ## Quick Start Use the i18n-next-intl skill to add a new translatable field to a Sanity schema and wire it through the queries and frontend for both ES and EN locales.
