Gettext: Ist es eine gute Idee, dass die Nachrichten-ID der englische Text ist?

Question

Wir bereiten uns vor, unsere PHP-Website in verschiedene Sprachen zu übersetzen, und die Gettext-Unterstützung in PHP sieht nach dem Weg aus.

Alle Tutorials sehe ich empfehlen, den Englisch Text als Message-ID, das heißt

gettext ("Hallo!")

Aber ist das wirklich eine gute Idee? Nehmen wir an, jemand im Marketing möchte den Text zu "Hallo, ihr alle!" Ändern. Dann müssen Sie nicht alle Sprachdateien aktualisieren, weil sich diese Zeichenfolge - die eigentlich die Nachrichten-ID ist - geändert hat?

Ist es besser, eine generische ID wie "Hallo.Message" und eine englische Übersetzungsdatei zu haben?

Answer 1

ich aussagekräftige IDs wie „welcome_back_1“, das wäre „welcome back, %1“ usw. Ich habe immer Englisch als meine „Basis“ Sprache so im schlimmsten Fall, wenn eine bestimmte Sprache, die ich nicht eine Nachrichten-ID hat, Rückgriff auf Englisch.

Ich mag es nicht, tatsächliche englische Sätze als Nachrichten-IDs zu verwenden, denn wenn sich das Englisch ändert, ändert sich auch die ID. Das mag Sie nicht sehr beeinflussen, wenn Sie einige automatisierte Tools verwenden, aber es stört mich. Ich mag es nicht, einfache Codes (wie msg3975) zu verwenden, weil sie nichts bedeuten, daher ist das Lesen des Codes schwieriger, es sei denn, Sie werfen Kommentare überall hin.

Answer 2

Haben Sie Ihre eigene Frage nicht schon beantwortet? :)

Klar, wenn Sie beabsichtigen, i18n Ihrer Anwendung zu unterstützen, sollten Sie alle Sprachimplementierungen gleich behandeln. Wenn jemand entscheidet, dass eine Zeichenfolge geändert werden muss, nehmen Sie eine ähnliche Änderung in allen Sprachdateien vor. Die Metadaten mit dem Einchecken sollten alle Sprachdateien in der gleichen Änderung gruppieren. Wenn Ihre "Standard" -Sprache anders gehandhabt wird, ist es schwieriger zu pflegen.

Answer 3

Der Grund für die IDs ist Englisch, so dass die ID zurückgegeben wird, wenn die Übersetzung aus irgendeinem Grund fehlschlägt - die Übersetzung für die aktuelle Sprache und Token nicht verfügbar ist oder andere Fehler. Das setzt natürlich voraus, dass der Entwickler den ursprünglichen englischen Text schreibt, nicht irgendeine Dokumentationsperson.

Auch wenn sich der englische Text ändert, müssen wahrscheinlich die anderen Übersetzungen aktualisiert werden?

In der Praxis verwenden wir auch Pure IDs anstelle von englischem Text, aber es bedeutet, dass wir viel mehr Arbeit auf Englisch machen müssen.

Answer 4

Ich würde so weit gehen, zu sagen, dass Sie nie (für die meisten Werte von nie) freien Text als Schlüssel zu irgendetwas verwenden möchten. Stellen Sie sich vor, wenn SO zum Beispiel den Abfragetitel als Schlüssel für diese Seite verwendet. Wenn jemand damit verlinkt und der Titel dann bearbeitet wird, ist der Link nicht mehr gültig.

Ihr Problem ähnlich ist, außer dass Sie auch für die Aktualisierung aller Links verantwortlich wäre ...

Wie Douglas Leeder erwähnt, was Sie wahrscheinlich wollen Englisch als Standard (Backup) Sprache, obwohl eine tun, verwenden Schnittstelle, die Englisch und eine andere Sprache vermischt verwendet, ist sehr verwirrend (aber auch leicht amüsant).

Answer 5

