Erst mal wo von ich rede. Man kann String Konstanten einmal so deklarieren:

markieren

Delphi-Quellcode:

const
  Test = 'Test';

Oder so:

markieren

Delphi-Quellcode:

resourcestring
  Test = 'Test';

Letzteres bewirkt, dass der String als ResourceString in einem Stringtable in die Ressource der Exe einkompiliert wird.

So, in dem Buch "Delphi in a nutshell" schreibt der Autor dazu:

Zitat:

You should expect your components to be used in an application that requires localization, and plan ahead.

Daraus schließe ich, dass es mit Ressourcestrings einfachher ist, Code an andere Landessprachen anzupassen. Und das ist der Punkt, den ich nicht verstehe. Die Strings stehen dann zwar in der Ressource der Exe, aber was hilft mir das, wenn ich die Anwendung übersetzen will? Da ich sowieso wieder kompilieren muss, kann ich auch die normalen Stringkonstanten im Quelltext übersetzten.

Oder kann mir jemand die Begründung des Autors erklären?

Zitat von Luckie:

Da ich sowieso wieder kompilieren muss,

Wieso das? Strings in einer Stringtable lassen sich direkt in der EXE-Datei verändern - normale Stringkonstanten nicht.

Bei der Initialisierung der RTL Deines Programms wird nach einer DLL gesucht, welche die Daten in der anderen Sprache enthält.
Falls eine passende gefunden wird, werden die Ressourcen aus der DLL anstatt der einkompilierten verwendet.

Bei Foo.exe wird im gleichen Verzeichnis nach Foo.deu (dreistellige Sprachkennung (Deutsch (Deutschland)) des Benutzers) und Foo.de (zweistellige Sprachkennung (Deutsch) des Benutzers) gesucht. Wobei das pro Benutzer/Programm unter HKEY_CURRENT_USER\Software\Borland\Locales überschrieben werden kann.


ps: Das bezieht sich nicht nur auf Strings, sondern auch auf Forms und andere Ressourcen. Zur einfacheren Verwaltung/Erstellung von Spach-DLLs gibt es in den teureren Delphi-Versionen einen Ressource-DLL Wizard und Language-Tools.

Aha. Ich brauche also nur eine Sprach DLL beilegen und wenn die Sprache des Stringtables in der Ressource nicht mit der Sprache des Systems übereinstimmt aber eine entsprechende Sprach DLL gefunden wird, dann wird diese genommen?

Die Sprache des Stringtables ist

Zitat:

STRINGTABLE
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL

Also Sprach neutral. Sollte das jetzt auf einem Englischen System laufen und wird eien Englische gefunden, dann wird diese genommen, ansonsten die aus der Exe?

Ich glaube, ich habe es verstanden.

Ach noch was, wie müsste so eine Sprach DLL aufgebaut sein?

Haben wir doch schon ausprobiert für den Movie Organizer.
Mit "wir" meine ich den (oft von mir) genervten Chakotay und mich.

Nummer 1: Du schaust nach dem Kompilieren nach, welche IDs die Strings bekommen haben. Leider vergibt Delphi IMHO die Nummern selbst, so dass man keinen Einfluss hat. Nehmen wir also an, der String hätte die ID 39678. Dann benutzt du die selbe ID für den lokalisierten String in deinem Ressourcenskript (Stringtable).

Nummer 2: Bei VCL-Programmen genügt es, die Texte in den DFMs zu übersetzen.

Die Ressource (*.res) mit den Strings und die übersetzten DFMs werden dann in eine leere DLL gespeichert, die die Endung erhält, die man wünscht
{$E deu} Kompilieren, und fertig. Wenn du die DLL dann in das Projektverzeichnis wirfst, in dem sich auch die originale EXE befindet, benutzt das Programm automatisch die Bibliothek, wenn auf dem Zielrechner Deutsch als Sprache eingestellt ist.

Du schaust dir als Beispiel entweder Nicos und CRAs DelphUBB an, oder du holst dir bei mir den D5-Quellcode des o.g. Programms.

Hallo,

ressourcestring haben außerdem den Vorteil, dass sie (im Gegensatz zu Konstanten) nur einmal in der exe gespeichert werden, auch wenn sie mehrmals verwendet werden. Allerdings dürfen sie maximal 1024 Zeichen lang sein (siehe LoadResString in System.pas) und man kann Resourcestrings nicht aus zuvor definierten Resourcestrings "zusammenbauen".

markieren

Delphi-Quellcode:

const
  cSelect = 'select * from TESTTABLE ';
  cWhere = 'where NR=:NR';
  cSQL = sSelect + sWhere; // das funktioniert

resourcestring
  rSelect = 'select * from TESTTABLE ';
  rWhere = 'where NR=:NR';
  rSQL = sSelect + sWhere; // das nicht

anbei mal ein Beipiel für 'ne Ressourcen-DLL. Vermutlich braucht man aber die Professional-Version von Delphi, um vernünftig damit arbeiten zu können.

Klappt noch nicht so ganz.
eng.rc:

markieren

Code:

STRINGTABLE
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
{
65520,    "File %s successfully splitted."
}

DLL:

markieren

Code:

library eng;

{$E en}

{$R eng.res}

begin
end.

Erzeugte Sprach DLL eng.en.

Den Wert in der Registry habe ich ergänzt:
D:\Programmierung\Delphi\Programme\NonVCL\in Bearbeitung\FileSplitter New\Source -> en

Beim Starten der Exe nimmt er aber nicht den String aus der Sprach DLL.

Was ist, wenn du der DLL mal die Endung ".deu" gibst? Geht es dann?

Wie dem auch sei, @Luckie. Aus dem Grund haben wir mit Chris den MO in Englisch gestaltet. Sollte sich das Programm wirklich mal richtig verbreiten (@Chris: ), dann haben die anderen wenigstens die englische Version und müssen sich nicht mit der deutschen Sprache rumschlagen. Und auf einem deutschen System wird dann eben die DEU-Ressource verwendet.

Aha. Exename.deu, dann geht es. Da stimmt was mit dem Registry Key nicht. Im Pfad sind nämlich Leerzeichen. Mal sehen.

[edit]
Auch wenn ich die Leerzeichen im Pfad entferne geht es nicht.

Hmpf.

Hm, ich bekomme das einfach nicht gebacken. Wenn ich der Sprach DLL die endung "deu2 oder "de2 gebe, dann nimmt er die. Aber erscheint die Registry Einstellungen zu ignorieren.