Support I18n #58

narr07 · 2025-02-16T07:32:47Z

I wish it could have a language changer feature

rusbers · 2025-02-16T07:40:09Z

That would be a great feature for this template

alioftech · 2025-02-21T11:41:32Z

This would be amazing!

nuotsu · 2025-02-22T00:49:59Z

Hi everyone, here's the approach I'm considering and would appreciate your opinions/feedback.

Firstly, i18n is complex and there's no easy and correct way of implementing (my excuse haha 😅). However, it's been frequently requested so I'll be taking a stab at it.

I'm deciding on a "page-level" localization approached, as opposed to a "field-level" one. Setting up a translation input/textarea for all/some fields would be way too much (for me and for users). I'd rather just have users duplicate a page, and replace the necessary values with the updated translations.

PROs:

easy as duplicating documents to add new translations
no need to set up translation fields

CONs:

content changes in either the original or translated would have to be copied over.

Proposed `language` document

Proposed `page.language` and `page.original` fields

I'm thinking to add a language and original field for Page and Blog post documents, that reference a Language document from above and the original ("translated from") document, respectively.

Proposed URL pattern

I assume we all can agree on the URL structure for translated pages would be to prepend the language code. I will also add the HTML lang attribute to the <body> tag upon implementation.

https://mywebsite.com/<lang>/<parent>/<slug>

# e.g.
https://sanitypress.dev/ja/  # index
https://sanitypress.dev/en-US/docs
https://sanitypress.dev/blog/fr/my-sample-blog-post

FYI — page.parent was introduced in v6.4.0

Do let me know your thoughts, suggestions, possible concerns, etc. I'm all ears👂

alioftech · 2025-02-22T10:02:45Z

Just sharing my experience with a non sanity translation project I worked on recently. That is www.xaxameme.com

The website supports about 5 languages and I had a few challenges with the localisation.

There are some languages that are RTL like Arabic so I needed to support that in the code. When the locals was Arabic. Later I used the next-intl package which was not optimised for nextjs 15 which made some things difficult. Also supporting multiple sitemaps for each language was also a thing.

I did research doing this for sanity and I was looking at the @sanity/document-internationalization as it's the official one. I imagine that there would just be some minor changes to the code base needed. Using an official plugin might be better than maintaining the functionality alone ?

Btw I'm happy to test and feedback the languages I know when gone a bit further

nuotsu · 2025-02-23T22:36:05Z

Thanks so much for your feedback @alioftech!

I've just pushed a new branch i18n (see commits here) using the @sanity/document-internationalization plugin.

Changelog

⚠️ Breaking: using optional catch-all route (app/[[...slug]]/page.tsx) 3d42adb
- replaces the page.tsx (homepage) and [...slug]/page.tsx (dynamic route)
add lang attribute to the <html> tag c8f65ce
Language Switcher (added to the site footer) 7d66d37
- adds a lang cookie for use in middleware
middleware for auto-redirecting existing/non-existing pages c83b375
auto-generated hreflangs meta tags 3ee9dd5

Config

// src/lib/i18n.ts

export const supportedLanguages = [
  { id: 'en', title: 'English' },
  { id: 'ja', title: 'Japanese' },
  // { id: 'fr', title: 'French' },
] as const satisfies Language[]

// sanity.config.ts

import { supportedLanguages } from '@/lib/i18n'
import { documentInternationalization } from '@sanity/document-internationalization'

export default defineConfig({
  plugins: [
    // ...
    documentInternationalization({
      supportedLanguages,
      schemaTypes: ['page', 'blog.post'],
    }),
  ],
})

Screenshots

@sanity/document-internationalization plugin

Language Switcher component in the footer:

If all looks good and I get some more feedback, if any, I prepare to be added in the next major version of Sanity (v6.5 or v7.0?)

wild2008 · 2025-02-24T01:51:55Z

@nuotsu I had the pleasure of seeing your work on i18n today, and I think it is definitely very good and very big news because you listened to the voice of the community.

I agree with your idea of unified page-level translation. For i18n, I have a few expectations for your reference:

