Noch einmal Mehrsprachigkeit

[MKJ]

Maennchen1 hat ja gebeten, dass wir unseren Senf zu diesem Thema abgeben. Leider beteiligt sich kaum jemand daran. Angesichts der vielen Interessenten bei der Wunschliste wundert das ein wenig. Ich bin sehr interessiert an diesem Feature, kann aber auch nicht mehr ewig darauf warten. Gibt es noch andere, die an einer Sparlösung interessiert wären? Für mich wäre es völlig ausreichend, wenn es im Plugin eine Funktion gibt, die die Inhalte aus Datenbank und am besten auch aus den Templates nach bestimmten Weichen ausgibt. Also z. B. page id="en" => Ausgabe der Produktbeschreibung in englisch, page id="de" => Ausgabe der Produktbeschreibung in deutsch. Ich hätte auch keine Probleme mit zwei WP-Instanzen. Nur müsste halt in einer Instanz der Shop auf eine gemeinsame Datenbank zurückgreifen.

Könnten die Entwickler dazu eine kurze Info zum Aufwand geben? Wäre so eine quick and dirty Lösung mit vertretbarem Aufwand machbar? Die Meinung der anderen User wäre natürlich auch interessant.

[Joe]

Hi Mike,
wenn ich mich recht entsinne, kannst du das, was du vorhast mit qTranslate sogar schon umsetzen..
einfach in den beschreibungen

Code: Alles auswählen

<!--:en-->english text<!--:--><!--:de-->german text<!--:-->

verwenden.
Habs nicht getestet, sollte aber gehen..
Gruß Joe

[MKJ]

Das wäre schön gewesen, klappt aber leider nicht. Aus diesem Grund habe ich seinerzeit von qTranslate Abstand genommen. Für reine Textseiten ist das Plugin prima, also vor allem für Blogs. Sobald komplexe Aufgaben dazu kommen, klappt es nicht mehr. Die Language Tags werden leider in der Produktbeschreibung ignoriert und erscheinen im Quelltext. Der Browser interpretiert sie als Kommentare und zeigt sie einfach nicht an. Beide Sprachen werden dann voll ausgegeben.

[Joe]

schade
wie ist es mit den quicktags? gehen die vielleicht?

Code: Alles auswählen

[:de]deutsch[:en]englisch

http://www.qianqin.de/qtranslate/forum/ ... ?f=3&t=385

[MKJ]

Leider nein!

[Joe]

eine andere Möglichkeit wäre es die Produktbeschreibung, Bilder etc auf Seiten/Artikel zu packen, die mit qTranslate mehrsprachig angelegt werden. und wpshhopgermany nur für das verkaufen selber benutzen...

[MKJ]

eine andere Möglichkeit wäre es die Produktbeschreibung, Bilder etc auf Seiten/Artikel zu packen, die mit qTranslate mehrsprachig angelegt werden. und wpshhopgermany nur für das verkaufen selber benutzen...

Hm, das ist den Kunden wohl nicht wirklich zumutbar. Man kommt beim Bestellvorgang eben doch nicht ganz ohne Text aus. Den müsste man dann eben englisch oder gleich zweisprachig anzeigen. Das wirkt nicht sehr professionell. Es bleibt das Problem, dass qTranslate eben nicht alle Elemente der Seite sicher kontrolliert. Ich neige als Übergangslösung für die Variante mit 2 WP-Instanzen. Lagerverwaltung und Wartung sind zwar mühsam, aber als Grundlage kann ich damit erstmal leben.

WPML schien mir am Anfang aussichtsreich zu sein, aber ich finde deren Politik nicht akzeptabel. Ich habe von denen noch nie Support bekommen, aber nach nur wenigen Minuten war gleich ein Kommentar der Jungs hier auf der Homepage, den man fast schon als Spam bezeichnen muss. Ein WP-Plugin, das de facto ein Abo ist, finde ich auch ziemlich abwegig. Vielleicht kommt Maennchen1 ja mit einer provisorischen Lösung raus, die man selbst anpassen muss. Damit könnte ich gut leben.

Nach unserer Vorarbeit für den PDF Hintergrund beim Rechnungsmodul wäre das ja das Mindeste!

[side777]

ich persönlich lehne wpml auch aus dem selben grund ab.

wie wär's denn mit mo-files? nur für die buttons und so? emails können von mir aus ruhig zweisprachig sein, nach dem motto 'english version below'...

produkte als artikel anzulegen würde ich für den rest bevorzugen. damit hätte man nicht nur mehr freiheit in der gestaltung der artikel-seiten, sondern könnte auch z.b. auf bilder aus der mediathek zugreifen, die suchfunktion benutzen, produkte über tags filtern, neue produkte in der sidebar, etc...

das wäre aber entweder eine grundliegende änderung am plugin, oder man bastelt sich immer jeweils einen artikel für jedes produkt, so mache ich das im moment...

[MKJ]

wie wär's denn mit mo-files? nur für die buttons und so? emails können von mir aus ruhig zweisprachig sein, nach dem motto 'english version below'...

