👋 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 #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 zolplay-cn/website@3668099 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? :)