Meine erste Übersetzung! Las alle Anleitungen. Hoffe, mich richtig eingebracht zu haben!

Einer der Schwierigkeiten für mich war, dass der englische Originaltext bereits fehlerhaft war. Tippfehler wie "Mange, Transnslation, Enalble". Singularangaben wo Singular/Plural-Angaben sinnvoller wären wie "Translation Not Found" statt "No translation(s) found". Vorübergehender Entwurfs/Platzhalter-text wie "desc here."

Hab dann einfach versucht stur so nah wie möglich am Original zu sein. Das Original kann sich ja bei der nächsten Überholung verbessern, dann kann die Übersetzung folgen. Aber die Übersetzung sollte quasi nicht vorauseilen (vorausdenken) in welche Richtung sich die Übersetzung ändern könnte/sollte im Sinne von "Was ja eigentlich gemeint ist".

Was ist eigentlich der richtige Weg, wenn das Original auch korrekturbedürftig ist? Geht das auch über das Localize Projekt und seine Methoden, aufdass es den Ball an den Entwickler semi-automatisch zurückspielt? Oder muss man informell dem Entwickler die Änderungsvorschläge zuschicken, darauf warten dass die dann bei der nächsten Version eingehen, und dann übersetzen? Und von wegen nächste Version: Gibt es auch Modul Versionsprünge, wo quasi nur die Strings erneuert werden ohne jegliche Funktionsänderungen? Oder gibt es da auch Lösungen abseits des Quellcodes eben durch Localize Methoden? Ich denke da an einen fehlerhaften englischen Quellcode-String der mittels englischem Sprachpaket technisch gesehen übersetzt (de fakto verbessert, umgegliedert, etc) wird, und somit in der Benutzerschnittstelle den Fehler quasi "überdeckt".

Danke für Auskunft!

Mfg, Stefan Nowak

Comments

tobiasb’s picture

Zu den schlechten englischen Texten:

Patch erstellen für das betroffende Modul. Ein Maintainer wird sicherlich keine neue Version rausbringen, nur wegen schlechten Strings, sei denn alle sind falsch :D.
Am besten dann einfach hier das Project ändern und wenn Patch einfllossen, wieder zurück auf "German translation".

Auf der eigenen Website, kann man solche Strings überschreiben lassen via settings.php oder dem Modul http://drupal.org/project/stringoverrides.

Thomas_Zahreddin’s picture

Assigned: Unassigned » Thomas_Zahreddin
Status: Active » Closed (fixed)

Hallo Stefan,

vielen Dank für Deine Übersetzungen und dass Du Dir die Mühe gemacht hast, die Anleitungen zu lesen (ich hoffe es war nicht all zu abschreckend).

Englisches Original fehlerhaft / korrekturbedürftig:
hilft nur ein issue bei dem jeweiligen Modul zu eröffnen, meine Idealvorstellung ist, dass alle Module von Muttersprachlern geprüft werden, bevor sie veröffentlicht werden (Weihnachten und Ostern sind noch nicht zusammengefallen …). Der Hintergrund: Natürlich ist die Regel, dass Texte in Modulen auf Englisch geschrieben werden, nur ist Englisch nicht die Muttersprache aller Programmierer.

Für manche Entwickler ist ein Patch noch einfacher zu verwenden, aber das erfordert entsprechendes Wissen und Werkzeuge beim issue-Ersteller. Die Wahrscheinlichkeit steigt, aber es gibt keine Garantie, dass ein Patch angenommen wird.

Zur Übersetzung stehen im Localization-Server nur Releases zur Verfügung (alpha, Beta …), aber keine *dev-Versionen. Was Bestandteil eines Releases / einer Version ist, liegt in der Entscheidung des Entwicklers.
Wurde z.B. ein Tippfehler im englischen Original verbessert, so ist der alte und der neue englische String nicht mehr identisch und von daher gilt die Übersetzung nur für den alten String. Tools wie Virtaal erkennen die Ähnlichkeit der Strings (und halten alle bearbeiteten in einer Datenbank) und schlagen die Übersetzung des alten Strings für den neuen vor, so dass diese mit einer Tastenkombination übernommen werden kann. Dieses Bereithalten von Originalstrings und Übersetzungen heißt 'Translation Memory', der Localization-Server verfügt (noch) nicht über diese Funktion.

