Best Practice für Schlüsselwerte in Übersetzungsdateien

Question

Im Allgemeinen verwenden Übersetzungsmethoden ein Schlüssel> Wert-Mapping und verwenden den Schlüssel, um das in einen Wert umzuwandeln. Jetzt erkenne ich zwei verschiedene Methoden, um Ihre Übersetzungsschlüssel zu benennen und innerhalb meines Teams kommen wir nicht zu dem Konsens, was die beste Methode zu sein scheint.

Methode 1: Verwenden englische Wörter oder Sätze:

Name => Name 
Please enter your email address => Please enter your email address 

Methode 2: Verwenden Sie Stichworte, um die Situation zu beschreiben:

NAME => Name 
ENTER_EMAIL => Please enter your email address 

Ich persönlich bevorzuge Methode # 1, da Es zeigt direkt die Bedeutung der Nachricht an. Wenn die Übersetzung nicht vorhanden ist, können Sie auf den Schlüssel zurückgreifen, und das verursacht keine Probleme. Die Methode ist jedoch umständlich, wenn sich eine Übersetzung häufig ändert, da alle Dateien aktualisiert werden müssen. Auch für längere Texte werden diese Tasten sehr groß. Dies wird durch die Verwendung von Schlüsseln wie ENTER_EMAIL gelöst, aber die Formulierung ist völlig außerhalb des Kontexts. Die Liste der abstrakten Übersetzung Schlüssel wäre riesig, Sie benötigen Metadaten für alle Schlüssel, die ihre Verwendung erklären und Kollisionen können viel einfacher auftreten.

Gibt es das Beste aus beiden Welten oder eine dritte Methode? Wie verwenden Sie Übersetzungsschlüssel in Ihrer Anwendung? In unserem Fall ist es eine php-basierte Webapplikation, aber ich denke, das obige Problem ist generisch genug, um über i18n im Allgemeinen zu sprechen.

Answer 1

Diese Frage stellen sich auch iOS/OSX-Entwickler. Und für sie gibt es sogar eine standard tool called genstrings, die Methode 1 annimmt. Aber natürlich müssen Apple-Entwickler dieses Werkzeug nicht benutzen - ich nicht.

Während das Sicherheitsnetz, das Sie mit Methode 1 erhalten, nett ist (d. H. Sie können den Schlüssel anzeigen, wenn Sie vergessen haben, eine Zeichenfolge zu lokalisieren), hat dies den Nachteil, dass es zu widersprüchlichen Schlüsseln führen kann. Manchmal muss ein identischer Stück Text aufgrund von Grammatikregeln oder Kontextunterschieden auf zwei verschiedene Arten lokalisiert werden. Zum Beispiel wäre die französische Übersetzung für "E-mail" "E-Mail", wenn es ein Dialogtitel ist und "Envoyer un e-mail", wenn es ein Knopf ist (auf Französisch ist das Wort "E-mail" nur ein Nomen und kann nicht als Verb verwendet werden, anders als im Englischen, wo es sowohl ein Nomen als auch ein Verb ist. Mit Methode 2 könnten Sie die Schlüssel EMAIL_TITLE und EMAIL_BUTTON haben, um dieses Problem zu lösen, und als einen Bonus würde dies einen Hinweis für Übersetzer geben, die ihnen helfen sollen, korrekt zu übersetzen.

Ein weiterer Vorteil von Methode 2 besteht darin, dass Sie den englischen Text ändern können, ohne sich um die Aktualisierung des Schlüssels in Englisch und in all Ihren Lokalisierungen kümmern zu müssen.

Also ich empfehle Methode 2!

Answer 2

Warum nicht beide Welten nutzen? Ich verwende Methode # 1 für kurze Strings und Methode # 2 für lange Strings, die ganze Sätze sind. Ich habe keine Angst, beides in der gleichen Datei zu mischen.

Zum Beispiel in der folgenden Zeichenfolge kann der Text, wenn in einer neuen App-Version ändert die Erfahrung Benutzer geändert wird:

"screen description" = "Tap the plus button to add a new item. Tap an item for more options or to edit its details."; 

Also hier ist es sinn Methode # 2 anzuwenden macht. jedoch für einfache Zeichenfolgen wie im folgenden Beispiel, Verfahren # 1 ist nützlicher:

"Preferences" = "Preferences"; 

Im Allgemeinen, wenn die Leute versuchen, die Dinge zu standardisieren es scheint mir oft restriktiv. Persönlich bevorzuge ich einen eher "anarchistischen" Ansatz, bei dem mehrere Methoden gültig sind (nicht nur wie in dieser Methode # 1 vs. Methode # 2, sondern auch zum Beispiel, wenn ein Team von Entwicklern um den Codierungsstil kämpft).