Frage

Ist es aus Ihrer Erfahrung besser, 1 Sprachdatei oder mehrere kleinere Langauge -Dateien für jede Sprache in einem PHP -Projekt mit der GetText -Erweiterung zu verwenden? Ich bin mir nicht einmal sicher, ob es möglich ist, mehrere Dateien zu verwenden. Es fällt mir schwierig, zu testen, da der Server die Sprachdateien zwischengespeichert.

Ich mache mehrere Sprachen auf einer Website für soziale Netzwerke, bisher nur die Anmeldeseite, die ungefähr 1 von 200 Seiten vor sich ist und 35 Textzeichenfolgen übersetzt werden. In diesem Tempo ist die Sprachdatei für jede Sprache wirklich groß. Ich dachte, es wäre vielleicht besser, verschiedene Sprachdateien für verschiedene Seiten oder Abschnitte wie Forenabschnitt und Blogs zu erstellen, aber wenn es keinen Unterschied macht, würde ich meine Zeit nicht verschwenden, um mehrere kleinere Dateien für jede Sprache zu erstellen.

Mir ist klar, dass jede Situation anders ist, und die einzige wirkliche Antwort ist, sie zu testen, aber ich hoffe, dass ich diesmal vermeiden und nur einige Gegenteiler von Menschen erfahren habe. Dies ist mein erstes Mal, dass ich GetText benutze, danke

War es hilfreich?

Lösung

Ich hätte das Modul der Sprachdateien basiert. Mit GetText müssen Sie für jede Sprache das Gebietsschema angeben. Für jedes Modul oder große Teile Ihrer Website würde es am besten zu einem separaten .po/.mo -Dateien passen.

Das ist meine Meinung. :-)

Andere Tipps

Ich automatisiere den Prozess normalerweise und habe mehrere Sprachen in mehreren Dateien mithilfe einer Datenbank, um die Site zu bearbeiten (mithilfe einer einfachen DB -Suche). Auf diese Weise können ich Übersetzer einstellen, um die aktuelle Übersetzung leicht zu überprüfen. Die Bereitstellung für die Produktion ist dann einfach die Datenbank in eine Reihe von Sprachdateien.

Aus Erfahrung würde ich die Sprachen pro Datei abbauen, wenn der Management -Overhead stark wird und es einen großen Umfang für Duplizierung und Fehler gibt.

Der andere Vorteil ist, dass die richtige Sprache durch die Verwendung einer Verzeichnisstruktur und der Namenskonvention programmlich einfacher ausgewählt werden kann als die große Datei, und es ist einfacher, Management -Tools zu einem späteren Zeitpunkt des Projekts zu schreiben.

Es lohnt sich auch, einige der Formate zu betrachten, die andere Menschen verwenden. Viele der Frameworks verwenden diese Art von Struktur, Dashcode, Symfony, Zend usw., und es gibt ein XML -Format XLIFF, das für die Übersetzung erstellt und in viele der Tools integriert wird, die Übersetzer verwenden.

Multiple files are the best way to go, but things can get disorganized.

We've just launched a free new service called String which solves most of the problems of managing multiple language files - like a basecamp for localization. You can either import existing files, or start from scratch with keys and strings in the system. When you're ready, you can export the files again to run your app. It works with PHP (array), PHP (define), po, yaml, ini and .strings formats.

String allows you to collaborate with translators easily - you just invite them to a project and set their language permissions. Translators can leave comments and questions on each string if they need more info - and you can revert strings back using the History function if things aren't quite right.

Anyway enough sales pitch! Check it out at http://mygengo.com/string - we'd love your feedback.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top