Should slugs be translated in Sanity translation template?

You're not missing anything – you're actually asking a great question! The archived sanity-template-translation-examples repository demonstrates two main localization approaches but doesn't explicitly handle translated slugs in the examples. This is actually intentional, and here's why:

Why Slugs Often Aren't Translated

For Document-Level Translations: When using the @sanity/document-internationalization plugin, each language version is a separate document. This means each document can (and should) have its own unique slug field. The template doesn't need special handling because the slug is just another field on the document – it's naturally independent per language version.

For Field-Level Translations: When using field-level translation (objects or arrays), slugs typically aren't translated because:

1. SEO and URL Structure: Many sites use a single canonical URL structure with language parameters (/en/article vs /es/article) rather than translating the slug itself
2. Complexity: Slugs need to be unique, and managing uniqueness across multiple languages within the same document adds significant complexity
3. Routing: Most frameworks handle i18n routing through path prefixes or subdomains rather than translated slugs

If You DO Need Translated Slugs

With @sanity/document-internationalization: Just add a regular slug field to your schema – each language document gets its own slug automatically. The Sanity docs on localization show this pattern in the "post" example schema, where the slug field exists on each translated document.

With field-level translations (using internationalized-array): You can make the slug field internationalized just like any other field. However, you'll need to handle uniqueness validation yourself, as Sanity's built-in slug uniqueness validation doesn't work across internationalized arrays.

Best Practices

The Sanity documentation recommends:

• Document-level translations are best when you need unique slugs per language (and for Portable Text content)
• Field-level translations work well for shared content structure where only certain fields differ

The template focuses on the core localization patterns, leaving routing and URL structure decisions to your specific front-end implementation. It's not an oversight – it's acknowledging that slug translation requirements vary significantly between projects, and most implementations handle this through routing strategy rather than translated slug fields.