For the default language, remove the language prefix in the URL. For example: English is the default language, use /about directly instead of /en/about.
Different languages of a page may use different slugs, such as English: /product/product-name, French: /fr/produit/nom-du-produit.
After clicking the language switcher on a certain page, switch to the URL of the corresponding language. If it does not exist, jump to the homepage of the corresponding language.
For the URL of Global modules, I prefer:

https://sanitypress.dev/blog/fr/my-sample-blog-post

to >

https://sanitypress.dev/fr/bloguer/mon-exemple-de-blog-post

In addition, for the text labels on the page, how are they translated? For example, there is a file similar to messages/en.json in next-intl.

Finally, if you can set up multiple languages like this, does it mean that you only need to maintain one branch? Because it can support both one language and multiple languages.

nuotsu · 2025-02-25T00:52:55Z

@wild2008 Thanks for your detailed feedback! To answer your points:

For the default language, remove the language prefix in the URL. For example: English is the default language, use /about directly instead of /en/about.

That's my intention:

if en is the default, the URL should not be prefixed.
if a users visits a URL with the default prefix (/en/blog), the middleware should redirect to the unprefixed URL (/blog)

(FYI the default defined as: the first item in the supportedLanguages config)

Different languages of a page may use different slugs, such as English: /product/product-name, French: /fr/produit/nom-du-produit.

I've updated the LanguageSwitcher component and the middleware to account for this.

You can now set different URLs for the same page, for each language. 12b7206

After clicking the language switcher on a certain page, switch to the URL of the corresponding language. If it does not exist, jump to the homepage of the corresponding language.

My personal take: as a user I would want to stay on the same page even if the translation doesn't exist, rather than being redirected to the Homepage.

I added a disabled state to the LanguageSwitcher options, for non-existent translations, so at least they know the translation is not available. d728be5

For the URL of Global modules, I prefer: //blog/*

Setting a different name for the /blog/ portion of URLs is rather tricky... I'd need to set up separate dynamic routes for each occasion. At that point, I'd have the developers set that up themselves. I'm planning to write a detailed blog post for advanced configurations that could include this setup.

In addition, for the text labels on the page, how are they translated? For example, there is a file similar to messages/en.json in next-intl.

If you are referring to the actual translations, those are done within the actual page document. It's essentially a duplicate of the original page/blog.post document so all the existing fields/labels are there to be updated.

Finally, if you can set up multiple languages like this, does it mean that you only need to maintain one branch? Because it can support both one language and multiple languages.

I can maintain this as a single branch. Everything should still work whether additional languages or zero languages are configured in the src/lib/i18n.ts file. ceec7ae

alioftech · 2025-02-25T15:09:01Z

Looking great!

wild2008 · 2025-02-26T02:10:31Z

@nuotsu I have to say that your solution is very practical. Only about point 3, a practical scenario is:

A visitor enters a landing page, he finds the entrance to other languages through the language switcher, then he only needs to click to enter the website in other languages (if there is a translation of the current page, it is better, if not, he can also view other pages in that language).

If the status is set to unavailable, the language switcher loses the function of the international version entrance.

nuotsu · 2025-02-26T02:36:22Z

@wild2008 Thanks again for reviewing! I do recognize the advantages of your approach. I will investigate the possibility of implementing options in the middleware to accommodate both approaches.

FYI, the LanguageSwitcher component sets a language cookie when an alternative language is selected. The middleware will read this cookie and display the translated page, falling back to the default language if it is not present.

In the event that the user navigates to subsequent pages, the middleware will persist in attempting to display the translated page (the selected language stored in the cookie).

As soon as the LanguageSwitcher is invoked and an alternative language is selected, the aforementioned process will be repeated.

wild2008 · 2025-02-26T13:45:10Z

@nuotsu I mentioned earlier that there are files like message/en.json in the next-intl project. My question is: for example, text like "Page not found" has different expressions in different languages. How to achieve multi-language translation in SanityPress?

nuotsu · 2025-02-27T00:42:46Z

@wild2008 I'm not sure if I can find any areas in the codebase where there is static text. All copy should reside in the Sanity Studio, including the 404 page (this is a Page document with slug 404).

