👋 Who is using next-intl?

[amannn]

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 next-intl@2.13.0-beta.1. 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!

[ovflowd]

1. Ty! Will keep an eye on that!
2. Yes, we don't want to have different locales, but sometimes, we could format dates on the client's browser's locale. For example, our English locale is only en-US but many people from other countries, even countries we have localized support, might prefer the English locale, but that's sorta limiting as we're enforcing always formatting the date on that said locale, instead of respecting the user's browser locale for time-date formatting.
3. Appreciate for creating an issue, that'd be super handy
4. Would love if you could automatically detect what messages were used on the server-side for that same page, keep track of that on a set, and automatically pass those to client-side.
   • And if a message is missing and client-side (i.e. because client-side component using hooks or whatever, or etc, emit a warning of missing messages)
   • It'd be really great, to be able to keep track of that and only pass for said page the necessary messages.
5. Well, for me it was annoying as hell. I would encourage that either you support the means of users migrating their messages to this format, or support both formats, otherwise you're losing people right at the beginning because they just don't want to go through updating every single message :) and this IMO was almost what made me drop this package, just because it is a manual work that is annoying, and also nested messages do not support things you could do without nesting:

   "some.key": "my message",
   "some.key.subkey": "my message",

   Is supported by non-nested message bags, but not on nested, as, you cannot define "some.key" as a key as it will be an object. Hence, this approach is sorta limiting.

[dmgawel]

Hi @amannn!

I'm Dawid, Frontend Engineer at Doist, creators of Todoist and Twist. We deeply care about internationalization. Our websites, apps, and materials are translated to almost 20 languages.

For weeks now, we struggled with the bug in Next.js that stops us from using Pages Router and App Router at the same time (that thing with i18n in the config file), and because we adapted App Router before the bug was introduced, we're stuck on an older Next.js version :/

With the release of next-intl v3 and routing middleware, we've been finally able to get it up and running! I'm currently working on migrating todoist.com to next-intl. It's a big website, so there's still some work to do (particularly around useRouter usage, changing languages, pathnames and stuff like that), but the early results are very promising!

Thanks a ton for working on this project 🙌

[amannn]

Hi @dmgawel,

that's so cool to hear, Todoist looks absolutely stunning! 🙌 I noticed you have a completely distributed team at Doist, I'm sure you take i18n very seriously! :)

Yep, the built-in i18n config from Next.js is known to be problematic when migrating to the App Router, next-intl currently warns when this is detected. There's a minimalistic App Router migration example in this repo which was contributed, but from what I can tell you're already past that.

Let me know in case you run into something! If you're interested, we could feature Todoist in the next-intl showcase on the homepage—I'd certainly be more than happy to! 🙂

[4Furki4]

It's one of my go-to libraries with Next.js. I still can't believe how few star counts this library has! I found it while we were building our final project in a bootcamp and suggested it to as many people in the bootcamp as possible. I'll publish an article to share it with more people, thank you Aman and all other contributors!

[dmgawel]

@amannn I'm happy to let you know as of today todoist.com runs on next-intl, at least for the routing part :-) And we're using both Pages and App Router 👍

Yep, the built-in i18n config from Next.js is known to be problematic when migrating to the App Router, next-intl currently warns when this is detected. There's a minimalistic App Router migration example in this repo which was contributed, but from what I can tell you're already past that.

The example was indeed very helpful! I encountered one or two problems, but I'll open separate issues to keep this one on topic :-)

If you're interested, we could feature Todoist in the next-intl showcase on the homepage—I'd certainly be more than happy to! 🙂

Absolutely, feel free to do so!

[dejurin]

Subdomain based English- https://timenow.zone/ Ukrainian - https://uk.timenow.zone/

[4Furki4]

Leveraged it in my portfolio site using locale URL param and localized pathnames. English: https://www.furkancengiz.software/ (localePrefix is set to as-needed) Turkish: https://www.furkancengiz.software/tr

[gootik]

next-intl is amazing! We use it for swypex.com webapp (https://app.swypex.com) :D. Thanks for the great work

[nekochan0122]

https://nikke.win

[RemyJouni]

Thank you for the amazing library. We are using it on our AI website.

AR: https://www.gulfpicasso.com EN: https://www.gulfpicasso.com/en

[alexk400]

I am trying to convert my english/french site using nextjs/intl but i dont like it. Because i dont like json. cant use object to get data or array. Its just bad. Why not use property file. Main reason is i am creating custom cms. All the language stuff will be connected to id Home_Title , HOME_STUFF1_STUFF2_TITLE ... so i can sort them easily and stored in property file than json. its easy for me this way.

Anyway to get rid of unmaintable json ? or give option of reading from property file ( like .env)

[blazorin]

https://www.getcoc.eu

[sayandedotcom]

I have added a default page inside [locale] folder and outside

[talatkuyuk]

I see nodejs web site also use next-intl.