Support for translated models

[m-kuhn]

Interlis has a concept with TRANSLATION OF models. A very good example are the ARE models where there are the models Nutzungsplanung_V1_1 (German base) with translation models PianiDiUtilizzazione_V1_1 and PlansDAffectation_V1_1.

The translated models are listed in the search interface of model baker, but if selected, the base language version is created. I.e. if "PlansDAffectation_V1_1" is typed in the model text edit, it is found (in French), but the generated db structure is in German.

The --nameLang parameter can be used to control the language of the generated db structure.

I see several possibilities:

1. use the language from the model (if PlansDAffectation is selected -> use French)
2. use the language of the system (QGIS language)
   3.a. add a combobox to allow selecting a language from a list of languages
   3.b. add a combobox only listing languages supported by the model

I think 1. would best match user expectations.
And could potentially be implemented as an ili2db switch (--useModelLanguageCC @claeis)?

[claeis]

It is possible to implement such an ili2db switch. However, I'm not sure if it offers the best user experience. I think a user has always the same preference, depending on his personal language skills. For one german speaking user this might be de->en->fr, for another it might be de->fr->en. (That's why I would prefere a global setting)

[m-kuhn]

True, if we look at it as order of preference - and not just a single preferred language - we'll need a (global) configuration.

What I wonder

• How should this originally be initialized?
• How many user will take the time to fine tune this away from the original value?
• How often does a user who prefers his model in German search for "Plans d'affectation" (and not "Nutzungsplanung")?
• In your example, how many models will be available in French and English (but not German) so it effectively makes a difference?

I could also very well imagine a global setting, and as long as this is not set default to the model language. Assuming that the model language is an implicit user choice expressed through the language used in the model search bar.

[romefi]

I think the language should be set by the model name the user chooses ("Nutzungsplanung" german, "Plans d'affectation" french, ...)

• My user expectation would be the model to be implemented in that language the model name assumes
• It think the usecase to import a model in a different language than the one set in global configuration is a real one, like in bilingual cantons or if a german ingeneering company has to set up a model for a french speaking canton/village
• I would not refer to the QGIS default language. Think many people like QGIS in english because it's more fancy, but prefer different model language (i.e. german or french)

[claeis]

Does the name of a table or column in the DB really matter? Is it not the user interface that matters?

[m-kuhn]

The most important part is the UI. An untranslated DB has the advantage of stability for logic like post sql scripts. A translated DB has the advantage of being easily introspectable by the user.

If we go for untranslated DB, do you see a way of getting the translated information (mapped to the sql objects) from the TRANSLATION OF model to QGIS?

[claeis]

More or less three variants:

1. a new t_ili2db table
2. t_ili2db_meta_attrs and the language/name pairs as json in column attr_value
3. t_ili2db_column_prop+t_ili2db_table_prop and the language/name pairs as json in column setting

2.) and 3.) have the disadvantage of a json encoded value (not so easy to edit by user)
3.) has the disadvantage that the same ili element might appear in different entries (due to o/r mapping)
1.) has the disadvantage of a new table

[claeis]

What would be the required information (per language)?

• name/label
• mnemonic
• short description/tooltip
• long description
• symbol/icon

Would it also be required to differentiate between different output screen sizes (e.g. between mobile and desktop)?

[claeis]

see claeis/ili2db#350

[romefi]

Check with swisstopo, if they're interested

[signedav]

Create the tables in the derived name is implemented here claeis/ili2db#221

What we need now to create the layernames / fieldnames is the "mapping" mentioned here #402 (comment) - I requested an estimate there.

[signedav]

As far as I understand the tendency of this thread we would keep as default the untranslated database. And maybe an additional request can be to be able to set the language that will be passed as --nameLang.

[signedav]

There is a new metatable t_ili2db_nls. It maps the iliname to the multilanguage names. Maybe there is an indicator that the user has imported a translated model (see claeis/ili2db#350 (comment)) and if so Model Baker should do the mapping to create layernames / attributenames etc.

Additionally Model Baker has to ignore t_ili2db_nls as a layer...

[signedav]

claeis/ili2db#350