Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getFixedT does not use fallbackLng from i18nextOptions #116

Open
jacknevitt opened this issue Feb 2, 2023 · 0 comments
Open

getFixedT does not use fallbackLng from i18nextOptions #116

jacknevitt opened this issue Feb 2, 2023 · 0 comments
Assignees

Comments

@jacknevitt
Copy link

Describe the bug

When using i18n.getFixedT inside a loader function, I have to redeclare the fallbackLng option.

import i18n from "~/i18next.server";
import i18nextOptions from "~/i18nextOptions";

export async function loader({ request }: DataFunctionArgs) {
  const t = await i18n.getFixedT(request, "welcome", {
    fallbackLng: i18nextOptions.fallbackLng, // required
  });

  return json({
    meta: {
      title: t("META_TITLE"),
    },
  });
}

Without declaring it again, t("META_TITLE") returns the translation key for languages without this key. I'm expecting to see the fallback language used in i18next.server.js to translate the string.

Your Example Website or App

Private repo

Steps to Reproduce the Bug or Issue

  1. Create an i18next instance as shown in i18next.server.js in https://github.com/sergiodxa/remix-i18next#configuration
  2. Import the i18next instance in a route file.
  3. Declare a variable t by calling i18next.getFixedT with the request and namespace arguments
  4. Call t function with a translation key that exists in the fallback language but not in another language
  5. Make a request with the browser language for the other language without the key

Expected behavior

I expect to see the translation for the given key in the fallback language used when none exist in the target language

Screenshots or Videos

No response

Platform

  • OS: macOS
  • Browser: Chrome
  • Version: 109.0

Additional context

Not a major issue as there is a workaround but it would save us repeating code in each route's loader. Thanks

@sergiodxa sergiodxa self-assigned this Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants