Closed simongray closed 2 years ago
Having a language selector next to every multi-language string turned out to be super cluttered. Did not end up merging the changes. However, it might still make sense to have a global language selector that is dynamically populated based on the LangStrings found in the data.
Widget committed in a1a76fe0fd4976cbcf2c1fc6a8ed30ddf768091f and remainder of page localised in 37d32686f044f1c9a8535be21970fa2387db3797.
For the individual labels, it makes sense that they are converted into select elements in cases where multiple languages exist and that the selected language becomes the default as opposed to all of the language info dissappearing from the UI entirely. For example, in some cases it might be nice to be able to see what the English label was as opposed to the Danish. This would be a relatively intuitive, hyperlocal way to inspect this data.
Implementing it entails creating a new component and passing down additional information in many places, e.g. languages and complete result sets.