Wenn Sie wissen wollen, wie Sie hartcodierte Texte in Themes und Plugins zur Übersetzung registrieren, lesen Sie bitte den Artikel Theme- und Plugin-Lokalisierung. Wenn Sie jedoch erfahren möchten, wie Sie Theme- oder Plugin-Optionen zur Übersetzung registrieren, sollten Sie eine Sprachkonfigurationsdatei verwenden.



Im folgenden Artikel geht es um alle anderen von Benutzern eingegebenen Texte, die von Themes und Plugins in der Datenbank gespeichert werden. Bitte beachten Sie: Wenn Ihr Theme oder Plugin Elemente erstellt, die besser als Gruppe übersetzt werden sollten (beispielsweise in Formularen), sehen Sie sich String-Paketübersetzung an.



Beginnen wir mit einem Beispiel.



Sie haben ein benutzerdefiniertes Widget mit einem Titel-Eingabefeld und einigen anderen Optionen erstellt. Sie können den Widget-Titel mit ‚apply_filters‘ zur Übersetzung registrieren, doch Sie sollten auch den Eingabetext registrieren, den Sie in allen anderen Optionsfeldern speichern können.



Wenn alle Texte im Plugin/Widget hartcodiert sind, können sie mit gettext lokalisiert werden (die .mo-Datei des Plugins). Was aber machen Sie mit Texten, die der Benutzer eingibt?

String-Übersetzung in WPML


WPML enthält ein String Translation-Modul, mit dem Sie Texte dieser Art übersetzen können. Standardmäßig hilft es Benutzern dabei, den Blogtitel, die Tag-Zeile, Text-Widgets und andere Texte zu übersetzen, die WordPress generiert. Andere Plugins und Themes können diesen Mechanismus ebenfalls benutzen, um Übersetzungen für Texte zu liefern, die sie anzeigen müssen.

1. Registrieren Sie die Strings, die übersetzt werden müssen


Erstellt der Benutzer neue Strings oder aktualisiert vorhandene Strings, müssen diese in der String-Tabelle von WPML registriert werden. Rufen Sie hierzu folgendes auf:

icl_register_string ( string $context, string $name, string $value );



  • $context


    • (string) (erforderlich) Der Name des Plugins, in einem für Menschen lesbaren Format.



  • $name


    • (string) (erforderlich) Der Name des Strings, der dem Übersetzer hilft zu verstehen, was übersetzt werden soll.



  • $value


    • (string) (erforderlich) Der String, der übersetzt werden soll.




In unserem Beispiel für ein benutzerdefiniertes Widget müssen wir ‚icl_register_string()‘ aufrufen, wenn die Widget-Optionen gespeichert oder aktualisiert werden. Dies geschieht in der ‚update‘-Funktion unseres benutzerdefinierten Widgets.



Hier ein Beispiel dafür, wie dies aussehen wird. Unser benutzerdefiniertes Widget hat einen Titel, ein einzeiliges Eingabefeld und einen Textbereich.

function update($new_instance, $old_instance){

$instance = $old_instance;
$instance['title'] = strip_tags($new_instance['title']);
$instance['custom_input'] = strip_tags($new_instance['custom_input']);
$instance['custom_textarea'] = $new_instance['custom_textarea'];

//WMPL
/**
* register strings for translation
*/
if (function_exists ( 'icl_register_string' )){
icl_register_string('Widgets', 'Custom Widget - input field', $instance['custom_input']);
icl_register_string('Widgets', 'Custom Widget - textarea field', $instance['custom_textarea']);
}
//WMPL


return $instance;
}


Dieses sagt WPML, dass der vom Benutzer eingegebene Text für das Eingabefeld und den Textbereich übersetzt werden müssen. Diese werden im „Widgets“-String-Kontext jeweils unter dem Namen „Benutzerdefiniertes Widget – Eingabefeld“ und „Benutzerdefiniertes Widget – Textbereich-Feld“ registriert.



