it-swarm.dev

Effektive Strategien zur Lokalisierung in .NET

Ich entwickle die Benutzeroberfläche für eine .NET MVC-Anwendung, die in naher Zukunft eine internationale Lokalisierung aller Inhalte erfordert. Ich bin mit .NET im Allgemeinen sehr vertraut, hatte aber noch nie ein Projekt, bei dem ein so starker Fokus auf internationale Zugänglichkeit erforderlich war.

Das Projekt wird zunächst in englischer Sprache durchgeführt. Welche Maßnahmen sollte ich an dieser Stelle ergreifen, um die zukünftige Implementierung der Lokalisierung zu vereinfachen?

123
smartcaveman

Sie entwickeln eine ASP.Net MVC-Anwendung, oder? Andere Antworten scheinen spezifisch für Desktop-Anwendungen zu sein. Lassen Sie mich gemeinsame Dinge festhalten:

Gebietsschemaerkennung

Es ist sehr wichtig, dass Ihre Anwendung das Gebietsschema des Benutzers korrekt erkennt. In der Desktop-Anwendung enthält CultureInfo.CurrentCulture das bevorzugte Formatierungsgebietsschema (das zum Formatieren von Zahlen, Datumsangaben, Währungen usw. verwendet werden sollte), während CultureInfo.CurrentUICulture das bevorzugte Gebietsschema der Benutzeroberfläche enthält (das zum Anzeigen lokalisierter Nachrichten verwendet werden sollte). . Für Webanwendungen sollten Sie beide Kulturen auf automatisch setzen (um das Gebietsschema automatisch aus dem AcceptLanguage-Header zu erkennen), es sei denn, Sie möchten einen ausgefallenen Workflow zur Erkennung des Gebietsschemas implementieren (d. H. Das Ändern der Sprache bei Bedarf unterstützen).

Strings externalisieren

Alle Zeichenfolgen sollten aus Ressourcen stammen, dh aus Resx-Dateien. In der Winforms App ist dies leicht zu erreichen, indem die Eigenschaft Form Localizable auf true gesetzt wird. Sie müssten auch (leider) Zeichenfolgen, die von Ihren Modellen stammen, manuell externalisieren. Es ist auch relativ einfach. In Asp.Net müssten Sie alles manuell externalisieren ...

Layouts

Sie müssen auf jeden Fall die Zeichenfolgenerweiterung berücksichtigen. In der Winforms-Welt ist dies über TableLayoutPanel möglich, mit dem sichergestellt werden soll, dass das Layout automatisch an längeren Text angepasst wird. In der Web-Welt haben Sie ein bisschen Pech. Möglicherweise müssen Sie den CSS-Lokalisierungsmechanismus implementieren - eine Möglichkeit, CSS-Definitionen zu ändern (zu überschreiben). Dies würde es den Lokalisierungsmitarbeitern ermöglichen, Stilprobleme bei Bedarf zu ändern. Stellen Sie sicher, dass jedes HTML-Element auf der gerenderten Seite eine eindeutige ID hat, damit es genau ausgerichtet werden kann.

Kulturspezifische Themen

Vermeiden Sie Grafiken, Farben und Sounds, die für die westliche Kultur spezifisch sein könnten. Wenn Sie es wirklich brauchen, geben Sie bitte Mittel zur Lokalisierung an. Vermeiden Sie richtungsempfindliche Grafiken (da dies ein Problem wäre, wenn Sie versuchen, Arabisch oder Hebräisch zu lokalisieren). Nehmen Sie auch nicht an, dass die ganze Welt dieselben Zahlen verwendet (d. H. Nicht für Arabisch).

ToString () und Parse ()

Stellen Sie sicher, dass immer CultureInfo übergeben wird, wenn Sie ToString () aufrufen, es sei denn, dies wird nicht unterstützt. Auf diese Weise kommentieren Sie Ihre Absichten. Beispiel: Wenn Sie eine Zahl intern verwenden und sie aus irgendeinem Grund in eine Zeichenfolge konvertieren müssen, verwenden Sie:

