Fallback strings are not formatted using the target locale.

[SpikyC]

🐛 Bug Report

Any translations that uses fallback strings will also use the fallback locale to format them instead of the target locale.
Using {{date, datetime}} without i18next-icu the fallback would still use the target locale to format the date.

To Reproduce

Fallback to en

import i18next from "i18next";
import ICU from "i18next-icu";

i18next.use(ICU).init({
  lng: "fr-CA",
  resources: {
    en: {
      translations: {
        short_date: "{date, date, short}"
      }
    }
  }
});

i18next.t("short_date", { date: new Date(2000, 1, 29) }); // 2/29/00 (Which is the en-US way to write it.)

Fallback to fr

import i18next from "i18next";
import ICU from "i18next-icu";

i18next.use(ICU).init({
  lng: "fr-CA",
  resources: {
    en: {
      translations: {
        short_date: "{date, date, short}"
      }
    },
    fr: {
      translations: {
        short_date: "{date, date, short}"
      }
    }
  }
});

i18next.t("short_date", { date: new Date(2000, 1, 29) }); // 29/02/00 (Which is the fr-FR way to write it.)

Expected behavior

import i18next from "i18next";
import ICU from "i18next-icu";

i18next.use(ICU).init({
  lng: "fr-CA",
  resources: {
    en: {
      translations: {
        short_date: "{date, date, short}"
      }
    }
  }
});

i18next.t("short_date", { date: new Date(2000, 1, 29) }); // 00-02-29 (Which is the fr-CA way to write it.)

Your Environment

• runtime version: node v18.17.0, npm 9.6.7, deno, browser Chrome/116.0.0.0
• i18next version: 23.4.5
• os: Windows 10 (WSL Ubuntu 20.04)

[adrai]

The language code in the resources is important.

So, this works:

i18next.use(ICU).init({
  debug: true,
  lng: "fr",
  fallbackLng: "fr-CA",
  resources: {
    "fr-CA": {
      translation: {
        short_date: "fr-CA: {date, date, short}"
      }
    },
    "en-CA": {
      translation: {
        short_date: "en-CA: {date, date, short}"
      }
    }
  }
});

i18next.t("short_date", { date: new Date(2000, 1, 29) }) // fr-CA: 00-02-29
i18next.t("short_date", { date: new Date(2000, 1, 29), lng: 'en-CA' }) // en-CA: 00-02-29

[SpikyC]

Hello @adrai,
While I know that providing the string in the resources will mitigate the issue, I’m saying that the normal behaviour of i18next is to format the string with the target locale as a base.

import i18next from 'i18next';

i18next.init({
  lng: "fr-CA",
  resources: {
    en: {
      translations: {
        date: "{{date, datetime}}"
      },
    },
  },
});

console.log(i18next.t("date", { date: new Date(2000, 1, 29) })); // 2000-02-29 (Which is the fr-CA value using Intl.DateTimeFormat.)

import i18next from 'i18next';

i18next.init({
  lng: "fr",
  resources: {
    en: {
      translations: {
        date: "{{date, datetime}}"
      },
    },
  },
});

console.log(i18next.t("date", { date: new Date(2000, 1, 29) })); // 29/02/2000 (Which is the fr-FR value using Intl.DateTimeFormat.)

[adrai]

Can you try with i18next v23.4.6 ?

[jamuhl]

wrong...format inside gets done with the language i18next is able to resolve a resource -> if it resolves the en string it will format dates in english format and not in french -> to keep a string consistent

[SpikyC]

Can you try with i18next v23.4.6 ?

It solved the issue, thanks!

[jamuhl]

23.4.6 is breaking change and wrong -> rollback is needed

[SpikyC]

23.4.6 is breaking change and wrong -> rollback is needed

While I agree that it is a breaking change, I don’t understand why it is wrong since it’s the default behavior of i18next?

import i18next from 'i18next'; //v23.4.5

i18next.init({
  lng: "de-DE",
  resources: {
    en: {
      translations: {
        date: "Latest tetracentennial leap day: {{date, datetime}}",
      },
    },
  },
});

console.log(i18next.t("date", { date: new Date(2000, 1, 29) })); // Latest tetracentennial leap day: 29.2.2000

[jamuhl]

then the default behaviour might be wrong - formatting and language should be consistent...or do you like german strings with american dates?

[SpikyC]

then the default behaviour might be wrong - formatting and language should be consistent...or do you like german strings with american dates?

Then it’s no use to follow this principle since those format might not be valid.
https://www.i18next.com/principles/fallback#variant-resolving-fallback-from-dialects-or-scripts

[jamuhl]

in that case we would have to decide on locale for formatting depending if it is a fallback to non regional variant...so you're right...both options are currently wrong depending on the fallback comes from same language or not

[SpikyC]

in that case we would have to decide on locale for formatting depending if it is a fallback to non regional variant...so you're right...both options are currently wrong depending on the fallback comes from same language or not

As a compromise, I would be happy with that solution.
But in both cases (i18next current behavior and i18next-icu v23.4.5 behavior) it will be a breaking change.

[jamuhl]

so as change already made we keep current change in hope we did not open a box ;)

[adrai]

ok, let's close this issue now ;-)