👋 Who is using next-intl?

[amannn]

trafficstars

Since the usage of this library is growing, I'm really curious which companies are using next-intl. Leave a comment here if next-intl is helpful to you! 🙂

[tacomanator]

Hello from Japan. Thanks for your work on this library. We use it at my company in our online paystub application. Soon we will use it for payroll and accounting products too. We want our products to work well for both native Japanese speakers and the growing immigrant population (like myself).

By the way, I haven't been able to figure out how to specify a global currency type for formatNumber. It would be great if we could intl.formatNumber(value, {style: "currency"}) without needing to add {currency: "JPY"} (or maybe this is already possible?). Or even better, intl.formatCurrency(value).

Update On global currency type, after writing that comment I took a deeper look and figured out I can use intl.formatNumber(value, "currency") with default formats:

{
  number: {
    currency: {
      style: "currency",
      currency: "JPY",
    },
  },
}

[amannn]

Hey @tacomanator,

thanks for leaving a note here, I'm really glad to hear that next-intl works for you! 🙂

Great you figured out a solution with the global formats, that looks correct to me!

[3lang3]

@amannn Hello from china. next- intl is very easy to use, especially friendly to typescript, Thanks for your work on this library.

I want to know how to sync the locale value to Accept-Language field of fetch, I know this is not a next-intl problem, but I am stuck by this problem now 🥲. Our api service hopes to return a specific content through the Accept-Language field.

[amannn]

Hi @3lang3 and thank you for your kind words!

If you don't mind, I'd like to avoid answering usage questions in this thread. Your question is best redirected to Stack Overflow, I check in there occasionally to see if a user of next-intl needs help. From your description it seems like you need to configure a header for the API client you're using and I don't think next-intl can help with that aspect, I hope you understand!

[peterbrczan]

Hey @amannn

Hello from Hungary! I've found this package shortly after I migrated to Next's app folder structure, and saw they have removed the built in support for i18n.

Other than that it's capable for fully replacing i18n I really love it's strong type support and the much better handling of the "namespaces".

Good work 👍

[CaliCastle]

Hey @amannn

Hello from China! I've found this package to be extremely helpful since we're always a bilingual team at heart. I'm the Founder and CEO at Zolplay and I've recently revamped the site to Next.js 13 (app router) with this incredible library!

The website is also open source at https://github.com/zolplay-cn/website here. I've found that sometimes the DX speed in dev feels a bit slow, and sometimes would get error messages like these out of nowhere (I'm on next-intl 2.12.0-beta.2 by the time of this writing):

But overall, I'm super satisfied! Appreciate for all the amazing work on the full i18n support!

[amannn]

@CaliCastle Thank you for the kind words, I really appreciate it! 🙌

I had a look at the Zolplay website, what a cool website! The animated page transitions are 👌

I also looked around your code, looks really good! FYI, in regards to your DefaultRichTextComponents module, you can also configure those globally on the provider if you want to avoid importing them everywhere (see also https://github.com/amannn/next-intl/issues/173).

I noticed that you use the domain-based routing feature. I just shipped some middleware enhancements in 2.12.0-beta.3 that include improvements for how domains are handled (see the updated docs, you should get a deprecation notice). Would you be interested in trying the new release out and let me know if everything works as expected?

I've found that sometimes the DX speed in dev feels a bit slow

Definitely feel free to open an issue in case you find something that you think could be improved!

sometimes would get error messages like these out of nowhere

I haven't seen that particular one, but I occasionally see hydration errors from Next.js 13—I guess they are still ironing out the RSC support. If you can track back an issue to next-intl I'd be happy to look into it!

[CaliCastle]

@CaliCastle Thank you for the kind words, I really appreciate it! 🙌

I had a look at the Zolplay website, what a cool website! The animated page transitions are 👌!

I also looked around your code, looks really good! FYI, in regards to your DefaultRichTextComponents module, you can also configure those globally on the provider if you want to avoid importing them everywhere (see also #173).

I noticed that you use the domain-based routing feature. I just shipped some middleware enhancements in 2.12.0-beta.3 that include improvements for how domains are handled (see the updated docs, you should get a deprecation notice). Would you be interested in trying the new release out and let me know if everything works as expected?

I've found that sometimes the DX speed in dev feels a bit slow

Definitely feel free to open an issue in case you find something that you think could be improved!

sometimes would get error messages like these out of nowhere

I haven't seen that particular one, but I occasionally see hydration errors from Next.js 13—I guess they are still ironing out the RSC support. If you can track back an issue to next-intl I'd be happy to look into it!

@amannn I've just updated next-intl to 2.12.0-beta.3 https://github.com/zolplay-cn/website/commit/36680991f0f8ce17ea5bf37d58320dea43a67e95 and removed all redundant imports. Also refactored using the new routing options in the middleware, everything seems to be working great!

Also noticed some speed bumps in local dev too, high five all around! Thank you!

[amannn]

Great to hear! 👏

Also, thank you so much for your generosity to provide sponsoring for next-intl! ❤️❤️❤️

[CaliCastle]

You definitely deserve a sponsor ❤️ and I was surprised you don't have one yet, a truly well developed library and I hope Next.js acquires it soon.

[Alex17000]

Hi,

With the new domain routing in @2.12.0-beta.5 the very good idea that the locale !== language has been lost.

For example we have a some-site.ca with some canadian specific services and en and fr languages. So, locale is the "ca", languages are in ["en", "fr"] with the "en" as default. In parallel we have a some-site.us with a US specific services and en and es languages.

The routing should be like: some-site.ca/ -> "en home page" some-site.ca/en/ -> "en home page" some-site.ca/fr/ -> "fr home page"

some-site.us/ -> "en home page" some-site.us/en/ -> "en home page" some-site.us/es/ -> "es home page"

Is it possible to return the above behavior? :)

[amannn]

Hi @Alex17000,

that's a great point, I overlooked this. I'll look into this, maybe you can stick to an earlier beta version in the meantime?

You can leave feedback for the RSC integration in https://github.com/amannn/next-intl/pull/149 btw.

[ghost]

Hi @Alex17000,

that's a great point, I overlooked this. I'll look into this, maybe you can stick to an earlier beta version in the meantime?

You can leave feedback for the RSC integration in #149 btw.

Hi, which beta version has support for multiple locales per domain? We have 2 domains, one .nl and one .be. .nl only has a dutch locale, .be has flemish and french.

Thanks for the help.

[amannn]

@Alex17000 @ddegooijer Proper support for handling multiple locales per domain just landed in [email protected]. Please upgrade and refer to the latest docs.

To other people finding this thread: Please leave feedback for the RSC integration exclusively in #149 and not in this thread—thank you!

[shadowlik]

Thanks to the team working on next-intl, we are currently using in our production MVP apuama.app, hope to be able to help supporting the project soon!

[amannn]

@shadowlik That's so cool! I'm a passionate runner myself, keep up the good work! 🙌

[kneza23]

Seems like a go to library for Next.js App Router per their docs https://nextjs.org/docs/app/building-your-application/routing/internationalization. I hope it would be long lived :)

Edit: We are currently researching possible solutions but next-intl seems like it would our choice on our new project. Do you have an advice how to connect external API for handling translations like https://phrase.com/products/phrase-strings/ with next-intl?

[ghost]

**kneza23 ** commented May 5, 2023 •

Does this mean next 13.4 has internationalization out of the box without using next-intl?

[amannn]

@kneza23

We are currently researching possible solutions but next-intl seems like it would our choice on our new project. Do you have an advice how to connect external API for handling translations like https://phrase.com/products/phrase-strings/ with next-intl?

Sure! There's a guide in the docs that describes an integration with Crowdin: https://next-intl-docs.vercel.app/docs/localization-management.

Full disclosure: Crowdin is the sponsoring partner of next-intl, therefore they are promoted in the docs. You can of course also use other translation management services!

[kneza23]

@kneza23

We are currently researching possible solutions but next-intl seems like it would our choice on our new project. Do you have an advice how to connect external API for handling translations like https://phrase.com/products/phrase-strings/ with next-intl?

Sure! There's a guide in the docs that describes an integration with Crowdin: https://next-intl-docs.vercel.app/docs/localization-management.

Full disclosure: Crowdin is the sponsoring partner of next-intl, therefore they are promoted in the docs. You can of course also use other translation management services!

Is there an example of integrating next-intl with crowdin js api? We want to have translation hosted on management platform and update them on the fly. I just saw the example that has integration with Github to make automatic merge requests.

[amannn]

I haven't personally looked into integrating with the Crowdin JS API but it should certainly be possible. In the places where in the documentation a JSON file is loaded from the repository, you'd use the Crowdin API instead.

[lachlanjc]

We're using next-intl on https://watershed.com! It's running entirely on App Router, using the Client Components version.

[amannn]

We're using next-intl on https://watershed.com! It's running entirely on App Router, using the Client Components version.

@lachlanjc Oh wow, that's so cool! Really happy to see next-intl being used in the context of climate protection, this really made my day and means a lot to me! ❤️

Keep up the good work! 🙌

[jokull]

www.triptojapan.com - RSC beta, Crowdin and Dato CMS integration, human translations for UI and some Microsoft Azure machine translations for content, which will be eventually QA'd.

[JulianJorgensen]

Hello from Self massage robot. We're using next-intl. Thanks so much https://www.selftime.io

[ovflowd]

Hey folks 👋 I'm one of the collaborators behind Node.js, and we love next-intl. We're adopting it on the Node.js Website here along with Next.js's App Router.

From all the i18n solutions out there for React and Next.js, so far the API and the design of next-intl has definitely become my favorite :)

