Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Projektvorstellung: LocalizeMe (Typsichere Lokalisierung)
IntelliSoft
myCSharp.de - Member



Dabei seit:
Beiträge: 13

Themenstarter:

Projektvorstellung: LocalizeMe (Typsichere Lokalisierung)

beantworten | zitieren | melden

Die Idee meines Tools ist, eine typsichere Lokalisierung von Strings, Enumerationen, Dateien & Bilder

Dazu gibt es ein NuGet Package: NuGet
& auch ein entsprechendes Testprojekt auf GitHub: Intelli-Soft/TypeSafeLocalization: Test Project for NuGetPackage IntelliSoft.LocalizeMe (github.com)

Das Projekt auf Github besteht aus 2 Projketen.
1) „TypeSafeLocalization“ -> Hier wird Lokalisierung wie code geschrieben & nach dem Ausführen dieses Projekts wird eine Klassenbibliothek erstellt, welche dann in
2) „TestOfCompiledProject“ verwendet werden kann, wo gezeigt wird, wie man die Klassenbibliothek nutzen kann.

Das erzeugte Projekt beinhaltet auch ein Interface, um es mit DI Container nutzen zu können.
Es ist möglich, Strings auch mit Platzhaltern zu versehen, diese werden dann als Methode im Code generiert, mit entsprechenden Parametern
Im Testprojekt wird auch gezeigt, wie man Enumerationen übersetzten kann.
Es ist möglich, verschieden viele Namespaces zu erzeugen.
Was eine Unterscheidung z.B. in Views / Errors / Inputs usw. einfach ermöglicht.
Eine Übersetzung ist dann auch pro Namespace möglich, oder automatisiert über alle Namespaces
Das ist insofern ein Vorteil, da man z.B. interne Fehler, die an das Entwicklungsteam gehen immer in einer speziellen Sprache absenden kann, die sich von der angezeigten Sprache unterscheidet.

Im Hintergrund wird KEINE Veränderung der Culture Information vorgenommen, so wie es bei den eingebauten Lokalisierungen von Microsoft erforderlich ist.
Vorteil davon ist, dass ich ohne Aufwand die lokalen Formatierungen behalte und z.B. trotzdem eine alternative Sprache anbieten kann.

Nach der Konvertierung stehen im Code für jede Eigenschaft / Methode ein paar extra Erweiterungen bereit, die vorab mit übergeben werden können.
Diese sind:
• Ein Tag
• Ein Kommentar (z.B. für Tool Tips)
• Ist Rechts / Links (Diese Eigenschaft kann händisch gesetzt werden, oder wird voll automatisch beim Erstellen der Klassenbibliothek entsprechend der gewählten Sprache gesetzt)
• Und die CultureInfo der geraden gewählten Sprache

Enumerationen können durch eine Extension übersetzt werden.

Erstellt werden kann eine Klassenbibliothek für
• .Net 2.0
• .Net 2.1
• .Net 5.0
• .Net 6.0 (Ist also auch für MAUI nutzbar)
Attachments
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16.030

beantworten | zitieren | melden

Hi,
Zitat von IntelliSoft
Im Hintergrund wird KEINE Veränderung der Culture Information vorgenommen, so wie es bei den eingebauten Lokalisierungen von Microsoft erforderlich ist.
Vorteil davon ist, dass ich ohne Aufwand die lokalen Formatierungen behalte und z.B. trotzdem eine alternative Sprache anbieten kann.
Davon abgesehen, dass das nicht zwangsweise erforderlich ist, sehe ich den Vorteil nicht :-)

Der Sinn der CultureInfo bzw. RegionInfo ist ja, dass ich nicht überall manuell etwas setzen muss, alles live sein kann und sicher verwendbar ist.
Darüber hinaus steht die Infos auf verschiedenen ebenen (UI, Thread..) zur Verfügung, sodass ich mit verschiedenen Cultures arbeiten kann.
Und wenn man doch eine manuelle Culture braucht (Sprache und Regionsinformationen unterschiedlich), dann kann ich das allen .NET Formattern manuell übergeben.
In .NET FX gabs dazu dann den CultureAndRegionBuilder, damit konnte man eigene Kombinationen umsetzen.
Was Du beschreibst ist also alles schon vorhanden - nur eine Frage der Nutzung :-)

Bei Deiner Lib sehe ich das Problem, das man vor ~18 Jahren in .NET hatte, als CultureInfo noch nicht verbreitet war: überall manuelle Formatierung.
.NET hat eine sehr mächtige Localization Engine: Localization in .NET
private Nachricht | Beiträge des Benutzers
IntelliSoft
myCSharp.de - Member



