Bisher habe ich Programme immer mit eigenem Code lokalisiert (enum auf Fenster, Controls, Liste mit anderen Meldungen, alles in einer .ini, so daß von Übersetzern einfach zu erledigen), das klappte recht gut.

Dieses System könnte ich nun auf Unicode umstellen (war bisher Delphi 2006 mit AnsiString und Codepages), aber irgendwo reizt es mich auch, "neue" und offiziellere Methoden anzuwenden. Als da wäre: MUI. Zur Abwärtskompatibilität die ältere Methode mit getrennten DLLs, da die Software nicht erst ab Vista laufen soll.

Eine DLL mit denselben Resourcen in mehreren Sprachen ist natürlich kein Problem, klappt wunderbar (Test mit LoadString). Aber doof, wenn's um's kleine und schnelle Aktualisieren einzelner Sprachen geht.

Der Pfad über muirct.exe scheint mir für kleine Projekte ohne externe Resourcen-DLL schwerfällig; dazu muss die Anwendung etwa alle Resourcen in einer Sprache haben. Das scheitert schon am Einsatz der JWA/JCL etwa, deren .res teilweise in französisch, teilweise anderen Sprachen vorkompiliert mit eingelinkt werden (habe ich dort bereits im Bugtracker unter der Nummer 5646 berichtet; genauso wie bei einigen anderen Komponenten).

Bas Beispiel hier scheint mir dennoch ein guter Ansatz zu sein. Leider habe ich auch danach keinen vollen Erfolg. Zwar habe ich passende MUI-Dateien, meine MyResources.dll enthält nur noch eine Section "MUI" (ist also korrekt LN), mein GetUserDefaultUILanguage ist $0409, trotzdem wird immer der Text aus der en-IE\MyResources.dll.mui, die überall als Fallback ($1809) spezifiziert ist, geladen. Auch wenn ich etwa SetProcessPreferredLanguages auf de-DE ($0407) setze, bekomme ich den Text aus der MUI-Datei für $1809, statt de-DE\MyResources.dll.mui.

Gibt's da Tipps, was ich falsch mache?

Nachtrag: die DLL musste doch eine reine Resource-DLL sein, damit das funktioniert (siehe auch http://www.delphipraxis.net/162609-w...erstellen.html).