possibility to add a new language

[samuelstroschein]

Problem

Contributors can't create new languages in the editor.

Proposal

Give a new option in the editor to add a new language.

Additional information

This feature is harder to accomplish. The inlang editor needs to:

1. Modify the config file dynamically
   Changing config.languages = [... new language] does not work. The change needs to be persistent be writing and committing a new config file.

2. readResources and writeResources need to account for not yet existent resources on disk
   If a language is defined but the resource does not exist on disk yet, inlang will likely crash.

[samuelstroschein]

An alternative to modifying the config dynamically could be a Monaco editor embedded into the editor that lets users directly modify the config in the inlang editor. The embedded Monaco editor should have extensive lints and warnings ofc. Maybe the embedded monaco editor can run part of the ide-extension that shows additional warnings and config steps.

[samuelstroschein]

Too complicated. A button with "add new language" is all it should need to add a new language.

[openscript]

How about having a initialize function somewhere, which a plugin can override. This initialize function does:

• create empty message files for all configured languages
• create an empty AST

[samuelstroschein]

I like that idea. It avoids apps to implement such logic by themselves. The empty AST is automatically created if an empty file is read by readResources. Thus, such an initialize function only needs to create (empty) files that are processed by readResources as a Resource with an empty body (no messages).

Here is an example implementation:

export function initializeConfig(env) {
	return {
	   languages: ["de", "en"],
           initialize: async (config) => {
               createFilesForNewLanguages({ env, config });
           },
	   writeResources: () => {
			// ...
	    },
	};
}

async function createFilesForNewLanguages(args: { env, config }) {
    for (const language of config.languages) {
        try {
            await env.$fs.readFile(language);
        } catch {
            const emptyResource = {
                type: "Resource",
                languageTag: {
                    type: "LanguageTag",
                    language: language,
                },
                body: [],
            };
            await config.writeResources({ config, resources: [emptyResource] });
        }
    }
}

1. The consuming apps need to call initialize every time a new language is dynamically added.
2. Conflicts with the initializeConfig export name. I should have named initializeConfig defineConfig. I will probably do that before inlang is adopted more widely.

[samuelstroschein]

writeResources could take care of writing new resources to the file system instead of an initialize function. Alternatively, hooks a la onLanguageAdded could be exposed that take care of the logic.

[samuelstroschein]

Discussion in a PR about adding new languages osmosis-labs/osmosis-frontend#1243 (comment).

@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:

[samuelstroschein]

Proposal

Encourage plugins, and config authors, to automatically derive languages that exist in a repository. If languages are automatically detected, inlang apps just need to create an empty ast.Resource, call config.writeResource(), and re-read the config via defineConfig().

export async function defineConfig(env) {
  const plugin = await env.$import(
    "https://cdn.jsdelivr.net/gh/samuelstroschein/inlang-plugin-json@1/dist/index.js"
  );

  const pluginConfig = {
    pathPattern: "./{language}.json",
  };

  return {
    // ...
    languages: await plugin.getLanguages({ ...env, pluginConfig }),
  };
}

Pros

• adding languages becomes possible without editing the inlang.config.js file
• better DX by automatically deriving the languages

Cons

• deriving languages could become ambiguous
• the source of truth for languages is outside the inlang.config.js file

---

Inspired by @ivanhofer's remarks and his plugin https://github.com/ivanhofer/inlang-plugin-typesafe-i18n

[samuelstroschein]

writeResources() would still require to account for non-existent resources.

[samuelstroschein]

Shipped by @ivanhofer, @NilsJacobsen and @NiklasBuchfink recently.