Ich stimme stark mit Richard Harrisons Antwort, über die er sagt es ist "der einzige Weg". Lieber Fragesteller, traue nicht einer Antwort, die besagt, dass es der einzige Weg ist, weil der "einzige Weg" nicht existiert.

ist hier eine andere Art und Weise, die meiner Meinung nach ein paar Vorteile gegenüber Richards Ansatz hat:

• Starten Sie die Proto-Version des englischen String als Vorlage mit verwenden.
  • lesbaren Code
  :
  • Sie eine Übersetzungsdatei für Englisch nontheless
  • Kopieren Sie die Proto-Strings an die Übersetzung für den Anfang

  Vorteile nicht diese Proto-Strings anzeigen, sondern erstellen

• Text in Ihrem Code ist sehr nahe, wenn nicht identisch mit dem, was Ihre Ansicht zeigt
• Wenn Sie den englischen Text ändern möchten, chan nicht ge des Proto-String aber die Übersetzung
• wenn Sie die gleiche Sache zweimal übersetzen wollen, nur ein etwas anderes Proto-String schreiben oder fügen Sie einfach ‚-Version für dies und die‘, und Sie haben immer noch einen perfekt lesbaren Code

Answer 6

Wow, ich bin überrascht, dass niemand die Verwendung des Englischen als Schlüssel befürwortet. Ich habe diesen Stil in einigen Softwareprojekten verwendet, und IMHO hat es ziemlich gut geklappt. Die Lesbarkeit des Codes ist groß, und wenn Sie eine englische Zeichenfolge ändern, wird es offensichtlich, dass die Nachricht für die Neuübersetzung in Betracht gezogen werden muss (was eine gute Sache ist).

Für den Fall, dass Sie nur die Rechtschreibung korrigieren oder eine andere Änderung vornehmen, die definitiv keine Übersetzung erfordert, ist es einfach, die IDs für diese Zeichenfolge in den Ressourcendateien zu aktualisieren.

Das heißt, ich überlege gerade, ob ich diesen Weg, I18N zu einem neuen Projekt zu bringen, mitnehme oder nicht, also ist es gut, ein paar Gedanken darüber zu hören, warum es keine gute Idee ist.

Answer 7

In einem Wort tun Sie das nicht.

Das gleiche Wort/Ausdruck im Englischen kann oft genug mehr als eine Bedeutung haben, und jeder bedeutet eine andere Übersetzung.

Definieren Sie mnemonische IDs für Ihre Strings und behandeln Sie Englisch als eine weitere Sprache.

Vereinbaren Sie mit anderen Plakaten, dass ID-Nummern im Code ein Albtraum für die Lesbarkeit von Code sind.

Ex Lokalisierung Ingenieur

Answer 8

Zusätzlich zu den obigen Überlegungen gibt es viele Fälle, in denen Sie den „Schlüssel“ wollen würden (msgid) verschieden sein kann, aus dem Quelltext (Englisch). In der HTML-Ansicht möchte ich zum Beispiel sagen [JJJJ], wo das Ziel und die Bezeichnung dieses Anchor-Tags vom Gebietsschema des Benutzers abhängen. Z.B. es könnte ein Link zu einem sozialen Netzwerk sein, und in den USA wäre es Facebook, aber in China wäre es Weibo. Die MsgIds könnten also etwas wie socialSiteUrl und socialSiteLabel sein.

Ich verwende eine Mischung.

Für grundlegende Zeichenfolgen, die ich glaube nicht, wird Konflikte/Änderungen/seltsame Bedeutungen haben, werde ich den Schlüssel der gleiche wie der Englisch sein.

Answer 9

Am Ende des Tages sollte ein Übersetzer in der Lage sein, sich zu setzen und die Texte für jede Sprache zu ändern (so dass sie in der Bedeutung übereinstimmen), ohne den Programmierer zu involvieren, der seine Arbeit bereits erledigt hat.

Das bin ich wie die richtige Antwort fühlen macht, ist eine modifizierte Version von gettext zu verwenden, in denen Sie Strings wie dieser sein

_(id, backup_text, context) 

