Allgemeines zu Übersetzungen im WP Kosmos

1. Darf jeder da einfach seine Übersetzung eintragen, auf Suggest klicken?

Alle, die sich auf WordPress.org registriert haben.

1. … prüft das jemand?

Dafür gibt es Project Translation Editors, die bezogen auf einzelne Themes und Plugins die Befugnis erhalten haben, Übersetzungen freizugeben und die Global Translation Editor, die auch Übersetzungen für den WordPress Core freigeben und PTE freischalten.
als PTE wirst du üblicherweise freigeschaltet, wenn du dich bereits mit verwertbaren Übersetzungen beteiligt hast, die Richtlinien einhältst und das Glossar (eine Sammlung festgelegter Übersetzungen) verwendest.

1. Was habe ich selber davon?

Viel Arbeit. Als GTE zusätzlich viel Verwaltungsaufwand, regelmäßige Teilnahme an Meetings und Rückfragen, wieso es nicht schneller geht. (Zumindest meine Erfahrung.)

Du bekommst allerdings einen tieferen Einblick in Plugins oder eben auch neue Festures im Core. Kann mal für eine Weile interessant sein.

Meine Motivation war damals, dass einiges wirklich schlecht übersetzt war. Aber die allgemeine Erwartungshaltung lässt die Motivation schnell sinken.

1. Muss man warten, bis die nächste Aktualisierung des Plugins, dessen Sprachdateien kommt?

Sobald ein Plugin/Theme zu mehr als 95% übersetzt wurde, wird die Übersetzung automatisch gepusht. Nachträgliche Änderungen werden zweimal täglich an Websites verteilt.

Also da kommen mir die anfangs erwähnten egoistischen Methoden einfacher vor.

Stimmt. Macht weniger Arbeit. Es lohnt sich, ein Freeloader zu sein. Bringt allerdings das Projekt nicht weiter. Wenn dir das egal ist … Loco Translate.

Wobei es da auch oft Probleme gibt, weil manchmal hat man mit Poedit keine Chance, etwas zu verändern.

Das Problem hast du, sobald der Entwickler (oft aus Unkenntnis oder Nachlässigkeit) keine Übersetzungsfunktionen verwendet. Manchmal hilft es, den Entwickler darauf anzusprechen und kostenlose Hilfe anzubieten. Manchmal hat der Entwickler aber einfach keinen Bock, hält deine Anfrage für eine Zumutung und meldet sich nicht mal. Alles erlebt.

Achso, ich sollte vielleicht mehr im Sinne der WordPress-Community schreiben? Also … Übersetzen ist voll geil und macht riesig Spaß und bei Übersetzungen vom Core taucht sogar dein Name auf der Seite der Mitwirkenden auf, die niemand liest. Du darfst dich von der Community beschimpfen lassen und bekommst garantiert jeden Fehler unter die Nase gehalten. Das ist doch was?

Vielleicht mag Angelika (@la-geek) noch ein paar Sätze dazu schreiben, die etwas motivierender klingen.

Sobald ein Plugin/Theme zu mehr als 95% übersetzt wurde, wird die Übersetzung automatisch gepusht.

Wurde geändert auf 90 % -> https://make.wordpress.org/polyglots/handbook/frequently-asked-questions/#strings-are-validated-when-are-they-taken-into-account-for-download

Du darfst dich von der Community beschimpfen lassen und bekommst garantiert jeden Fehler unter die Nase gehalten.

Joa, von „Danke, Danke, Danke“ bis hin zu Anspruchsdenken, beleidigten Reaktionen, Vorwurf der Besserwisserei & co ist so alles dabei.

Du bekommst allerdings einen tieferen Einblick in Plugins oder eben auch neue Festures im Core. Kann mal für eine Weile interessant sein.

Man beschäftigt sich zudem sehr mit der deutschen Sprache und kann viel dazulernen, wo man doch zuvor dachte, dass man diese eigentlich gut beherrschen würde 🙈🌞

Ergänzende Lektüre:

https://make.wordpress.org/polyglots/handbook/translating/how-to-translate/
bzw.
https://make.wordpress.org/polyglots/handbook/

Bego, deinen Beitrag hatte ich vor meiner ersten Antwort hier nicht gesehen bzw. ich habe sie gerade erst gesehen (die Beiträge hatten sich zeitlich wohl überschnitten). Meine Antwort war als Ergänzung zu deiner ersten Antwort (der ich übrigens vollkommen zustimme) gedacht 🙂 – aber ob die nun tatsächlich positiver war …? 😁 😉

