How to get current language?

[luizeboli]

Is there any way to retrieve current language outside of a component?

I have an API fetcher method that uses the active language to set Accept-Language header.

Just read source code but couldn't find anything that exposes the i18n instance.

[aralroca]

I think Next.js expose it under req.query

[luizeboli]

Hi!

Maybe, but It'll be better if we have access to it outside of Next data fetching methods.

So we don't have to pass current lang to every single fetch done.

We use an API wrapper

[aralroca]

The safest thing to do is to use it under useTranslation and propagate it. In case of the browser you can expose it globally to the window, but in case of the Node it is not recommended to make it global.

[luizeboli]

I'll have to think about it, we're migrating from next-i18next and there's a i18n instance to get current lang.

Our structure is like:

Page > getInitialProps > getUsers (service method) > apiGet (method to fetch w/ GET) > apiFetch (wrapper that uses i18n instance to retrieve current language)

So many layers to pass down from useTranslation I guess

[oceandrama]

@aralroca Could you expose global i18n instance like next-i18next does?
As for me, I use t function in onError callback in apollo-error-link. It cannot be asynchronous, so I can't use getT function here. Global instance with t function and lang could resolve this problem

[aralroca]

I understand that it would be useful, but a global instance in Node can have concurrency conflicts with several users connected at the same time, it wouldn't know which language to show you. Do you know how next-i18next does it to avoid this?

[oceandrama]

As I know, it creates (or clones existing) i18n instance on each request on server side. You can find implementation here
browser: https://github.com/isaachinman/next-i18next/blob/master/src/createClient/browser.ts
server: https://github.com/isaachinman/next-i18next/blob/master/src/createClient/node.ts

This is the commit, that exposes global i18n instance i18next/next-i18next@7fd4f09

[aralroca]

OK, this seems to work if you have little traffic... But if you have a lot of requests per second, this looks like it can generate a lot of concurrency conflicts... If each request overwrites a global variable, if the request you make takes a while, it could be that the instance has already been changed by another request during the execution of the other one... At least, I don't see how they solve this.

[isaachinman]

Great points, @aralroca. The disclaimer, and entire point, is that the global i18n instance is only intended to be used client side. If you are relying on a global i18n instance for SSG/SSR, you are probably doing something wrong.