Mo-Files wären sicher sehr elegant. Aber dafür müsste der Shop letztlich die gleiche Technologie verwenden, die Plugins wie qTranslate schon haben. Genau das wollen die Entwickler ja vermeiden. Den ganzen Wordpress-Teil könnte man sehr leicht über ein custom field ("de" und "en") und Klassen steuern. Das custom field lässt sich einfach als body id="" einlesen. Anschließend kann man alle zweisprachigen Elemente mit jeweils einer Klasse versehen. Zwei CSS-Befehle braucht man dann nur noch:

Code: Alles auswählen

#de div.HideEn {display:none;} #en div.HideDe {display:none;}

Bei einer Seite mit dem custom field "en" wird dann die "deutsche Klasse" ausgeblendet und anders herum. Unschön ist daran natürlich, dass es jede Menge Quelltext mit dem Attribut display:none gibt. Man könnte aber auch eine Kombination nehmen und qTranslate für alles nutzen, was es kann, den Rest macht man wie oben. Der Shop bräuchte alle eigenen Funktionen dann nur noch über einen Parameter (z.B. die body id) schalten. Das wird im Detail natürlich nicht ganz so simpel sein, aber das Prinzip finde ich schlüssiger als die Abhängigkeit von einem anderen Plugin. Wenn man die Auslesefunktion für das custom field (in diesem Fall "page")

Code: Alles auswählen

<body id="<?php echo get_post_meta($post->ID, 'page', true);?>">

über das Backend einpflegen könnte, müssten die Nutzer nicht einmal den Quellcode anfassen.

[Olaf]

Hallo Allerseits,
ich brauchte bisher das nur englisch, also nicht mehrsprachig. Deshalb hab ich mich damit nicht weiter befasst.

IMHO wäre der beste Weg sich QTranslate mal anzuschauen wie es the_excerpt bzw. the_content behandelt. Da wird es eine Funktion geben die entsprechende Teile strippt. Diesen Parser müsste man mit in den Shop reinbasteln. Am Ende wird im Shop sicher die gesamte Ausgabe per "echo $shop_content" ausgegeben. Dann einfach qtrans_funktion($shop_content)

[MKJ]

Ich habe in einer Testinstallation jetzt mal den Shop auf englisch umgestellt. Soweit so gut. Bei einem Update wird das allerdings eine fiese Arbeit, weil man in der übersetzten Version natürlich die neuen Dateien nicht einfach darüber braten kann. Dann wären ja auch alle Übersetzungen weg.

Eine dicke Bitte an die Entwickler: Könntet Ihr einen schnellen Workaround posten, mit dem Texte als Variablen hinterlegt und in einer zentralen Sprachdatei gespeichert werden? Das würde auch ohne ausgefeilte Zweisprachigkeit zumindest als Übergangslösung funktionieren und könnte in der endgültigen Lösung vielleicht auch verwendet werden. Es würden vielleicht auch ein paar generelle Hinweise reichen. Ich könnte das testen und hier dann auch die Übersetzungen einstellen. Quick and dirty könnte man das natürlich mit Variablen pro Seite lösen. Das funktioniert und wäre schon mal besser für ein Update. Aber so richtig prickelnd ist diese Lösung natürlich nicht.

Danke und Gruß, Mike

[Olaf]

Hi Mike,
hast du dir "CodeStyling Localization" mal angeguckt? Las das mal zum testen drüberlaufen, liest das die Strings schon aus? Einige sind ja schon entsprechend eingebaut....

[MKJ]

Hi Olaf,

das Problem dürfte wohl sein, dass der Shop noch nicht für gettext vorbereitet ist. Der Aufwand dafür ist aber, denke ich, sehr überschaubar. Hier ist eine gute Anleitung dazu. Am Quellcode wären nur minimale Veränderungen nötig. Eine Zeile wie:

Code: Alles auswählen

<h2 class="widgettitle">Warenkorb</h2>

würde dann ungefähr zu:

Code: Alles auswählen

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

Die .mo und .po Dateien müsste man erstellen und einbinden. Damit hätte man bis auf die Datenbank alles schon mal ganz gut im Griff. Ich würde das bei mir auch sofort umstellen, aber solange die Updates das nicht haben, bringt es halt nicht viel. Wenn es noch einen Workaround für die Datenbank gäbe, dann wäre das Plugin damit an sich schon mehrsprachig. Für echte Mehrsprachigkeit müsste natürlich auch die gleiche Datenbank genutzt werden, aber bis dahin könnte man sich ganz gut behelfen, ohne dass jedes Update zu einem Tageswerk wird. Die üblichen Plugins setzen ja auch auf diese Technik für alles, was nicht im Backend editiert wird.

@Maennchen1: Wäre das nicht ein guter Startpunkt?

[Olaf]

Wie gesagt, teilweise ist das ja schon vorgesehen:

Code: Alles auswählen

<strong>'.__("wpShopGermany: Ihr Lizenzkey ist ungültig.", "wpsg").'</strong>

mal ein beliebig schnell gefundener Schnipsel.

Wenn Localisation das findet, dann kannst du dir die mo/po selbst im Plugin generieren.

[maennchen1.de]

Richtig. Gettext war unser erster Ansatz. 3 Wochen nach dem ersten Release. Deshalb ist so gut wie alles schon damit umgesetzt. Aber es gibt noch ein paar Stellen, die sich nicht selber finden lassen wollen... Wir sind aber dabei diese stetig auszubessern.