Am Original bleiben
Also, da nicht alle Entwickler englisch Muttersprachler sind, sind schon die Originale oft genug nicht optimal. Zum anderen unterscheidet die deutsche Sprache zwischen Du und Sie, wir haben uns für die Übersetzung entschieden die Sie-Form zu verwenden. Das muss natürlich nicht immer mit der Intention des Autors übereinstimmen. Letztlich sagt nur der Sourcecode was tatsächlich passiert (nicht immer was gemeint war), aber es ist extrem aufwendig (sprich: faktisch nicht machbar) jeden String im Code zu suchen und im Ablauf zu erleben, bevor man diesen übersetzt. Daher nehme ich mir die Freiheit und die meisten Übersetzer sehen das ganz ähnlich, dass die Übersetzung eher das Gemeinte ausdrücken soll, als eine wortwörtliche Übersetzung. Denn das Ziel ist ja, dass ein Anwender versteht, was zu tun ist oder welche Möglichkeiten die Website zu einem bestimmten Zeitpunkt bietet.

:-)

Hoffe Deine Fragen sind beantwortet, ansonsten gerne einen weiteren Kommentar anhängen.

porg’s picture

Thomas, danke für Deine Erklärungen!

Zusammengefasst: Wenn Fehler im Original: An Entwickler wenden: Formell mittels Issue Tracker oder informell/direkt via Email/PM/Chat. Besonders bequem kann man's ihm machen wenn man ihm einen Patch anbietet, den er nur mehr ins Versionskontrollsystem einspielen muss. Und wenn man's nur am eigenen Server überschreiben will dann mittels stringoverrides wie von @tobiasb beschrieben. Und um dann mit wenig Aufwand die Tippfehler-korrigierten Originalstrings wiederum den am ehesten entsprechenden Übersetzungen zuzuweisen, nimmt man sowas wie Virtaal.

Noch eine Frage: Auf der Localization Seite für das Modul Translation404 sehe ich meine Übersetzungen von Dir bereits als übernommen. Wenn ich allerdings auf meinem Server mittels Translation Update (Site Building > Translate Interface > Update oder /admin/build/translate/update ) aktualisieren will, ist der Letztstand 23.10.2010, von meiner heutigen angenommenen Übersetzung vom 26.10.2010 noch keine Spur! Wann erscheint die dort?

Thomas_Zahreddin’s picture

Generieren neuer Downloadfiles (*.po) läuft in der Infrastruktur von Drupal.org und dauert in der Regel wenige Stunden bis maximal Tage, der theoretische Höchstwert liegt bei 28 Tagen, dieser sollte aber immer deutlich unterboten werden. Dieser Höchstwert würde dann zustande kommen, wenn für alle Projekte und in allen Sprachen alle *.po-Dateien neu erzeugt werden müssten.

Praktisch müssen nicht alle po-Dateien erzeugt werden, weil nicht für alle Sprachen und jede Version eine Projektes Übersetzungen existieren. Es werden nur Dateien neu erzeugt, für die auch tatsächlich eine Änderung vorliegt. Daher liegt die Zeit für neue Dateien in der Regel unter 3 Tagen.

porg’s picture

1) Verstehe nun, und warte die nächsten maximal 3 Tage einfach ab.

2) Übrigens viele der Fragen und Antworten aus diesem unserem "Issue" wären wohl wertvolle Infopunkte im Willkommens/Anleitungs-Text der deutschen Übersetzungsgruppe. Oder? Wenn ja, wer bringt das dort ein? Du? Ich? Wenn Du, kannst gerne einfach Textteile kopieren.

porg’s picture

Irgendwas stimmt da nicht!

Wenn ich auf meinem Server mittels Translation Update (Site Building > Translate Interface > Update oder /admin/build/translate/update ) aktualisieren will, ist der Letztstand noch immer 23.10.2010, der durch mich hinzugefügte Letztstand vom 26.10.2010 auch heute am 08.11.2010 noch immer nicht verfügbar.

porg’s picture

Am Server liegt:
http://ftp.drupal.org/files/translations/6.x/translation404/
translation404-6.x-1.2.de.po 30-Oct-2010 01:00
Und dennoch meint das sture "Translation Update" alles auf Letztstand.

Woran kann das liegen?

Habe diese Datei versuchsweise aus dem Ordner heraus bewegt:
sites/all/modules/translation404/translations/modules-translation404.de.po"
Aber auch bei neuerlichem "Translation Update" Versuch, wieder nichts.

Ich weiss nicht weiter.

Thomas_Zahreddin’s picture

da gibt es einen Fehler im l10n_update - Module (wahrscheinlich beziehst Du Dich auf diesen)

- nimm die dev-Version
http://ftp.drupal.org/files/projects/l10n_update-6.x-1.x-dev.tar.gz

porg’s picture

Jawohl, nach der Aktualisierung von l10n_update auf 6.x-1.x erkannte dieses dann auch die neueren Übersetzungen.
Problem gelöst.

joachim namyslo’s picture