Stringkonstanten als Resourcestring deklarieren

[Luckie]

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

Delphi-Quellcode:

const
  Test = 'Test';

Oder so:

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?

[Niko]

Zitat:

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.

[NicoDE]

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.

[Luckie]

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. :thumb:

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

[MathiasSimmack]

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

Delphi-Quellcode:

{$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.

[mr2]

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".

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.

[Luckie]

Klappt noch nicht so ganz.
eng.rc:

Code:

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

DLL:

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.

[MathiasSimmack]

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.

[Luckie]

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. :evil:

[Luckie]

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.

[MathiasSimmack]

Jetzt muss ich die alte Möhre selbst noch mal hervorholen. Also, ich habe ein paar Dialoge. Jeweils doppelt, einmal mit englischen Sprachangaben, einmal mit deutschen:

Code:

400 DIALOGEX DISCARDABLE  0, 0, 317, 163
STYLE WS_CHILD | WS_DISABLED | WS_CAPTION | DS_SHELLFONT
CAPTION "Konvertierung läuft"
FONT 8, "MS Shell Dlg"
LANGUAGE LANG_GERMAN, SUBLANG_NEUTRAL
// ...


400 DIALOGEX DISCARDABLE  0, 0, 317, 163
STYLE WS_CHILD | WS_DISABLED | WS_CAPTION | DS_SHELLFONT
CAPTION "Starting Task"
FONT 8, "MS Shell Dlg"
LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL
// ...

Wenn ich nach meiner eigenen Beschreibung die deutschen Ressourcen in eine separate DE-Bibliothek kompiliere, dann ignoriert Delphi diese und zeigt mir die englischen Dialoge an. Wenn ich die deutschen Ressourcen aber direkt mit ins Programm einbinde (ohne zusätzliche DE-Datei), dann zeigt mir das Programm die deutschen Dialoge an. Kann ich davon ausgehen, dass jemand mit einem englischen Windows stattdessen die englischen Dialoge sehen würde, oder ist das nur ein Zufall? :gruebel:


Edit: Okay, es scheint zu funktionieren. Gebe ich der englischen Ressource LANG_NEUTRAL, dann zeigt er mir die an. Das erklärt aber nicht, warum die separate DE-Datei nicht mehr funktioniert. :gruebel:

[himitsu]

wo ich das grad zufällig seh ... theoretisch kann man also über eine externe Sprach-DLL andere Sprachen unterstützen und Delphi dürfte diese auch automatisch laden, aber

die ID/Indizes der ResourceStrings in den Resourcen sind nicht fest und können sich bei jeder Kompilierung oder zumindestens kleineren Änderungen am Programm (Quelltext) ändern
und soweit ich weiß, machte Borland keine Angaben wie/wo sich diese Strings in den Resourcen befinden können.

im Prinzip müßte man also nach (je)dem Compilieren erst in der EXE nachschauen wie und wo die Strings nun liegen und die SprachDLL eventuell anpassen.

Genauso gut dürfte man auch gleich die anderen Sprachresourcen direkt in die EXE einbauen können.

[Bernhard Geyer]

Falls es nur um die unterstützung von mehrsprachigkeit in der App geht, so schau dir mal GNU Gettext for Delphi an.