Laden...

prakt. Erfahrungen mit Standard-Lokalisierung von WinForms-Projekten

Erstellt von ErfinderDesRades vor 6 Jahren Letzter Beitrag vor 6 Jahren 1.423 Views
ErfinderDesRades Themenstarter:in
5.299 Beiträge seit 2008
vor 6 Jahren
prakt. Erfahrungen mit Standard-Lokalisierung von WinForms-Projekten

Hi!

In unsere Firma wird ein selbstgebasteltes Lokalisierungs-System verwendet, was die Programm-Wartung imo exorbitant behindert.
Aber bevor ich die Kollegen mit den Vorzügen der Standard-Vorgehensweise konfrontiere, hätte ich gerne Erfahrungsberichte aus anner Leuts Praxis, weil meine Erfahrungen gehen über ein paar Tests nicht hinaus.

Mit "Standard-Vorgehensweise" meine ich, dass man beim Form Localizable.True einstellt, dann zB Language.fr-fr, und dann das Gui französisch betextet.
Dann werden ja entsprechende Resorucen generiert und Satteliten-Dlls.

Ich persönlich habe ja einen sehr angenehmen Eindruck von dieser Vorgehensweise - ja wie gesagt: bestätigt sich das auch in eurer Praxis?

Ist das durchgängig anwendbar, oder sind in bestimmten Fällen Nacharbeiten erforderlich?
Etwa Messagebox-Texte anzeigen findet ja nicht im Designer statt - wie gaht man damit um?
Oder Spaltenbeschriftungen von Datagridviews? Oder gar von zugekauften TabellenControls - wird das auch durch die Standard-Vorgehensweise unterstützt?

Der frühe Apfel fängt den Wurm.

849 Beiträge seit 2006
vor 6 Jahren

Hi,

ich fand das standard System immer recht frickelig bis ich den hier gefunden habe:
ResxResourceManager

Die Extension erleichtert die Arbeit mit dem System doch ungemein. Zumal man dann nicht immer alle Forms durchklickern muss und immer wieder die Sprache ändern muss. Wenn ich mich recht erinnere hat der Manager auch eine Ex/Import Funktion was die Arbeit mit externen Übersetzern nochmal erleichtert.

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo ErfinderDesRades,

Etwa Messagebox-Texte anzeigen findet ja nicht im Designer statt - wie gaht man damit um?

Dazu kannst du (einmal) per Hand eine Ressourcen-Datei mit entsprechenden Lokale hinzufügen.

Z.B. Strings.resx (für die Assembly-neutrale Kultur) und Strings.fr-fr.resx.
VS erzeugt dabei Code und beim Build die Ressourcen-Assemblies.
Der Zugriff ist dann einfach string myLocalizedString = Strings.Foo, wobei Foo ein Eintrag in der Resx-Datei ist.

Das finde ich echt super und geht problemlos.

Vorteilhaft sehe ich auch wie die .net-Runtime die Ressourcen-Assemblies (oder auch Satelliten-Assemblies) sucht. Dadurch ist es möglich dass diese Assemblies auch später nachgeliefert werden können und das Programm diese ohne Neukompilierung, etc. verwenden kann.

Zu den Punkten wie Datagridviews kann ich leider nichts sagen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

R
228 Beiträge seit 2013
vor 6 Jahren

Wir nutzen seit längerem das Mutlilingual App Toolkit für Wpf (WinForms sollte auch kein Problem sein) --> https://marketplace.visualstudio.com/items?itemName=MultilingualAppToolkit.MultilingualAppToolkitv40

Wir schicken dann die standardisierten XLIFF Exporte (falls nötig) an ein Übersetzungsbüro und müssen dann nur die bearbeitete Datei einbinden. Zugriff auf die übersetzten Texte erfolgt dann über die Ressourcen-Dateien.

Auch automatische Übersetzungen sind möglich, aber die bewegen sich meist auf google translator Niveau.