That said, I likely won't add a .json based translation in the initial release (this may change in the future if it's requested by more users or if it's needed at all).

@wild2008 On a separate note, I couldn't find any contact details on your profile... Would you kindly reach out to the SanityPress email ([email protected])? I would like to share some special details with you, if you may!

wild2008 · 2025-02-27T07:14:20Z

@nuotsu I have sent you an email and I am happy to contact you via email.

nuotsu · 2025-02-28T23:26:00Z

@wild2008 As for suggestion on translating static text, such as in the Search module etc., I will make the "suggestion" of implementing 3rd party plugins like next-intl. I've prepared a blog post that gives a brief configuration write-up on this.

The example with the Search module gets quite dynamic (since I use concepts like search scope [pages, blog posts, etc]) so storing this in Sanity could get a bit bloated, hence I've put in only in the Next.js frontend. Anything static that can be in Sanity, should be in Sanity for easier translations.

nuotsu · 2025-03-06T03:09:07Z

I'm thrilled to announce i18n is now supported in SanityPress v7.0.0. See SanityPress Pro for details.

mitchuman added the 🧰 feature request label Feb 17, 2025

nuotsu assigned nuotsu and mitchuman Feb 22, 2025

nuotsu added the ⏳ pending Awaiting response from issuer(s) label Feb 22, 2025

nuotsu moved this to In Progress in SanityPress 2049 Feb 23, 2025

nuotsu added this to SanityPress 2049 Feb 23, 2025

nuotsu added the 🏃‍♂️ in progress label Feb 24, 2025

nuotsu closed this as completed Mar 6, 2025

github-project-automation bot moved this from In Progress to Done in SanityPress 2049 Mar 6, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support I18n #58

Support I18n #58

narr07 commented Feb 16, 2025

rusbers commented Feb 16, 2025

alioftech commented Feb 21, 2025

nuotsu commented Feb 22, 2025 •

edited

Loading

alioftech commented Feb 22, 2025 •

edited

Loading

nuotsu commented Feb 23, 2025 •

edited

Loading

wild2008 commented Feb 24, 2025 •

edited

Loading

nuotsu commented Feb 25, 2025 •

edited by mitchuman

Loading

alioftech commented Feb 25, 2025

wild2008 commented Feb 26, 2025 •

edited

Loading

nuotsu commented Feb 26, 2025

wild2008 commented Feb 26, 2025

nuotsu commented Feb 27, 2025 •

edited

Loading

wild2008 commented Feb 27, 2025

nuotsu commented Feb 28, 2025

nuotsu commented Mar 6, 2025

Support I18n #58

Support I18n #58

Comments

narr07 commented Feb 16, 2025

rusbers commented Feb 16, 2025

alioftech commented Feb 21, 2025

nuotsu commented Feb 22, 2025 • edited Loading

Proposed language document

Proposed page.language and page.original fields

Proposed URL pattern

alioftech commented Feb 22, 2025 • edited Loading

nuotsu commented Feb 23, 2025 • edited Loading

Changelog

Config

Screenshots

wild2008 commented Feb 24, 2025 • edited Loading

nuotsu commented Feb 25, 2025 • edited by mitchuman Loading

alioftech commented Feb 25, 2025

wild2008 commented Feb 26, 2025 • edited Loading

nuotsu commented Feb 26, 2025

wild2008 commented Feb 26, 2025

nuotsu commented Feb 27, 2025 • edited Loading

wild2008 commented Feb 27, 2025

nuotsu commented Feb 28, 2025

nuotsu commented Mar 6, 2025

nuotsu commented Feb 22, 2025 •

edited

Loading

Proposed `language` document

Proposed `page.language` and `page.original` fields

alioftech commented Feb 22, 2025 •

edited

Loading

nuotsu commented Feb 23, 2025 •

edited

Loading

wild2008 commented Feb 24, 2025 •

edited

Loading

nuotsu commented Feb 25, 2025 •

edited by mitchuman

Loading

wild2008 commented Feb 26, 2025 •

edited

Loading

nuotsu commented Feb 27, 2025 •

edited

Loading