Is defaultLocale necessary?

[zackrw]

No problem, just a discussion question about a potential optimization:

• Is there a reason that "defaultLocale" can't just always be the first one in the locales array?
• I could imagine someone wanting to order those alphabetically, but even when that means not putting the default first?

[gustaveWPM]

lol, that was somehow what I was doing.

Here are some snippets:

export const getEnumKeys = (e: object): string[] => Object.keys(e).filter((key) => isNaN(Number(key)));
export const getEnumFirstKey = (e: object): string => getEnumKeys(e)[0];

type LanguageFlagKey = keyof typeof ELanguagesFlag;
export type LanguageFlag = LanguageFlagKey;
export type LocalesGetterConfigObjTypeConstraint = Record<LanguageFlag, () => Promise<unknown>>;

export enum ELanguagesFlag {
  fr,
  en
}

export const LANGUAGES: LanguageFlag[] = getEnumKeys(ELanguagesFlag) as LanguageFlag[];
export const DEFAULT_LANGUAGE: LanguageFlag = getEnumFirstKey(ELanguagesFlag) as LanguageFlag;
// * ... lol. Could be also DEFAULT_LANGUAGE = LANGUAGES[0]

const getLocales = () =>
  ({
    fr: () => import('@/i18n/locales/fr'),
    en: () => import('@/i18n/locales/en')
  } satisfies LocalesGetterConfigObjTypeConstraint);

export const locales = getLocales();
export default locales;

const I18nMiddleware = createI18nMiddleware({
  locales: LANGUAGES,
  defaultLocale: DEFAULT_LANGUAGE,
  urlMappingStrategy: 'rewriteDefault'
});

export const { useI18n: getClientSideI18n, useScopedI18n, I18nProviderClient, useCurrentLocale } = createI18nClient(locales);

export const { getI18n: getServerSideI18n, getScopedI18n, getStaticParams } = createI18nServer(locales);

[QuiiBz]

Is there a reason that "defaultLocale" can't just always be the first one in the locales array?

The reason is that it's (in my opinion) better to explicitly define which locale is the default because it's visually easier to understand what's going on. Someone that doesn't know anything about next-international will immediately understand how it works.

That's certainly debatable, but I'll close this issue as we want this library to be simple and straightforward. Thanks for the suggestion though!