Nützlich zu wissen: Wenn ein bestimmter Text im Plugin nicht mehr übersetzt werden muss (wenn der Benutzer das Plugin zum Beispiel gelöscht hat), kann der String mit diesem Befehl aus der Übersetzungstabelle gelöscht werden:

icl_unregister_string ( string $context, string $name );


2. Nutzung der Übersetzung bei der Anzeige


Wenn das benutzerdefinierte Widget im Front-end angezeigt wird, muss es die Übersetzungen abrufen und verwenden. Dazu nutzt es die Funktion icl_translate:

icl_translate ( string $context, string $name, string $value );


WPML sucht nach einem String mit passendem $context und $name. Findet es diesen, sucht es nach einer Übersetzung in der aktuellen Sprache (der Sprache, in der die Seite angezeigt wird). Falls es eine Übersetzung gibt, wird diese ausgegeben. Ansonsten wird der Original-String ausgegeben.



Das $value-Argument wird an den Befehl ‚icl_translate()‚ weitergegeben, sodass für den Fall, dass WPML bei der Erstellung des Strings nicht aktiv war und dieser nicht registriert ist, der normale String-Wert ausgegeben wird.



In unserem Beispiel eines benutzerdefinierten Widgets würden wir noch einmal ‚icl_translate()‚ in der Ausgabefunktion aufrufen.



Hier ein Beispiel dafür, wie dies aussehen wird. Beachten Sie, dass der Widget-Titel apply_filters durchläuft.

function widget($args, $instance){

        extract($args);
        $title               = apply_filters('widget_title', $instance['title'] );
        $custom_input        = $instance['custom_input'];
        $custom_textarea     = $instance['custom_textarea'];
        
        # Before the widget
        echo $before_widget;

        # The title
        if ( $title )
        echo $before_title . $title . $after_title;

        # Output
        //WMPL
        /**
         * retreive translations
         */
        if (function_exists ( 'icl_translate' )){
            $custom_input    = icl_translate('Widgets', 'Custom Widget - input field', $instance['custom_input']);
            $custom_textarea = icl_translate('Widgets', 'Custom Widget - textarea field', $instance['custom_textarea']);
        }
        //WMPL
        
        
        ?>
        <ul class="a_custom_widget clearfix">
            <li>
                <span><?php echo $custom_input;?></span>
                <p>
                    <?php echo $custom_textarea;?>
                </p>
            </li>
        </ul>
    
        <?php
        # After the widget
        echo $after_widget;
    }


So funktioniert die Stringübersetzung intern in WPML


WPML umfasst eine String-Übersetzungsschnittstelle, welche die Strings auflistet und die Verwaltung ihrer Übersetzung ermöglicht.



WPMLs Schnittstelle zur String-Übersetzung
WPMLs Schnittstelle zur String-Übersetzung




Wenn Benutzer auf Übersetzungen für einen String klicken, öffnet sich eine mehrsprachige Übersetzungsübersicht, auf der sie die Übersetzung für die jeweilige Sprache bearbeiten können. Jede Übersetzung enthält eine Abgeschlossen-Markierung. Wenn die Übersetzungen für alle Sprachen abgeschlossen sind, wird auch der String selbst als abgeschlossen markiert.



Ändert sich der String, werden alle seine Übersetzungen als unvollständig markiert, sodass der Benutzer weiß, dass die Übersetzung überarbeitet werden muss.



Die gesamte Stringbearbeitung erfolgt in derselben WordPress Admin-Schnittstelle und erfordert keine Aufrufe von externen Services.

So integrieren Sie die WPML-Stringübersetzung mit Plugins und Themen


Bei der Integration der Stringübersetzung in Plugins und Themen ist es wichtig darauf zu achten, dass die Befehle existieren.



