[Erledigt] "Automatisierte" Lokalisierung

[Gast]

Hallo!
Ich habe mir Gedanken zum Thema Lokalisierung einer Applikation gemacht und habe mich nun gefragt, ob es für Visual Studio evtl. schon passende Addins gibt.
Und zwar würde ich gerne in folgender Form lokalisierte Strings bekommen:

localize("String in der Hauptsprache des Quellcodes")

Nun würde dieses "gedachte" AddIn vor dem Kompilieren alle Ausdrücke dieser Form parsen, mit gperf eine perfekte Hashfunktion für sie erstellen und anschließend durch localize(hash) ersetzen.
Zur Laufzeit würde ich eine Lokalisierungsdatei lesen (Format: "Ursprünglicher Text" "Lokalisierter Text") und dann den ursprünglichen Text mit der generierten Hashfunktion hashen und das ganze dann in einer hash_map ablegen. Somit könnte sich jeder seine eigene Lokalisierungsdatei erstellen und man könnte sogar noch automatisch eine Default-Datei anlegen.
Das ganze am besten nur im Release-Build und im Debug-Build wird halt immer zur Laufzeit ein Hash generiert.

Nun meine Frage: Ist der Ansatz evtl. dumm oder gibt es sowas vielleicht schon als Addin?

Viele Grüße,
Michael

[Martin Richter]

In der MFC und WinAPI platziert man Texte nicht im Programm. Dafür gibtes Ressourcen, die man getrennt laden kann und die man dadurch auch leicht lokalisieren kann. Es ist weitaus einfacher IDs zu verwalten und diesen passende Texte aus INI Datei oder DLL zuzuweisen.

Siehe auch
http://www.mpdvc.de/artikel/MultilingualeProgramme.htm

[Gast]

Genau die Grütze mit den ID's wollte ich mir gerne sparen. Ich fände es wesentlich lesbarer, wenn der Text direkt im Code steht (Weil er ja auch zum Verständnis beiträgt...). Jetzt kann man natürlich einwenden, dass ID's auch toll benannt sein können, aber riesige Makro-Geschwülste sind für mich ehrlich gesagt nicht das Wahre. Findest Du diesen Weg der Lokalisierung (über ID's) wirklich gut, oder verwendest du ihn, weil er in Windows so "vorgesehen" ist?
Wäre es nicht einfacher, einen String als Literal in den Quellcode einzufügen anstatt im Stringtable ID->String anzulegen, in der Resource.h ne ID zu definieren und im Source dann die ID zu benutzen?
Und wie kann sich jemand, der nur die Executable hat, selber eine Lokalisierung schreiben?

Viele Grüße,
Michael

PS: Da ich ja nun die MFC benutze, würde ich für die MFC selber halt den Weg der ID's gehen (was für mich ja praktisch bedeutet, dass ich da gar nichts verändere) und für meine eigenen Texte halt eine schönere Variante wählen.

[Martin Richter]

Decimad schrieb:

Genau die Grütze mit den ID's wollte ich mir gerne sparen. Ich fände es wesentlich lesbarer, wenn der Text direkt im Code steht (Weil er ja auch zum Verständnis beiträgt...).

Ich empfinde solchen Text in Programmen eher als Fehler, denn als Benefit.
Zudem sind Layout des Dialoges und Texte direkt verbunden. Warum sollte man das trennen?

Decimad schrieb:

Jetzt kann man natürlich einwenden, dass ID's auch toll benannt sein können, aber riesige Makro-Geschwülste sind für mich ehrlich gesagt nicht das Wahre. Findest Du diesen Weg der Lokalisierung (über ID's) wirklich gut, oder verwendest du ihn, weil er in Windows so "vorgesehen" ist?

IDs sind kompakt einfach und schnell zu nutzen. Textliterale sind langsam und unhandlich.
Ich finde ihn gut weil er UI Layout und den Code weitgehend trennt.
Oder zumnidest eine Trennung ermöglicht.
Zusätzlich Code zu schreiben, der dann erst nachträglich die Dialoge auf die Sprache setzt, die ich möchte finde ich lästig.

Decimad schrieb:

Wäre es nicht einfacher, einen String als Literal in den Quellcode einzufügen

Nein!
Eine ID ist immer handlicher als der Text!

