Translation for the admin project

[effjot]

I’ve implemented the approach mentioned in #30: create a .ts file from the admin project and both translate the field aliases, form titles, layer names etc. and the label_en glossary field references in the attribute forms. This works nicely, the translated project pulls the glossary terms from the label_de column now.

This PR also extends the “create administration project” processing algorithm: The user can select a language (default is the user’s locale) and the corresponding .qm file is copied alongside the target .qgs project file.

At the moment, the .qm files would reside in resources/projects, but they could also fit in i18n. Also, you would need to add the Transifex part of the translation process.

Sorry, the German .ts is in i18n but the .qm is in projects. But that will be obsolete anyway when moving to Transifex.

[Gustry]

I would need to make a PR in QGIS-Plugin-CI to push and pull TS files for Transifex. I will have a look.
QGIS-Plugin-CI is only taking care of *.ui or *.py files.

Thanks for looking into this ticket.

[effjot]

I would need to make a PR in QGIS-Plugin-CI to push and pull TS files for Transifex. I will have a look. QGIS-Plugin-CI is only taking care of *.ui or *.py files.

Thanks for looking into this ticket.

If I understand correctly, qgis-plugin-ci takes tr()-strings from all .py files and pushes them directly to Transifex without an intermediary .ts file? When you wrote “This TS file could be sent to Transifex with a new resource and translated.” in #30, I thought there’s some behind-the-scenes process which I’m not aware of.

We can let this PR rest until Transifex integration is available. In the meantime, my colleagues and I are happy with the local .qm file. ;-)

[effjot]

Another issue with translating the admin project is that the selection lists in the attribute form will be empty if there is no translation of a label. This could be solved by translating all labels in the glossary or by providing a new view with a label column that uses coalesce(label_de, label_en) to fall back to English. I’ve tried the second approach and it seems to work in principle in the “proof of concept” stage.

[effjot]

I’ll fix this today, so it will be ready for the 1.3.0 version

[effjot]

I have made the simple fixes (pathlib, f-strings) in commits fdee520, 3021bca

The last commit (4882db2 “Provide translated glossary…”) is a suggestion on how to handle the translated and untranslated glossary terms. This commit would provide a new view which offers a label and description for every item; if the translations is missing, the English terms are used (also see my comment above #139 (comment)).
With this, the attribute forms can use label and description in the relation widgets without worrying about missing translations, and the attributes in all those forms don’t have to be translated in the .ts file.

The previous commits use the admin project as-is and selection of the proper locale in the attribute forms is done via project translation / .ts file. However, this doesn’t provide a straightforward fallback mechanism, at least within QGIS, as far as I can see. (We could of course create a view that replicates the structure of the glossary table, filling in fallbacks with coalesce.)

I guess the proper way forward depends on what fits your design approach and workflow (esp. Transifex) best.

[effjot]

Ah, and I should rebase. I’ll do that when you have decided which approach to take.

Joyeux noël!