Assign same Enketo UI language (de) for two languages

[DSimon]

Hi there,
we ran into a very specific problem. We want to deploy a multi language form that contains two different german language versions (“normal” german and simplified german language for people with cognitive impairments or learning disability).

Now the goal is to have Enketo’s UI displayed in german language for both german language versions (normal and simplified).

Problem: When assigning the language code “de” to both languages’ label column, the contents of both languages’ label columns are displayed together in Enketo. This is definitely not an option.
Assigning a dummy language code (e.g. “xx”) to one of the languages (leaving the other with “de”) leads Enketo’s UI to be displayed in english for the “xx”-assigned version. Also not an option (only our last option if this cannot be solved.)

We tried a workaround on our server editing this file: https://github.com/enketo/enketo-express/blob/master/app/views/index.pug

Approach 1: add a new when-statement

when “xx”
li= t(“langs.de”)

Resulting in english UI language

Approach 2: modify an existing when-statement (Swahili) to point to german UI language settings and tag the other german language with “sw”

when “sw”
li= t(“langs.de”)

Resulting in swahili UI language

Now we suppose that modifying this file is not sufficient (or even the wrong place?) to get what we aim for. Can anyone with deeper knowlege regarding the UI language mapping in Enketo point us to the spots to look at and modify?

Thanks in advance
Daniel

[wroos]

Maybe, you can try with the iso 3 letter codes: ger and deu?

[DSimon]

Hi wroos,

just tried both, unfortunately again fallback to english UI. Additionally I validated the form with ODK’s online validator throwing a warning:

The following language declarations do not contain valid machine-readable codes: Einfache Sprache (ger)

So must be a two letter code.

[wroos]

Hi @DSimon,
Really an interesting question, important for accessibility.
Maybe, someone of the core team might help, please: @Kal_Lam, @yanokwa, @Xiphware ?
I am even not sure if the automatic combining of labels with the same 2-letter code, done by Enketo, is ok.

Meanwhile, I tried some more options, e.g. German without code or with DE or ger. Here is an example XLSForm. You can change the columns form German (de) to German (ger) to see more.
Language01.xlsx (11.4 KB)

The problem is if the code is not correct, system elements will show in the internal default, i.e. English, e.g. buttons, system messages like required. This is the effect if you use “(ger)” for example. The messages could be overwritten by ::language (code) or own overall message definition (without ::language), but the button etc. issue would remain - even if the browser is set to German, see screenshot.

Your problem could be solved, if there is a way to change the Enketo (internal) default language. Maybe, there is a solution if the server (or/and device?) system is set to German.

Here the concatenated labels, if the same code (de) is used for two language columns.

Other options might be;
- Clone the project and use two separate DE-language forms and databases, both with identical structure, which could be combined externally.
- Use an initial question to switch between dynamic labels, esp. for questions and hints, based on calculate types. (This would create disadvantages for monitoring and data export, as in label view mode column headers would only show the $-reference ).
- Show the simplified language as hint or guidance_hint.
- Only use the simplified language for the survey

Also, Collect seems not a solution: This app takes one language only, depending on a complex rule. either the default language or the (2nd !) found language code corresponding to the local project language settings, treating (de) and (ger) as the same !

[DSimon]

Hi @wroos,

thanks for digging into this and providing the examples. This exactly matches my observations.

And yes, I agree with all of your solutions. Unfortunately the only viable options for us are to modify the mapping (as we initally tried) or to switch Enketo default UI language to german.

Because we are using Kobo/Enketo for public participation (so no trained enumerators) it is publicly available to everyone and should be easy to use. Creating two versions would be confusing. I also thought about the solution with intoducing an intro question to chose between the two german languages, but since there are also other translations (EN, RU, TR and ES) this would not work out because this question would also be displayed in these languages but without labels, because they are not needed in these translations.

We now went with the most pragmatic solution to have an English UI for the “normal” German translation and a German UI for the simplified German translation.

Unfortunately this came up pretty short termed before the start of the participation, which was today (yes, I should have tested this earlier). So we will go with the English/German UI solution for now.

Maybe it’s also worth creating an issue on GitHub. Or taking this over to the ODK forum as they are now in charge of maintaining Enketo.

Maybe one of the devs can help out with a stable short-termed server side solution and maybe this can generally be solved in a future Enketo release. Would be a nice improvement in terms of accessibility for non-enumerator based surveys (despite being aware that this type of usage is not how Kobo is meant to be used at the core; but from five years of experience using it mainly as a public participation tool, I can say it works pretty well for this purpose).

[wroos]

Hi @DSimon,
If you use (en), I would suggest providing all possible _messages in German in the XLSForm, e.g. required_message, etc. Otherwise, the user will get standard system messages in the system default language, i.e. English.

Of course, systematic pre-tests are essential and should cover the whole process, incl. export/import to other external tools.

[DSimon]

Hi @wroos,

Oh thanks, important hint! Will update the messages asap.

Currently I’m using (xx) to have a fallback to English UI because (en) is in use for the English translation.