int i = 42;
var s = i.ToString(CultureInfo.InvariantCulture);

Für Nummern, die dem Benutzer angezeigt werden sollen, verwenden Sie:

var s = i.ToString(CultureInfo.CurrentCulture); // formatting culture used

Gleiches gilt für Parse (), TryParse () und sogar ParseExact () - einige böse Fehler könnten ohne die ordnungsgemäße Verwendung von CultureInfo eingeführt werden. Das liegt daran, dass eine arme Seele in Microsoft, die voller guter Absichten ist, entschieden hat, dass es eine gute Idee ist, CultureInfo.CurrentCulture als Standard zu behandeln (es wird verwendet, wenn Sie nichts übergeben) - schließlich, wenn jemand ToString verwendet ( ) er/sie möchte es dem Benutzer anzeigen, oder? Es stellt sich heraus, dass dies nicht immer der Fall ist. Versuchen Sie beispielsweise, die Versionsnummer Ihrer Anwendung in der Datenbank zu speichern und sie dann in eine Instanz der Versionsklasse zu konvertieren. Viel Glück.

Daten und Zeitzonen

Stellen Sie sicher, dass immer DateTime in UTC gespeichert und instanziiert wird (verwenden Sie DateTime.UtcNow anstelle von DateTime.Now). Konvertieren Sie es bei Anzeige in die lokale Zeit im lokalen Format:

DateTime now = DateTime.UtcNow;
var s = now.ToLocalTime().ToString(CultureInfo.CurrentCulture);

Wenn Sie E-Mails mit Zeitreferenz im Text senden müssen, müssen Sie Zeitzoneninformationen angeben - geben Sie sowohl den UTC-Versatz als auch die Liste der Städte an:

DateTime someDate; // i.e. from database
var formattedDate = String.Format("{0} {1}", 
             someDate.ToLocaleTime().ToString(CultureInfo.CurrentCulture),
             TimeZoneInfo.Local.DisplayName);

zusammengesetzte Nachrichten

Sie wurden bereits gewarnt, Zeichenfolgen nicht zu verketten. Stattdessen würden Sie wahrscheinlich String.Format () wie oben gezeigt verwenden. Ich muss jedoch feststellen, dass Sie die Verwendung zusammengesetzter Nachrichten minimieren sollten. Dies liegt nur daran, dass die Zielgrammatikregeln häufig unterschiedlich sind. Daher müssen Übersetzer den Satz möglicherweise nicht nur neu anordnen (dies würde mithilfe von Platzhaltern und String.Format () behoben werden), sondern den gesamten Satz auf unterschiedliche Weise basierend auf übersetzen was wird ersetzt. Lassen Sie mich einige Beispiele nennen:

// Multiple plural forms
English: 4 viruses found.
Polish: Znaleziono 4 wirusy. **OR** Znaleziono 5 wirusów.

// Conjugation
English: Program encountered incorrect character | Application encountered incorrect character.
Polish: Program napotkał nieznaną literę | Aplikacja napotkała nieznaną literę.

Andere Verkettungsprobleme

Die Verkettung ist nicht auf Zeichenfolgen beschränkt. Vermeiden Sie es, Kontrollen gemeinsam auszulegen, sagen Sie:

Erinnern Sie mich noch einmal in [Textfeld mit Nummer] Tagen.

Dies sollte wie folgt umgestaltet werden: Erinnern Sie mich in dieser Anzahl von Tagen noch einmal: [Textfeld].

Zeichenkodierung und Schriftarten

Speichern, übertragen Sie immer den Text in Unicode (d. H. In UTF-8). Codieren Sie Schriftarten nicht fest - Die Lokalisierung muss sie möglicherweise ändern, und der Standard-Fallback-Mechanismus für Schriftarten wird deaktiviert (im Fall von Winforms). Denken Sie daran, in den meisten Feldern "seltsame" Zeichen zuzulassen (d. H. Benutzername).

Test

