fix dayjs i18n

[baurine]

resolve #754

This bug should be brought by PR #677 which changed all 'zh-CN' to 'zh' limit the available languages to 'zh' and 'en', but dayjs doesn't have a 'zh' locale name, it should be 'zh-cn'.

Effect:

[breezewish]

The whole logic becomes.. zh-CN -> zh -> zh-CN now. Is it better to revert some the changes in #677? IMO it is better to leave some capability to support both zhCN and zhTW. Will it work if we fallback zh to zh-CN?

https://www.i18next.com/principles/fallback#fallback-language

[baurine]

Tried the fallback-language setting, it's a bit troublesome, you need to cover many languages, for example:

fallbackLng: { 
    'zh-HK': ['zh-CN', 'en'], 
    'zh-TW': ['zh-CN', 'en'],
    'zh-SG': ...,
    'zh-Hans': ...,
    'zh-Hant': ...,
    ...
}

According to some documents, the languages are also maybe:

zh-Hans 简体中文
zh-Hans-CN 大陆地区使用的简体中文
zh-Hans-HK 香港地区使用的简体中文
zh-Hans-MO 澳门使用的简体中文
zh-Hans-SG 新加坡使用的简体中文
zh-Hans-TW 台湾使用的简体中文
zh-Hant 繁体中文
zh-Hant-CN 大陆地区使用的繁体中文
zh-Hant-HK 香港地区使用的繁体中文
zh-Hant-MO 澳门使用的繁体中文
zh-Hant-SG 新加坡使用的繁体中文
zh-Hant-TW 台湾使用的繁体中文

(Although I don't meet)

[baurine]

I think maybe we can fix this bug first. Then later if someone contributes the traditional Chinese translation for us, we can add the support for dayjs.

[breezewish]

This fallback looks to be stupid. Why can't we just fallback zh to zh-CN?

[baurine]

Not sure whether zh -> zh-CN will make zh-TW fallback to zh-CN, let me have a try.

[baurine]

Tried to revert it and use the following setting for i18next:

export const ALL_LANGUAGES = {
  'zh-CN': '简体中文',
  en: 'English',
}

i18next
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources: {}, // oh! this line is a big pitfall, we can't remove it, else it will cause strange crash!
    fallbackLng: {
      zh: ['zh-CN'],
      default: ['en'],
    },
    interpolation: {
      escapeValue: false,
    },
  })

It works in most cases, except when you run the dashboard for the first time with another language likes zh-TW.

Because we don't import zh-tw locale for dayjs, and i18next's fallback doesn't affect dayjs.

But it will always works fine after manually selecting the 'zh-CN' or 'en' language.

[baurine]

I also tried this:

import en from 'dayjs/locale/en'
import zh from 'dayjs/locale/zh-cn'

//...

const DAYJS_LOCALES = { zh, en }
// console.log(DAYJS_LOCALES)
i18next.on('languageChanged', function (lng) {
  dayjs.locale(DAYJS_LOCALES[lng.toLocaleLowerCase()] || en)
})

It works when language is zh, but crashes when en, I think the dayjs has bug (will check it later).

[baurine]

Seems to find a good way:

import zh from 'dayjs/locale/zh-cn'

const DAYJS_LOCALES = { zh }

i18next.on('languageChanged', function (lng) {
  dayjs.locale(DAYJS_LOCALES[lng.toLocaleLowerCase()] || 'en')
})

[breezewish]

Maybe the real problem that #677 need to solve is that, the initial language is the detected language, instead of the effective language. So that by assigning the detected language it may not be a useful language.

[baurine]

So you mean we need write a util method getEffectiveLang() and use its value as Select component's default value, right?

I tried it and works fine. We don't need to revert the zh.yml to zh-CN.yml, and we shouldn't, else 'zh-TW' will fallback to 'en' translation instead of 'zh' translation.

export function getEffetiveLang(): string {
  const effetiveLangs = Object.keys(ALL_LANGUAGES)
  const detectedLang = i18next.language
  if (effetiveLangs.includes(detectedLang)) {
    return detectedLang
  }
  if (detectedLang.startsWith('zh')) {
    return 'zh-CN'
  }
  return 'en'
}

        <Form layout="vertical" initialValues={{ language: getEffetiveLang() }}>
          <Form.Item name="language" label={t('user_profile.i18n.language')}>
            <Select onChange={handleLanguageChange} style={{ width: 200 }}>
              {_.map(ALL_LANGUAGES, (name, key) => {
                return (
                  <Select.Option key={key} value={key}>
                    {name}
                  </Select.Option>
                )
              })}
            </Select>
          </Form.Item>
        </Form>

[breezewish]

this might cause bugs since all locale files are now named as zh instead of zh-CN.

[baurine]

But actually it works fine after trying. Because all languages that start with 'zh-' will fallback to use 'zh' translation first if they can't find its own language translation, and this is i18next's default behavior. https://www.i18next.com/principles/fallback#locals-resolving

[breezewish]

Is this helpful? i18next/i18next#489 I found others may meet similar problems.

[baurine]

😂 Sorry, I didn't get the relationship between this method and issue i18next/i18next#489 .

[baurine]

Hi @breeswish , the root cause of this bug is that the PR #677 limit the available languages to 'zh' and 'en' by whitelist: ['zh', 'en'] option, but for dayjs, we only import the 'en' and 'zh-cn' locales for it, we don't import 'zh' locale for it.

So I just found a new and simpler solution which works fine after trying. Just need to change one line code, to import 'zh' locale instead of 'zh-cn' locale for dayjs. (I checked 'zh' locale and 'zh-cn' locale are exactly same except the name).

- import 'dayjs/locale/zh-cn'
+ import 'dayjs/locale/zh'

How about this?

I don't think currently we need to support 'zh-TW' etc languages for dayjs. Because if we want to support this, we need to import an extra 'dayjs/locale/zh-tw' for it, but we don't prepare any other zh-TW.yml, it makes no much meaning.

[breezewish]

Neat!