Da stellen wir uns janz dumm und fragen uns, wat is ene Dampfmaschin‘ … pardon, ich meinte, wie funktioniert das mit der Übersetzung?

Nehmen wir an, ein Plugin will die Zeichenkette Hello world ausgeben. In PHP gibt es dafür das Sprachkonstrukt echo():

<?php echo 'Hello world"; ?>

Um das zu übersetzen, bietet WordPress verschiedene Funktionen zur Internationalisierung (abgekürzt I18n) und Localization (wenn z.B. Zahl- oder Datumsformate angepasst werden müssen). Statt der Funktion echo() verwenden wir

<?php _e( 'Hello world', 'textdomain' );?>

Das _e ersetzt echo(), der textstring (hier „Hello world“) ist die Zeichenkette, die übersetzt werden soll und die Textdomain gibt an, in welchem Zusammenhang die Übersetzung erfolgen soll. Meistens hat das Plugin/Theme eine eigene Textdomain, die im Plugin-/Theme-Header angegeben wird. Die Textdomain ermöglicht vereinfacht gesagt, das Wort bank einmal mit „Finanzinstitut“ und einmal mit „Parkbank“ zu übersetzen.

Hat der Entwickler gar keine Übersetzungsfunktion verwendet, lässt sich auch nichts übersetzen. Wurden hingegen Übersetzungsfunktionen verwendet, kann mit einem Tool jede Zeichenkette ausgelesen und in einer Übersetzungsvorlage mit der Endung .pot (für Portable Object Template, auf Deutsch Vorlage übersetzbarer Objekte) gesichert werden. Diese Datei kann dann in Programmen wie z.B. POedit eingelesen und für eine Übersetzung in verschiedene Sprachen verwendet werden. Das Programm speichert zu jeder Zeichenkette die Übersetzung in einer Datei mit der Endung .po (für Portable Objects). Außerdem wird eine maschinenlesbare Version mit der Endung .mo (machine readable object) erstellt, mit der Übersetzungen schneller gelesen werden können. Wenn du (im Rahmen eines OpenSource-Projekts) eine Übersetzung mit jemand teilen möchtest, verwendest du immer nur die .po-Datei, weil die mit jedem Programmiereditor im Klartext lesbar ist. Die .mo-Datei könnte theoretisch auch Malware enthalten; niemand läd sowas gerne auf seinen Computer.

Wenn ich Plugins übersetzt habe, habe ich meistens die Vorlagendatei (.pot) geladen oder bei bereits vorhandenen Dateien die .po-Datei und dann mit dem Plugin POedit zuende übersetzt. Da können je nach Komplexität des Plugins mehrere Tage bei drauf gehen, manchmal ist das auch in einer Viertelstunde erledigt. Mit den entsprechenden Benutzerrechten kann ich die fertige Übersetzung auch komplett in translate.wordpress.org importieren. Für die formelle Übersetzung lade ich die Datei erneut in POedit, gehe die Sätze einzeln durch und ändere „du“ in „Sie“, „deine“ in „Ihre“ usw.

Tools wie LocoTranslate habe ich nie benutzt. Ich war immer der Meinung, wenn ich mir ohnehin schon die Mühe mache, ein Plugin zu übersetzen, kann ich das auch mit anderen teilen. Wenn dann jemand einen Tippfehler findet und korrigiert, haben wir beide etwas davon. Wenn jemand meine Übersetzung nicht gefällt, bleibe ich ganz tapfer. Er/sie kann eine alternative Übersetzung vorschlagen. Vielleicht gebe ich sie anschließend selber frei. 😉

Loco Translate bietet dir an, eigene Übersetzungen in wp-content/languages/loco anzuspeichern. Bekommst du einen Koller und willst die ganzen Übersetzungen loswerden, löschst du dieses Verzeichnis.

Was mich immer wieder fasziniert hat: du kannst jederzeit das Verzeichnis wp-content/languages löschen und WordPress schlägt anschließend unter Dashboard > Aktualisierungen vor, die Sprachdateien entsprechend deiner Auswahl in Einstellungen > Allgemein, neu zu laden. Das geht erstaunlich schnell und es werden stets die neuesten Varianten der Übersetzung aus dem WordPress-Polyglot-Verzeichnis abgerufen. Und Zack! spricht WordPress wieder Deutsch mit dir. Oder Nederlands, Français, … was auch immer.

