Internationalisierung
-
Hi Leute,
wir würdet Ihr am besten vorgehen, wenn Ihr eine Software internationalisieren müsstet?
Mehrere DLL´s für jeweils verwendete Sprache, oder unterschiedliche Kompilate?Bin für jegliche Anregung offen... (außer Datenbank spezifische Lösungen)
-
Wenn´s mehrsprachig sein soll, würde ich die Texte aus einer Sprach.ini auslesen. Je nachdem, welcher Flag gesetzt wurde ist der Text dann Deutsch, Englisch, Französisch oder was weiss ich.
-
Ich erzeuge Dlls, die die lokalisierten Resourcen enthalten, lade sie zur Laufzeit mit LoadLibrary und schalte dann mit AfxSetResourceHandle um.
Es gibt Lokalisierungstools (z.B. Passolo), die dir eine DLL direkt aus der Exe Datei erzeugen.
Wichtig ist, dass geprüft wird, ob die Version der Dll mit der der Exe übereinstimmt, sonst könnten falsche Resourcen geladen werden.Nur bei kleinen Programmen schreibe ich die Übersetzungen zurück in die Exe. Damit ist das ganze etwas kompakter, hat aber den Nachteil, dass die Sprache vom Benutzer nicht beliebig gewählt werden kann. Wenn mehrere Sprachen in der Exe sind, wählt das System immer die zur Systemsprache passende.
Auf jeden Fall sollte die Übersetzung auf der Exe-Datei aufsetzen, nur wenn man kein Lokalisierungstool hat, kann man die .rc-Datei übersetzen oder die Dialog-Kopier-Funktion von VisualStudio benutzen. Beides führt aber zu Stress, wenn das Programm dann erweitert wird und man alle Änderungen in allen Sprachen wiederholen muss - ist auch ziemlich unsicher.
-
Auch eine Möglichkeit:
http://www.c-plusplus.net/forum/viewtopic.php?t=39062
-
Trikor schrieb:
Wenn´s mehrsprachig sein soll, würde ich die Texte aus einer Sprach.ini auslesen. Je nachdem, welcher Flag gesetzt wurde ist der Text dann Deutsch, Englisch, Französisch oder was weiss ich.
Und was ist mit Dialogen? Wenn man vom Englischen ins Italienische übersetzt werden die Texte locker mal um 50% länger (ins Deutsche etwa 30%). Ich kenne solche Programme, die fast nur aus abgek. Txtn bsthn., damit sie in die Buttons passen. Und von Anfang an mal alle Buttons doppelt so breit zu machen ("man weiß ja nie...") sieht auch nicht so toll aus.
Eine richtige Lokalisierung beinhaltet also auf jeden Fall auch das Anpassen von Dialogen.
-
Uwe Philipps schrieb:
Und was ist mit Dialogen? Wenn man vom Englischen ins Italienische übersetzt werden die Texte locker mal um 50% länger (ins Deutsche etwa 30%). Ich kenne solche Programme, die fast nur aus abgek. Txtn bsthn., damit sie in die Buttons passen. Und von Anfang an mal alle Buttons doppelt so breit zu machen ("man weiß ja nie...") sieht auch nicht so toll aus.
Eine richtige Lokalisierung beinhaltet also auf jeden Fall auch das Anpassen von Dialogen.
Hi Uwe,
das Problem hat man doch immer. Klar muß man sich gedanken machen, wie es anschließend ausschaut. Bei den meisten Sachen (Ja, Nein, Abbruch-Button bzw. Beschriftung von Groupboxen oder Static-Feldern) reicht aber ne ini.
Glücklicher weise kann man ja auch die Schriftgröße der Sprache anpassen.Aber wer lust hat, kann sich natürlich für jede Sprache ein neues Dialogfeld machen.
Ob das so sinnvoll ist, wage ich zu bezweifeln. Da sieht das Prog in einer anderen Sprache schnell mal ganz anders aus.
-
OK danke Leute, das mit den INI Files ist natürlich am einfachsten, trotzdem werde ich mich wohl mal an den Vorschlag von Uwe ranwagen...
Frage:
Die übersetzten Strings sind dann wohl als externe Variablen gekennzeichnet?!Das mit den Dialogen habe ich nicht so ganz kapiert. Welche DLL´s muß ich denn dann dynamisch laden (außer die Übersetzen), oder meinst Du das Du die Dialoge direkt übersetzt und diese dann dynamisch lädts. Wahrscheinlich kompilierst Du diese dann auch Sprachspezifisch, oder?
-
wobei ich mir noch nicht ganz schlüssig bin... die INI gefällt mir auch
-
Das Konzept mit den DLL geht so, dass eine DLL erstellt wird, die nur Resourcen enthält und zwar die gleichen wie die EXE nur halt in einer anderen Sprache.
Mit den richtigen Tools ist das überhaupt kein Problem, auch die Stellen an denen Dialoge angepasst werden müssen, bekommt man angezeigt. Aber natürlich kosten die Geld und sind hauptsächlich für professionelle Software-Entwicklung und Shareware-Programme, die man weltweit vertreiben möchte, geeignet.
Früher gab's mal die rltools von Microsoft, mit denen eine Lokalisierung gemacht werden konnte. Such' einfach mal mit google, die müssten noch irgendwo zu finden sein.
Um's mal auszuprobieren und sein Testprogramm mal in einer anderen Sprache zu sehen, ist das mit den .ini-Dateien oder Stringtables natürlich ok. Allerdings wenn das Programm noch wachsen soll, sollte man sich ein vernünftiges Konzept ausdenken, wie die Texte den Menüpunkten und Kontrollen zugeordnet werden sollen. Sonst gibt es Probleme, wenn Menüpunkte oder neue Dialoge dazukommen.