Eigene Plugin-Übersetzung vor Update schützen

  • Gelöst youngtimer

    (@youngtimer)


    vor 1 Woche, 5 Tage

    Unter „Allgemeines zu Übersetzungen im WP Kosmos“ haben wir eben allgemeines dazu diskutiert und schließlich sogar einen kleinen Kurs dazu erhalten. Danke.

    Ich habe da dann doch noch vieles weiter experimentiert und versucht, den Punkt „Textdomain“ zu verstehen.
    Denn ich glaube, wenn man seine eigenen Übersetzungen Update-sicher haben will, kommt man an dieser Textdomain nicht vorbei.
    Ja, ich habe auch durch die WordPress Developer Resources geackert, doch irgendwie will das alles nicht so klappen.

    Mein letzter Versuch, mit einem fiktiven Plugin namens „pluginname“, welches lt. Header eine Textdomain „plugin-textdomain-name“ hat:

    function lade_meine_uebersetzung_zu_pluginname($domain, $mofile)
{
    if ('plugin-textdomain-name' === $domain && plugin_dir_path($mofile) === WP_PLUGIN_DIR.'/pluginname/languages/')
    {
load_textdomain('plugin-textdomain-name', WP_LANG_DIR.'/plugins/pluginname/'.$domain.'-'.get_locale().'.mo');
   }
}
add_action('load_textdomain', 'lade_meine_uebersetzung_zu_pluginname', 10, 2);

    Was ich damit erreichen will:
    Dem Plugin „pluginname“ sagen: Nimm nur meine eigene Version der *.po (+mo), welche in
    wp-content\languages\plugins\pluginname\
    ausgelagert sind und nicht die in
    wp-content\plugins\pluginname\languages\

    Da das nicht klappt, ergebe sich Fragen:

    1. Wie könnte so ein Code wirklich aussehen?
    2. Textdomain angeben: Heißt es nun load_textdomain, load_plugin_textdomain, load_textdomain_mofile oder …?
    3. Kann es sein, dass einige Plugins so gecodet sind, dass solche Überschreibungen nicht funktionieren?

    Okay, das geht evtl. über den Anwendersupport hinaus, aber es muss ja auch ohne Loco einen Weg geben, die eigenen Übersetzungen zu sichern. Derweilen kopiere ich die halt lokal irgendwo hin, bzw. sende sie dem Pluginautor.
    Doch das muss ja auch komfortabler möglich sein. Immerhin zeigen 999 Sites die Codes dazu, aber bisher ging das nicht so wie es sollte.

    Hinweis auf möglichen Doppelpost:
    Hier fragte ich vorhin einen Pluginautor, ob und wie man das bei seinem Plugin machen könnte. Vmtl. dauert dessen Antwort noch länger und daher frage ich auch hier, wie man einem Plugin beibringt, eine anderswo ausgelagerte *.mo zu nehmen.

    UPDATE: Eben gesehen, dass es inzwischen noch eine detaillierte Antwort zum eingangs erwähnten allgemeinen Thema gibt – Sorry!

    • Dieses Thema wurde geändert vor 1 Woche, 5 Tage von youngtimer. Grund: Update