Aber das mit der „Textdomain“ ist mir völlig abstrakt.

Du entwickelst ein Plugin zur amerikanischen Presidentschaftswahl und möchtest den Begriff „he/she is running for president“ gerne mit „er/sie bewirbt sich um das Amt des Präsidenten“ (und nicht mit „er/sie rennt für den Präsidenten“) übersetzen. Ein anderes Plugin verwendet den Begriff „run“ vielleicht für ein Programm („the program runs, if you click a button“). Um solche Mehrdeutigkeiten in der Übersetzung zu vermeiden, gibst du im Header deines Plugins an, wie die Textdomain lautet:

/*
 * Plugin Name:       My Basics Plugin
 * Plugin URI:        https://example.com/plugins/the-basics/
 * Description:       Handle the basics with this plugin.
 * Version:           1.10.3
 * Requires at least: 5.2
 * Requires PHP:      7.2
 * Author:            John Smith
 * Author URI:        https://author.example.com/
 * License:           GPL v2 or later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Update URI:        https://example.com/my-plugin/

 * Text Domain:       my-basics-plugin

 * Domain Path:       /languages
 * Requires Plugins:  my-plugin, yet-another-plugin
 */

Die Übersetzungsfunktion verwendet dann diese Text-Domain:

_e( 'he/she is running for president', 'my-basic-plugin' );

Naja, genauso wie man per Poedit weiter übersetzte *.po weitergeben kann, geht das ja auch mit Loco. Loco bietet aber den oft sehr hervorgehobenen Vorteil …

Alles OK. Ich nutze es trotzdem nicht. 🙂

Aber werden dann auch die Millionen darin enthaltener anderer Sprachedateien der Plugins und Themes neu geladen?

Kleine Anekdote: Gelegentlich gibt es bei Websites Probleme mit falsch zugewiesenen Benutzerrechten. Aus Erfahrung weiß ich, dass sich dann unter Einstellungen > Allgemein nur Englisch und Deutsch als Sprache für die Website auswählen lassen. Ich frage dann schon mal nach, ob es theoretisch möglich wäre, zum Beispiel Französisch auszuwählen. Dann kommt die Rückmeldung „ja, habe ich jetzt gemacht, ist jetzt alles in Französisch – und ich weiß, dass jetzt zusätzlich alle Übersetzungen für Themes und Plugins auf Franzözisch geladen wurden und bei jedem Sprach-Update berücksicht werden müssen. Urgs. Bekommt man aber wieder in den Griff, indem man die Website wieder auf Deutsch umstellt und dann den ganzen Inhalt des Verzeichnisses languages löscht.

Die Anzahl der Übersetzungsdateien ist vor allem durch die Einführung des Block-Editors enorm gestiegen, weil jeder Block seine eigene Übersetzungsdatei als .json-Datei bekommt (hier gelten nicht die üblichen Übersetzungsfunktionen). Eigentlich kann einem das aber auch egal sein. Der Server bekommt die Dateiflut gut bewältigt und als Nutzer braucht man sich mit diesen Dateien nicht weiter beschäftigen.

Wieso einige Plugins die Übersetzungsdateien in einem Unterverzeichnis wp-content/plugins/{pluginname}/languages und andere in wp-content/languages/plugins speichern, kann ich adhoc gar nicht beantworten. Ich vermute, dass die vom Theme-Entwickler erstellten Übersetzungen im Plugin-Verzeichnis landen, während die auf translate.wordpress.org erzeugten Übersetzungen in wp-content/languages landen.

Kurz noch ein Hinweis zu „einige machen das per Stringersetzung in der functions.php [eines Child-Themes]“: Damit kann man eine „offizielle“ Übersetzung für die eigene Website dauerhaft anpassen, ohne die eigentliche Übersetzung zu ändern. WordPress liest erst das Skript des Plugins ein, ersetzt dann mit Hilfe der Übersetzung Zeichenketten, sucht anschließend raus, für welche Zeichenketten es eine Stringersetzung gibt und korrigiert den Text entsprechend. Wenn man diesen Ablauf kennt, überrascht es nicht, dass sich diese Ersetzung negativ auf die Performance auswirkt. Wenn es irgendwie geht, sollte darauf verzichtet werden.