Dabei seit:
Beiträge: 13

Themenstarter:

beantworten | zitieren | melden

Hallo

Schade, dass Du das so siehst.
Ich habe geschrieben, dass mein Tool keine Veränderung des Threads vornimmt.
Man kann das ja immer noch nutzen und entsprechend dann reagieren.
Was Du mit meinem Tool sehr einfach machen kannst, dass Du z.B. die Sprache der GUI in Deutsch hast, aber die Fehlerbeschreibungen in Englisch (ohne Eingriff auf CultureInfo/RegionInfo).

Wenn Du Dir das Projekt angeschaut hättest, hättest Du gesehen, dass die Culture Info zurück gegeben wird (auf Wunsch)

& was definitiv am Wichtigsten dabei ist, ist die Typsicherheit.
Wenn Du Dich noch nie verschrieben hast, oder Du noch nie nach dem Eintrag einer Ressource gesucht hast, weil Du dir nicht sicher warst, wie sie heißt, dann hast Du noch nie mit Lokalisierung gearbeitet
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 2.033
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

So ganz klar sind mir die Vorteile leider auch nicht.
Nach dem Überblicken des Projekts scheinen die Übersetzungen bei dir halt auch wieder fix in den Code gepackt zu werden.
Oder gibt es in deiner Lib auch die Möglichkeit, die Übersetzungen aus den bestehenden resx Dateien zu nehmen?
Falls nicht, wäre es wieder ein Schritt zurück da man Übersetzungen nicht direkt in den Code packen will und vorhandene Übersetzungen auch weiterverwenden will.
Gerade dies wäre ein wichtiger Punkt mit dem man sich befassen müsste.

Für Projekte, die den .NET Weg bereits nutzen, sehe ich auch keinen Vorteil.
Die Typsicherheit spielt dabei auch nur eine Untergeordnete Rolle.
Diese kann man auch durch Kapselung der .NET Methoden z.B. durch Extention Methods erreichen.
Dafür brauche ich dann keine Lib.

Mir fehlen halt auch gute Beispiele wo ich nun Vorteile bei der Nutzung deiner Lib gegen den .NET Weg habe.
Vielleicht solltest du hier dein Beispielprojekt erweitern um dies etwas klarer hervorzustechen.

T-Virus
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
IntelliSoft
myCSharp.de - Member



Dabei seit:
Beiträge: 13

Themenstarter:

beantworten | zitieren | melden

Man kann sich einen kleines Tool selber schreiben, um RESX Files einzulesen.
Das sollte kein großer Aufwand sein. - Könnte natürlich für ein nächstes Update nicht uninteressant sein

Mein Tool erstellt eine komplette DLL, die alle relevanten Daten enthält.
"Füttern" muss ich die Information natürlich mal - Egal ob ich eine RESX Datei habe, oder die Daten irgendwo her bringe.

Man könnte über mein Tool sogar eine GUI legen & dass dann dort über eine Datenbank speichern & an eine Übersetzungs-KI senden und sich alles automatisch übersetzen lassen...
Wäre alles möglich.

Zitat
Vielleicht solltest du hier dein Beispielprojekt erweitern um dies etwas klarer hervorzustechen.

Ja, das kann man immer machen.
private Nachricht | Beiträge des Benutzers
pinki
myCSharp.de - Member

Avatar #avatar-4072.jpg


Dabei seit:
Beiträge: 708
Herkunft: OWL

beantworten | zitieren | melden

Mich verwirrt, dass das Enum-Beispiel keine Enums verwendet.
private Nachricht | Beiträge des Benutzers
IntelliSoft
myCSharp.de - Member



Dabei seit:
Beiträge: 13

Themenstarter:

beantworten | zitieren | melden

Wo genau?

Bei den Enums verhält es sich so:
Du erstellst zuerst die lokalisierte Ressource (wie im PDF, das angehängt ist, im ersten Posting) beschrieben:


new LocalizeMeShared.Data.ResourceData()
 {
 Name = "RedColor",
 Comment = "Red Color",
 CultureCodeName = LocalizeMeShared.Enums.TypesOfCulture.de_AT,
 IsInvariant = true,
 Value = "Rot"
 });

Nach dem nun die Assembly erstellt wurde, benötigst Du in deiner Anwendung, in der die Lokalisierung funktionieren soll


