i18n Configuration failed to load tw-TW

[muzsor]

Hello!

I tried changing the Chinese (Taiwan) language code in supportedLngs from zh-TW to tw-TW in the config.js file and also renamed the zh-TW folder in the locales directory to tw-TW.

Before	After
/* src/i18n/config.js */ // Add names for each locale to // show the user in our locale // switcher. export const supportedLngs = { "en-US": "English", "de-DE": "Deutsch", "zh-TW": "繁體中文", "zh-CN": "简体中文", "pt-BR": "Português (BR)" }	/* src/i18n/config.js */ // Add names for each locale to // show the user in our locale // switcher. export const supportedLngs = { "en-US": "English", "de-DE": "Deutsch", "tw-TW": "繁體中文", "cns-CN": "简体中文", "br-BR": "Português (BR)", "jp-JP": "日本語" }

When I tested it, I got this error: i18next::languageUtils: rejecting language code not found in supportedLngs: ak-TW

I've tested with cns-CN, br-Br and jp-JP, and those work fine.

de-DE Deutsch	cns-CN 简体中文	br-Br Português (BR)	jp-JP 日本語

My main goal is to make sure it displays correctly in other languages, but I'm not really sure how to configure the i18n settings.

I also tried a few other approaches, but none of them worked.

Another idea I had was to use region codes instead of language codes, and just keep the original supportedLngs values.

I'm not sure if there's a better way, so I'd like to open this up for discussion.

Thank you!

[johnfriedrich]

I already answered via Discord, but your provided language tags are not valid. See here for a list:
https://github.com/ladjs/i18n-locales
Not sure if its complete though

[muzsor]

Thanks for your reply!

I understand that tw-TW isn’t valid, that’s because the LocalizedText key used in the API is tw, and the code is set up to get the language code, not the region code.

So it can’t correctly fetch the translation for tw.

Not sure if switching to get the region code would be a better idea?

/* src/flyff/flyffutils.js */

/**
 * @param {string} id The stat id
 * @param {object} i18n Localization
 * @returns A string matching the appropriate stat name
 */
export function getStatNameByIdOrDefault(id, i18n) {
    var stat = statNames[id];
    if (stat == null) {
        return id;
    }

    var shortLanguageCode = "en";
    if (i18n.resolvedLanguage) {
        shortLanguageCode = i18n.resolvedLanguage.split('-')[1].toLowerCase();
    }

    return stat[shortLanguageCode] ?? stat.en;
}

Thanks again for your help!

[johnfriedrich]

Okay I see the issue. The issue lies in how Flyff handles those different translations. Flyff mixes languages and regions in those jsons.

Example:

"en": "Bleeding",
"cn": "流血中",
"tw": "失血",
"fr": "Saigner à blanc",

E.g. "en" and fr is a language.
"tw" and "cn" however is a region

We got "en-US" and "en-GB". In both cases we grab "en" to look for a translation. Or "fr-FR" or "fr-LU". We grab "fr" there.

In case of zh-TW and zh-CN we would grab zh, which doesnt exist but it exists TW and CN.

You see, if we always grab the second part, it would break other languages. Its Flyff fault for not supporting language-region codes.

Two possibilities:

• We always grab the second part.
  • There isn't always a region and e.g. for "fr" there are like 5 regions. So if someone adds french, french files have like 5 duplicates and we would need to translate e.g. fr-XX to fr.

OR

• We add a language helper function that does the following:
  • In case its zh-TW we translate to tw or zh-CN to cn (Those are the special cases, maybe some more). Else we just use the first part as we are doing now
  • In this case we keep support for all languages with many regions without manually mapping them

I would personally go with option 2

[muzsor]

I should've made that clear at the beginning, sorry about that. 🙏

I agree with the second approach as well; it will be much clearer and easier to follow.

Thank you!

[Frostiae]

If it helps, in flyff the languages are matched by whatever detector we give it, for example for english it's "en", french is "fr", german is "de", and so on. For CN it's "zh" and for TW it's the whole "zh-tw" string. Maybe it can work in a similar way in Flyffulator.

[johnfriedrich]

If it helps, in flyff the languages are matched by whatever detector we give it, for example for english it's "en", french is "fr", german is "de", and so on. For CN it's "zh" and for TW it's the whole "zh-tw" string. Maybe it can work in a similar way in Flyffulator.

Yes, thats exactly option 2 from my last post here 🥳 Best option I can think of.

Pseudo code:

getFlyffLanguageShortCodeFromLanguage {
  var lang = i18n.resolvedLanguage;
  if (lang === "zh-TW") {
    return "tw";
  } else if (lang.startsWith("zh")) {
    return "cn";
  } else if (lang.includes("-")) {
    return lang.split("-")[0];
  } else {
    return lang;
  }
}

Something like that

[muzsor]

I would like to add the getFlyffLanguageShortCodeFromLanguage(i18n) function to flyffutils.js.

export const LANGUAGE_CODE_MAP = {
    "zh-tw": "tw",
    "zh-cn": "cn",
    "zh": "cn",
    "pt-br": "br",
    "en-us": "en",
    "en": "en",
}

export function getFlyffLanguageShortCodeFromLanguage(i18n) {
    const lang = i18n.resolvedLanguage.toLowerCase();

    if (LANGUAGE_CODE_MAP[lang]) {
        return LANGUAGE_CODE_MAP[lang];
    }

    const baseLang = lang.split("-")[0];
    return baseLang || "en";
}

Let me know if you have any thoughts or ideas.

Thanks!

[johnfriedrich]

Looks good, you could remove "en-us" and "en" from that map, as it would resolve that anyway