Danke für die Empfehlung
Darüber war ich hier im Forum tatsächlich auch schon gestolpert, und es sieht fraglos gut aus. In Details deutlich ordentlicher als meine eigene alte Lösung. Leider aber schien es zu meiner Problemstellung nicht zu passen. Unsere aktuelle Version (mit Delphi 2006 und noch AnsiStrings mit Charsets) gibt es in über 30 vollständigen Übersetzungen - sowas ist als Resource fest einkompiliert einfach nicht hinzubekommen - alle Übersetzer sind Freiwillige, deshalb natürlich nicht innerhalb kürzester Zeit vor einem Release verfügbar, und getrennte Versionen sind einfach unpraktisch, da würde die Build Chain ewig lang werden.
Wenn ich schon auf Resourcen setzen würde, dann der Flexibilität halber per MUI, die lassen sich beliebig jederzeit neue Übersetzungen ergänzen. Evtl. würde das in Lingus per zur Laufzeit nachgeladener .lpf funktionieren?
Das soll Lingus jetzt nicht schmälern, es sieht halt auf den ersten Blick nur nicht zu meinen Anforderungen passend aus.
Wie sieht es denn mit Lingus und der oben genannte Problematik aus (nur verwendete Units aus Pfaden wirklich in Übersetzungsdatei landen lassen)? In meinem eigenen Code hatte ich das so gelöst, dass die Basis-Sprachdatei zur Laufzeit generiert werden kann, mit dem Nachteil, dass alle Strings quasi im initialization stecken müssen, um da bekannt zu sein.
Vielleicht starte ich mal mit einer Meta-
Unit, die es mir ermöglicht, später einfach über eine Änderung der Meta-
Unit das System ändern zu können.
Eine kurze Idee in Sachen ursprünglicher Problematik: die verwendeten Units könnte ich doch aus der .map-Datei rausholen (für die habe ich schonmal einen Parser geschrieben), oder? Dann könnte ich es evtl. sogar in die Build Chain packen. Ein Funktionsaufruf in der initialization aller Units, die die Meta-
Unit verwenden, wäre auch möglich, aber entweder mit Konstante (unschön), oder bekomme ich den aktuellen
Unit-Namen per Code raus, ohne Debug-Infos?