Hallo, ich habe folgendes Problemchen. Mein Programm wurde in Visual C++ 5.0 entwickelt (deutsch). Nun soll es aber auch in mehrere Sprachen übersetzt werden; ist auch noch kein wirkliches Problem ;-) Alle Texte, z.B. in AfxMessageBoxen, können ja einfach übersetzt werden. Menueeinträge der Fenster sind ja in der Ressourcendatei abgelegt. Diese müßte dann "per Hand" übersetzt werden, um dann das ganze Projekt wieder neu durchzukompilieren. Für jede Sprache wäre eine eigene Datei erforderlich. Was aber wenn das Programm neue Funktionen, Fenster oder Dialoge bekommt...Alle Resourcendateien müßten dann wieder übersetzt werden, da sie während der Programmentwicklung durch Visual Studio verändert werden. Alles Murks :-( Wer kennt Entwicklungstools mit C++ als Sprache unter Windows, mit denen es möglich ist, eigene Entwicklungen komfortabel in andere Sprachen zu überführen. Ich denke da z.B. auch an Spanisch, Italienisch, usw. Grüße Oliver
Wenn Du Dir den (VC++) Resourceneditor mal genauer ansiehst, wirst Du
feststellen, daß als Eigenschaft einer Resource eine Sprache
eingestellt werden kann.
Damit kann eine Resource mit der gleichen Resource-ID mehrfach
vorkommen.
Im Resourceneditor steht die gewählte Sprache hinter der zugehörigen
Resource-ID; sie wird nur bei der Standardsprache des
Entwicklungssystems weggelassen.
Somit erhältst Du beispielsweise sowas:
MyApp resources
-- DIALOG
IDD_ABOUTBOX
IDD_ABOUTBOX [Hungarian]
etc.
(Ausschnitt des Workspace-Fensters bei Ansicht der Resourcen)
(die erste ist implizit Deutsch, da Du höchstwahrscheinlich ein
deutschsprachiges Windows verwendest)
Mit einem Rechtsklick auf die jeweilige Resource und Wahl des
Kontextmenüpunktes "Copy" kann direkt eine Kopie einer Resource mit
gleichzeitiger Auswahl der Sprache der Resource angelegt werden.
Texte, die per MessageBox oder ähnlichem ausgegeben werden sollen, sind
nicht als Stringkonstanten im Programm, sondern als Strings in einer
Stringtabelle in den Resourcen zu definieren. Da diese, wie jede andere
Resource auch, mehrsprachig sein können, ist das dann auch kein Problem
mehr.
Im Detail mag es da noch Unterschiede zwischen VC++ 5 und 6 (das ist
die von mir verwendete Version) geben, das Konzept aber ist deutlich
älter.
Etwaige Fragen diesbezüglich hier posten.
Habe gerade einmal damit rumgespielt... ja, auch in VC++ 5 kann eine Ressource in einer anderen Sprache kopiert werden. Fragen: 1. Wenn ich z.B. 5 Sprachen habe, dann müßte ich doch auch JEDE Ressource 5 mal kopieren. Ist aber eine ganze schöne Menge. Ich habe überschlagsmäßig 20 Ressourcen (Dialoge, Menues, etc). Dann wären das ja schon 100! Da steigt doch keiner mehr durch. 2. Wenn ich in der Originalressource etwas hinzufüge, z.B. neue Buttons, Listenelement etc, dann sind die kopierten Ressourcen davon unbetroffen. So scheint es mir jedenfalls nach den ersten Versuchen.
1. Ja, genau so ist das.
Ob "da keiner mehr durchsteigt"? Da die Resourcen ja alle die gleiche
Resourcen-ID haben, sollte das kein so arges Problem sein.
2. Das ist in der Tat ein Problem. Die "Internationalisierung" ist
dann wohl etwas, was zu allerletzt geschehen sollte.
Alternative: In Dialogresourcen stehen keine festen Strings, sondern
nur Platzhalter, die aus Stringresourcen mit Inhalt gefüllt werden.
Statt die Texte aus Stringresourcen zu holen, könnten diese auch aus
einer externen Datei geladen werden.
Die Verwendung von Stringresourcen ist aber wg. FormatMessage() gar
nicht schlecht, da hier auch die Verwendung von Platzhaltern möglich
ist, deren Reihenfolge sprachabhängig definiert werden kann
("this operation will delete %1 files in %2 directories", "In %2
Verzeichnissen werden %1 Dateien gelöscht")
All dies erfordert zwar eine gewisse Disziplin beim Programmieren,
müsste aber noch handhabbar sein.
Ganz andere Alternative wäre die Verwendung einer anderen
Klassenbibliothek als der MFC; wxWidgets bietet, wenn ich mich jetzt
nicht völlig vertue, andere Ansätze zur Internationalisierung. Das
bringt natürlich nichts, wenn man ein bereits exisitierendes Projekt
internationalisieren möchte.
Ganz am Rande: Was für ein wichtiges Produkt bearbeitest Du da, daß Du
meinst, daß fünf verschiedene Sprachfassungen erforderlich sind?
Ich danke Dir für Deine Hilfe. Leider ist diese Lösung für mich ein weiterer Problembringer. Mein Kunde ist sehr groß und leider auch sehr anspruchsvoll :-( Dem fällt ständig etwas neues tolles ein, was ich in mein Programm reinmatschen soll. Wiederum hat mein Kunde auch Kunden. Denen fällt auch immer etwas tolles ein, was doch so schööön wäre. Natürlich zukünftig in allen erdenklich Sprachen. 5 war nur so dahergesagt. Es ist schon ein Wunder, daß die von mir noch keine runden Fenster haben wollten ;-) Ich werde wohl meine erste Idee aufgreifen müssen: Es gibt ein Mutterprogramm (z.B. deutsch). Alle Strings werden separat in Dateien (einer Datei) verwaltet und können durch #def für eine Sprache aktiviert werden. Die Ressourcendatei ist ja eigentlich auch nur eine Textdatei. Ich werde ein Übersetzungsprogramm schreiben, welches mir die Datei am Ende in jede beliebige Sprache übersetzt. Das Programm sucht also nach den Begriffen "Datei", "Speichern unter..." usw. Was alles eben in den Menüs, Dialogen, auf den Buttons und Beschreibungstexten auftaucht. Das alles steht in der Ressourcendatei. Nach dem Übersetzen der Datei wird das ganze Projekt neu durchkompiliert. Der Vorteil ist ein Mutterprogramm. Eine Änderung muß nicht in allen Sprachversionen nachgezogen werden.
"Alle Strings werden separat in Dateien (einer Datei) verwaltet und können durch #def für eine Sprache aktiviert werden." Gut möglich, daß ich das jetzt falsch verstanden habe. Aber durch ein #define wird keine Sprache aktiviert. Du verpackst Deine Ressourcen in Dlls (Resource-Only-Dlls). Je nach gewünschter Sprache lädst Du zu Programmstart die passende (oder wenn nichts passendes dabei ist, die Default-) Dll nach. Selbst bei kleinen Projekten, wo sich das nicht lohnt und alles in der Exe vorhanden ist, machst Du das nicht per #define. Hier verwendest Du die API-Funktion SetThreadLocale. Im Folgenden werden die richtigen Ressourcen automatisch verwendet. Den bereits erwähnten Ansatz mit FormatMessage finde ich übrigens auch ganz nett. Deswegen möchte ich noch kurz auf den Message-Compiler hinweisen (mc.exe, Bestandteil des PSDK). Siehe: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/tools/message_compiler.asp?frame=true
Danke für die Hinweise. Ich stehe auch kurz vor einem Upgrade meines 5.0 Studios. Gerade unter Windows 2000 treten vermehrt mysteriöse Effekte in meinem Programm auf. Auf Win95, Wind98 etc. läuft es, und bei win2000 nicht!!!! Beispiel: Die CDC-Funktion TabbedTextOut() gibt einen durch Tabulatoren formatierten Text aus(MFC,CView). Unter Win2000 gibt sie gar nichts aus. Nichts, nada. Bildschirm ist leer. Jetzt gibt es noch das Visual-Studio 6.0 und das neue xy.NET Hat jemand Erfahrungen im letztgenannten? Oder sollte ich auf das 6.0 umsteigen? Meinungen dazu? Grüße Oliver
"Beispiel: Die CDC-Funktion TabbedTextOut() gibt einen durch Tabulatoren formatierten Text aus(MFC,CView). Unter Win2000 gibt sie gar nichts aus." Da muß ich doch mal ganz vorsichtig fragen, ob das nicht auch an Dir liegen kann. CDC::TabbedTextOut ist nichts weiter als eine Inline-Funktion, die die Arbeit lediglich an die API-Funktion gleichen Namens delegiert. Ich kann mir deswegen nur schwer vorstellen, daß Dir die Umgebung da Schwierigkeiten macht. Im Falle eines Fehlschlags sollten cx und cy der zurückgegebenen Size genullt sein. Unter Windows 2000 kannst Du dann mit ::GetLastError nähere Informationen über den Fehler erhalten. Ich muß aber noch sagen, daß ich den VC5 nicht wirklich kenne. Etwas aktuelleres kann aber natürlich trotzdem nicht schaden. :) "Oder sollte ich auf das 6.0 umsteigen?" Das Ding ist von 1998, warum solltest Du auf sowas altes umsteigen sollen? Ich würde das jedenfalls nicht machen. Der aktuelle Compiler - ist Standard-Konformer - schmeisst noch mehr Warnungen (bessere Prüfung zur Compile-Zeit) - fügt, wenn gewünscht, noch mehr Laufzeit-Prüfcode ein - erzeugt schlankeren Code Auch der Debugger hat sich sehr zu seinem Vorteil verändert, ist umgänglicher geworden. Allerdings ist die IDE sehr gewöhnungsbedürftig, aber naja.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.