Lokalisierung in WinForms: verwendet jemand die vorgesehene Technologie?

  • VB.NET

Es gibt 19 Antworten in diesem Thema. Der letzte Beitrag () ist von Cell.

    Lokalisierung in WinForms: verwendet jemand die vorgesehene Technologie?

    Im FW vorgesehen ist ja, das Form auf "Localizable" zu stellen, und einfach inne Muttersprache zu gestalten.
    Dann kann man wenns fertig ist, nachträglich lokalisieren, indem man eine abweichende Language auswählt, und dann alle Beschriftungen neu machen.
    Mehr muss man nicht tun, alles weitere macht Visualstudio - läuft das Produkt in einer ausländischen RechnerKultur, bekommen die User es in ihrer Sprache angezeigt.
    Es gibt sogar Übersetzer-Tools, aber ich find das zunächstma garnet so blöd, tatsächlich alle Controls selbst zu re-beschriften, und zu testen - dann weiss man am genauesten, wie's rauskommen wird.

    Also meine Frage: Kennt jemand dieses Feature, und arbeitet praktisch damit?
    Wenn nein, warum nicht?

    Hintergrund meiner Frage ist, dass ich neuerdings an einem sehr komplexen Produkt mit-arbeite, und das ist mit unerhört umständlichen Aufwand lokalisiert, mit einem mir fast abstrus erscheinendem selbstgebastelten "Lokalisierungs-Procedere".
    Aber ehe ich mich da bei den Kollegen unbeliebt mache mit:
    "Kinners - haut den Sch... bitte in Tonne und lasst uns anfangen, normal zu lokalisieren..."

    dachte ich, ich frag mal, ob jemand praktische Produktiv-Erfahrung hat mit dem Lokalisierungs-Konzept, wie es von MS für WinForms ja vorgesehen ist.

    Ich hab mich mit Lokalisierung auch schon bischen beschäftigt, vor langem, und auch Ergebnisse veröffentlicht - also falls jmd genauer gucken will, wovon ich eiglich rede:
    activevb.de/cgi-bin/tippupload/show/106/Lokalisierung

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    ErfinderDesRades schrieb:

    Kennt jemand dieses Feature, und arbeitet praktisch damit?
    Gehört habe ich davon mal. Allerdings benutze ich das nicht. Das erscheint mir irgendwie nicht wirklich flexibel, da alles im Designer stattfindet. Ist klar, wo diese Lokalisierungsdaten/Strings für die Kulturen dann gespeichert werden? In irgendwelchen Dateien, die man auch einfach so hinzufügen kann? Wenn ja, dann ist das ganz in Ordnung. Ansonsten ist halt das weitere Hinzufügen von Sprachen imho etwas umständlich.
    Ich arbeite da mit JSON und Serialisierung. Das heißt, ich setze halt dann im Code meistens die Texte etc. über die Instanz von der Klasse, die die lokalisierten Strings in Form von Eigenschaften enthält. Ob das so schön und sauber ist, will ich nicht behaupten, aber es funktioniert so halt und man kann flexibel Sprachdateien hinzufügen und auswählen, die dann ausgelesen werden.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Theoretisch ginge das hierbei auch.
    Die Sprachdatei ist eine resx Datei, also eine Ressource. Ich setze die Control Texte im Designer in der jeweiligen sprache und für Texte, die flexibel sein müssen, erstelle ich eine entsprechende Ressource Datei.
    "Hier könnte Ihre Werbung stehen..."

    Wie siehts aus, wenn man Controls wegnimmt, umbenennt, neue zufügt?
    Gefährdet das die Stabilität, oder zieht das Nacharbeiten nach sich (ist bei uns derzeit die Hölle)?

    Das ist eine Frage an euch beide, Trade & MichaHo

    Ach -fallen mir noch mehr fragen ein: Was ist mit Tooltip-Texten, DatagridviewColumn-Überschriften etc?

    Also wenn Du meine Methode meinst, dann würde das ja automatisch mitgeändert, da ja nur die Eigenschaften der Controls angesprochen werden.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Also mit weg nehmen und hinzufügen von controls ist eigentlich einfach. Du musst lediglich dran denken, die Sprachen umzustellen und die Benennung anzupassen.
    Bei den DGV Colums bin ich so vorgegangen:
    ich habe eine Ressource Datei erstellt und dort jedem felexiblem Text eine Einstellung verpasst.
    zum Beispiel ​dgvColName = Bezeichnung
    EIne Datei für die Standard Sprache und eine Datei für die 2. Sprache (bei mehreren Sprachen halt mehrere Dateien).
    dann brauchst immer nur den Controls oder hier DGV die entsprechende Einstellung zuzuweisen und sie wird automatisch an die ausgewählte Sprache angepasst.
    ​dgv.Headertext = dgvColName
    Beim Compilieren hast du dann einen Ordner für jede Sprache den du mitlieferst.
    "Hier könnte Ihre Werbung stehen..."

    Trade schrieb:

    Also wenn Du meine Methode meinst, dann würde das ja automatisch mitgeändert, da ja nur die Eigenschaften der Controls angesprochen werden.
    Verstehe ich nicht.
    Also angenommen, ich hab ein Label1 auffm Form, mit Text "Hallo Welt", und engl: "Hello World".
    Nu bau ich einen SplitContainer ein, verschiebe das Label da drauf, und benenne es um zu lbHalloWelt, weil man soll ja ordentlich benamen.
    Das würde keine Lokalisierungs-Nacharbeit nachziehen, sondern nach deim System hätte nun lbHalloWelt automatisch in englischer Kultur den Text "Hello World"?

    Du könntest den Beschriftungen der Controls einen String aus einem ResourceDictionary zuweisen welche z.B. standardmäßig Deutsch ist. Zusätzlich schreibst du alternative ResourceDictionaries in unterschiedlichen Sprachen und überschreibst die Deutsche anhand der Thread.CurrentCulture.

    C#-Quellcode

    1. var cultureInfo = Thread.CurrentThread.CurrentCulture;
    2. var resourceFile = new FileInfo(Path.Combine(Environment.CurrentDirectory, "Resources", "Languages",
    3. $"Resources.{cultureInfo.Name}.xaml"));
    5. if (resourceFile.Exists)
    6. {
    7. var resourceDictionary = new ResourceDictionary {Source = new Uri(resourceFile.FullName, UriKind.Absolute)};
    8. Current.Resources.MergedDictionaries.Add(resourceDictionary);
    9. }


    Ich bin mir aber gerade nicht sicher ob nur WPF ResourceDictionaries besitzt oder ob du das in WinForms auch verwenden kannst.

    en-US.xaml

    <ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:system="clr-namespace:System;assembly=mscorlib"
    xmlns:local="clr-namespace:MilkyCoffee.Resources.Languages">

    <system:String x:Key="LanguageFriendlyName">English (en-EN/US)</system:String>

    <system:String x:Key="PlaybackTab">playback</system:String>
    <system:String x:Key="LibraryTab">library</system:String>
    <system:String x:Key="DiscoverTab">discover</system:String>
    <system:String x:Key="SettingsTab">settings</system:String>

    <system:String x:Key="GeneralOptions">General</system:String>
    <system:String x:Key="PlaybackOptions">Playback</system:String>
    <system:String x:Key="AppearanceOptions">Appearance</system:String>
    <system:String x:Key="PluginOptions">Plugins</system:String>
    <system:String x:Key="ApiOptions">API</system:String>
    <system:String x:Key="AboutOptions">About</system:String>

    <system:String x:Key="AppTheme">Theme</system:String>
    <system:String x:Key="Accent">Accent color</system:String>

    </ResourceDictionary>

    de-DE.xaml

    <ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:MilkyCoffee.Resources.Languages"
    xmlns:system="clr-namespace:System;assembly=mscorlib">

    <system:String x:Key="LanguageFriendlyName">Deutsch (de-DE)</system:String>

    <system:String x:Key="PlaybackTab">aktuelle wiedergabe</system:String>
    <system:String x:Key="LibraryTab">bibliothek</system:String>
    <system:String x:Key="DiscoverTab">entdecke</system:String>
    <system:String x:Key="SettingsTab">einstellungen</system:String>

    <system:String x:Key="GeneralOptions">Allgemein</system:String>
    <system:String x:Key="PlaybackOptions">Wiedergabe</system:String>
    <system:String x:Key="AppearanceOptions">Erscheinungsbild</system:String>
    <system:String x:Key="PluginOptions">Erweiterungen</system:String>
    <system:String x:Key="ApiOptions">API</system:String>
    <system:String x:Key="AboutOptions">Über</system:String>

    <system:String x:Key="AppTheme">Theme</system:String>
    <system:String x:Key="Accent">Akzentfarbe</system:String>

    </ResourceDictionary>


    EDIT: Current ist die aktuelle AppDomain

    ja, das meine ich.
    Nur ist meine Frage nicht, wie das geht, sondern wie eure Erfahrungen (möglichst im prof. Bereich) damit sind. Trade zB verwendet es nicht, MichaHo schon, allerdings ist sein PassGen glaub ein Privat-Projekt. ThuCommix redet von Wpf, während ich nach WinForms frage.
    Wie siehts bei dir aus? Wird Lokalisierung bei dir in Firma in dieser Form umgesetzt?

    us4711 schrieb:

    Sorry, gehts um KÖNNEN, oder um ERFAHRUNG mit einer bestimmten Programmiertechnik für WinForms?
    Es geht um Erfahrung damit.
    Weil bei verschiedenen Gelegenheiten hab ich mitbekommen, dass WinForms-Projekte mit anderen Strategien lokalisiert werden als über die scheints doch dafür vorgesehene Form.Localizable-Schiene. Klar ist die teilweise auch einfach unbekannt, aber wenn man sie kennt, täte es mich sehr interessieren, warum man sich trotzdem für einen anneren Weg entscheidet.
    Oder eben auch - wenn man sie verwendet - wie die praktischen Erfahrungen damit sind.

    ErfinderDesRades schrieb:

    umgesetzt
    Wir packen die Items (Name und Text) in eine Excel-Tabelle, wohl sortiert nach Main und Dialogen, und geben das ganze zu einem Übersetzer oder lassen einen kommen.
    Wenn der mehrere Sprachen sieht, kann er den Inhalt auch besser beurteilen und übersetzen. Bei den kurzen Strings ist ja der Inhalt eigentlich nur aus dem Kontext erfassbar, da isses noch gut, wenn die Dialoge als Screenshot mitgegeben werden.
    Gut isses natürlich, wenn entsprechende Fremdsprachler in der eigenen Firma arbeiten, die kann man an den Entwicklungsrechner holen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    @ErfinderDesRades

    private verwende ich das lokalisieren nach Visual Studio, hier in der Arbeit geht das nicht da alle unsere Programme ihr Texte aus INI Dateien holen.
    Das ist historisch bedingt so.

    Die Sache mit den INI's hat den Vorteil, dass jeder Kunde den Text reinschreiben kann den er will.
    Hat oft etwas mit der Kultur des Kunden zu tun. Asien, Europa und Amerika ticken halt anders, was sich z.T. in den Texten widerspiegelt.

    Finde wie eingangs erwähnt die Lokalisierung unter Visual Studio sehr praktisch, passende Namen in der Resourcedatei helfen dir im Code.

    Am Ende kommt es jedoch auch auf andere Dinge an, wie z.B. bei uns - weil man das schon immer so macht und die Kunden das so kennen.

    Gruss

    mikeb69

    Hi, pasGen ist privat, das ist richtig.
    Ich hab aber auch ein FirmenProjekt, da geht es um Vertriebs Auswertungen. Das ist zur Zeit 4 sprachig (deutsch, englisch, grieschich und tschechich) übersetzt haben wir das ähnlich wie Rod, über Excel Tabelle. Die Eigenschaft in der Ressource heisst so wie das Control.
    Die Controls bekommen erst beim Start ihre Beschriftung. Funktioniert einwandfrei.
    "Hier könnte Ihre Werbung stehen..."

    Hallo EdR

    Ich arbeite schon länger mit der WinForms Lokalisierungsmethode. Da ich in einem Konzern im Automotive Bereich arbeite bleibt da lokalisierung nicht aus. Deutsch,Englisch,Französich,Mandarin,etc..

    Wichtigste Voraussetzung ist meiner Meinung nach, dass der Code und die GUI nach möglichkeit sauber getrennt sind und nicht die Code großartig die GUI anpackt. Das dürfte Logisch sein. Was Flexibilität angeht ist die Methode im Designer meiner Meinung nach kaum zu schlagen, weil jedes Formular für jede unterstützte Sprache komplett angepasst werden kann. Von den Lokalisierungsstrings mal abgesehen kommt es immer wieder mal vor, dass das Control für den anderssprachigen Text zu klein ist. Spätestens hier kanns dann ganz schnell problematisch werden. Das VS genieriert aber bei korrekter Lokalisierung ein eigenes Formular für jede Sprache und steuert dann auch je nach eingestellter Systemsprache beim Enduser die korrekte Version an.

    So schicke ich das fertige Projekt beispielsweise zu meinem Kollegen in China und der legt dann eine neue Lokalisierung in Mandarin an. Dann haben wir z.B. Login.vb,Login_EN.vb,Login_DE,Login_CN.vb
    DIe ganzen Formulare braucht man nicht anlegen. Sobald in der Lokalisierungseigenschaft des Forumulars eine neue Sprache angegeben wird und dann am Formular was geändert wird generiert VS dieses neue Forumular sprachenabhängig.

Facebook
Telefonspende