Rethink FormIO translations

CharString commented 1 year ago

Thema / Theme

Other

Omschrijving / Description

FormIO translations are a mapping of [string in source language] ⇒ [string in target language]

Given we are in control of constructing that mapping, we could choose to make it [message identifier] ⇒ [string]

Added value / Toegevoegde waarde

While it is still nowhere close to ICU's MessageFormat or Fluent in terms of expressibility and power to create naturally sounding translations for languages that have different plural forms, conjugations and gender, it would solve 2 things.

string collisions; FormIO will run all strings through this mapping and some strings in the source language may collide with semantically different meanings in different contexts. Some may even collide with the default FormIO strings! A message-id constructed from on this context, say a concatenation of {formdefinition,formstepid, componentkey, ...}, would lock the string to its context.
interpolation of variable values into label strings, changes these, so these will most likely not occur as a key in the mapping, or collide with a different key. This is now circumvented in #2501 by translation during the interpolation step.

Aanvullende opmerkingen / Additional context

This would add a difference between forms that don't use translations and forms that do. This could be solved by always having translations on, but that's undesirable. Or, given messageids should uniquely identify the location where they are used, a function (and it's inverse) exists that can go from untranslated to translated for a given language code.

sergei-maertens commented 1 year ago

I'd postpone this and revisit if/when we manage to replace the formio renderer with something under our control, that would allow us to define the translation machinery ourselves, allowing us:

to take into account the scope/context of a translations
use ICU's messageformat (and use server-side tooling to pre-compile the translation assets!), bringing all the frontend translations in line (there's also backend tooling for ICU for server-side rendering in PDFs etc.)
handle the translations enabled/disabled case more elegantly

CharString commented 1 year ago

But pigs with lipstick look so cute! :)

sergei-maertens commented 11 months ago

Likely solved by storing all translations on the component itself and creating a natural context, which avoids collissions.

The message format to ICU is a bigger thing, so leaving this open for that reason.

open-formulieren / open-forms