namespace dotnetProTest
{
 internal enum Colors
 {
 RedColor
 }
}
Wichtig, daß der Lokalisierungs Name Genau den selben Namen hat, wie die Enum selbst.
& dann kannst Du per Extension auf die lokalisierte Enum zugreifen:


using Extensions;
var locLocalizedProjekt = new LocalizedProjekt.LocalizeMe();

dotnetProTest.Colors.RedColor.GetLocalizedText(locLocalizedProjekt.GetLocalizedEnumerations.GetActualLocalization))
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von IntelliSoft am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16.030

beantworten | zitieren | melden

Also auch mit Deinen Erklärungen, werde ich nicht schlauer; ich verstehe nicht, welches "Problem" diese Lib löst - ich seh nur, ohne das ich das alles schlecht reden will, sondern rein auf Fakten basiert, dass sie welche schafft.
Zitat von IntelliSoft
Ich habe geschrieben, dass mein Tool keine Veränderung des Threads vornimmt.
Jo, und das ist ein Problem. Das heisst: alles, was existiert, kann mit Deiner Lokalisierung nicht verwendet werden.
Du baust etwas vollständig anderes, als in .NET Lokalisierung designed wurde - über 20 Jahre - und verwendet wird (ähnlich wie auch bei dem Logging-Thema in Dependency Injection, wo schreibe ich allgemein gültigen Code).
Das ist inkompatibel zu allem, was existiert. Das weicht komplett vom impliziten Verhalten auf ein explizites, manuelles Verhalten aus.

Eigentlich das, was man eben genau nicht will.
Keine Frage, das .NET Lokalisierungsframework ist auch nicht perfekt - aber schon nah dran.

Aber gut, vielleicht verstehe ich einfach nicht, welches Problem gelöst werden soll....?
Zitat von IntelliSoft
Man kann das ja immer noch nutzen und entsprechend dann reagieren.
Ja ne, ich wills ja eben nicht doppelt.
Genau deswegen nutze ich ja ein Lokalisierungsframework - dass ich mich nicht drum kümmern muss.
Der Entwickler hat also mehr Arbeit und Verantwortung statt weniger.

Das Ziel ist aber doch genau umgekehrt: der Entwickler soll sich darum nicht kümmern (müssen).
Zitat von IntelliSoft
Was Du mit meinem Tool sehr einfach machen kannst, dass Du z.B. die Sprache der GUI in Deutsch hast, aber die Fehlerbeschreibungen in Englisch (ohne Eingriff auf CultureInfo/RegionInfo).
Das hört sich danach an, dass Du Exception-Messages (ich vermute, dass Du das mit Fehlerbeschreibungen meinst) an den Benutzer ausgibst - genau das, was man nicht tun soll.
Basics: https://docs.microsoft.com/en-us/dotnet/standard/exceptions/
Das sind Entwickler-Messages, keine UI-Messages.
Zitat von IntelliSoft
& was definitiv am Wichtigsten dabei ist, ist die Typsicherheit.
Das habe ich doch mit dem eingebauten Mechanismus schon seit 15 Jahren..? Wo ist der denn anders?
Kann doch einfach den ResourceManager nehmen, und über Resources vollständig typisiert arbeiten - und der unterstützt sogar Multi Culture Management, der ebenfalls von der UI getrennt ist.
Hier, hab Dir nen Beispiel rausgesucht, wie das verwendet wird, falls Du das nicht kennst: https://www.jetbrains.com/dotnet/guide/tutorials/localization/basics/ (etwa im unteren Drittel das "Resources.Program.HelloWorld" Beispiel).

Aber viele wollen diese Typsicherheit gar nicht, weswegen der IStringLocalizer (Api-Docs) entstanden ist - weil die .NET Community das so wollte und brauchte.

Zitat von IntelliSoft
...
Wenn Du Dir das Projekt angeschaut hättest, hättest Du gesehen, dass die Culture Info zurück gegeben wird (auf Wunsch)
...
wie sie heißt, dann hast Du noch nie mit Lokalisierung gearbeitet
Nur weil ich eine andere Sichtweise und evtl. Erfahrung habe, musst nicht pampig werden. Es ist reines, sachliches Feedback, das Du annehmen kannst - oder eben nicht.
Der Forenbereich ist auch eben genau für dieses Feedback gedacht; willst das nicht, dann poste es halt nicht..?
Aber so machst Dir keine Freunde.
private Nachricht | Beiträge des Benutzers
pinki
myCSharp.de - Member

