Danke, ich werde mir das noch mal alles anschauen

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.

Mach ich gerne - dauert ein paar Tage

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.

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.

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)

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))

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.

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

Ja, das kann man immer machen.

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 😉

Hallo

SetLoggingLevel kann nur vor dem ersten Log Event einmalig gesetzt werden, da sonst eine entsprechende Exception geworfen wird.
Ist absichtlich so gemacht, damit ich aus der Config auslesen kann, welches Level gerade gesetzt wurde & eben dadurch das Logging sehr fein einstellen kann 😉

Aber danke für den Gedanken

Danke für Deinen Input!
Interessant & sehr hilfreich!

Hallo

Da hast Du wahrscheinlich recht.
Ich habe es soeben getestet & scheint korrekt zu funktionieren.

DANKE für die Hilfe!

Danke fürs Willkommen heißen!

Genau das, was Du geschrieben hast, versuche ich ja zu vermeiden.
Wenn ich DI nutze, dann möchte ich ja keine (oder so gut wie keine) Abhängigkeit zu einem anderen Projekt haben.
Sondern nur auf das Interface.

Um Deine Frage zu beantworten - Das Projekt SharedDI ist das einzige Projekt, dass alle anderen Projekte referenziert.
Die anderen Projekte referenzieren dann "nur" mehr das Projekt, dass das Interface bereitstellt "*.Contracts"

DANKE

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)

Hallo

Ich beginne ein neues Projekt, unter Verwendung von DI (Habe mich für AutoFac entschieden)
Meine Projekt Struktur ist wie folgt aufgeteilt.
Ich habe ein Projekt "Database" und ein Project "Database.Contracts"
Ein Projekt "Logging" und ein Projekt "Logging.Contracts"
Ein Projekt "SharedDI"
Im SharedDI sind alle anderen Projekte verknüpft. Wobei in den Projekten "Database" und "Logging" nur die entsprechenden "Contracts" verbunden sind.
Soweit, so gut.
In meinem Logging Contract Projekt habe ich ein Interface deklariert, dass unter anderem die Methoden "EnterMethod" und "LeaveMethod" beinhalten.
Damit möchte ich eine schöne Struktur in die Log-File bekommen. Dazu habe ich nun eine Klasse geschrieben, die ich instanziere (dabei EnterMethod ausführe) & dann bei Dispose die "LeaveMethod". Damit ist es einfach, das Logging durchzuführen. Der Code dazu sieht so aus:

using System;

public sealed class LoggingService : IDisposable
{
    IntelliSoft.Logging.Contracts.ILogger myLogger;
    string myMethodName = String.Empty;
    string mySourceFilePath = String.Empty;

    public LoggingService(
        IntelliSoft.Logging.Contracts.ILogger logger,
        IntelliSoft.Logging.Contracts.Enums.TypeOfLoggingLevel? level = null,
        [System.Runtime.CompilerServices.CallerMemberName] string methodName = "",
        [System.Runtime.CompilerServices.CallerFilePath] string sourceFilePath = "")
    {
        myLogger = logger;
        if(level != null)
            myLogger.SetLoggingLevel = level.Value;

        myMethodName = methodName;
        mySourceFilePath = sourceFilePath;
        myLogger.EnterMethod(myMethodName, mySourceFilePath);
    }

    public IntelliSoft.Logging.Contracts.ILogger Logger => myLogger;

    public void Dispose() { myLogger.LeaveMethod(myMethodName, mySourceFilePath); }
}

Das Problem, dass ich hier habe ist, dass ich diesen Code aber in allen Projekten "kopieren" müsste, damit er funktioniert (oder per File-Link) Das scheint mir aber keine saubere Lösung zu sein!? Kann mir bitte jemand sagen, wie ich das richtig mache, dass dieser Code überall Gültigkeit hat und die Regeln der DI nicht verletzt.

DANKE im Voraus