Mehrsprachige Firmware

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

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

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.