|
Hallo Andreas.
Kurz vorab: Ganz am Ende habe ich Vorschlag 2 eben hinzugefügt.
Der sollte für euch besser umzusetzen sein und weniger kompliziert als Vorschlag 1 sein.
Wir prüfen noch einmal im Detail, ob uns #2 genügen würde.
Du kannst dennoch gerne schon darauf Bezug nehmen.
#1 kannst du gerne auch lesen.
Denke jedoch, dass es viel zu kompliziert ist.
Auch beim Thema UX.
Wäre eher eine Notlösung, schätze ich.
#2 sollte besser gehen.
Bin gespannt auf dein Feedback.
Hier Bezug zu deiner Testseite, und was eigentlich das Problem ist, das wir zu lösen versuchen.
Habe nun eine Seite erstellt auf der Testumgebung.
- versteckter Link
Kann sie jedoch nicht mit auto translate übersetzen.
Soll irgendwie 100 Euro hinterlegen?
Am Ende auch egal.
Habe das Thema oben beschrieben.
Du kannst es gerne ausprobieren.
1. Übersetze die von mir verlinkte Seite mit auto translate Richtung DE.
2. Gib die Überprüfung frei, damit die DE-Version veröffentlicht wird.
3. Ändere nun Inhalt beim Original-Text EN.
4. Nochmal übersetzen mit auto translate
5. Gib die Änderungen sofort frei, damit die DE-Version aktualisiert wird - wichtig, damit CSS-Klassen etc. immer in sync sind zwischen Übersetzungen und Originalinhalt. Wir können mit dieser Überprüfung nicht warten, bis der Übersetzer Zeit hat. Wir müssen nach Inhaltsänderung sofort freigeben, damit CSS-Änderungen bei Content-Updates in sync sind und unsere wichtigen Verkaufsseiten auch bei Übersetzungen keine Darstellungsfehler haben.
6. Gehe nun in die freigegebene Übersetzung und versuche herauszufinden, welche Sätze sich im Originalinhat bei Schritt 3 geändert haben.
So. Ab hier wird es schwierig.
Wie kann unser Übersetzungsbüro nun herausfinden, welche strings im Originalinhalt durch Schritt 3 geändert wurden?
Dadurch, dass in Schritt 5 die Übersetzung freigeben wurde, haben alle strings die gleiche Farbe im ATE.
(Oder irre ich mich?)
Der Vorschlag mit den farbigen Linien funktioniert, soweit ich das sehe, nur, wenn der Übersetzer den auto translate-Vorschlag vor der Freigabe prüft.
Er kann jedoch erst nach der Freigabe prüfen, weil er nicht 24/7 am Rechner neben mir sitzt.
Ich als admin gebe alles sofort frei.
Der Übersetzer kommt später und korrigiert/verbessert die deepL Ergebnisse.
Wir können die Überprüfung der auto translate Inhalte nicht sofort vom Übersetzer durchführen lassen.
Er kann erst nach der Veröffentlichung - irgendwann später, wenn er Zeit hat - drüberschauen und korrigieren.
Dann haben die Linien jedoch alle die gleiche Farbe, weil vorher freigegeben durch uns.
Er kann also nicht einfach die Änderungen erkennen.
Ich hoffe, dass diese lange Erklärung, das Problem verständlich gemacht hat, das wir haben.
Hier ein Lösungsvorschlag
"Felder sollten im ATE nicht gellert werden, wenn der originale Inhalt editiert wurde?"
Ist das korrekt?
Nein.
Es geht im Kern um etwas anderes.
Die Frage wäre: Wie kann ein Übersetzer, erkennen, welche strings sich zwischen der aktuellen Version vom Originalinhalt und der letzten vom user durchgeführten manuellen Prüfung/Korrektur geändert haben.
Da sich via Code eher nicht so leicht herausfinden lässt, was eine manuelle Prüfung ist und was einfach eine Freigabe von auto translated content ist, damit Inhalte endlich live gehen, braucht es vermutlich einen flexibleren Ansatz.
Im Prinzip bräuchte es vermutlich eine Art diff.
Also eine Anzeige, was sich zwischen der letzten Version und der aktuellen im Originalinhalt verändert hat. Dann kann der Übersetzer darauf eingehen und lediglich diese Sätze beachten.
Die Originalinhalt-Versionen, die zu vergleichen sind, müsste der Übersetzer frei wählen können.
Wenn er z.B. im Urlaub war oder wir mehrfach Schreibfehler in DE korrigiert haben, macht es keinen Sinn, dass er nur die letzte Version als Vergleich heranzieht.
Muss irgendwie flexibel sein.
Revisionsansicht ähnlich, wie WordPress sie schon hat, vermute ich.
Jedoch ohne HTML und smooth in den ATE integriert.
z.B. ein einfaches Farbhighlight im ATE nähe vom Originaltext in der linken Spalte.
Zeilen farblich hervorheben, die sich im Vergleich zur ausgewählten Original-Version geändert haben/neu sind.
Diese Info sollte angezeigt werden können - egal, ob der Inhalt von einem Menschen oder auto translate übersetzt wurde. Es sollte auch egal sein, ob die Übersetzung schon freigegeben wurde, oder nicht.
Es geht um den reinen Vergleich von Originalinhalten. Nicht von Übersetzungen.
Keine Ahnung, ob es anders auch einfacher geht. Mit fällt gerade nur das ein.
Beispiel:
DE rev 1:
"Ich mag Blumen.
Blumen sind schön.
Bäume sind groß."
DE rev 2:
"Ich mag rote Blumen.
Blumen sind schön.
Bäume sind groß."
DE rev 3:
"Ich mag rote Blumen.
Große Blumen sind schön.
Bäume sind groß."
Wenn ich nun die auto translate Übersetzung vom aktuellen Inhalt - DE rev 3 - prüfe, dann sollte ich als Übersetzer auswählen können, womit ich den Originalinhalt vergleichen möchte.
z.B. DE rev 1. Zu DE rev 2 war der Übersetzer krank, darum muss er mit DE rev 1 vergleichen und alle Änderungen ab diesem Zeitpunkt prüfen/verbessern.
Der Übersetzer muss dann direkt sehen können, dass nur die ersten zwei Sätze sich im Vergleich zum ausgewählten Originalinhalt DE rev 1 verändert haben.
So könnte der Übersetzer herausfinden, welche einzelnen strings er sich seit seiner letzten Prüfung/Korrektur anschauen muss.
Der Übersetzer müsste nun natürlich wissen, wann er das letzte mal die Übersetzung kontrolliert hat, damit er die richtige Revision als Vergleich auswählt.
Das berücksichtigt mein Punkt noch nicht.
Das Ganze erscheint mir überaus komplex.
Habe jedoch keine Andere Idee, wie wir die Zusammenarbeit mit einem professionellen Übersetzer weiter automatisieren können.
Es macht keinen Sinn, wenn wir jeden Satz, den er sich anschauen soll, manuell via Mail senden müssen.
Macht auch keinen Sinn, ihn jedes Mal alles ansehen zu lassen, wenn sich nur ein, zwei Sätze oder ein Satzzeichen im Originalinhalt geändert haben.
Kannst du grob verstehen, was wir meinen?
Also, was aktuell unser "Problem" ist und was wir zu erreichen versuchen?
Lösungsvorschlag #2 - viel einfacher
Eine Alternative könnte es sein, dass ein Übersetzer im ATE übersetzte strings als "geprüft/verifiziert" markieren kann.
So könnte ein professioneller Übersetzer ebenfalls dafür sorgen, dass deepL-Inhalte qualitativ von ihm geprüft und nicht doppelt kontrolliert werden müssten.
Also "Hallo Markus => Hello Markus" = geprüft ✔️.
Wenn der Originalinhalt nun geändert wird, und der Übersetzer ATE anschaut, sieht er direkt, dass er diesen string schon einmal geprüft hat und muss seine Zeit nicht noch einmal damit verschwenden.
Alles was im ATE ein Häkchen (geprüft) dran hat, muss ein Übersetzer beim nächsten Text-Update nicht beachten.
Netter Bonus: Diese Info (geprüft/verifiziert) könnte WPML künftig ggf. direkt mit dem translation memory linken, sodass global/seitenweit komplette Sätze direkt wiedererkannt und als "geprüft" angezeigt werden.
Im Prinzip wäre das Ganze dann eine Art erweitetes Glossar. Ein index mit verifizierten strings, die der Übersetzer sich künftig nicht mehr anschauen muss.
Cool wäre dann natürlich, wenn ich, wie auch beim Glossar schon vorgeschlagen, Sätze seitenweit rückwirkend austauschen kann, falls eine verifizierte Übersetzung doch einmal angepasst werden soll.
z.B. weil sich ein Fehler eingeschlichen hat. Kann ja mal passieren.
Bin gespannt auf euer Feedback, besonders zu Vorschlag #2.
Der erscheint mir weniger kompliziert und erreicht unser Ziel ebenfalls.
|
