amannn / next-intl

🌐 Internationalization (i18n) for Next.js
https://next-intl-docs.vercel.app
MIT License
2.58k stars 236 forks source link

How to send the language (locale) code to Fetch operations processed by the Client Side? #1243

Closed salihandic closed 3 months ago

salihandic commented 3 months ago

Description

I've done all the checks and I've gone through all the documents in detail, but I can't find a solution. I think there's something missing here.

Problem 1: I want to fetch from the client side (when the document is created). For example, the user will submit a form to the API. I want to create a global fetch function for such later fetch operations and include the locale information in the header of this function so that I don't have to call the useLocale hook all the time. But it seems that it is not possible to access locale information from outside Next-Intl.

Example: In this example I want to create a function that I can use globally and I want to include the locale information in this function. (I can send this in Component. But this causes me to run the uselocale() hook on every fetch operation. This is also not useful)

const request = async (method, path, data = {}) => {
  const options = {
    Method,
    headers: {
      headers,
     // "x-locale": *** /** I want to add locale information globally here*/
    },
    body: JSON.stringify(data),
  };

  const respose = await fetch(process.env.NEXT_PUBLIC_API_URL + path, options);
  return await respose.json();
};

const onFavorite = async () => {
   const resrult = await request("POST", "favorite", {id: 4566})
}

<Button.favorite onClick={onFavorite}>

Please tell me how to pass locale information outside the Component of the request() function.

Issue 2: I want to access locale information from the server side, but the problem is that x-locale information is sent in server side requests. This information is not sent in custom requests on the client side. Also getLocale() does not get the locale code in special requests.

Example:

import { getTranslations, getLocale } from "next-intl/server";

const locale = getLocale();

const t = await getTranslations({ locale, namespace: "home" });

I can't get the locale information from the server side with getLocale. Intl already generates a locale information. I don't understand why this is empty by the API. I wonder why this happens?

Problem 3: In some translation files I want to store an array. For example I have a static list of items. Since I am not going to update this list, I want to take it as an array and use it with map. However, I realized that it is not possible to access it as raw, even though I have examined the documentation many times. Is this feature not available? (It is a must-have feature)

Respectfully

Verifications

Mandatory reproduction URL

https://next-intl-docs.vercel.app/docs/getting-started/app-router/with-i18n-routing

Reproduction description

Next-Intl should be developed further. It is easy to set up and the documentation clearly answers everything. But it needs to be improved. The user should be given more access.

Expected behaviour

1 - It is necessary to get the Array/Object array in the translation file in raw format and use it. 2 - The server should be able to get the locale information without any additional settings. 3 - Functions/global functions other than Component should have access to locale and translation information.

amannn commented 3 months ago

Problem 1

The locale can only be read during render, via useLocale() (or await getLocale() in Server Components). If it's a hassle to read the locale for every HTTP call you're making from the client side, you can consider storing it in React Context.

This would enable usage like this in components:

const fetch = useFetcher();

async function onFavorite() {
  const result = fetch('POST', 'favorite', {id: 4566});
}

In this case you can use this opportunity to share other options, like your API URL as well.

Libraries like React Query have this behavior built-in by allowing to configure a global fetcher.

Problem 2

If you're sending the locale consistently via a x-locale request header, then you can read it accordingly via headers().

Problem 3

See arrays of messages in the docs.


I'm going to move this to a discussion since this is a usage question and not a bug report.