Noch einmal Mehrsprachigkeit

[MKJ]

Puh, das ist eine ziemliche Fummelei. Grundsätzlich findet Localisation schon ein paar Strings, nachdem ich in die wpshopgermany.php oben eingefügt hatte:

Code: Alles auswählen

 add_action( 'init', 'langswitch' );
function langswitch() {
load_plugin_textdomain( 'wpsg', false, 'wpshopgermany/lib' );
}

Identifiziert wird etwa:

Code: Alles auswählen

if ($this->produkt['id'] <= 0) $strReturn_Gesamt .= __("Ungültiges Produkt", "wpsg");

Nicht gefunden hat es aber den neu von mir erstellten String:

Code: Alles auswählen

<h2 class="widgettitle"><?php echo __("Warenkorb", "wpsg");?></h2>

Warum denn das? Der Text wir korrekt ausgegeben, wird aber beim Scan nicht in der .po Datei berücksichtigt. Insgesamt ist nur ein Teil der Texte erkannt worden. Irgendwo liegt da der Hase im Pfeffer. Ich denke aber, es wäre ein wichtiger Schritt, das Plugin gettext-ready zu machen. Ideen?

Gruß, Mike

[maennchen1.de]

Vielleicht parst das Plugin nur php Dateien?

[MKJ]

Vielleicht parst das Plugin nur php Dateien?

Du hast leider den Nagel auf den Kopf getroffen. PHTML sollte sich eigentlich genau so parsen lassen. Ich werde dem Entwickler des Plugin mal schreiben. Dennoch gibt es Fortschritte. Mit PoEdit kann man auch die Templates parsen, wenn man das ausdrücklich in die Settings schreibt. Das Programm meckert zwar, parst aber. Ich habe testweise ein deutsches und ein englisches Set hochgeladen in den Ordner wpshopgermany/lang. Aktiviert wird das Ganze mit

Code: Alles auswählen

add_action( "init", "langswitch" );
function langswitch() {
load_plugin_textdomain( "wpsg", false, "wpshopgermany/lang" );}

In der wp-config kann ich nun mit

Code: Alles auswählen

define('WPLANG', 'de_DE');

oder

Code: Alles auswählen

define('WPLANG', 'en_EN');

die Sprache auswählen. Und das klappt auch. Wordpress selbst kümmert sich nicht darum, wenn keine entsprechende Sprachdatei vorhanden ist. Das ist gut, denn das deutsche Sprachpaket ist ein Speicherfresser vor dem Herrn. Ein Schönheitsfehler ist, dass das Localization Plugin die von PoEdit erzeugten Dateien verschmäht. Änderungen sind also nicht so komfortabel. Vielleicht lässt sich das Plugin ja entsprechend modifizieren. Alternativ könnte man auch .PHP statt .PHTML bei den Templates verwenden, sofern nichts dagegen spricht.

Wichtig wäre also, dass alle Textausgaben, die das Frontend betreffen, gettext-ready werden. Dann ist das Problem mit den Updates behoben. Alles weitere kann dann nach und nach kommen. Das Backend halte ich für weniger wichtig, denn der Shop ist ja ausdrücklich für deutsche Betreiber gedacht.

@Maennchen1: Könnten wir das bis zum nächsten Backup einpflegen? Ich gehe gerne alle meine Übersetzungen durch und mache sie, wenn nötig, gettext-ready. Für das Frontend würde ich dann aber lieber einen anderen Index verwenden, um die Sprachdateien schlank zu halten und Frontend und Backend zu trennen. Ihr habt "__" verwendet. Wie wäre es mit "_e"? Falls diese Methode auch für andere Elemente funktioniert (Graphiken, Navigation etc.), dann könnte man mit qTranslate kostenlos und simpel Mehrsprachigkeit realisieren. Dann müsst Ihr "nur" noch die Ausgabe aus der Datenbank regeln. Diese Lösung ist nix für Leute mit Angst vor Quelltext. Aber es ist ja auch schon viel verlangt, einen kompletten Shop installieren zu wollen, ohne eine Zeile HTML schreiben zu können.