_('ABOUT_ME', 'About Me', 'HOMEPAGE') 

Kontext setzen optional

warum so? , weil Sie Text im System identifizieren müssen, indem Sie einen eindeutigen englischen Text verwenden, der anderswo wiederholt werden könnte.

Sie sollten auch die Sicherung, id und den Kontext an der gleichen Stelle im Code halten Diskrepanzen zu verringern.

Die IDs müssen auch lesbar sein, die das Problem der Synonyme bringt und doppelte Nutzung (auch als ids), wir die IDs wie dieses „HOMEPAGE_ABOUT_ME“ prefix könnte oder „MAIL_LETTER“, aber

1. Leute vergessen, dies zu Beginn tun und es später sind ein Problem, ändern
2. seine flexibler für das System zur Gruppe der Lage sein, sowohl von id und Kontext

, weshalb ich auch die Kontextvariable hinzugefügt am das Ende

kann der Backup-Text so ziemlich alles, sogar könnte „[ABOUT_ME @ Home Text konnte nicht geladen werden, bitte kontaktieren Sie example@example.com]“

Es wird nicht mit den aktuellen gettext Bearbeitungsprogrammen arbeitet wie "poedit", aber ich denke, dass Sie benutzerdefinierte Variablennamen für Übersetzungen wie nur "t()" ohne den Unterstrich am Anfang definieren können.

Ich weiß, dass gettext hat auch Unterstützung für Kontexte, aber es ist nicht sehr gut dokumentiert oder weit verbreitet.

P.S. Ich bin mir nicht sicher über die beste variable Reihenfolge, um guten und erweiterbaren Code zu erzwingen, so dass Vorschläge willkommen sind.

Answer 10

Es gibt eine Menge zu bedenken und zu beantworten ist nicht so einfach.

plain English

Pros

• Einfach unter Verwendung des Code
• In den meisten Fällen zu schreiben und zu lesen, es funktioniert auch ohne
in Codeübersetzungsfunktionen laufen

Cons

• Involved Programmierer müssen auch gute Texter sein :)
• Sie müssen in Englisch korrekt präzise Texte vollständig schreiben, auch in dem Fall, dass erste Sprache, die Sie etwas ausführen müssen andere (dh wir beginnen lof von Projekte in tschechischer Sprache und wir lokalisieren sie später auf EN).
• In vielen Fällen müssen Sie Kontexte verwenden. Wenn Sie es nicht von Anfang an tun, ist es eine Menge Arbeit, sie später hinzuzufügen. Um zu erklären: In Englisch kann ein Wort viele verschiedene Bedeutungen haben - und Sie müssen Kontexte verwenden, um sie zu unterscheiden - und es ist nicht immer so einfach (Reihenfolge = Reihenfolge sortieren, oder es kann Bestellung sein).
• Es kann sehr schwer sein, Englisch später im Prozess zu korrigieren. Korrekturen der Quellstrings führen sehr oft zum Verlust bereits übersetzter Phrasen. Es ist sehr frustrierend, die Übersetzung in 3 verschiedene Sprachen zu verlieren, nur weil Sie Englisch korrigiert haben.

Mit den Tasten

Pros

• Sie können auch für die englische Sprache Lokalisierung Plattform Funktionen nutzen. I.e. Wir benutzen die schöne Crowdin-Plattform. Es gibt viele praktische Tools - oder besser gesagt einen kompletten Workflow - für das Übersetzungsmanagement: Abstimmung für verschiedene Übersetzungen, Übersetzungshistorie, Glossare (hilft dabei, die Übersetzung/Sprache kohärent zu halten), Proofing, Genehmigung, etc. Die Verwendung von Schlüsseln macht diesen Prozess sehr viel Mehr glatt.

• Es ist viel einfacher für Normalerweise Korrektur usw. Engish Texte zu senden, ist es keine gute Idee, Texter direkt Ihren Code ändern zu lassen :)

Cons

• Mehr komplizierte Projekteinrichtung
• Härtere% d zu verwenden,% s usw.