Der englische String wird wohl bald geändert. Ich nehme an, dass Änderungen der Orginalstrings dann auch in Transifex angezeigt werden, so dass dann auch die deutsche Übersetzung besser wird.
Danke!
1 Like
Ja, sobald der englische String geändert wird, so ist es auf Transifex einer neuer und wird daher übersetzt.
Ist jemand von Euch auf Mastodon?
Falls ja, dann gerne mal an folgender Umfrage teilnehmen:
Information:
Seit kurzem wird die App " OpenID Connect user backend" übersetzt (Resource auf Tx: user_oidc) .
Die Anwendung nutzt sehr Domänen-spezifische Begriffe wie u. a. “Mapping”, “Audience”)
Nach kurzem Austausch mit @Soko haben wir beschlossen hier einige Begriffe nicht mit Gewalt einzudeutschen, sondern die englischen Begriffe zu übernehmen.
1 Like
Ist es auch. Wenn man weiß wie man der KI das Lügen abgewöhnt. Hier habe ich eine vollständige Übersetzung von meiner Nextcloud-Instanz gemacht, inklusive Prompt für ChatGPT:
Hallo,
bei der deutschsprachigen Benutzerdokumentation gibt es ein bisschen was zum Korrekturlesen.
Gruß,
Mark
1 Like
Hallo zusammen,
beim Reviewen sind mir zwei String-“Gruppen” aufgefallen, bei denen die Übersetzungen trotz ähnlicher Syntax im Englischen etwas zu verschieden sind.
1. “successfully”-Meldungen
Mal wird “successfully” übersetzt, mal nicht. Oft gibt es auch verschiedene Übersetzungen im gleichen Kontext. Z.B.:
- 642 Files successfully converted → Dateien konvertiert
- 645 File successfully converted → Datei erfolgreich konvertiert
Ich plädiere stark dafür, die Übersetzung “erfolgreich” bei allen entsprechenden Strings wegzulassen.
Wenn eine derartige Meldung erscheint, impliziert sie bereits einen “Erfolg”. Es gibt technisch keinen Unterschied zwischen einer konvertierten/gelöschten/… und einer erfolgreich konvertierten/gelöschten/… Datei.
Wenn man die Vorkommnisse von “successfully” in englischen Strings grob überfliegt, ist die Mehrzahl bereits ohne “erfolgreich” übersetzt, jedoch ist das immer noch weit weg von einer einheitlichen Übersetzung.
2. “Failed to”-Meldungen
Bei Fehlermeldungen, die im Englischen mit “Failed to” beginnen, gehen die Übersetzungen noch weiter auseinander. Dabei fallen vor allem drei verschiedene Varianten auf, die ich am folgenden Beispiel aufzeigen möchte:
- Failed to convert file → Datei konnte nicht konvertiert werden
- Failed to convert file → Fehler beim Konvertieren der Datei
- Failed to convert file → Konnte Datei nicht konvertieren
x konnte(n) nicht y werden
Diese Variante halte ich persönlich für die beste Übersetzung. Sie legt den Fokus auf das Bezugswort (Datei, Ordner, Projekt, Einladung, Einstellungen usw.). Damit ist klar und direkt erkenntlich, was nicht funktioniert hat.
Bezugswort an 1. Stelle und Vorgang/Verb an 4. Stelle
Fehler beim y der/des x
Diese Variante legt den Fokus auf das Auftreten eines Fehlers. Worin der Fehler liegt, wird erst ab ab dem dritten Wort erkenntlich, das den Vorgang beschreibt. Gerade bei beengten Platzverhältnissen oder mehreren gleichzeitig auftretenden Fehlern kann es schwierig werden, die Unterschiede einzelner Fehler festzustellen.
Vorgang/Verb an 3. Stelle und Bezugswort an 5. Stelle
Konnte x nicht y
Die letzte Variante erscheint auf den ersten Blick als die “direkteste” Übersetzung. Jedoch halte ich die Formulierung “Konnte” am Anfang der Meldung für umgangssprachlich und nicht dem Sprachstil der restlichen Nextcloud-Übersetzung entsprechend. Wir sollten hier wie an den meisten anderen Stellen den Infinitiv vorziehen.
Bezugswort an 2. Stelle und Vorgang/Verb an 4. Stelle
Was meint Ihr dazu?
Grüße
Martin
Hallo Martin,
bei beiden Fragen bin ich voll Deiner Auffassung:
x konvertiert
x konnte(n) nicht y werden
Andere Meinungen?
Ciao,
Joachim
Die Festlegung eines Strings sollte beim Entwickler liegen nicht bei uns. wenn im source z. B. successfully verwendet wird, sollten wir das entsprechend auch berücksichtigen.
Mit dem Argument, dass wir die deuschen Strings nicht als Übersetzung ansehen, sondern “besser” als das Original machen wollen, eröffnen wir ein weites Feld für Änderungen an den Texten.
Verbesserungen sollten m. E. grundsätzlich an der Quelle und nicht an Folge-Stellen korrigiert werden.
Das Argument “Wenn eine derartige Meldung erscheint, impliziert sie bereits einen “Erfolg”. Es gibt technisch keinen Unterschied zwischen einer konvertierten/gelöschten/… und einer erfolgreich konvertierten/gelöschten/… Datei.” ist unabhängig von der Sprache. Insbesondere würde das auch für die englischen Strings gelten. Wenn wir erkannte Uneinheitlichkeiten nur bei der deutscchen Variante ändern, bleiben die Uneinheitlichkeiten bei den anderen Sprachen (vermutlich) weiterhin erhalten. Bei “Verbesserungen” sollten wir das gesamte Nextcloud Projekt in Blick haben und nicht nur die deutsche Sicht.
2 Likes
Dem stimme ich absolut zu.
Doch das Nextcloud-Projekt hat Eigenschaften, die hier einwirken
-
aktuell gibt es keine Vorgaben zum Wording von Sätzen. Erst seit wenigen Tagen haben Joas und ich folgendes auf den Weg gebracht: feat(l10n): Improve translation guidelines by nickvergessen · Pull Request #12806 · nextcloud/documentation · GitHub Das ist aber noch weit entfernt von einem Vorgabenkatalog.
Hat jemand Interesse daran an Vorgaben zum Wording mitzuarbeiten? -
Entwickler, welche nicht bei der Company arbeiten, haben keine Vorgaben, sprich können vieles frei entscheiden u. a. die Texte.
-
unterschiedliche Programmiersprachen / Framework → Wir haben sehr wenig Kommentare von Entwicklern. Entwickler für Desktop und Mobile verfolgen andere Ansätze zur Bedienung und haben dadurch auch andere Vorstellungen von Texten z. B. Kurz fassen vs. ausformulierte Texte
Zurück zu den Fragen von @MartinWilco :
1. “successfully”-Meldungen
Ich habe mir angewöhnt, die Übersetzung wegzulassen und kenne dies auch von anderen Projekten.
Stimme also für das “weglassen”.
2. “Failed to”-Meldungen
Stimme für:
x konnte(n) nicht y werden
Wenn hier keine Vetos mehr kommen, so sehe ich das als Beschluss.
Volle Zustimmung.
Ja, dem ist so.
Wer ist hier “wir”? Und vor allem was machen “wir” bei Auffälligkeiten?
EDIT: Ich habe diese Frage etwas provokant gestellt, da es sehr, sehr wenige Beiträge von Übersetzern auf GitHub gibt um die Quelltexte zu verbessern.
1 Like
Und dann versteht man auch wieder, warum Twain ein Büchlein über The Awful German Language geschrieben hat.
Okay, in diesem seltenen Fall ist die deutsche Version tatsächlich kürzer als die englische, aber definitiv nicht schöner. 
Die Deutschen sind einfach Technokraten, überlange Wörter und Sätze, wo es auch einfacher ginge, und alles abzukürzen, wo ein ausgeschriebenes Wort oder wie in diesem Fall, ein zusätzliches Wort eine Aussage etwas netter machen würde 
1 Like
Ich würde mich sehr freuen, wenn all die anderen Sprachen, welche weit von einer Vollständigkeit der Übersetzung entfernt sind, solche schöne Diskussionen führen würden
Danke für den Link zu Mark Twain.
2 Likes
1. “successfully”-Meldungen
Wenn ich alle Kommentare richtig nachvollzogen habe, steht es 3 zu 2 für das Weglassen der Übersetzung “erfolgreich”. Ich biete mich an, die entsprechenden Strings anzupassen.
2. “Failed to”-Meldungen
Aufgrund von Einstimmigkeit habe ich bereits die betreffenden Strings geändert. Schaut man sich die Strings mit Fehlermeldungen an, können wir eine simple Regel aufstellen:
Failed to… → x konnte(n) nicht y werden
z.B. Failed to load file → Datei konnte nicht geladen werden
Error… → Fehler beim…
z.B. Error loading file → Fehler beim Laden der Datei
Strings, bei denen schon im Englischen explizit von einem “Error” gesprochen wird, übersetzen wir auch als “Fehler”. Hier ist die Übersetzung bereits einheitlich.
2 Likes
Super, bitte für beide Sprachvarianten anpassen.
Super, bitte für beide Sprachvarianten anpassen.
Gerade erledigt!
2 Likes
Hallo an alle Übersetzer,
im September findet ja die nächste Conf in Berlin statt.
Kommt jemand von Euch?
Falls Ihr Fragen dazu habt, kann ich vielleicht helfen. Schreibt mir einfach eine PM.
Gruß