Avatar #avatar-4072.jpg


Dabei seit:
Beiträge: 708
Herkunft: OWL

beantworten | zitieren | melden

Ach so.
Ich hatte hier den Enum vermisst, weil das Teil LocalizedEnum heißt.
private Nachricht | Beiträge des Benutzers
IntelliSoft
myCSharp.de - Member



Dabei seit:
Beiträge: 13

Themenstarter:

beantworten | zitieren | melden

Also, ich entschuldige mich gerne, wenn Du glaubst, dass ich pampig reagiert habe, was so nicht gemeint war (deshalb auch der Zwinker Smiley am Ende...)

Sorry, dass wir unterschiedlicher Meinung sind, beim Thema Thread Wechsel.
Zitat
Genau deswegen nutze ich ja ein Lokalisierungsframework - dass ich mich nicht drum kümmern muss.

Okay, dann nutze diese doch - Ich möchte keinen zwingen, mein Tool zu nutzen.
Ich nutze es in meiner Software & ich habe keine Probleme.
Zitat
Das hört sich danach an, dass Du Exception-Messages (ich vermute, dass Du das mit Fehlerbeschreibungen meinst) an den Benutzer ausgibst - genau das, was man nicht tun soll.

Nein, ich meinte damit, dass Du Deine Log (Fehler) in einer anderen Sprache nutzen möchtest.
Bsp.: Die GUI ist französisch & Du hast ein support Team in Italien, dann kannst Du die Log Datei in italienisch erstellen, oder eben in französisch, oder....

Was auch noch sehr einfach möglich ist, Mehrsprachigkeit innerhalb einer Ansicht zu erstellen. (Z.B. den selben Text in 2 Sprachen auf einer Seite)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16.030

beantworten | zitieren | melden

Ok, das hab ich gesehen, dass das möglich wäre.

Die Aussage, dass das bisher aber nicht gehen würde bzw. ein "Vorteil" gegenüber den existierenden Lokalisierungsmöglichkeiten wäre, ist halt so nicht ganz korrekt: das kann man auch mit .NET Bordmitteln machen. Ich seh jetzt nicht unbedingt ein "exklusives" Feature in der Lib, daher sehe ich auch nicht, welches Problem das löst.

Magst einfach mal ein wirkliches Use Case Beispiel machen, welches reale Problem aktuell existiert, und wie man das mit Deiner Lib löst?
Das ist ja meist das Interessante.
private Nachricht | Beiträge des Benutzers
IntelliSoft
myCSharp.de - Member



Dabei seit:
Beiträge: 13

Themenstarter:

beantworten | zitieren | melden

Mach ich gerne - dauert ein paar Tage
private Nachricht | Beiträge des Benutzers
Papst
myCSharp.de - Experte



Dabei seit:
Beiträge: 424
Herkunft: Kassel

beantworten | zitieren | melden

Ich hab mir das Projekt nicht angeschaut, bin aber über das hier im Thread gestolpert:
Zitat von IntelliSoft


namespace dotnetProTest
{
 internal enum Colors
 {
 RedColor
 }
}
Wichtig, daß der Lokalisierungs Name Genau den selben Namen hat, wie die Enum selbst.

Wenn hier wieder Namen übereinstimmen müssen - wo ist dann die Typsicherheit?
Da müsste dann eher ein Quellcode Generator dazwischen, damit das wieder typsicher ist, sonst könnte mir passieren, dass ich den Enum Eintrag RedColour nenne und nichts geht mehr?
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.818
Herkunft: Düsseldorf

beantworten | zitieren | melden

Ich schließe mich dem Feedback dazu an: Wo ist der Sinn?

Ich will die .NET-Lokalisierung nicht aufs Blut verteidigen, aber das Konzept hinter den RESX-Dateien, wie die Sprachen gesucht werden und die Tools dazu (RESX-Manager) sind schon sehr gut und ich wüsste nicht, was man da noch besser machen kann. Gerade der RESX-Manager macht das erst richtig wertvoll, da ich mit wenigen Klicks einfach die gesamte Lokalisierung als XLSX exportieren, zum Kunden/Übersetzer schicken und danach wieder importieren kann - quasi keine zusätzliche Arbeit für mich.

Also wenn Du etwas in die Richtung entwickeln möchtest und auch möchtest, dass andere davon profitieren (können), dann sollte ein wichtiges Ziel sein, genau diese bestehenden Tools möglichst gut zu unterstützen. Oder Du baust direkt darauf auf, z.B. indem Du einen eigenen Code-Generator schreibst, der das Problem, um das es dir hier geht, auf Basis der RESX-Dateien lösen kann.

