PHP-Übersetzungs-Frontend ähnlich wie Rosetta?

Ich migriere derzeit eine Webanwendung von einem datenbankbasierten Internationalisierungsansatz (jedes Wort hat einen Eintrag in der Übersetzungstabelle und die eigentliche Übersetzung) zu einem basierend auf Zend_Translate und CSV-Dateien.

Ich muss eine benutzerfreundliche Möglichkeit bieten, diese Übersetzungen schnell und einfach zu aktualisieren. Im Idealfall, um das Risiko zu minimieren, Inhalte zu beschädigen, würden Benutzer die CSV-Dateien nicht direkt bearbeiten, sondern ein nettes Formular mit Feldern angezeigt bekommen.

Kennen Sie ein eigenständiges, PHP-basiertes, endbenutzerkompatibles Übersetzungs-Frontend, das einen der Adapter unterstützt? Zend_Translate zu bieten hat – idealerweise gettext oder csv?

So etwas wie Pythons/Djangos Rosette aber in PHP? Rosetta macht genau das, was ich brauche:

aber aus Gründen der Servereinrichtung möchte ich hier sehr gerne bei PHP bleiben.

EinfachPO sieht aus, als würde es in die richtige Richtung gehen, ist aber zu einfach – es scheint nicht in der Lage zu sein, mit mehreren Sprachen und Katalogen und Pluralformen umzugehen.

Ich habe keinen anderen gesehen und wahrscheinlich aus folgendem Grund. Ungeachtet dessen, was auf der SimplePO-Website steht, mögen und arbeiten Übersetzer oft nicht mit Seite-an-Seite-Übersetzungssystemen, wie oben gezeigt.

So stellen sich Programmierer Übersetzer vor, und das ist fehlerhaft. Übersetzer arbeiten mit einem Toolkit namens TMX, Translation Memory Exchange (generischer Name siehe Okapi, eine Open-Source-Implementierung, um ein Gefühl dafür zu bekommen), und darin bauen sie Übersetzungswörterbücher für Wörter, Phrasen und Sätze auf. Sie nehmen eine Datei mit unterschiedlichen Formaten und speisen sie in die TMX-Software ein. Dies gibt ihnen einen ersten Durchgang, der zu 60 %, 70 % usw. übersetzt ist, aber wie die Google-Sprach-API schrecklich verstümmelt ist, was den Sinn in der Zielsprache angeht.

Dann übersetzen sie die Wörter, die nicht von TMX behandelt werden, ergänzen die Wörterbücher, wo es logisch ist, und sie umgangssprachlich, dh sie bringen es in die Zielsprache und machen es sinnvoll. Aus diesem Grund sollte der Übersetzer immer in seine Muttersprache übersetzen.

Sie tun dies aus einer Reihe von Gründen so, a) es ist sinnvoll und funktioniert und reduziert ihre Arbeitsbelastung und b) weil sie pro Wort bezahlt werden und die parallele Übersetzung es ihnen nicht erlaubt, ihre Tools zu nutzen und zu maximieren ihr Einkommen.

Was Übersetzer wollen, ist eine Datei in einem Format, das Sie exportieren, importieren und übersetzen, exportieren und Ihnen zum Importieren zurücksenden können.

Die Dateiformate können csv, rtf, tmx, xliff, gettext sein und wenn Sie die Symfony-Framework-Dokumentation lesen, können Sie sehen, wie sie es tun und damit umgehen (sie leisten meiner Meinung nach ziemlich gute Arbeit).

Abgesehen davon war ich vor ungefähr 8 Jahren in einer ähnlichen Position, als ich eine Website in Englisch, Französisch, Deutsch, Ungarisch und Slowakisch schreiben musste, und ich tat dasselbe wie SimplPO und schrieb einfach meine eigene Side-by-Side-Anwendung, um dies zu ermöglichen getan werden. Das Unternehmen, für das wir die Bewerbung geschrieben haben, hat jedoch alle ihre eigenen Übersetzungen im eigenen Haus durchgeführt, sodass wir nicht auf das Problem mit den Übersetzern gestoßen sind. Als wir das taten, schrieben wir einen Export nach RTF und einen Import aus RTF (das ist an sich umwerfend), damit die Übersetzer wie oben beschrieben funktionieren konnten.

SimplePO ist jedoch die einzige andere Implementierung der Idee, die ich gesehen habe. Die Frameworks wie Zend scheinen zu glauben, dass Sie nur Lookup-Tags erstellen, um Wörter und Phrasen zu ersetzen, und keine Kontrolle in die Anwendung einbauen, um den Prozess zu verwalten. Folglich gerät es schnell außer Kontrolle und seine Wartung wird sowohl schwierig als auch teuer.

Die meisten Leute, die mehrsprachige Websites schreiben, tun dies tatsächlich nicht. Sie schreiben eine Master-Site und erstellen dann eine Kopie, übersetzen sie und pflegen die übersetzte Version. Es erscheint uns logischen Typen klobig, ist aber tatsächlich sehr effektiv.

Einer der Gründe, warum es so effektiv ist, ist, dass es bei i18n und l10n um viele andere Dinge als Sprache geht.

• Sehen und fühlen. Angelsachsen mögen kühle Farben und serifenlose Schriften, Hispanoamerikaner mögen Serifenschriften und hellere Farben. Und wenn Sie andere Kulturen durchqueren, variieren die Erwartungen stark in Layout, Typen, Farben usw.

• Französisch und bis zu einem gewissen Grad Deutsch sind 30 % länger und ausführlicher als das entsprechende Englisch, sodass Ihr Layout in einem Handkorb sehr schnell zum Teufel geht.

• Semitische Sprache läuft von rechts nach links

• Japanisch und andere Sprachen, die nicht auf dem Alphabet basieren, können ltr rtl von oben nach unten ausführen, und einige haben nicht einmal Leerzeichen
• Termine? USA, Japaner, Großbritannien, Ungarn, da alle unterschiedlich
• Währungs- und Zahlenformate, fangen Sie mich nicht einmal an

Tut mir leid, weiterzumachen und zusammenzufassen: – Für eine einfache Seite an Seite schreiben Sie es einfach selbst, ich habe ungefähr zwei Wochen ohne Frameworks gebraucht und es im Laufe der Zeit ausgearbeitet, indem Sie einfach Tag-Ersetzung verwenden. Aber nicht mehr und bedenke, was du tust. Sorgfältig.

Wenn Sie Gettext-Dateien verwenden können (Zend_Translate unterstützt sie), können Sie dies geben POBearbeiten ein Versuch. Es ist recht einfach zu bedienen und unterstützt Pluralformen seit Version 1.3.

Benutzer müssen die Dateien jedoch herunterladen und am Ende erneut hochladen, da POEdit kein Online-Tool ist. Ich kenne kein anderes webbasiertes Tool.

Du kannst es versuchen Übertragbareine einfache Webschnittstelle zum Bearbeiten von Übersetzungen in PHP-Arrays.