Mehrsprachigkeit mit wpShopGermany

18.03.2011   von maennchen1 unter Allgemein

Die Mehrsprachigkeit ist ein vielgefordertes Feature für wpShopGermany. Dabei ist sie extrem komplex, unterscheidet sie sich doch in mehrere Bereiche:

  • Backend (Theme, Shop-Einstellungen, Status-Mails)
  • Frontend (Theme, Shop-Templates)
  • Produkte (Produktnamen, -texte, -attribute, -preise, -variablen, etc.)

Darüber hinaus gilt es zu beachten bestimmte Formatierungen (Datum, Uhrzeit, Zahlen) einzuhalten. Wir beschäftigen uns intern schon eine Weile mit der technischen Umsetzung einer Mehrsprachigkeit. Dabei geht es hauptsächlich darum, die Kompatibilität einzuhalten. Denn die oben genannten Bereiche müssen natürlich vollständig und nachhaltig über das komplette Blogsystem abgedeckt sein und nicht nur in unserem wpShopGermany Plugin.

Wird die Sprache auf Seite XY umgeschaltet, so muss sich das System den “Schalter” merken und auch im wpShopGermany nutzen.

Bei WordPress liegt der Schluss also nahe, ein vorhandenes Plugin zu nutzen, was die Internationalisierung ermöglicht. Und hier brauchen wir dringend die Mithilfe aller Kunden und die, die es werden wollen. Bisher liebäugeln wir mit WPML. Auch wenn es jetzt kostenpflichtig ist, so scheint es für uns die beste Wahl zu sein. Schließlich soll mit dem Shop professionell Geld verdient werden. Da darf nix schief laufen und kann auch was kosten!

Hast du schon Erfahrung mit WPML sammeln können? Oder vielleicht mit anderen Plugins oder Techniken? Schildere uns doch bitte kurz deine Erfahrungen oder diskutiere mit!

Bevor wir das Feature umsetzen, müssen wir uns im Klaren sein, was die wpShopGermany-Kunden wollen und bedienen können!

Mehrsprachigkeit mit wpShopGermany: 1 Stern2 Sterne3 Sterne4 Sterne5 Sterne
1,00 von 5 Sternen, basieren auf 1 abgegebenen Stimmen.
Loading...