Ich sehe hier also nur eines:
Ein Konzept, das extrem vom aktuellen bewähren Konzept abweicht und eigentlich nur genutzt wird, um eine klapprige Brücke zum bestehenden Konzept zu bauen.
Also auch, wenn deine Library ein reales Problem löst (ich sehe es auch noch nicht wirklich), dann hast Du immer noch das Problem, dass Du eine von Anfang an erzwungene Basis mit schleppst, die eigentlich niemand will.

Sorry, aber wenn ich ein konkretes Problem damit habe, dann baue ich die Lösung lieber direkt auf der erprobten Basis auf
private Nachricht | Beiträge des Benutzers
IntelliSoft
myCSharp.de - Member



Dabei seit:
Beiträge: 13

Themenstarter:

beantworten | zitieren | melden

Gut, ich habe es verstanden.
Da ich das Projekt aber noch fertig gemacht habe, stelle ich es trotzdem hier rein, um zu zeigen, dass es funktioniert...

Was ich nicht konnte, obwohl es lt. allen hier leicht funktionieren sollte, war es mehrere unabhängige Sprachen/Formatierungen in einer Ansicht zu haben.
Vl. hat ja jemand die Geduld, mir zu zeigen, wie mein kleines Programm mit den Board mitteln, leicht zu lösen geht.

Ich hänge 2 Zip Dateien an.
1) LocalizationPreparings. -> Das ist das Projekt, dass meine Übersetzung erstellt
2) UILocalization -> Die Verwendung in einem konkretem Beispiel (Als WinForms -> würde aber überall anders auch funktionieren)

Dazu gleich vorab: Es folgt keinem Design Schema - sondern soll "nur" darstellen was es kann.
Auf der linken Seite sind 3 Labels und 3 Textboxen
Die Labels können per Listbox links übersetzt werden
Mittig sind nochmals 3 Labels, die übersetzt werden & erklären worum es bei den linken Inputs geht.
+ die Formatierung des Preises in der 3. Textbox ändert sich, auf Grund der gewählten Sprache.

Ich danke euch für eure Geduld & inputs.
PS - Ich möchte bitte keine Anfrage, ob das Szenario Sinnhaft ist. - Ja es kann Sinnhaft sein, ja ich brauche eine Lösung für so eine Situation.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von IntelliSoft am .
Attachments
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.818
Herkunft: Düsseldorf

beantworten | zitieren | melden

Zitat von IntelliSoft
Was ich nicht konnte, obwohl es lt. allen hier leicht funktionieren sollte, war es mehrere unabhängige Sprachen/Formatierungen in einer Ansicht zu haben.
Vl. hat ja jemand die Geduld, mir zu zeigen, wie mein kleines Programm mit den Board mitteln, leicht zu lösen geht.
Du meinst, Du suchst eine Übersicht aller Texte für alle Sprachen?

Das habe ich schon genannt: RESX-Manager
ResXManager - Visual Studio Marketplace
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 2.033
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

Dein Problem sollte sich doch direkt über den ResourceManager lösen lassen.
Dort kannst du doch einfach bei GetString die CultureInfo für die Sprache mitgeben.
Dann hast du die richtige Übersetzung für die ausgewählte Sprache.
Du benötigst dann nur in deiner UI einfach die resx Datei für die Form mit der jeweiligen Sprache.
Zusätzlich sollte man auch eine neutrale Sprache als Default mitbringen als Fallback falls Übersetzungen fehlen.

Die Formatierung für die Textbox kannst du dann auch über die ausgewählte Sprache formatieren, was du selbst ja schon machst wenn auch über Umwege mit deiner Lib.
Damit kannst du ohne Probleme mehrere Sprachen anzeigen.
Passend dazu schau dir den Jetbrains Link von Abts zweiten Beitrag und die Doku zum ResourceManager an.
Dann solltest du es hinbekommen ohne deine Lib oder eine extra kompilierte DLL einbinden zu müssen.
Die Resourcen werden dann direkt in die Form DLL einkompiliert.

T-Virus
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
IntelliSoft
myCSharp.de - Member



Dabei seit:
Beiträge: 13

Themenstarter:

beantworten | zitieren | melden

Danke, ich werde mir das noch mal alles anschauen
private Nachricht | Beiträge des Benutzers