Decimad schrieb:

anstatt im Stringtable ID->String anzulegen, in der Resource.h ne ID zu definieren und im Source dann die ID zu benutzen?
Und wie kann sich jemand, der nur die Executable hat, selber eine Lokalisierung schreiben?

Solche Programme haben ich nicht. Meine Programm sind so groß, dass wir Übersetzungsbüros einsetzen, die entsprechenden Ressourcen mit entsprechenden Programmen zu übersetzen.
Wenn Du es anderen überlassen willst. Bleib bei IDs und nimm eine INI Datei...

PS: Alleine weil ein einziger Verschreiber oderene Korrektur in Deinem Sourcecode alle Übersetzungen bricht solltest Du es vermeiden.
Denn Du hashst ja die primäre Übersetzung. Was ist wenn da ein Fehler drin ist?
Du korrigierst diese und der Hash ist kaputt.
Eine ID ändert sich nicht....

[Gast]

Hrmm, naja, ich dachte in dem Fall daran, den Rechtschreibfehler nicht im Code zu korrigieren (bis zur nächsten "Version"), sondern als Korrektur-File im gleichen Stil der Fremdsprachen-Lokalisierung.
Ich habe jetzt zu meinem Leidwesen natürlich nicht daran gedacht, dass sich Standard-Dialoge nicht von selber auf eine passende Größe für unterschiedliche Texte/Sprachen einrichten können... Das wäre dann natürlich auch nochmal eine schöne Sache

Viele Grüße,
Michael

PS: Ich weiß jetzt nicht, ob ich das verständlich rübergebracht habe, aber im zu kompilierenden Code (Die Ausgabe von dem Tool, welches vorher über den Source läuft) sollen dann ja für zu lokalisierende Strings gar keine String-Literale mehr vorhanden sein, sondern nur deren Hashes als automatisch generierte ID's. Es soll ja sozusagen die Geschwindigkeit der ID's mit dem Komfort von String-Literalen verbinden.

[Martin Richter]

Decimad schrieb:

PS: Ich weiß jetzt nicht, ob ich das verständlich rübergebracht habe, aber im zu kompilierenden Code (Die Ausgabe von dem Tool, welches vorher über den Source läuft) sollen dann ja für zu lokalisierende Strings gar keine String-Literale mehr vorhanden sein, sondern nur deren Hashes als automatisch generierte ID's. Es soll ja sozusagen die Geschwindigkeit der ID's mit dem Komfort von String-Literalen verbinden.

Dann verstehe ich nicht warum Du diesen Umweg überhauopt willst.
Bleb doch bei IDs und gut ists.

[Gast]

Wie gesagt, bei ID's muss ich an 3 Stellen im Projekt editieren um einen String hinzuzufügen... Da ja nun das Layoutproblem für Dialoge existiert, macht es natürlich keinen Sinn da zwei verschiedene Wege zu gehen und ich werde halt mit den Stringtables vorlieb nehmen müssen. Gibt es da evtl. Tool um das "abzukürzen"? Dass ich zB im Codeeditor ein Stringliteral per Kontextmenü automatisch in den Stringtable verschieben kann, dann noch einen ID-Namen angebe und das automatisch mit der resource.h synchronisiert wird? Sozusagen ohne einmal aus dem Codefenster rauszumüssen.

Viele Grüße,
Michael

[Martin Richter]

3 Stellen? Wo musst Du Dein Projekt an drei Stellen editieren?

Die ID wird doch beim Anlegen der Ressource vergeben mit dem Namen den Du willst. Die Nummer wird automatisch hochgezählt. Sicher must Du noch zusätzlich eine String ID Eruegen in der INI Datei.

So passiert es bei mir (wenn man es richtig einrichtet):
Ich erzeuge meinen Dialog wie ich es will.
Schmeiß meinen RC-WinTRans an, der mir eine neue RC-Datei erstellt.
Compile das wars.

[Gast]

Entschuldige bitte, ich habe es eben nochmal ausprobiert und musste zu meiner Scham erkennen, dass der Stringtable-Ressourcen-Editor die ID's ja automatisch in die resource.h einträgt. Ich meinte mich irgendwie zu erinnern, dass das ein manueller Schritt war.

Viele Grüße,
Michael