Hallo, ich habe das Problem, dass ich bei einer Gerätefirmware wo der Platz im Flash sowieso schon etwas knapp wird mehrere Sprachversionen anbieten möchte. Bisher hatte ich dafür ein kleines Tool, welches alle Strings innerhalb des Programms über eine entsprechende Datenbank in das jeweils (in dem Fall) englischsprachige Pendant übersetzt und ausgetauscht hat. Mit dem Programm stoße ich allerdings mittlerweile an die Grenzen bzw. es ist nicht allzu gut an andere Projekte anzupassen. Kennt jemand von euch ein entsprechendes Tool, welches (zumindest auf ähnliche Weise) die Erzeugung von mehreren Firmwares ermöglicht, ohne auf eine externe Resourcen-Datei zurückgreifen zu müssen? Was sind andere Möglichkeiten in so einem Fall ein Programm in mehreren Sprachen anbieten zu können? Ich bin gespannt auf die Tipps ;-) Schöne Grüße und vielen Dank, Tobi
Alle Zeichenketten in einem Definierten Bereich im Speicher abspeichern und dann mit selbstgeschriebenen Programmen anpassen lassen.
Bedingte Compilierung? D.h. alle strings stehen in allen gewünschten Sprachen im Quelltext, aber nur eine davon wird beim compilieren benutzt.
Ach so.. ich sollte vielleicht dazu sagen, dass der Großteil der Quelltexte in C geschrieben ist.. Gruß, Tobi
Qt macht das so, dass dort Strings als "übersetzenswert" markiert werden, das macht dann das Suchen für das Programm deutlich leichter, da es nurnoch nach dem "Trigger" suchen muss.... HIer is die Doku dazu: http://doc.qt.digia.com/4.7/linguist-programmers.html du könntest sowas in der Art (vlt. etwas abgespeckt) auch für dein System nutzen
Moin, die Sache mit dem Speicher klingt nach "on the fly"-Tauschen der Texte. Dafür reicht auf dem Mikrocontroller leider weder der RAM, noch der Flash um beide Varianten mitzuführen. Oder verstehe ich die Idee gerade falsch? Bedingte Compilierung wäre eine Variante, dann müsste ich aber meinen Quelltext in 4-5 verschiedenen Varianten bauen. Das wird leider viel zu unübersichtlich. Wenn der Text beim Kompilieren (oder durch das Tool vor dem Kompilieren) entsprechend getauscht würde bleibt es übersichtlich und es wird kein Platz verschwendet. Nur bin ich für sowas (oder einer besseren Lösung) halt noch auf der Suche. Gruß, Tobi
Tobias H. schrieb: > Moin, > > die Sache mit dem Speicher klingt nach "on the fly"-Tauschen der Texte. > Dafür reicht auf dem Mikrocontroller leider weder der RAM, noch der > Flash um beide Varianten mitzuführen. Oder verstehe ich die Idee gerade > falsch? > > Bedingte Compilierung wäre eine Variante, dann müsste ich aber meinen > Quelltext in 4-5 verschiedenen Varianten bauen. Das wird leider viel zu > unübersichtlich. > > Wenn der Text beim Kompilieren (oder durch das Tool vor dem Kompilieren) > entsprechend getauscht würde bleibt es übersichtlich und es wird kein > Platz verschwendet. Nur bin ich für sowas (oder einer besseren Lösung) > halt noch auf der Suche. > > Gruß, > Tobi Wie wärs mit einer Header-Datei, jeweils für jede Sprache eine. Beim Bedingten Compilieren dann die richtige mit einbinden. Die Konstanten-Namen können dann ja durchaus in Englisch oder Deutsch gehalten werden, nur der Inhalt ist dann angepasst. Bedingtes Compilieren ginge dann z.b. übers Makefile, für jede Sprachversion.
Das wäre natürlich die Variante mit der bedingten Kompilierung. Es gibt da aber auch einige Möglichkeiten die Binäre Firmwaredatei zu modifizieren wenn es im Quelltext richtig verankert wird.
Texte in ein externes EEPROM auslagern und je nach gewählter Sprache auf eine andere Page umschalten. Braucht zur Laufzeit etwas mehr RAM, dafür aber viel weniger ROM. Wenn das Gerät in einsprachigen Versionen verkauft werden soll, dann kann man mit einem statischen Programm arbeiten und nur das EEPROM umprogrammieren bzw. tauschen.
Dennis Heynlein schrieb: > Wie wärs mit einer Header-Datei, jeweils für jede Sprache eine. Das ist der übliche Weg, aber mir ist es lieber bzw. übersichtlicher, den Text an der entsprechenden Stelle im Programm zu haben. In Pascal z.B. so:
1 | help := |
2 | {%G 'Parameterdatei nicht vorhanden! #Enter druecken !'}
|
3 | {%E 'Parameter file not found ! Press #Enter ! '}
|
4 | ; |
5 | wrcomm; {write to display}
|
In C entsprechend mit "#IFDEF KISUAHELI" usw. Damit die Sache für weitere Sprachen besser handhabbar wird, habe ich dazu Textdatenbanken angelegt in folgender Form:
1 | {%G ' Adapter-Liste wird gedruckt.'}
|
2 | {%F ' liste adaptateur est imprimee.'}
|
3 | {%I ' La lista adatt. viene stampata'}
|
4 | {%E ' printing adapter list. '}
|
5 | {%S ' Adapterlista skrivs ut. '}
|
6 | {%R ' ðîçðíé ßãßîñäïíá îäößñßäñðþ '}
|
Diese wird nach dem deutschen Text indiziert. Ein Preprozessor holt sich dann fehlende Texte aus dieser Datei (R ist Russisch, kann man hier nicht darstellen). Wird eine weitere Sprache benötigt, gebe ich diese Textdatei an ein Übersetzungsbüro zur Ergänzung. Gruss Reinhard
Reinhard Kern schrieb: > (R ist Russisch, kann man hier nicht darstellen) Doch, wenn Du keine 8-Bit-Codierung (CP-1251), sondern UTF-8 verwendest. Damit lassen sich in diesem Forum nicht nur kyrillische Zeichen darstellen: Но если у вас нет 8-битной кодировки (CP-1251) с использованием, но UTF-8. Таким образом, может быть представлена в этом форуме не только символы кириллицы: (Da ich gar kein Russisch kann, musste hier Tante Googles Übersetzer herhalten. Mit den vermutlich zu erwartenden Ergebnissen)
Oder einfach im EEPROM eine passende Tabelle mit den Namen anlegen und im eigentlichen Programm via defines auf diese Tabelle referenzieren. Dann kann man auch on the fly die Sprache ändern ohne das Programm anfassen zu müssen.
Hi, danke für die vielen Überlegungen. Mir liegt sehr viel daran, dass die entsprechenden Quelltexte noch übersichtlich sind. Außerdem ist das Gerät, um das es geht, von der Hardware her schon fertig und "auf dem Markt", so dass ein externes EEPROM etc nicht in Frage kommt. Die Sprache muss auch nicht umgeschaltet werden können, daher reicht es, für jede Sprache eine separate Firmware anzubieten (Updates sind bei den Benutzern ohne Probleme möglich). Folgende Lösung läuft bisher (und ich habe sie gestern erweitert, so dass sie noch etwas flexibler ist): Ein kleines Tool durchsucht alle Quelltextdateien nach entsprechenden Texten und erstellt einen einzelnen #define-Block, durch den (bei vorhandensein einer entsprechenden Headerdatei) eine Präprozessor-Variable statt der originalen Stringdefinitionen benutzt wird. Diese Variable wird über einen Hash-Algorithmus aus dem Inhalt der Variable erstellt, der Variablenname bleibt also - so lange der Text nicht geändert wird und daher neu übersetzt werden müsste - bei jedem Durchlauf gleich. Auf die Art und Weise kann ich, bevor ich das Projekt kompiliere, alle Quelltexte automatisiert so umbauen, dass ich auf die Header-Datei zurückgreife. Nachdem die neue "offizielle" Version fertig ist (in verschiedenen Sprachen kompiliert) kann ich die Änderungen (die durch entsprechende Kommentare für das Tool kenntlich gemacht sind) wieder entfernen und das Projekt ist wieder übersichtlich. Etwas fertiges in die Richtung gab es leider nicht. Auch mein (also selbstgebautes) Tool ist weit von vorzeigbar entfernt, aber es erfüllt für mich den genannten Zweck. Vielen Dank für die Ansätze - leider war für mich nichts passendes dabei. Gruß, Tobi
Tobias H. schrieb: > Etwas fertiges in die Richtung gab es leider nicht. Das ist ziemlich genau das, was ich für Pascal gemacht habe - ich musste mir die Präprozessor-Software aber auch selber schreiben. Ist aber ein noch überschaubarer Aufwand und per Makefile leicht in den Workflow integriert. Gruss Reinhard
Tobias H. schrieb: > Hallo, > > ich habe das Problem, dass ich bei einer Gerätefirmware wo der Platz im > Flash sowieso schon etwas knapp wird mehrere Sprachversionen anbieten > möchte. Mach ich über Excel Dateien. Hinterher wird die Spalte mit dem entsprechenden Text in den Quellcode kopiert (oder alle wenn mehr Platz ist). Character code Konvertierungen (z.B. kyrillische LC-Displays) werden in Excel über Makros gemacht, aber eben nur 1x. Hat den Vorteil das der Übersetzer/Tester/Auftraggeber gleich loslegen/Prüfen kann, auch wenn er auf der anderen Seite des Planeten sitzt (Office ist in Sachen Internationalisierung sehr mächtig und alle haben es). Zu viele Zeichen in der Spalte werden rot (bei bedingter Formatierung ) und durch den Arial-Unicode Font wird alles so angezeigt wie es eingegeben wurde, was wichtig zum testen ist. Wird also komplett extern geführt, was den Quellcode vereinfacht und der Programmierer muss nicht auch noch Sprachwissenschaftler sein.
Moin, ich habe da mal so'n Hack mit XML gemacht und daraus C Stringtabellen erzeugt. Die Strings werden dann über einen kleine Routine via ein Handle selektiert. Die Übersetzer kriegen nur die XML-Dateien und fuddeln somit nicht am Code rum. Daraus wird der Prototypen-Header und die Stringtabelle per XSLT gebaut. Hiess allerdings: Von vornherein sind keine printfs erlaubt, und man muss alle Ausgaben in dieser Form machen
1 | MESSAGE(MSG_UNIT_NOT_READY) |
Da beim Bauen nur die Link-Option (per Makefile) und keine bedingte compilierung verwendet wird, bleibt's übersichtlich, und alle Strings werden über die eine XML-Datei verwaltet. Allerdings braucht man einen Mechanismus, um einen Check über die Messages zu machen, falls mal in der XML eine Übersetzung für ein Wort vergessen ging.
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.