[amannn]

@ovflowd Oh my god, that's soo cool to hear! Thank you so much for leaving a note here!

And definitely reach out in case you run into something that you think can be improved!

[ovflowd]

Thank you, @amannn! I'd say so far it has been a smooth ride, but here are 2cents if I could share:

• The App Router example, uses dynamic segments, which is great, but on the example you define the root layout under the locale segment.
  • It is not explicit on the Next.js docs, but as using a non-root layout (/app) and placing the HTML tag actually will make the HTML tag lose any extra attribute on Edge\Serverless (aka deployed on Vercel)
  • An easy solution for that is to simply make a root layout that doesn't rely on the locale parameter from the dynamic segment, and that works perfectly if you use the setRequestLocale function that you expose.
• the useFormatter Hook is a great abstraction for the Intl API and I like that it sets the locale based on the current locale. But it'd be great to allow to override that somehow to either use the user's browser locale (ie grab from the User Agent header, or fallback to navigator.language. (I am talking about an extra feature where instead of using the registered locale for Intl, to use the user's locale if available, of course, no static generation in this case.)
• It'd be great if the API of the useTranslations t.rich and/or t.markup allowed allowed a bare string instead of a function, and use template variables for the named ICU variables to replace on the rich/markup. The main motivation here is that if I pass these translation values as a prop from a Client Component to a Server Component it fails, because right now t.rich and t.markup require functions for values/templates that have rich/markup and sadly React cannot serialize functions.
• Finally it'd be great if NextIntlClientProvider also inferred messages by default. Locale, Timezone, Now, etc are already, why not the messages also?
• Finally, it is kinda restrictive that namespacing (translation keys) (ie: "something.under.namespace.key") requires nested JSON objects, I had to convert all my JSON files to use nested keys otherwise next-intl wouldn't be happy

[ovflowd]

Besides those comments above, fantastic work done here! (Also apologies for the poorly written comment, somehow decided to write that minutes before settling for the day 😅)

[amannn]

@ovflowd Thank you for the detailed feedback, this is really helpful!

To address your points in order:

1. I think there's some inconsistency currently on the Next.js side: https://github.com/vercel/next.js/issues/55735#issuecomment-1733611397. I hope that there will be updates to this from the Next.js team.
2. I'd be curious what kind of use case you have. It's important that the locale is in sync across the server and client to avoid markup mismatches, but theoretically, on the client side, you could add a NextIntlClientProvider that overrides the locale.
3. The serialization story for passing translation values for t.rich and t.markup is arguably not that great currently, I agree. Esp. passing these via defaultTranslationsValues is not ideal, as we can't pass it to the client across the serialization boundary. I've added https://github.com/amannn/next-intl/issues/611 to track this issue.
4. I totally see your point. We don't automatically pass messages to the client side, since the serialized messages can affect performance. Instead, there's a guide about the options a developer has in this situation. However, I'm really interested in finding a solution that automatically passes the minimum of required messages to the client side, as well as optimizing the messages, to avoid bundling the ICU parser (see also https://github.com/amannn/next-intl/issues/2). There might be some interesting news on this side in the future, something is silently cooking here! 🤫
5. There's been some previous discussion about this, see e.g. https://github.com/amannn/next-intl/discussions/148. My current perspective is that this can be slightly annoying during a migration, but a conversion (which can also happen at runtime if that's easier for you) is arguably quite straightforward.

Definitely feel free to open separate issues for these points to discuss in more depth if you like!