Sie müssen wahrscheinlich eine sogenannte Pseudo-Übersetzung implementieren, dh Ressourcen für beispielsweise die deutsche Kultur erstellen und Ihre englischen Zeichenfolgen kopieren, indem Sie Präfix und Suffix hinzufügen. Sie können auch Platzhalter einschließen, um zusammengesetzte Zeichenfolgen leicht zu erkennen. Der Zweck der Pseudoübersetzung besteht darin, Lokalisierungsprobleme wie fest codierte Zeichenfolgen, Layoutprobleme und die übermäßige Verwendung zusammengesetzter Nachrichten zu erkennen.

74
Paweł Dyda

Einige grundlegende Dinge, die Sie berücksichtigen sollten:

Externalisieren Sie alle String-Ressourcen

Alle Ihre Ressourcen sollten in externen Dateien enthalten sein, die zur Lokalisierung übergeben werden können. Vergessen Sie nicht die Fehlermeldungen, wenn Sie diese auch lokalisieren möchten.

Lassen Sie ausreichend Platz für die Zeichenfolgenerweiterung

Zeichenfolgen in einigen Sprachen sind in der Regel bis zu 30% länger (z. B. Griechisch). Stellen Sie daher sicher, dass Sie Ihre Benutzeroberfläche so gestalten, dass Zeichenfolgen bei Bedarf erweitert werden können. Hier ist ein ziemlich extremes Beispiel für Französisch:

Ok -> Accepter (Französisch - 400% Expansion)

