introduce concept of system wide fallback logic

[ivanhofer]

Problem

In real world applications there will be cases where not every Message get's translated to all languages. Some might not be important because e.g. features are hidden in certain markets or maybe because a feature needs to be shipped as soon as possible when translators didn't had the time to write all translations. In this cases having a fallback mechanism is important to not render empty strings in the UI.

The SDK requires such a functionality, but also the IDE extension could benefit from it so developers can see what will be rendered if a message is missing in a certain language. It also makes sense to include the fallback logic into the Editor so translators can also immediately see what text get's rendered.

Solution

So adding a new property to the root of the inlang.config.json would make sense.

	fallbackLanguageTag: FallbackLanguageTag

Options

We don't have to introduce all options for now, but sourceLanguageTag and none should be the options we support at the beginning.

type FallbackLanguageTag = 'sourceLanguageTag' | 'none' | 'bestMatch' | 'sameLanguage' // | ... others

• none: No fallback variant get's rendered (empty string if languageTag is missing)

• sourceLanguageTag: Always falls back to the sourceLanguageTag

  users preferred languages: de-AT, de, fr
  source language: en
  available languages: fr, en
  fallback: en
  

• bestMatch: Finds the first match in the users' preferred languages.

  users preferred languages: de-AT, de, fr
  source language: en
  available languages: fr, en
  fallback: fr
  

• sameLanguage: if no exact match, it takes an variant from another country with the same language.

  users preferred languages: de-AT, en
  source language: en
  available languages: de-DE, en
  fallback: de-DE
  

Counts for all except none: If no match is found, the sourceLanguageTag get's chosen.

Should we make the option optionally an array? So people can mix strategies however they like e.g. ['sameLanguage', 'bestMatch'].

Alternative

Or maybe should a "Plugin" provide a fallback logic written in JS to also accomplish complexer scenarios?
We can provide 2-3 plugins with common fallback strategies and the rest is up to other developers.

Default

We can hide the option from the config and decide on a default value. But then we can't introduce the "better" variant at a later point because it would be a breaking change.

Anyways we need to come up with a default value.

Implementation

We should provide some utility functions each app can use to "enhance" the messages returned from a plugin. Maybe a variant languageTag: '*' could be added to each message to mark it as the fallback. As each app will probably have minor differences I'm usure if inlangProject should do that already or if each app can decide if it needs to "enhance" all messages or just a single one.

---

@inlang/team please discuss.

[samuelstroschein]

Alternative proposal - Use BCP-47 spec and contain logic in @inlang/language-tag

BCP-47 defines the matching of language tags, see https://www.rfc-editor.org/rfc/rfc4647#page-6.

• Three different matching patterns are described.
• We should implement the three patterns as required.
• For now, we seem to need only need lookup (matching exactly 1 language tag) that should be consistent across the inlang ecosystem.

Pros

• spec compliance with BCP-47
• logic is contained in @inlang/language-tag to use by the inlang ecosystem and web dev community
• simple functions
• no additional inlang.config properties required

Cons

• less flexibility (defining custom logic is prohibited; i think that's good though. Don't deviate from BCP)

Example code

import { lookup, basicFiltering, extendedFiltering } from "@inlang/language-tag"

// for now, I would define in an inland project that the defaultTag is the sourceLanguageTag 
const match = lookup({ tag: userLanguageTag, defaultTag: sourceLanguageTag, availableTags: availableLanguageTags })

console.log(messages.where( { languageTag: match } )

// ... to do in the future once required
// const matches = basicFiltering({ })

[ivanhofer]

BCP-47 defines the matching of language tags, see rfc-editor.org/rfc/rfc4647#page-6.

Great, didn't know this also get's defined in BCP-47 👍

---

Then we don't want to allow to have no fallback at all (none)?

[samuelstroschein]

Then we don't want to allow to have no fallback at all (none)?

For now, I think we are good with lookup only which will always return a language tag.

Returning no fallback is defined in simple and extensive matching in the BCP spec. The use cases are different from our app use case. For example, showing similar documents or emails in other languages where those docs or emails might exist or might not.

[Sansumaki]

i would make it easy. but i‘m not an expert. we already define refLanguage in the config. just use the ref as fallback. but using a spec already solving this issue is always the better solution.