update inlang.config.js

[samuelstroschein]

There were some breaking changes, see opral/monorepo#290. No further breaking changes are expected for the foreseeable future.

I also looked at finding a method to let users add new languages. Difficult. The day js files (https://github.com/osmosis-labs/osmosis-frontend/blob/master/packages/web/localizations/dayjs-locale-en.js) can not be generated via the editor. Adding new languages via the editor could creating new resources (de.json) etc. but the maintainers would still need to manually create the dayjs files + in the user store settings:

osmosis-frontend/packages/web/stores/user-settings/language.tsx

Line 12 in e478fd9

const SUPPORTED_LANGUAGES: MenuDropdownIconItemProps[] = [

Ideally, an i18n library (see opral/monorepo#289 (comment)) would deal with both problems automatically.

[vercel]

@samuelstroschein is attempting to deploy a commit to the OsmoLabs Team on Vercel.

A member of the Team first needs to authorize it.

[ivanhofer]

@samuelstroschein inlang should probably not deal with altering other files. It could provide a hook onLocaleAdd inside inlang.config.js. Then each project could implement it's own logic.

inlang should probably also provide and manage an enum-like object of all available locales, so developers can e.g. write a switch-case statement, and TypeScript could throw an error if a locale does not get handled.

In this special case probably the easiest option is it to rewrite the code using the Intl.DateTimeFormat api:

const getLocalizedMonths = (locale: string) => {
	const monthFormatter = new Intl.DateTimeFormat(locale, { month: 'long' })
	return new Array(12).fill(0).map((_, i) => monthFormatter.format(new Date(0, i)))
}

const getLocalizedWeekdays = (locale: string) => {
	const weekdayFormatter = new Intl.DateTimeFormat(locale, { weekday: 'long' })
	return new Array(7).fill(0).map((_, i) => weekdayFormatter.format(new Date(1, 0, i)))
}

console.log(getLocalizedMonths('en'))
console.log(getLocalizedWeekdays('en'))

output:

[vercel]

Deployment failed with the following error:

Was unable to schedule a deployment.

[samuelstroschein]

@ivanhofer

inlang should probably not deal with altering other files.

Absolutely agree. I was referring to an i18n library that deals with altering files based on the inlang.config.js file but inlang would not do it itself.

inlang should probably also provide and manage an enum-like object of all available locales

The config already provides config.languages that could be used. But ... to access the languages, the defineConfig function needs to be called, probably without dynamically importing plugins or dependencies.