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.
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.
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!"
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.