Gruß, Mike

[Olaf]

Glückwunsch Mike und vielen Dank für deine Mühen!!!

Mit Bildern klappt das dann auch mal wenn die so eingebunden werden, denk ich

Code: Alles auswählen

__("<img src='URL/DEUTSCHES_BILD.GIF' alt='' />", "wpsg")

oder eleganter:

Code: Alles auswählen

<img src='__("URL/DEUTSCHES_BILD.GIF", "wpsg")' alt='' />

[MKJ]

Mit Bildern funktioniert das auch:

Code: Alles auswählen

<?php echo __( '<img src="/en/wp-content/themes/twentyten/images/red.jpg" alt="Test" />', 'wpsg' ) ?>

Allerdings muss der jeweilige String natürlich in PHP eingebettet sein. Das kann bei gemischten HTML/PHP Zeilen etwas Gefummel sein. Aber grundsätzlich geht's. Leider kommt jetzt die schlechte Nachricht: qtranslate erkennt die gettext Anweisungen nicht und schaltet auch nicht WP auf eine andere Sprache. Der Code oben funktioniert also tadellos, wenn die Spracheinstellung in WP geändert wird, nicht aber, wenn ich die Einstellung über qtranslate vornehme. In dem Forum dort gibt es leider mehr Fragen als Antworten. Selbst diese Variante geht nicht:

Code: Alles auswählen

<?php echo _e( '<!--:en--><img src="/en/wp-content/themes/twentyten/images/red.jpg" alt="Test" /><!--:--><!--:de--><img src="/en/wp-content/themes/twentyten/images/green.jpg" alt="Test" /><!--:-->' ) ?>

Das wäre aber auch keine echte Lösung, weil wir die Sprache ja zentral verwalten wollen. Es ist mir absolut unbegreiflich, dass ein Plugin, das so lange entwickelt wird, noch immer solche Probleme mit Basisfunktionen hat. Haben die Nutzer von qTranslate eine Idee? Warum gibt es für Wordpress nach 8 Jahren eigentlich noch immer keinen wirklich guten Sprachumschalter?

Mike

[Olaf]

Leider kommt jetzt die schlechte Nachricht: qtranslate erkennt die gettext Anweisungen nicht und schaltet auch nicht WP auf eine andere Sprache.

Ach du meine Fresse, stimmt, so ein Mist. Dann ist das Plugin für hier unbrauchbar.

Ich hab auf einer Seite noch dieses Teil (Polyglott) am laufen, das schaltet um und läuft trotz keiner Weiterentwicklung auch auf WP 3.1

Weiß aber nicht inwieweit das Sinn macht, seit 04.2008 nichts mehr passiert dort, außer RussenSpammer die sich da austoben

P.S. übrigens wäre hier die Funktion für das parsen der Ausgabe vom Shop:

Code: Alles auswählen

if(function_exists('qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage')) $output = qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage($output);

Also $output müsste die Variable sein die den gesamten Content des Shops enthält, dann müssten die QT-Tags da ersetzt werden.

[MKJ]

Polyglot schaltet bei mir nicht den Shop um, dieses Plugin macht das tadellos, unterstüzt aber keine Tags bei den Posts. Das ist natürlich keine Lösung, aber zum Testen schon mal ganz gut. Das ist doch wirklich zum Mäusemelken, dass es kein Plugin gibt, dass dieses Problem löst!

@Maennchen1: Macht es Sinn, dass ich meine Installation schon mal auf PO-MO Dateien umstelle? Oder stehen die Chancen schlecht, das bis zum nächsten Update zu integrieren?

Mike

[maennchen1.de]