Kommentare

  • roger sagt:

    Momentan wird im Forum heftig diskutiert und mittels qtranslate ist auch schon so gut wie eine Lösung gefunden. Du findest das gut oder schlecht? Diskutiere mit:
    http://forum.maennchen1.de/viewtopic.php?f=13&t=933&start=30

  • David sagt:

    @Mike:
    Falls du das meinst: Ich komme mit zig Widgets und WPML super klar: wird alles sauber getrennt über Conditional-Abfragen via “language” über Widget Logic oder inzwischen wohl auch nativ… So kann man pro Sprache getrennte Widgets anlegen… Oder bei nicht so komplexen Widgets via String-Übersetzung. Läuft bei mir wunderbar.
    Natürlich hast du Recht mit den komplexen Abhängigkeiten, nur stellt sich mir die Frage, wie man das dauerhaft perfekt lösen/verhindern will? Dürfte so nicht möglich sein in dieser Welt… Wie auch immer: so schlecht finde ich die Preise gar net (natürlich: kostenlos oder preiswerter würde mir auch SUPER gefallen!!!), man kann die freie Vers. ausprobieren, hat 30 Tage Rückgaberecht und 2 Preisvarianten. Und nach 1 Jahr für die Hälfte… Wenn mir für das Geld ordentliche Updates und Support gewährleistet werden, warum nicht? Ich brauche für meine Projekte ordentliche Lösungen, und Mehrsprachigkeit ist nun mal nicht so trivial wie es erscheinen mag (hab ich auch gedacht vor meinem ersten Projekt letzen Herbst…).
    [obligatorischer Hinweis: ich hab mit WMPL nichts zu tun, werde nicht “bezahlt” von denen!]

  • Mike sagt:

    Unterstützt WPML inzwischen sicher und zuverlässig PHP Widgets? Das war vor einigen Monaten noch nicht der Fall (ich meine damit PHP Code in einem Widget). Auf meine Anfrage habe ich beim Support NIE eine Antwort erhalten. So ging es mir auch mit anderen Problemen. Wenn sich ein Plugin von einem anderen abhängig macht, muss dieses 100% in allen Lebenslagen funktionieren. Das war bei WPML nicht der Fall. Im Übrigen finde ich deren Preispolitik inakzeptabel.

  • David sagt:

    Ich verwende bei einigen Projekten WPML – sowohl in der freien als auch der neuen kostenpflichtigen Version. Bin damit äußerst zufrieden. Die Performance wurde letzens nochmals deutlich gesteigert, das System ergibt für mich den meisten Sinn, da es umfassende Werkzeuge zur Übersetzung bietet: Inhalte/Posttypen inkl. Archive/Tags, Widgets, Themes usw. Wirklich zweisprachige Webseites sind damit möglich und die Vorbereitung/Unterstützung für viele andere wichtige Plugins ist auch ein großer Vorteil.
    Ich kann ihrer Firma nur empfehlen, WMPL zu unterstützen bzw. mit denen an einer Lösung zu arbeiten. Ich denke, das ergibt am Ende eine professionelle Lösung für alle Seiten, die in erster Linie FUNKTIONIERT.
    Danke!

  • Mike sagt:

    So einfach ist es leider nicht!

  • ICKUH sagt:

    Am besten so einfach wie möglich und mit einem Button im Webshop versehen mit dem jeder Kunde direkt die Sprache wählen kann.
    Beim nächsten Shopupdate würde ich mich über dieses Feature sehr freuen, hätte auch kein Problem damit einen kleinen Betrag zu zahlen.

  • Simon sagt:

    Bin jetzt seit einiger Zeit auch mit qtranslate am probieren und bin bisher SEHR zufrieden. Ich habe nicht viele andere plugins ausprobiert aber bsiher überzeugt es mich völlig. das konzeept einfach ein neues tab neben dem deutschsprachigen für jede einzelne sprache zu haben ist super übersichtlich….

  • Mike sagt:

    Aus verständlichen Gründen beantwortet der Entwickler aber nicht alle Emails. Deshalb frage ich hier nach. Das qTranslate Support-Forum scheint jedenfalls keine erweiterten Möglichkeiten zu kennen. Insbesondere graphische Navigationen sind wohl ein Problem. Für einen Shop ist das aber wichtig.

    Ich fände eine Shop-interne Lösung am besten, bei der eine PHP-Weiche die verschiedenen Übersetzungen nach bestimmten Kriterien ausgibt. Also etwa nach URL (www.domain/en/ etc.) oder nach einer ID (body id=”en”).

    Das ist keine Fire & Forget Lösung, aber dafür ist das Ganze nicht von einem anderen Plugin abhängig und ließe sich – für den Shop – sauber implementieren. Die Nutzer wären dann halt für die Übersetzung der übrigen Inhalte selbst zuständig.

    Für eine zweisprachige Seite fände ich auch zwei WP-Instanzen und die Enterprise-Lizenz ok. Das Problem ist eben nur, dass bei Instanzen auf die gleiche Produktdatenbank zurückgreifen müssen (Lagerbestand etc.)

    Vielleicht sollten die Entwickler eine Umfrage ins Forum stellen, die die Anzahl der benötigten Sprache abfragt. Ich bin ziemlich sicher, dass kaum jemand mehr als Englisch braucht. Das ist ja auch eine Kostenfrage, wenn man einigermaßen korrekte Übersetzungen möchte.

    Die Abhängigkeit von einem anderen Plugin, vor allem von einem kostenlosen, finde ich auch bedenkenswert.

  • Geru sagt:

    Der Entwickler von qTranslate spricht perfekt Deutsch! Nur er wird kompetent
    Auskunft gegen können.
    http://www.qianqin.de/

  • Mike sagt:

    Die Übersetzung kann einem kein Plugin abnehmen. Können die Nutzer von qTranslate mal prüfen, ob über das Plugin überhaupt die nötigen Daten für den Shop gesteuert werden können? Entscheidend sind ja letztlich die Datenbank-Templates. Hier wird der Shop eventuell selbst eine Lösung mitbringen müssen. Kann qTranslate z.B. die Navigation steuern, wenn man Graphiken und keinen Text verwendet?

  • Geru sagt:

    Arbeite schon länger mit qTranslate und habe sehr gute Erfahrungen damit gemacht!
    WMPL habe ich auch mal kurz getestet aber eine Umstellung wäre mit sehr viel Arbeit verbunden gewesen und ausserdem ist WMPL viel aufwändiger und komplizierter als qTranslate. Mag sein, dass es stabiler läuft aber wer schnell Texte bzw. Produkte übersetzen will ist mit qTranslate viel besser bedient!

    Zitat: “Auch wenn es jetzt kostenpflichtig ist, so scheint es für uns die beste Wahl zu sein. Schließlich soll mit dem Shop professionell Geld verdient werden. Da darf nix schief laufen und kann auch was kosten!”
    Stimmt! Aber der Verkäufer sollte auch nicht stundenlang mit Übersetzungsarbeiten beschäftigt sein. Auch das kostet nämlich Geld!!

  • Mike sagt:

    qTranslate wird das Problem, glaube ich, nicht knacken. Die Mehrsprachigkeit muss ja auch die Inhalte in der Datenbank, PHP-Widgets, die phtml-Templates etc. abdecken. Ich glaube, das kann qTranslate nicht. War jedenfalls so, als ich es probiert habe. Da war die Domäne von qTranlate der normale Inhalt, der zweimal angelegt und mit einem Sprachtag versehen wurde. Könntest Du das mal überprüfen, Joe?

    Gruß, Mike

  • Joe sagt:

    Für mehrsprachige Projekte setze ich bisher qTranslate ein.
    Hatte bisher keine Probleme damit.
    weitere Infos hier: http://www.qianqin.de/de/qtranslate/
    das Einzige was man da meiner Meinung nach noch optimieren könnte, wären eigene permalinks.

    Gruß Joe

  • Amir Helzer sagt:

    Sorry for writing here in English. I hope we can manage with that.

    We’re currently doing large projects with two other major e-commerce plugins for WordPress and we will be happy to help make wpShopGermany multilingual-ready.

    The approach that we’re taking is to add a small number of hooks and filters in the e-commerce plugin and then write a new plugin that sits between WPML and the e-commerce plugin and handles everything.

    The big challenge is to allow translation for products, but keep the product, stock and delivery administration unified. This is why multiple WordPress installs, one per language, cannot work. You will end up managing everything twice.

    As the web-developer, it looks like a small thing, but the client who will run the website will throw this solution out the window. It’s just impossible to track everything separately in each language.

    I’m subscribing to the comments here. Let me know if you’d like to work together to make your plugin and WPML compatible.

  • daniel sagt:

    Mein Plan bisher war diese “Gettext” Funktion von WordPress __($text, $namespace) zu verwenden. Diese ist bisher auch schon in ca. 80% des Codes verwendet worden.

    Jetzt bräuchte ich doch nur noch die Keywords in eine .po Datei zu bringen die dann übersetzt werden kann.

    Diese .po bzw. die .mo Datei müsste dann je nach Browser Einstellung oder Backend Einstellung geladen werden wenn vorhanden.

    Ne Idee für ein extra Widget wäre dann noch ein Sprachumschalter.

    Hier gibts noch Infos dazu:

    http://codex.wordpress.org/Translating_WordPress

    Von daher wären wir auch von keiner anderen Extension abhängig. Das php müsste dann Serverseitig mit gettext Unterstützung ausgerüstet sein.

    Nachteil der Lösung wäre aber sicherlich das die Anpassbarkeit eingeschränkt wäre.

  • Mike sagt:

    Mehrsprachigkeit ist ein extrem wichtiges Feature! Ich habe in der Vergangenheit mehrere Plugins getestet und fand WPML am ehesten brauchbar. “Am ehesten” heißt: Die meisten versprochenen Features funktionierten, aber keineswegs alle. Der Support war so katastrophal, dass er diesen Namen nicht verdient.

    Das Plugin ist jetzt kostenpflichtig. Dagegen wäre an sich nichts zu sagen. Aber auch hier ist die Politik der Firma mal wieder alles andere als transparent. So ist zunächst nicht klar, was die 79 USD von der 29 USD Version unterscheidet. Im Kleingedruckten erfährt man dann, dass der “Support” (das sind auch die neuen Versionen!) nach einem Jahr für 50% des Preises gekauft werden muss. Das ist eine absurde Regelung, die ich so noch nicht kannte.

    Unter diesen Bedingungen scheinen mir derzeit zwei getrennte WP-Instanzen fast die bessere und letztlich auch preiswertere Lösung. Der administrative Aufwand ist größer, keine Frage. Aber dafür ist so eine Variante absolut stabil.