last translations tww-project, german are not ok

[urskaufmann]

Describe the bug
there have been several translation in the last days (189 strings by geopint): thanks for the work.
But sorry: there are too many bad translations: There should the used the DSS-Terms and not some other translations:
Example: renovation_demand is Sanierungsbedarf, not Renovationsbedarf, urgency_figure is Dringlichkeitszahl, not Dringlichkeitswert. etc.
And the idee of the class-shortcuts as prefix is not realized in the translation. I think it should be handled as in QGEP, where we had also these shortcuts in german (there are also defined in the TWW-Database) and in german they are with capital letters.

@PeterZamudio and Sandro: Pleace do better not translate than translate like this.

[ponceta]

@sjib I do think we need to set some common reference before going further on what you provided me, renovation_demand is Instandstellung...

Glossaries have been set today on Transifex but they do not enforce anything. (Anyone is free to uses the provided strings) We could add people as "réviseurs" to deal with specific translations.

Glossaries are not providing any hint on fk_values, relation_values (co_renovation_demand), technical values (detail_geometry3d_geometry) so we maybe have to think of that too.

You can have a look at the proposed values here :
https://docs.google.com/spreadsheets/d/1qeoCVwdOLyhdLHqVKsOzZ5zyle3iiQd1pVTFKU_rbGU/edit?usp=sharing

[sjib]

That is a tricky one

We have

• structure_part.renovation_demand -> BauwerksTeil.Instandstellung

and

• wastewater_structure.renovation_necessity -> Abwasserbauwerk.Sanierungsbedarf

[sjib]

Here an example how to correctly translate the prefixes (shortcuts) of classes (these can be found in tww_sys.dictionary_od_table)

Example: co_venting become de_Entlueftung

[sjib]

Example venting (attribute) - has now the hints in the Glossary tab and the translation can be copied from there.

[sjib]

The layer name should not be translated (have also not been translated in qgep), as we don't know whether this would break the project.

Check for the context: project\:layers\:cover_venting

[sjib]

@urskaufmann Can you document which fields not to translate (was this your comment about that #398 (comment))? Could you add a screenshot of an example?

[urskaufmann]

Be careful about value_en.
First: all value_en are at the moment translated. But there will be more "value_en" if there will be more value_lists in the project.

When translating it's important to know, where the word is coming from. In "more info" you find for every text the context. "value_en" has two contexts:

1. it can be a value_relation value: then it has to be translated to value_de or value_fr:
   
   green: table or view, field. blue: valuerelation value
   
   effect: in the translated project, there will stand value_de / value_fr instead of value_en - you have your language.

2. it can by a field alias (name of the attribute of a table or of a view). All other fieldaliases should be translated, but not field-aliases of value lists (Wertetabellen). Becaue if you do this, there will be two fields with value_de after the translation. The value relation goes to the field with name value_de. QGIS will take the first field with value_de. This is the field with the english values, but has alias value_de. Your valuelists in the attributes form will be in english!
   
   these blue value_en should keep his name.
   
   Do not translate field aliases of value list!.

Value lists are tables with name "classname"_"fieldname". In the example: class reach_point, field elevation_accuracy

[ponceta]

@urskaufmann thank you for this very precious feedback, I fixed the FR translation on that matter using this query filter :

text:value_en context:fieldaliases