Wie oben beschrieben, läuft schon viel mit __(, es sind aber einige Stellen, die es noch zu finden gilt :-/
Ich kann leider nicht garantieren, die alle schon bis zum nächsten Update zu finden...

[MKJ]

Ab heute unterstützt das Plugin Localization auch PHTML Dateien. Chapeau!! Damit ist es so einfach wie noch nie, Sprachdateien zu erstellen (!!) und zu editieren. Das Plugin findet nicht weniger als 462 Strings! Hätte ich das nur ein paar Tage vorher gewusst! Egal, der Shop kann jetzt jedenfalls ganz leicht auf Mehrsprachigkeit umgestellt werden, was die Dateien außerhalb der Datenbank angeht. Bei Updates bleiben diese Übersetzungen also erhalten! Man muss nur einen Ordner anlegen mit den Sprachpaketen (in meinem Fall lang) und die wphsopgermany.php ergänzen um

Code: Alles auswählen

add_action("init", "langswitch"); function langswitch() {load_plugin_textdomain("wpsg", false, "wpshopgermany/lang");}

Wahrscheinlich ist das nicht der beste Code der Welt, aber er funktioniert.

Wenn Maennchen1 jetzt noch eine Lösung für die Datenbank findet, wäre schon viel gewonnen. Solange der Zugriff auf eine gemeinsame Datenbank aber nicht möglich ist, würde das nicht viel ändern. Aber schon jetzt kann man den Updates gelassen entgegen sehen. Man braucht sich um die zweisprachigen Elemente einfach nicht mehr kümmern.

[maennchen1.de]

Das fördert natürlich die Motivation! Sofern es kein Aprilscherz ist...
Neben der Produkt-Datenbank gibt es aber noch ein paar kleine Schwierigkeitchen. Zum Beispiel die Templates aus der Datenbank (Produkttemplates, E-Mail, etc). Aber wir sind da dran. Bald gibt es eine offizielle Meldung dazu.
Aber erstmal das hier hinter uns bringen.

[MKJ]

Das fördert natürlich die Motivation! Sofern es kein Aprilscherz ist...

Für einen Scherz wäre das etwas zu viel Arbeit gewesen! Nö, ist alles ganz ernst gemeint!

[MKJ]

Die meisten Nutzer von qTranslate, die hier im Forum mitlesen, haben doch sicher ein Interesse an Mehrsprachigkeit für den Shop. Könnten die hier mal etwas mitmischen? Ich habe keine Ahnung, warum qTranslate die gettext Strings des Shops ignoriert. Im Forum dort habe ich bisher keine Antwort bekommen. Grundsätzlich kann das Plugin das ja, sonst würde es mit Wordpress nicht funktionieren. Wenn das hinhaut, wäre der Weg schnell frei für einen mehrsprachigen Shop.

Mike

[Olaf]

Das schrieb ich weiter oben zum Thema:

P.S. übrigens wäre hier die Funktion für das parsen der Ausgabe vom Shop:

Code: Alles auswählen

if(function_exists('qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage')) $output = qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage($output);

Also $output müsste die Variable sein die den gesamten Content des Shops enthält, dann müssten die QT-Tags da ersetzt werden.

Problem ist das der Shop die Artikel(Beschreibungen) nicht in wp_posts vorhält sondern in ExtraTabelle. QTranslate parst aber nur wp_content/wp_excerpt. IMHO brauchte Männchen nur mal verraten wo obiges einzufügen wäre....

[MKJ]

Hi Olaf,

im Moment geht es mir weniger um den Inhalt der Datenbank. Dafür muss Maennchen1 eine Lösung finden. Das Problem, das ich zunächst knacken möchte, sind die gettext Strings. Ich habe hier in meiner Testumgebung wunderschön alles mit Sprachpaketen ausgerüstet. Und warum, um alles in der Welt, frisst qTranslate das nicht? Möglicherweise ist das Problem, wann die jeweiligen Funktionen aufgerufen werden. Aber vielleicht tritt das Problem nur bei mir auf. Deshalb wäre es so sinnvoll, wenn mal ein anderer Nutzer von qTranslate das bei sich testen könnte. Die Sprachpakete kann ich auch hochladen.

Gruß, Mike

[Olaf]

Ach so, ja, hatte ich nicht mehr auf dem Schirm.

Schick mir mal die Sprachdateien, vielleicht komm ich dazu mir das mal anzuschauen...