Die Befehle an WPMLs String-Übersetzungsfunktionen sollten in if_function_exists()-Aussagen gepackt werden. So wird WPML aufgerufen, wenn es aktiviert ist. Andernfalls bleibt der Vorgang wie gehabt.



Darüber hinaus sollten Plugin-Entwickler den Fall berücksichtigen, dass WPML aktiviert wird, lange nachdem der Benutzer beginnt, das Plugin zu nutzen. In diesem Fall erfolgt der Aufruf icl_register_string nicht, wenn neue Strings erstellt werden, und diese werden niemals übersetzt. Zur Lösung dieses Problems sollten immer alle Benutzer-Strings registriert werden, sobald der Admin-Bildschirm für das Plugin geladen wird.



Dies macht die Ausführungszeit ein winziges bisschen länger, garantiert aber, dass stets alle Strings zur Übersetzung eingesandt werden und aktuell sind. Der Code kann einmal testen, um zu sehen, dass der icl_register_string existiert und diesen dann aufrufen, um alle Strings zu registrieren, die der Benutzer eingibt.



Wenn diese Funktion mit leeren oder NULL-Werten aufgerufen wird, ignoriert WPML sie. Wenn der String bereits existiert und unverändert ist, wird der Befehl ebenfalls ignoriert. Er wirkt sich nur aus, wenn neue oder geänderte Strings registriert werden.



Die gesamte Übersetzungstabelle wird im Cache gespeichert, so dass ihr wiederholter Aufruf nur wenig Verarbeitungsaufwand bedeutet.

Was muss zur Übersetzung geschickt werden?


Beginnen wir zunächst mit dem, was nicht mithilfe von icl_register() zur Übersetzung geschickt werden muss.



WPML verwendet verschiedene Beiträge, Seiten, Tags und Kategorien für verschiedene Sprachen. Das heißt, dass falls eine Webseite die beiden Seiten – example.com/about/ und example.com/es/sobre/ enthält, sind dies verschiedene WordPress-Seiten.



Alle Texte, die einer Seite hinzugefügt werden, erscheinen bereits in mehreren Sprachen, da der Benutzer den korrekten Text bereits in der Sprache eingibt, in der die Seite geschrieben ist.



Mit der WPML String-Übersetzung müssen Texte übersetzt werden, die zu keinem Beitrag, keiner Seite, keinem Tag und keiner Kategorie gehören. SEO-Plugins erlauben beispielsweise die Eingabe von Texten für den Startseitentitel, Keywords und eine Beschreibung. Dieser Text muss mithilfe der WPML-Stringübersetzung übersetzt werden. So wird er für Startseiten in verschiedenen Sprachen übersetzt angezeigt.

Eine Antwort zu “Übersetzung von vom Benutzer eingegebenen Texte aus Plugins und Themes”

  1. Hallo,

    ich habe die große Version von WPML gekauft und muss Strings übersetzen, die das Plugin nicht automatisch findet/auflistet. Diese Erklärung hier hilft mir aber nicht ganz. Denn ich weiß nicht, wo ich die Strings registrieren soll: irgendwo in WordPress auf einer WPML-Konfigurationsseite oder direkt in einer php-Datei? Könnten Sie mir bitte sagen, wo genau ich die Strings registrieren muss? Ich habe von programmieren nicht den leisesten Schimmer, kann aber schon fertigen Code in ein Dokument einfügen, wenn ich weiß, wo ich das machen muss. (Muss ich auch den Code unter Punkt 2. irgendwo eintragen? Wenn ja, wo?)

    In meinem Fall geht es um Werte in den Theme-Options und um ein Widget, das wohl nicht zum Standardumfang von WordPress zählt (ich bin WordPress-Neuling). Es heißt: „Custom Tabbed Widget +“ Es ist möglicherweise Bestandteil des Plug-ins „WP-PageNavi“, das ich für das Theme installieren musste. Das verwendete Theme heißt „Paradise Premium“ und ist von Thememakers.

    Vielen Dank!
    Peter