Ansicht von 15 Antworten – 1 bis 15 (von insgesamt 25)
1 2
  • Moderator Bego Mario Garde

    (@pixolin)

    vor 1 Woche, 5 Tage

    Im Theme-Handbook heißt es im Abschnitt Text-Domain:

    Die Textdomäne ist ein eindeutiger Bezeichner, der es WordPress ermöglicht, zwischen allen geladenen Übersetzungen zu unterscheiden. Die Textdomäne muss nur für Themes und Plugins definiert werden. (Übersetzung: Deepl)

    Die Text-Domain ist selber kein Verzeichnisname! (Word aber dann im Dateinamen der Übersetzungs-Dateien verwendet).

    In einem Theme-Header gibst du den Ort der Übersetzungsdateien im Theme-Header in der style.css. (bei Plugins im Plugin-Header in der Haupt-Datei des Plugins) an:

    /*
    * Theme Name: My Theme
    * Author: Theme Author
    * Text Domain: my-theme
    * Domain Path: /languages
    */

    Alles was du in einem Plugin- oder Theme-Verzeichnis sowie in wp-content/languages/, wp-content/languages/plugins und wp-content/languages/themes änderst, wird beim nächsten Update überschrieben. Deshalb empfehlen die Entwickler von Loco Translate, eigene Übersetzungen in einem Unterverzeichnis languages/loco zu sichern. (vgl. FAQ: Why have my translation files been deleted / reverted?)

    Seit WordPress Version 4.6 braucht z.B. load_plugin_textdomain() nicht mehr explizit angegeben werden (vgl. I18N Improvements in 4.6). WordPress sucht automatisch nach passenden Übersetzungsdateien in wp-content/languages/{plugins, themes} und anschließend in einem im Header angegebenen Domain-Pfad. Möchte man das nicht, kann die Funktion override_load_textdomain() verwendet werden.

    Im Rahmen der Vorstellung der Änderungen in WP 4.6 fragte ein Benutzer:

    Wie kann ich override_load_textdomain() verwenden, um meine benutzerdefinierte Übersetzung zu laden, die nicht für ein Plugin überschrieben wird? (Woocommerce) (Übersetzung: Deepl)

    Pascals Antwort dazu

    Diese Frage wird wahrscheinlich am besten in den Support-Foren gestellt, aber hier ist eine schnelle Antwort: Erstelle eine Funktion, die sich den Hook override_load_textdomain verwendet und die Übersetzungen manuell von einem anderen Ort lädt. Wenn das erfolgreich ist, gibt sie true zurück, um anzuzeigen, dass das Überladen erfolgreich war.

    Hier sind einige Beispiele, die ich bei einer schnellen Google-Suche gefunden habe, um Ihnen den Einstieg zu erleichtern:

    https://stackoverflow.com/a/8243299/12490449
    …

    Auf Rückfrage hat Pascal dann eine eigene Funktion geteilt, mit der er den Ort der Dateien ändert:

    function wporg_forums_override_load_textdomain($override, $domain ) {
    	if ( 'my-plugin' === $domain ) {
    		load_textdomain( $domain, 'path/to/my/custom/translation.mo' );
    		return true;
     	}

    	return $override;
    }

    add_filter( 'override_load_textdomain', 'wporg_forums_override_load_textdomain', 10, 2 );

    Ich verstehe das so, dass ich im Verzeichnis wp-content/languages ein Unterverzeichnis my-way anlege (das von keinem Plugin/Theme/Core-Update geändert wird) und dann mit der Funktion für ein Theme mit der Textdomain my-theme geladen wird. Sinngemäß …

    function wporg_forums_override_load_textdomain($override, $domain ) {
    	if ( 'my-plugin' === $domain ) {
    		load_textdomain( $domain, WP_LANG_DIR . 'my-way/my-theme-de_DE.mo' );
    		return true;
     	}

    	return $override;
    }

    add_filter( 'override_load_textdomain', 'wporg_forums_override_load_textdomain', 10, 2 );
    Moderator Angelika Reisiger

    (@la-geek)

    vor 1 Woche, 5 Tage

    Bei eigenen Übersetzungen, die vor dem Überschreiben geschützt sind, gibt es mögliche Probleme; so werden die originalen Sprachdateien im Laufe der Zeit mit neuen Strings erweitert, diese sind logischerweise nicht in der eigenen Übersetzung vorhanden und im Endeffekt werden diese Strings auf Englisch wiedergegeben.

    Hier bietet Loco Translate (unter anderem) eine super Lösung, denn man kann lediglich einzelne Strings dauerhaft anders übersetzen. Ich musste das einmal in einer Kunden-Website für ein paar Strings machen, die im Kontext der Website absolut nicht passten. Da diese Strings im Original perfekt übersetzt waren, hätte ich auf translate.wordpress.org keine Änderung herbeiführen können.

    Loco Translate hat eine ausgezeichnete Dokumentation, die eigentlich alle Fragen beantworten sollte:
    https://localise.biz/wordpress/plugin/custom-translations

    Thread-Starter youngtimer

    (@youngtimer)

    vor 1 Woche, 5 Tage

    @pixolin

    Glaube, nun erhellt sich auch das mit der Textdomain. Ich habe nur noch keine, für mich selber eingängige Eigendefinition gefunden, einen Merksatz der dann auch hängenbleibt.
    Im anderen, allgemeinen Thema notierte ich dazu:

    … das ist bloß eine Unterscheidungshilfe, eine Art eindeutige Var, eher „Konstante“ welchem Plugin welche Übersetzung zugeordnet werden soll. Sofern es mehrere ähnliche oder gar gleiche Übersetzungen für den gleichen englischen Begriff gibt, ist so der Kontext zu einem bestimmten Plugin herstellbar.

    (Daran feile ich noch …)

    Deshalb empfehlen die Entwickler von Loco Translate, eigene Übersetzungen in einem Unterverzeichnis languages/loco zu sichern.

    Das ist ja eine gute Idee, würde Loco echt verschieben und nicht kopieren. Kopieren vermehrt nur die ohnehin massenhaften Sprachdateien.

    Ich verstehe das so, dass ich im Verzeichnis wp-content/languages ein Unterverzeichnis my-way anlege (das von keinem Plugin/Theme/Core-Update geändert wird) und dann mit der Funktion für ein Theme mit der Textdomain my-theme geladen wird.

    Genau das möchte ich auch erreichen. Jetzt mal für ein Plugin.

    die Funktion override_load_textdomain()

    Oh, es gibt noch eine Funktion dafür?
    Okay, die probiere ich heute auch noch aus. Danke!

    @la-geek

    Bei eigenen Übersetzungen, die vor dem Überschreiben geschützt sind, gibt es mögliche Probleme; so werden die originalen Sprachdateien im Laufe der Zeit mit neuen Strings erweitert, diese sind logischerweise nicht in der eigenen Übersetzung vorhanden und im Endeffekt werden diese Strings auf Englisch wiedergegeben.

    Logisch, ja.
    Aber dann muss halt ab und zu die aktuelle *.pot bemühen und das halt nochmal machen – richtig?

    Strings machen, die im Kontext der Website absolut nicht passten

    Also das kann ich mir sehr gut vorstellen!

    Moderator Angelika Reisiger

    (@la-geek)

    vor 1 Woche, 5 Tage

    Aber dann muss halt ab und zu die aktuelle *.pot bemühen und das halt nochmal machen – richtig?

    Bei eigenen Websites klar, umständlich aber machbar. Bei Kunden-Websites jedoch eher kompliziert, selbst bei einem Wartungsvertrag, schließlich hat man die Übersetzungen nicht stets im Blick.

    Thread-Starter youngtimer

    (@youngtimer)

    vor 1 Woche, 5 Tage

    Verstehe. Aber technisch wäre das so richtig? (was bei mir schon ein Fortschritt ist)

    Thread-Starter youngtimer

    (@youngtimer)

    vor 1 Woche, 5 Tage

    Bez. der function wporg_forums_override_load_textdomain($override, $domain) :
    Sobald ich eine existierende Textdomain eines Plugins eingebe, ist Fatal Error. 

    function wporg_forums_override_load_textdomain($override, $domain ) {
	if ( 'paid-memberships-pro' === $domain ) {
		load_textdomain( $domain, WP_LANG_DIR . 'plugins/paid-memberships-pro/paid-memberships-pro-de_DE_formal.mo' );
		return true;
 	}
	return $override;
}
add_filter( 'override_load_textdomain', 'wporg_forums_override_load_textdomain', 10, 2 );

    erzeugt den Fehler:
    [01-Sep-2024 14:53:33 UTC] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 262144 bytes) in ...\wp-includes\class-wp-hook.php on line 326

    Ändert man die Frage nach der Textdomain auf irgendeinen nicht existierenden Begriff, geht alles wieder.

    Moderator Bego Mario Garde

    (@pixolin)

    vor 1 Woche, 5 Tage

    Allowed memory size of 536870912 bytes exhausted …

    … bedeutet, dass der Arbeitsspeicher (RAM, nicht Festplatte) den dein Webhoster zur Verfügung stellt, nicht ausreicht.

    Nach dem, was Angelika schreibt, würde ich aber Loco Translate verwenden.
    Mir ging es mehr darum, zumindest etwas Hintergrundwissen zu vermitteln (soweit ich das überhaupt kann). Wie du merkst, ist das Thema nicht ganz trivial.

    Moderator Angelika Reisiger

    (@la-geek)

    vor 1 Woche, 5 Tage

    Mir ging es mehr darum, zumindest etwas Hintergrundwissen zu vermitteln (soweit ich das überhaupt kann). Wie du merkst, ist das Thema nicht ganz trivial.

    Du bist ein wandelndes und schreibendes WordPress-, PHP- und thematisch-zugehöriges- Lexikon der Güteklasse 1 A (und das meine ich ganz ernst und ehrlich). Danke für die vielen Bereicherungen hier im Forum.

    Thread-Starter youngtimer

    (@youngtimer)

    vor 1 Woche, 5 Tage

    Die Bedeutung ist schon klar. Nur warum sollte das plötzlich (und für das Laden einer Übersetzung von einem anderen Ort) nicht mehr reichen? Da ist was anderes kaputt.
    Möglicherweise kollidiert das mit den Funktionen, mit denen das Plugin selbst die Lade-Reihenfolge (usw.) der Übersetzung bestimmt.
    Also muss ich warten, bis sich der Entwickler meldet.

    Loco habe ich nun zum 3. Mal entnervt aufgegeben. Hatte das nur verdrängt, wie oft ich damit schon gescheitert bin.
    Denn wie gesagt: Auch damit wurden bereits funktionierende und erfolgreich extern ausgelagerte Übersetzungen nach ein paar Tagen ignoriert. Dafür ärgere ich mich nicht stundenlang mit dem Handling von Loco.

    PS:
    Habe den RAM auf 1024 MB verdoppelt, Ergebnis wie erwartet nun:
    [01-Sep-2024 15:52:28 UTC] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 262144 bytes) in \wp-includes\class-wp-hook.php on line 326

    • Diese Antwort wurde geändert vor 1 Woche, 5 Tage von youngtimer. Grund: Ergebnis mit 1024 MB RAM
    Thread-Starter youngtimer

    (@youngtimer)

    vor 1 Woche, 5 Tage

    So, nach weiteren Versuchen folgende neuen Erkenntnisse:

    Sobald override in add_filter steht, schmeißt es immer den gleichen Fehler, egal was man an dem Script sonst alles ändert und versucht.

    Auch keine der 999 anderen Scripte, die man so zum Thema findet und die ich in zig Varianten probierte, modifizierte können die eigene *.mo laden.

    Einzig geht folgendes:

    1. Man kopiert die *.po nach \wp-content\languages\plugins (aber bloß nicht in einem, nach dem Plugin benannten Unterordner!)
    2. übersetzt die einfach per Poedit, erzeugt die *.mo
    3. Fertig! Diese neue *.mo wird sofort übernommen und die Originale aus pluginname/languages nicht mehr !

    Also gibt WP den Sprachdateien in \wp-content\languages\plugins den Vorrang. Aber die dürfen nicht nochmal in einem Unterordner stecken (wie es viele Anleitungen erklären).
    Das betone ich auch noch, weil in \wp-content\languages\plugins schwirren eine Unmenge an Sprachdateien wild durcheinander gewürfelt herum – und – das ist ein Problem! Denn erst wenn man diese auch noch löscht, dann klappt das in der Liste beschriebene!
    Solange es darin ähnliche Sprachdateien gibt, kann es sein, dass WP die darin enthaltenen, meist veralteten Übersetzungen zeigt.

    Ob das alles für alle Plugins gilt und echt updatesicher ist wird sich noch zeigen.

    Moderator Bego Mario Garde

    (@pixolin)

    vor 1 Woche, 5 Tage

    Sobald override in add_filter steht, schmeißt es immer den gleichen Fehler, egal was man an dem Script sonst alles ändert und versucht.

    Da habe ich vermutlich aus Unkenntnis etwas übersehen. Die Frage ist dann auf WordPress Stackexchange doch besser aufgehoben. Ich bin wie gesagt nur ein Anwender mit bescheidenen Kenntnissen (auch wenn Angelika mich hier etwas zu überschwänglich lobt).

    Man kopiert die *.po nach \wp-content\languages\plugins (aber bloß nicht in einem, nach dem Plugin benannten Unterordner!)

    Das ist der Standard-Speicherort der Übersetzung und sobald es eine Übersetzung der WordPress-Community gibt, werden dort gespeicherte Übersetzungen überschrieben. Genau das wolltest du aber vermeiden?

    Also gibt WP den Sprachdateien in \wp-content\languages\plugins den Vorrang.

    Ja, das hatte ich auch so geschrieben: „WordPress sucht automatisch nach passenden Übersetzungsdateien in wp-content/languages/{plugins, themes} und anschließend in einem im Header angegebenen Domain-Pfad.“ (Aber, OK, ich hab‘ wahrscheinlich viel zu viel geschrieben und niemand blickt mehr durch. 😛 )

    Das betone ich auch noch, weil in \wp-content\languages\plugins schwirren eine Unmenge an Sprachdateien wild durcheinander gewürfelt herum – und – das ist ein Problem!

    Hm, nun ja … das ist eben seit WordPress 4.6 der Standard. 😀
    So „wild durcheinandergewürfelt“ ist das ja nicht. wp-content/languages/plugins enthält die Übersetzungen für alle Plugins. Die Dateien werden nach der Textdomain benannt und haben dann die Endung der Locale, also für informelles Deutsch („Du“) {textdomain}-de_DE.{p|m}o.

    Ich vermute, 99,8% aller Nutzer freuen sich, wenn überhaupt eine Übersetzung vorhanden ist. (Ich habe gerade eine Stunde am Plugins OPcache Manager gesessen und dabei nur die informelle Übersetzung erstellt. Die Zeit und Geduld muss man ja erst einmal haben.) Wo und wieviele (sehr kleine!) Dateien dann im Verzeichnis mit den Übersetzungen liegen, wird den meisten Anwendern herzlich egal sein. Die Frage „wie sichere ich dauerhaft eine eigene Übersetzung“ ist aber legitim und ich hoffe, dass wir mit dem Thread hier nicht zusätzliche Verwirrung gestiftet haben.

    Thread-Starter youngtimer

    (@youngtimer)

    vor 1 Woche, 4 Tage

    Unkenntnis .. Anwender mit bescheidenen Kenntnissen

    😲 ³

    Ja, das hatte ich auch so geschrieben: .. wahrscheinlich viel zu viel)

    Stimmt, das stand da wo. Und ich dachte, da hätte ich was neues endeckt…
    Für mich, der sich als einäugiger unter IT-Blinden sieht, ist das alles viel Stoff und da kann schon mal ein Satz untergehen.

    Das ist der Standard-Speicherort der Übersetzung und sobald es eine Übersetzung der WordPress-Community gibt, werden dort gespeicherte Übersetzungen überschrieben.
    Genau das wolltest du aber vermeiden?

    So ist es. Nur wie? (wenn mal Loco sowas von nicht mag)

    wp-content/languages/plugins enthält die Übersetzungen für alle Plugins.

    Also ich habe > 10 yo Installationen laufen, welche darin bisher nur die Sprachdateien von max. einer Handvoll Plugins haben. (das aber in 999 Versionen)
    Die anderen Plugins behalten ihre Sprachdateien für sich.
    Also „alle Plugins“ sind da nicht drin. Oder verstehe ich da wieder was nicht?

    Und warum muss das so kompliziert sein? Warum kann man, ausgehend von einer *.pot nicht bei jeweils einer Übersetzung pro Sprache bleiben? Warum po und mo und warum kann man die nicht dort lassen, wo sie mal waren und … ach ich höre eh schon auf. (Diese Raunzerei muss man nicht beantworten)

    99,8% aller Nutzer freuen sich, wenn überhaupt eine Übersetzung vorhanden ist.

    Schon ja.

    Meine Meinung dazu:
    Solange man im DE Sprachraum WP auf dem Standard, dem „DU“ lässt, ist alles gut. Hier sind die meisten bekannten Plugins und beliebten Themes 100 % übersetzt.
    Aber: Sobald man eine Business-Website macht, welche den Betreiber, seine Benutzer usw. auch intern mit „SIE“ anreden soll, dann ist der Komfort dahin. Da stolpert man plötzlich über Sachen, welche zu 30, 50 Prozent oder so übersetzt sind.
    Und genau da stehe ich jetzt: Eine Website, wo der eigentliche Betreiber darauf besteht, dass keiner seiner Mitarbeiter und Nutzer der Site mit jovialen Tönen konfrontiert wird. Kein Problem bei allen was in der DB steht, kein Prob mit WP – wohl aber sogar mit recht bekannten und größeren Plugins.

    Moderator Bego Mario Garde

    (@pixolin)

    vor 1 Woche, 4 Tage

    Warum kann man, ausgehend von einer *.pot nicht bei jeweils einer Übersetzung pro Sprache bleiben? Warum po und mo und warum kann man die nicht dort lassen, wo sie mal waren …

    Das war jetzt eine rethorische Frage? Der Prozess, wie ein Plugin hochgeladen, die Übersetzungsfunktionen ausgelesen und zur Übersetzung auf translate.wordpress.org bereitgestellt werden, wird sonst hier nochmal recht umfassend beschrieben: Translations

    Wieso die Übersetzung nicht im Plugin-Verzeichnis sondern unter wp-content/languages/plugins liegen, hat mit der Umstellung in WordPress 4.6 zu tun, seit der die Übersetzungsdateien automatisch eingelesen werden und nicht mehr mit load_textdomain() eingebunden werden müssen. Das hat vermutlich auch mit organisatorischen Gründen zu tun.

    Aber: Sobald man eine Business-Website macht, welche den Betreiber, seine Benutzer usw. auch intern mit „SIE“ anreden soll, dann ist der Komfort dahin.

    Ich beiteilige mich seit Jahren am OpenSource-Projekt (hauptsächlich mit Übersetzungen und Support) und habe dafür (bis auf einen einmaligen Förderpreis durch einen großen Plugin-Entwickler) nie einen Cent für den Aufwand vergütet bekommen. Macht trotzdem (meistens) Spaß.

    Heute Morgen habe ich das Plugin OPcache-Manager in informelles Deutsch übersetzt. 279 Zeichenfolgen, gute Stunde Arbeit. Geschenkt. Gern geschehen.
    Die Anpassung für die formelle Übersetzung dauert vielleicht nochmal 15 Minuten, aber dazu habe ich heute keine Lust. Mag sich doch bitte jemand beteiligen, der mit der Website Geld verdient. Manchmal kommt an dieser Stelle dann die Rückfrage, wie man die Übersetzung nur für die eigene Website umgesetzt bekommt. Abgesehen von dieser legitimen Anwendungsfrage bleiben die formellen Übersetzungen dann eben unvollständig.

    Wir bieten unseren Support hier selbst dann kostenlos an, wenn wir wissen, dass eine Web-Agentur oder ein Freelancer mit unserer Hilfe (hoffentlich viel) Geld verdient. (Bei Fragen zu WooCommerce halte ich mich persönlich eher zurück; ansonsten gerne.)
    Für die großzügige Unterstützung müssen wir uns manchmal ganz schön viel Quatsch anhören, weil schnell ein verkehrtes Anspruchsdenken entsteht. Sehr schöns Beispiel aus der OpenSource-Welt ist die weltweit millionenfach eingesetzte, kostenlos erhältliche OpenSource-Software cURL. Der Entwickler bekam von einem Unternehmen eine scharf formulierte Aufforderung (sic!), sich binnen 24 Stunden zu einer Sicherheitslücke zu äußern und diverse Fragen zu äußern. Der Entwickler hat dann klar gestellt, dass es keine vertraglichen Verpflichtungen zu irgendwas gibt (vgl. LogJ4 Security Inquiry – Response Required).

    Manchmal wünsche ich mir im Gegenzug ein Feedback „was kann ich beitragen?“
    Ich bin da selbst nach Jahren etwas naiv.

    Sorry für’s off topic. Soweit ich helfen konnte, sind wir hier mit der Frage aber auch durch?

    Thread-Starter youngtimer

    (@youngtimer)

    vor 1 Woche, 4 Tage

    Wieso die Übersetzung nicht im Plugin-Verzeichnis sondern unter wp-content/languages/plugins liegen,

    Naja, sowohl als auch.
    Bei mir liegen im Schnitt 5 Sprachdateien (pro genutzter Sprache) von 20, 25 Plugins dort. Der Rest bleibt stets in wp-content/plugins/pluginname/language …
    Warum das so ist, ja es war eine gar theoretische Frage und ich würde die Antworten eh nicht verstehen.

    Und ich habe mir, wie gesagt, vorgenommen, so zur Community beizutragen, in dem ich die Übersetzungen den jeweiligen Autoren zukommen lasse. (Immerhin bitten etliche sogar darum, es genauso zu machen)
    Aber selbst dazu muss man es mal im lokalen Rahmen begreifen, wie dieser Mechanismus funktioniert, dann kann man das Ergebnis auf die Welt loslassen.
    Ja, mit den OT Ausflug sind wir durch.

    Wichtiger ist mir, einen updatesicheren Weg für die Sprachdateien zu finden. Sonst ist all die Arbeit für die Kat’z …
    Der eine Pluginautor meinte, ich solle es vorher noch mit unload_textdomain( 'plugin_textdomain_name' ); versuchen. Hat aber auch nicht geklappt, das lädt auch den von WP bevorzugten Zugriff auf wp-content/languages/plugins aus und nimmt die in wp-content/plugins/pluginname/language.

    Moderator Angelika Reisiger

    (@la-geek)

    vor 1 Woche, 4 Tage

    Ich kann einfach nicht nachvollziehen, wieso du solche Probleme mit Loco Translate hast.
    Lösche alle individuellen Sprachdateien, die du erstellt hast (sichere sie einfach auf deinem Computer), lösche alle Einträge/Code-Snippets, die du möglicherweise in der functions.php oder wo auch immer eingetragen hast, auch die load text-domain etc.

    Fang also noch einmal mit einem bereinigten System an.

    Installiere Loco Translate (falls es noch installiert sein sollte, lösche auch dort die zuvor erstellten individuellen Sprachdateien).

    Suche in der (Seitenleiste) Liste Loco Translate > Plugins > Paid Membership.
    Da es ein kommerzielles Produkt ist, könnte eine Übersetzung als Autor angezeigt werden. Entweder kopierst du das, oder wenn nicht vorhanden, dann System, das aus der Spalte „Folder“.

    Im Bildschirm „Hinzufügen einer neuen Sprache“ (Initializing new translations in „…“) wählst du unter WordPress language Deutsch formal aus
    Location: custom: languages/logo/plugins/pluginname-de-formal.po
    Template options: „just copy English source strings“ und „use de-formal as template when running Sync“

    Button -> Start translation
    Übersetze die Strings, die du möchtest, es müssen nicht alle übersetzt werden.
    Die Übersetzung wird sicher in deiner eigenen benutzerdefinierten Datei gespeichert, die WordPress bei Systemaktualisierungen nicht berühren sollte.

    Die Liste der Übersetzungen für das Plugin zeigt nun 2 oder 3 Übersetzungen an:
    System, Custom (und evtl. Author)

    Weiteres Wichtiges, Zitat (wobei Theme/Design durch Plugin gedanklich ersetzt werden sollte):

    Wenn WordPress das Design in Zukunft aktualisiert, stellen Sie möglicherweise fest, dass Ihre Übersetzungen nicht mehr dem englischen Text im Design entsprechen. Loco Translate behebt dies nicht automatisch für Sie. Wenn Sie also wissen, dass das Design aktualisiert wurde, müssen Sie Ihre benutzerdefinierten Übersetzungen manuell aktualisieren.

    WordPress sollte die ursprünglichen Systemübersetzungen automatisch aktualisieren, wenn es das Design aktualisiert. Überprüfen Sie jedoch, ob dies funktioniert, bevor Sie mit dem nächsten Schritt fortfahren. Sie können sie bei Bedarf selbst herunterladen .

    Öffnen Sie nun Ihre benutzerdefinierten Übersetzungen im Editor und klicken Sie auf die Schaltfläche „Synchronisieren“. Wenn sich eine der Quellzeichenfolgen geändert hat, wird eine Zusammenfassung wie „2 neue Zeichenfolgen hinzugefügt. 1 veraltete Zeichenfolge entfernt“ angezeigt . Es wird noch nichts gespeichert, aber der Editor wird mit den neuen Änderungen aktualisiert. Nehmen Sie die erforderlichen Änderungen vor und klicken Sie auf „Speichern“.

    Für möglicherweise noch existierende Probleme gibt es diese FAQ
    https://localise.biz/wordpress/plugin/faqs/custom-folder

Ansicht von 15 Antworten – 1 bis 15 (von insgesamt 25)
1 2