Ich würde empfehlen, eine Art Pseudo-Übersetzung als Ausgangspunkt zu verwenden ( http://en.wikipedia.org/wiki/Pseudolocalization ). Oder Sie übersetzen Ihre Ressourcen über Google Translate oder Bing. Dies gibt Ihnen einen guten Hinweis darauf, wie die tatsächlichen Übersetzungen aussehen werden.

Achten Sie auf Text in Bildern

Wenn Sie in Ihrer Anwendung Bilder verwenden - stellen Sie sicher, dass diese keinen Text enthalten -, kann dies offensichtlich nicht übersetzt werden.

Codieren Sie niemals Pfade zu Windows-Ordnern fest

Offensichtlich, aber ich habe es in der Vergangenheit gesehen. Beispielsweise, C:\Program Files wird in einigen internationalen Windows-Versionen übersetzt, z. es ist C:\Programme auf einem deutschen Betriebssystem.

Vermeiden Sie die Verwendung länderspezifischer Begriffe

Wenn Sie beispielsweise jemanden auf einem Formular nach seiner „High School“ fragen, hat dies in Westeuropa wenig Bedeutung.

Vermeiden Sie das Erstellen von Zeichenfolgen durch Verkettung von Zeichenfolgen

Das sieht zum Beispiel harmlos aus:

strWelcome = ReadExternalString("Welcome"); 
strMessage = strWelcome + ", " + UserName;

Die Wortreihenfolge auf Japanisch wäre jedoch anders, sodass dies möglicherweise keinen Sinn ergibt.

Zeit-/Datumseinstellungen

Stellen Sie immer sicher, dass das Uhrzeit-/Datumsformat vom Betriebssystem stammt.

74
Jimmy Collins

Besondere Überlegungen für asiatische Sprachen

Zusätzlich zu all den tollen Antworten, die hier bereits vorhanden sind, gibt es einige Hinweise für asiatische Sprachen:

Achten Sie auf unterschiedliche Textlängen

Chinesischer und koreanischer Text sind in der Regel viel kürzer als der entsprechende englische Text (da Sie normalerweise weniger Blockzeichen benötigen, um dasselbe zu schreiben), sodass eine Seite möglicherweise auf Chinesisch leer aussieht, aber vollgestopft ist auf Deutsch ... Sie müssen hier eine dynamische Dimensionierung vornehmen, um gut auszusehen.

Japanischer Text ist jedoch in der Regel viel länger, in Bezug auf die Anzahl der Zeichen sogar länger als der entsprechende englische Text.

Achten Sie auf das Grundlayout und den "nach oben geschobenen" Look

Asiatische Zeichen werden normalerweise auf der Grundlinie angeordnet, die keine Nachkommen enthalten (dh den unteren Teil von y, g, q, j usw.). Wenn Sie ein Bildschirmelement formatieren - normalerweise Schaltflächen - mit Text darin, und wenn dieser Text nur asiatische Sprachen ist (dh keine westlichen Alphabete), sieht der Text so aus, als wäre er nach oben verschoben.

Formatierung von Zahlen und lokalisierten numerischen Einheiten

Behandeln Sie die Formatierung von Zahlen anders. Verschiedene asiatische Länder haben unterschiedliche Möglichkeiten, Zahlen zu formatieren. Gleiches gilt für Währungen. In Ostasien sind beispielsweise 10.000 (wan) eine übliche Einheit. In Indien sind 100.000 (Lakhs) üblich.

Lokale Währungen

Die Währungen einiger Länder haben viele Nullen und keinen Dezimalpunkt (z. B. Japan, Indonesien, Italien), während andere bis zu zwei Ziffern nach dem Dezimalpunkt haben.

Achten Sie auf unterschiedliche Wortreihenfolgen

Die Wortreihenfolge ist möglicherweise nicht immer dieselbe. Verwenden Sie am besten {0}, {1} usw. bei der Formatierung von Zeichenfolgen anstelle der hartcodierten Wortreihenfolge, wenn Ihre Zeichenfolge aus einer Kombination verschiedener Daten stammt.

Verwenden Sie die länderspezifische Sortierung

Die Sortierung ist je nach Sprache und Gebietsschema unterschiedlich. Sie sollten sich immer auf die länderspezifische Sortierung des Betriebssystems verlassen.

Seien Sie sehr vorsichtig mit Zeichen voller Breite/halber Breite

Beachten Sie die Unterschiede zwischen Zeichen mit "voller Breite" und "halber Breite". Klammern, Interpunktion usw. können Versionen mit "voller Breite" haben, die sich von Standard-ASCII unterscheiden. Wenn Sie anhand dieser Buchstaben suchen oder Zeichenfolgen aufteilen, müssen Sie zuerst alle Symbole voller Breite in Äquivalente halber Breite konvertieren.

Ein Punkt ist kein Punkt ... ein Komma ist kein Komma ...

Hüten Sie sich vor Dateneingabe-Gotchas - zum Beispiel ist auf Chinesisch ein Punkt nicht ein Punkt ".". Ein Komma ist in voller Breite, nicht ",". Versuchen Sie nicht, nach westlicher Interpunktion zu suchen, wenn der Benutzer, der die Dateneingabe vornimmt, versehentlich die asiatische Sprache IME einschaltet.

Telefonnummern

Nehmen Sie bei der Formatierung der Telefonnummer nicht irgendetwas an. Es gibt nicht immer eine Vorwahl usw. und diese kann unterschiedlich formatiert werden. Normalerweise haben Sie eine Formatzeichenfolge pro Land.

Gehen Sie nicht davon aus, dass die Leute nur eins Handynummer oder eins Faxnummer usw. haben. In Asien ist das nicht so.

Adressen - dichter als Sie vielleicht denken

Nehmen Sie für Adressen nicht irgendetwas an. Möglicherweise gibt es nicht immer eine Postleitzahl. Postleitzahlen sind möglicherweise nicht immer Zahlen. Ein Land darf keine Provinzen/Staaten haben. Ein Land kann nur eine große Stadt sein (z. B. Singapur). Für bestimmte asiatische Länder kann die kleinste Einheit eines Hauses "Raum X, Einheit Y, Abschnitt Z, Etage A, Block B, Gruppe C, Nachlass D" sein. Seien Sie im Allgemeinen sehr liberal in der Anzahl der Felder und der Anzahl der Zeichen, die in Adressen zulässig sind.

Grüße

Anreden sind nicht nur auf Mr., Mrs. usw. beschränkt. Obwohl Sie wahrscheinlich sicher sind, "M" und "F" für Sex zu verwenden, sind wir noch nicht das seltsam ...

24
Stephen Chung

Einige grundlegende Schritte bestehen darin, sicherzustellen, dass eine auf dem Bildschirm angezeigte Zeichenfolge kein Literal in Ihrem Code ist. Wenn Sie Winforms ausführen, verfügt jedes Formular über eine UI-Ressource. Stellen Sie für Dialoge, Berichte usw. sicher, dass Sie die Projektressourcendateien verwenden.

Anstelle von "Upload fehlgeschlagen" in Ihrem Code haben Sie möglicherweise so etwas wie Resources.UploadFailed

Auf diese Weise können Sie für jede Sprache, die Sie verwenden, eine neue Ressourcendatei erstellen (und .Net hilft dabei.) Und die lokalisierte Zeichenfolge in jeder Datei haben.

EDIT Ich habe vergessen zu erwähnen, wenn Sie Ihre Benutzeroberfläche ausführen. Stellen Sie sicher, dass Sie nicht nur Dinge drin stopfen. Abhängig von den Sprachen, in denen Sie lokalisieren, können Immobilien ein Problem sein. Ich habe an einem Projekt gearbeitet, bei dem Deutsch und Portugiesisch die beiden größten Straftäter für das Saitenwachstum waren. Wenn wir nicht vorsichtig wären, was auf Englisch gut wäre, würden Französisch und Italienisch auf Deutsch in die Luft jagen.

11
taylonr

Ich schlage vor, Sie führen FXCop oder Visual Studio Code Analysis (sie sind ziemlich gleich) auf Ihren Assemblys aus.

Sie sind gut darin, .NET-Code zu erkennen, der nicht die richtigen kulturorientierten Überladungen verwendet, wie diese: CA1305: IFormatProvider angeben .

Ich muss hinzufügen, dass diese Tools auch frustrierend sind, weil sie normalerweise zig Probleme in Ihrem Code erkennen, aber selbst wenn Sie nicht jede Regel befolgen, sollten Sie viel lernen.

9
Simon Mourier

Zusätzlich zum spezifischen Laden von Ressourcen würde ich sicherstellen, dass Sie zunächst mit einer pseudolokalisierten Version testen. Andernfalls werden Sie wahrscheinlich nicht die Stellen bemerken, an denen Überlegungen zur Internationalisierung bis zum Ende weggelassen wurden.

7
Jeremy

Neben all den anderen hilfreichen Hinweisen fehlen hier einige:

Berücksichtigen Sie, dass einige Länder mehr als eine Sprache verwenden. In Kanada würde ein Benutzer beispielsweise erwarten, dass er problemlos zwischen Englisch und Französisch wechseln kann.

Wenn Sie dem Benutzer eine Frage stellen, die eine Antwort auf einen einzelnen Buchstaben erwartet, darf der Benutzer nicht die Taste "Y" drücken, um "Ja" zu sagen.

Beachten Sie in gespeicherten Prozessen, dass Daten in der SQL-Datenbank im USA-Format vorliegen

Durch das Platzieren von Textzeichenfolgen in der Datenbank können Sie später weitere Sprachen hinzufügen, ohne sie erneut bereitstellen zu müssen.

Geben Sie beim Senden von geschriebenen Textdateien zur Übersetzung immer eine Beschreibung des Kontexts an, um sicherzustellen, dass der Übersetzer das richtige Wort auswählt. ZB ohne Kontext könnten Sie "Tonhöhe" in etwas übersetzen, das mit Klang oder einem Ort zu tun hat, an dem Sie Fußball spielen

Adressetiketten müssen immer konvertiert werden. Provinz in Kanada, Staat in Amerika, Grafschaft in Großbritannien

6
Brian Leeming

Sie müssen berücksichtigen:

  1. Routing für mehrsprachig

  2. Verschieben Sie alle Hardcode-Zeichenfolgen in die Ressourcendatei

Ein Beispiel für eine Eigenschaft:

Modell:

[Display(Name = <Resource for display name>.<field for this property>)]
[Required(ErrorMessage = <Resource for error message>.<field for this validate message>)]
public string TestProperty { get; set; }

Aussicht:

@Html.LabelFor(m=>m.TestProperty)
@Html.EditorFor(m => m.TestProperty)
@Html.ValidationMessageFor(m => m.TestProperty)
5
langtu

Hier ist etwas, das in den restlichen Antworten nicht erwähnt wird.

Abhängig von der Komplexität Ihrer Anwendung und ihrer Lokalisierung würde ich dringend empfehlen, einen alternativen Ressourcenanbieter zu implementieren und lokalisierte Ressourcen in einer Datenbank zu speichern. Mit dem Standard-ASP.NET-Lokalisierungsschema werden alle Ressourcen in RESX-Dateien gespeichert.

  1. Sind ein Schmerz im Hintern in Visual Studio zu bearbeiten
  2. Beschränken Sie die Verteilung und Verwaltung lokalisierter Ressourcen, nachdem die Anwendung kompiliert/ausgeliefert/ausgeführt wurde.

Als möglichen Anwendungsfall sollten Sie Sprachpakete für Ihre Anwendung und die Möglichkeit zum Importieren und Exportieren von Sprachen über die Benutzeroberfläche bereitstellen. RESX-Dateien würden hier nicht helfen.

In solchen Szenarien ist ein alternativer Ressourcenanbieter sehr hilfreich. Weitere Informationen zur Implementierung finden Sie hier . Dies ist natürlich ein seltener Fall, der häufiger in Unternehmensanwendungen auftritt, aber immer noch gültig ist.

5
Slavo

Das Wichtigste ist die Verwaltung des Inhalts in verschiedenen Sprachen. Ich habe selbst einige Websistes entwickelt und die Verwaltung der Inhalte in verschiedenen Sprachen ist die größte Herausforderung.

Ich verwende die Datenbank, um die Ressourcen/Inhalte zu speichern. Es gibt mir die Flexibilität, jede gewünschte Sprachunterstützung hinzuzufügen. Ich habe die Logik implementiert, auf die englische Sprache zurückzugreifen, wenn eine Ressource in einer bestimmten Sprache nicht gefunden wird.

Sie können später einen Übersetzer verwenden, um den englischen Wert in eine beliebige Sprache umzuwandeln.

3
Tushar

Zusammenfassung der bei der Internationalisierung zu berücksichtigenden Punkte:

  • Alle Informationen sollten internationalisiert werden. Berücksichtigen Sie, dass die Grafiken möglicherweise Informationen enthalten, die wir internationalisieren möchten.

  • Die Größe der Felder oder Zeichenfolgen hängt von der Sprache ab, da dies zu Problemen führen kann.

  • Die Reihenfolge der Wörter hängt von der Sprache ab, in der wir uns befinden. Daher ist eine Reihenfolge in einer Sprache in einer anderen Sprache dieselbe.

  • Wir müssen berücksichtigen, dass sich das Datumsformat von einer Sprache in eine andere ändert

2
Jonatan

Machen Sie den Türkei-Test :

Die Internationalisierung von Software ist nter den besten Umständen schwierig , aber es hat mich immer wieder überrascht, wie oft ein bestimmtes Land in Diskussionen über Internationalisierungsprobleme auftauchte: Türkei ...

Wenn Sie sich für Lokalisierung oder Internationalisierung interessieren, zwingen Sie Ihren Code, so schnell wie möglich unter dem türkischen Gebietsschema ausgeführt zu werden. Es ist ein starkes Signal für Ihren Code, der in den meisten - aber keineswegs allen - Kulturen und Regionen ausgeführt wird ...

Wenn Ihre Site/Ihr Programm mit einem türkischen Client gut läuft, können Sie sicher sein, dass es auf den meisten anderen Plattformen ausgeführt wird.

1
Carra