Der Sinn von übersetzten Modellen (TRANSLATION OF) ist m.E. die Unterstützung der Mehrsprachigkeit, insbesondere für die Datenerfassung und die Datennutzung, z.B. in GIS-Systemdialogen. Da INTERLIS 2.4 nurmehr ein einziges XML-Format kennt, hat auf dieser Stufe die Übersetzung keine Bewandtnis (mehr) – vgl. Translation-Of Modelle in Interlis 2.4.
Sehe ich das richtig, dass bei übersetzten Modellen (TRANSLATION OF) ili2db immer das Urmodell (meist DE) in der DB anlegt?! Das wäre in meinen Augen ein grober Mangel der Tools, der schnellstmöglich behoben werden müsste!
Urmodell:
INTERLIS 2.4;
MODEL TestDe_V1 (de) AT "mailto:localhost" VERSION "20250605" =
TOPIC ThemaDe =
CLASS KlasseDe = NameDe: MANDATORY TEXT; END KlasseDe;
END ThemaDe;
END TestDe_V1.
Übersetztes Modell:
INTERLIS 2.4;
MODEL TesteFr_V1 (de) AT "mailto:localhost" VERSION "20250605"
TRANSLATION OF TestDe_V1 ["20250605"] =
TOPIC ThemeFr =
CLASS ClasseFr = NomFr: MANDATORY TEXT; END ClasseFr;
END ThemeFr;
END TesteFr_V1.
Auch im Datenerfassungsdialog in QGIS werden dann nur die deutschen Bezeichnungen angezeigt, also „NameDe“ und nicht, wie erwartet und gewünscht, „NomFr“.
PS: wenn man mit dem QGIS Model Baker arbeitet, kann im Verlauf des Wizards die Sprache des Projekts nicht gewählt werden, diese Option erscheint zwar, ist aber ausgegraut und es steht nur die Originalsprache des Modells zur Verfügung.
Test: ich implementiere das DE-Modell in ein GeoPackage. In QGIS erfasse ich dann ein, zwei Dummy-Objekte.
Wenn ich mittels ili2gpkg XML-Transferdaten gemäss dem übersetzten Modell exportiere, erhalte ich ein anderes XML-Format, als wenn ich die Daten gemäss dem DE-Originalmodell exportiere!
Absolut einverstanden! Nur scheint es grad, dass man mit der Formulierung im RefHB eher unglücklich ist. Vielleicht sollte man dem Grund dieser spezifischen Änderung am Transferformat auf den Grund gehen (Sprung zurück ins Jahr 2016 …) und danach entscheiden, wo und wie man Änderungen anbringen soll …
Die Problematik ist im Zusammenhang mit der Einführung des DMAV aktuell sehr akut. Die Romandie hat grosse Probleme mit dem Modell bzw. der franz. Übersetzung, weil das offenbar – entgegen auch meiner Annahme – mit den Tools nicht korrekt umgesetzt werden kann.
Hier scheint es klar einen Mangel in den Tools zu haben wofür es schnell Lösungen braucht…
Ich denke es ist eine Unterscheidung nötig zwischen einem Basis-Werkzeug wie ili2db und einem darauf aufbauenden Werkzeug wie Model Baker. Ich meine, man kann nicht selbstredend davon ausgehen, dass ein Erfassungswerkzeug wie QGIS mit Model Baker nun automatisch Mehrsprachigkeit unterstützt, nur weil das RefHB von INTERLIS Mehrsprachigkeit vorsieht. ili2db ist „nur“ eine Bibliothek, welche eine Schnittstelle zwischen dem objektorientierten INTERLIS und relationalen Datenbanken anbietet. Natürlich wird bei der Entwicklung von ili2db mittlerweile Rücksicht auf die Anforderungen von Model Baker genommen. Aber ili2db ist grundsätzlich nicht für mehrsprachige QGIS-Formulare zuständig und verantwortlich. Sondern - und da sind wir uns ja einig - für die Umsetzung der Regeln, wie sie im RefHB definiert sind (und dies auch nur, sofern es einen Auftrag gab, dies zu implementieren …).
Ich habe den Anspruch, dass die Basis-Werkzeuge die Mehrsprachigkeit gemäss RefMan sauber unterstützen:
der Compiler soll für alle Modellübersetzungen das gleiche XML-Format erzeugen.
die ili2db-Familie soll übersetzte Modelle implementieren, und nicht Ur-Modelle, weil man mit übersetzten Modellen arbeiten will (wozu wären sie sonst gut?)
der ilivalidator muss mit sprachspezifischen Dateninhalten, übersetzten Modellen und den vereinheitlichten XML-Format umgehen können.
Aufbauende Werkzeuge müssen das dann übernehmen. Ich meine, dass der QGIS Model Baker hier schon nicht „zu viel“ selber tut: er steuert ja ili2db an. Wenn mit ili2gpkg aus einem FR-übersetzten Modell doch ein deutsches DB-Schema erstellt, ist es folgerichtig, dass der Model Baker daraus nichts anderes machen kann als deutsche Erfassungsdialoge.
Kann mir jemand wie einem 5-Jährigen erklären, was jetzt genau im Kontext des DMAV korrekt wäre?
Gibt es ein Transferformat mit z.B. französischen XML-Elementnamen überhaupt?
Falls immer deutsche (Originalsprache) XML-Elementnamen verwendet werden müssen (in der Transfergemeinschaft), welche Sprache steht bei den Aufzählungstypen? Auch die Originalsprache?
Gemäss RefMan gibt es nur noch ein XML-Format, nämlich gemäss (deutschem) Original-Modell. Z.B. der Compiler erzeugt mir aber heute ein XSD mit franz. Elementnamen, was gemäss ILI 2.4 falsch wäre.
Die Aufzähltypen werden ja als Dateninhalte gespeichert, die übersetzt wurden. Sie werden als XML-Werte serialisiert, nicht als Tags. Demzufolge müssten die dann schon französisch erscheinen, wie die Textattribut-Inhalte z.B.
XSD: Weiss nicht. Welche Rolle spielt das XSD im Referenzhandbuch / in der Spezifikation? Der Compiler übersetzt halt ein INTERLIS-Modell in ein XML-Schema. Oder steht da was dazu im Referenzhandbuch wie es bei TranslationOf-Modellen passieren muss?
Aufzähltypen: Die „Dateninhalte“ werden aber im Modell definiert. Und sind nicht beliebiger Text.
ili2db erstellt mit „Magie“ in der Datenbank die abgeleitete Sprache der Wahl, d.h. Tabellennamen und Aufzähltypen/Domains sind in der abgeleiteten Sprache. Beim Export wird ein korrektes Originalsprache-XML hergestellt. Wie Modelbaker damit umgeht, muss ili2db nicht wissen.
ilivalidator muss nur mit dem Originalsprache-XML umgehen können. Was mich aber wieder irritiert, wenn die Aufzähltypen in der abgeleiteten Sprache vorhanden sein dürften.
XSD: Ok, kann man so argumentieren. Aber welchen Stellenwert hat das XSD in der Spezifikation? Das XSD interessiert mich in der Regel ja nie. Es gibt ein Modell und das Austauschformat, das sich aus dem Modell ableitet und nicht aus dem XSD (in der INTERLIS-Welt). Sonst würden wir auch gegen das XSD testen und nicht gegen das Modell.
Aufzähltyp: Dann benötige ich für die Prüfung von Transferdateien, die aus einer abgeleiteten Sprache stammen, mehrere Modelle und nicht nur mehr das Originalmodell. Fände ich auch unglücklich.
Diese Anpassung ist aus meiner Sicht beim 2.4-Update wohl schlichtweg untergegangen. Die Taskliste orientierte sich damals primär an der Auflistung im Absatz „Erweiterungen von INTERLIS 2.4 gegenüber INTERLIS 2.3“ des Kapitels 1.2
einer unserer Entwickler schaut sich diese Problematik codeseitig an. Ich melde mich dann mit den Inputs wieder.
@peterstaub Unserem Entwickler ist aufgefallen, dass Dein übersetztes Modell ebenfalls ‚de‘ als Sprache referenziert:
INTERLIS 2.4;
MODEL TesteFr_V1 (de) AT "mailto:localhost" VERSION "20250605"
TRANSLATION OF TestDe_V1 ["20250605"] =
TOPIC ThemeFr =
CLASS ClasseFr = NomFr: MANDATORY TEXT; END ClasseFr;
END ThemeFr;
END TesteFr_V1.
Die Aufzähltypen sind im Modell definiert und müssen von der Bedeutung und der Menge her mit dem Originalmodell übereinstimmen. Daher bin ich der Meinung, dass diese beim Datenexport in die Originalsprache übersetzt werden müssen.
Beim Erzeugen der TRANSLATION OF-Modelle für DMAV ist mir aufgefallen, dass sich die Elemente „IMPORTS“ nicht automatisiert mit dem UMLEditor übersetzen lassen. So müsste das TRANSLATION OF-Modell „Immeuble“ das Typenmodell „PositionTexte“ (mit den französisch bezeichneten Elementen „position“, „texte“, „orientation“ etc.) importieren können, was im UMLEditor nicht berücksichtigt werden kann.
