Hallo Community,
Ich überlege gerade, wie eine "saubere" Implementation eines
mehrsprachigen Benutzermenüs aussehen könnte. Dazu gibt es sicher viele
Ansätze, jedoch würden mich Eure Ideen interessieren.
Konkret geht es um die Bedienung eines Geräts über ein Menü auf einem
kleinen alphanumerischen Display, auf dem sich der Benutzer via Encoder
zurechtfinden kann. Wie unterstützt man da am besten mehrere Sprachen?
Die wahrscheinlich schlechteste Lösung könnte etwa so aussehen:
1
if(LANGUAGE==ENGLISH){
2
lcd_write("Settings");
3
}elseif(LANGUAGE==GERMAN){
4
lcd_write("Einstellungen");
5
}
...usw., ihr versteht.
Das wird schnell enorm unübersichtlich und macht das Hinzufügen einer
neuen Sprache zur Qual.
Ein anderer Lösungsansatz wäre vielleicht die Verwendung eines Arrays
für jeden Ausdruck, das dann die verschiedensprachigen Übersetzungen
davon als Strings enthält. Aber auch das wirkt irgendwie "unschön".
Wie würdet Ihr dieses Problem angehen? Wie machen das die Profis in
grosser Software?
Es geht mir weniger um ein spezifisches Projekt sondern eher um einen
Ideen-Pool für später ;)
Freundliche Grüsse,
Stefan
Stefan schrieb:> Ein anderer Lösungsansatz wäre vielleicht die Verwendung eines Arrays> für jeden Ausdruck, das dann die verschiedensprachigen Übersetzungen> davon als Strings enthält. Aber auch das wirkt irgendwie "unschön".
Was ist daran "unschön"?
Das ist im Grunde, doch das was "GNU gettext()" auch macht.
Ja, da kannst du dir sicherlich was abschauen...
Stefan schrieb:> Wie würdet Ihr dieses Problem angehen? Wie machen das die Profis in> grosser Software?
Genau so:
Stefan schrieb:> Ein anderer Lösungsansatz wäre vielleicht die Verwendung eines Arrays> für jeden Ausdruck, das dann die verschiedensprachigen Übersetzungen> davon als Strings enthält. Aber auch das wirkt irgendwie "unschön".
Je nach verwendeter Programmiersprachen gibt es dazu mehr oder weniger
elegante vorgefertigte Wege, oder man muss halt selbst basteln.
Stefan schrieb:> Ein anderer Lösungsansatz wäre vielleicht die Verwendung eines Arrays> für jeden Ausdruck, das dann die verschiedensprachigen Übersetzungen> davon als Strings enthält. Aber auch das wirkt irgendwie "unschön".
Würde hier nicht nach Ausdruck gruppieren sondern wenn dann nach
Sprache.
Zu Beginn würde ich pro Ausdruck einen Index/Key definieren.
Dann legst du die Ausdrücke pro Sprache in einem Array ab.
Ein Pointer zeigt dann je nach gewählter Sprache auf das entsprechende
Array welches dann mit dem Key ge-indexed wird.
z.B.
Danke für Eure zahlreichen Antworten.
Arduino F. schrieb:> Was ist daran "unschön"?
Ich dachte dabei, wenn ein Array-Element vergessen oder verschoben wird
(wieso auch immer), dass dann alles nachfolgende verrutscht und somit
falsch ist. Anfällig auf Programmierfehler, sozusagen. Aber ich vermute,
mit dem muss man leben und stellt auch keine Katastrophe dar.
Arduino F. schrieb:> Das ist im Grunde, doch das was "GNU gettext()" auch macht.> Ja, da kannst du dir sicherlich was abschauen...
Interessantes Stichwort. Werde ich mir ansehen.
Dominik S. schrieb:> Würde hier nicht nach Ausdruck gruppieren sondern wenn dann nach> Sprache.
Scheint mir sinnvoll, dann sollte das Hinzufügen/Löschen einer Sprache
einfacher fallen.
Dominik S. schrieb:> z.B.
Danke für den Code! Der Ansatz gefällt mir.
Freundliche Grüsse,
Stefan
physiker schrieb:> Das ist natürlich nur der einfachste Fall. Schau Dir z.B. an wie QT es> macht:> http://doc.qt.io/qt-5/i18n-source-translation.html> http://doc.qt.io/qt-5/internationalization.html
Danke! werde ich mir ansehen. Sieht so aus, als wäre da einiges an
Aufwand betrieben worden, denn aufgrund
physiker schrieb:> Sprachen die von rechts nach links geschrieben> werden. Pluralbildung und zusammengesetzte Sätze mit Platzhaltern für> Zahlen und Strings. Datums- und Zahlenformate
wird das ganze anscheinend ziemlich komplex, wenn man Wert auf die
Details legen möchte. Das ist man sich unter Umständen gar nicht
bewusst.
Freundliche Grüsse,
Stefan
Um wieviel text geht es sich ? (wieviel characters * wieviel Sprachen ?)
Rechne damit das text ein zimlich groszer teil deiner Flash memory kann
benoetigen. Kann die language durch benutzer geandert werden oder gibt
es mehrere verschiedene HEX files ?
Im letzten fall kannst du pre-compiler directives benutzen
Ein Array ist, bei ein paar Textzeilen, die bei weitem effektivste
Lösung für Dein Problem.
Spätestens wenn mehr als 2 Sprachen ins Spiel kommen, oder mehr Texte
benötigt werden, ist diese Lösung aber nicht mehr das Gelbe vom Ei.
Rund um das Stichwort "i18n" gibt es ein komplettes Tool-Set, um auch
mehr als 2 Sprachen zu handhaben. Natürlich bedeutet dies, dass Du dich
in das zugehörige System einarbeiten musst. Aber spätestens nach der 5.
Menüerweiterung oder nach der Feststellung: "Frankreich ist nicht weit
und Franzosen können keine Fremdsprachen", rechnet sich das.
Nicht elegant, aber langsam: Mein printf wertet bei "%s" eine globale
Variable aus und gibt je nach "locale" den ersten, zweiten, n-ten String
zwischen den '^' aus:
Arduino F. schrieb:> Stefan schrieb:> Ein anderer Lösungsansatz wäre vielleicht die Verwendung eines Arrays> für jeden Ausdruck, das dann die verschiedensprachigen Übersetzungen> davon als Strings enthält. Aber auch das wirkt irgendwie "unschön".>> Was ist daran "unschön"?>> Das ist im Grunde, doch das was "GNU gettext()" auch macht.> Ja, da kannst du dir sicherlich was abschauen...
Genauso in der Form wird es gemacht und nicht anders.
Stefan schrieb:> Ein anderer Lösungsansatz wäre vielleicht die Verwendung eines Arrays> für jeden Ausdruck,
das hat auch den Vorteil dass alle Texte an einer Stelle sind.
Wenn Du das jemandem zum Übersetzen gibst musst der nicht alle
Programmtexte durchsuchen
Stefan schrieb:> Bedienung eines Geräts über ein Menü auf einem> kleinen alphanumerischen Display, auf dem sich der Benutzer via Encoder> zurechtfinden kann.Dirk schrieb:> beim> Programmstart bzw. Sprachänderung die richtige Sprache aus der Datenbank> laden.
passt nicht so ganz zusammen vermute ich
Stefan schrieb:> Danke für Eure zahlreichen Antworten.>> Arduino F. schrieb:>> Was ist daran "unschön"?>> Ich dachte dabei, wenn ein Array-Element vergessen oder verschoben wird> (wieso auch immer), dass dann alles nachfolgende verrutscht und somit> falsch ist. Anfällig auf Programmierfehler, sozusagen. Aber ich vermute,> mit dem muss man leben und stellt auch keine Katastrophe dar.
Nur Tunnelblick lässt zu dass Quellcode ausschliesslich von Compilern
verarbeitet wird.
Gerade um solche Meta Disziplinen einzuhalten braucht es hauptsächlich
Fantasie: ob nun per C-Präprozessor oder beliebige externe
Scriptsprachen (Reguläre Ausdrücke lassen grüssen), es lassen sich
beliebige und beliebig nötige andere Verarbeitungsschritte in das
Makefile des Subsystems/Projektes integrieren.
Gerade bei verschiedenen Sprachen (aber nicht nur) will man ja auch
gerne ein Referenzhandbuch aller Menutexte dazu haben: lässt sich auf
diesem Wege sozusagen fast "für Umme" auch gleich bei jedem Buildablauf
direkt aus dem Quellcode generieren. Dies oft sogar in mehreren Formate
(Markdown, ReST, XML (-->SGML, HTML), PDF, ...) und die zugehörige
SW-Version steht dann auch "automagisch" richtig drin.
Lieber als
1
:
2
constchar*terms_de[2]={"Einstellungen","Zurück"};
3
constchar*terms_en[2]={"Settings","Back"};
4
:
mag ich es mehrdimensional mit der Sprache auch als Index. Dies
ermöglicht Funktionen welche zur Laufzeit fehlende Einträge detektieren
können und fallback auf die Haupsprache bieten können. (solche
Vorkommnisse sind zu loggen...)
Wie <Makefiles!> schon angedeutet hat, ist der Präprozessor bzw. die
dadurch integrierten Makros das Schlüsselwort.
Ich hab das in projekten aber mal anders genutzt:
In deiner Datei mit den Text-Arrays legst du zu jedem eintrag, mittels
#define Auch gleich eine Makro-Variable an welche den Arrayzugriff
beinhaltet.
Z.B:
1
int sprache = 0; // 0 für Deutsch und 1 für Englisch
Es sei noch angemerkt, dass die printf-Familie auch positionale
Argumente verarbeiten kann. Damit kann man Argumente in einer fixen
Reihenfolge im Code übergeben, während sie in einer der Sprache
angemessenen Reihenfolge erscheinen.
Datumsangaben sind immer solche Kandidaten, einerseits wegen z.B.
"tt.mm.jjjj" und "yyyy-mm-dd" oder dem Würgereiz "mm/dd/yyyy",
andererseits wegen "N. September 2012" und "September 5, 2012". Das gilt
aber auch allgemein für viele Formulierungen, die sonst unschön klingen.
Damit kann man schon einiges erschlagen, wenn man auf schwierige
Schriftsysteme (z.B. Hebräisch, Japanisch oder Arabisch) verzichten
kann.
Nachtrag: Eine Lösung mit Präprozessor-Makros spart Flash, raubt aber
die Möglichkeit von Multilanguage-Images.
S. R. schrieb:> Es sei noch angemerkt, dass die printf-Familie auch positionale> Argumente verarbeiten kann.
Das wäre mir neu. Leider hast du kein Beispiel genannt, wie das
aussieht.
Rolf M. schrieb:>> Es sei noch angemerkt, dass die printf-Familie auch positionale>> Argumente verarbeiten kann.>> Das wäre mir neu. Leider hast du kein Beispiel genannt, wie das> aussieht.
Das ist ganz einfach, statt '%' schreibst du '%n$', wobei n den
Argumentindex (gezählt ab 1) angibt:
Ich habe mir dafür eine Datenbank eingerichtet. Die Source-Dateien
enthalten den speziell gekennzeichnenten deutschen Text, ein
Präprozessor ersetzt diesen vor dem Kompilieren durch den
fremdländischen. Da ich nicht gut genug Französich, Spanisch, Russisch
unw. kann, werden die übersetzten Texte von professionellen
Übersetzungsbüros in die Datenbank eingetragen. Die müssen sich
natürlich auch sachlich auskennen, in meinem Fall in CNC-Tectnik - ein
Romanüberstzer weiss sicher nicht, wie man Istwert oder Sollwert korrekt
übersetzt.
Georg
Da machst Du ein Fass ohne Boden auf... mehrsprachlichkeit in der IT ist
etwas, das unendlich komplex werden kann. Die Repräsentation der Strings
ist dabei nur die allerkleinste Herausforderung. Wo es vom OS
unterstützt wird, werden meistens Satelliten Resource Only DLLs
verwendet, die dann auch nur punktuell angefasst werden müssen, ohne den
Code neu zu bauen.
Hier sind nur ein paar Dinge, die dann zuwangsläufig auf Dich zukommen:
1. Stringlänge. Deutsche Ausdrücke sind in der Regel länger als
Englische, d.h. wer mit Englisch anfängt, kriegt beim Deutschen gerne
eines der folgenden Probleme:
- Plötzliche über den Rand einer Displayzeile rollende oder
abgeschnittene Texte
- Platzende Arrays, wenn eine Maximale Stringlänge hardcodiert ist
- Wenn ein etwas komfortableres GUI im Spiel ist: Zu kurze Textfelder
natürlich tritt dasselbe Problem auf, wenn Du vom Deutschen in eine
Sprache lokalisierst, die längere übersetzte Strinsg haben
2. Zeichensätze: Kann deine Zielhardware ä,ö,ü sowie die dänischen und
französischen Sonderzeichen bzw. Alle in der Zielsprache nötigen? Wenn
ja, bist Du sicher, dass der Quellcode dieselben Codepages unterstützt?
Wenn nicht, passiert Dir genau das, was man z.B. oft an Auto- oder
Internetradios sieht, wenn vom Sender kommende Sonderzeichen im
günstigsten Fall fehlen, im schlechteren crashes verursachen.
Danke allen für Ihre Beiträge.
S. R. schrieb:> Es sei noch angemerkt, dass die printf-Familie auch positionale> Argumente verarbeiten kann.
Wieder was gelernt!
S. R. schrieb:> Nachtrag: Eine Lösung mit Präprozessor-Makros spart Flash, raubt aber> die Möglichkeit von Multilanguage-Images.
Anfänglich war ich nur an einer Lösung ohne Präprozessor interessiert,
doch scheint es auch da mehrere, spannende Ansätze zu geben.
Hat da jemand Erfahrung aus einem industriellen Umfeld, bzgl. fest
programmierten Sprache und flexibler Sprachwahl (dafür mehr
Flashbedarf)? Ist der logistische Aufwand in der Fertigung üblicherweise
nicht zu gross, dass man die Geräte vor Auslieferung auf die passende
Sprache flasht?
georg schrieb:> Ich habe mir dafür eine Datenbank eingerichtet. Die Source-Dateien> enthalten den speziell gekennzeichnenten deutschen Text, ein> Präprozessor ersetzt diesen vor dem Kompilieren durch den> fremdländischen. Da ich nicht gut genug Französich, Spanisch, Russisch> unw. kann, werden die übersetzten Texte von professionellen> Übersetzungsbüros in die Datenbank eingetragen.
Könntest Du das genauer erläutern?
Ich nehme an, für die Übersetzung resp. die Sprachänderung muss ein
File, das alle passenden Ausdrücke enthält, vor dem Kompilieren
ausgetauscht werden. Der Präprozessor nimmt dann die Ausdrücke aus
diesem File und setzt sie in die Sources ein. Etwa so?
main.c
1
lcd_write(SETTINGS_LABEL);
2
lcd_write(COLOR_LABEL);
und dann ein "Sprachfile" german.h
1
#define SETTINGS_LABEL "Einstellungen" //Settings
2
#define COLOR_LABEL "Farbe" //Color
Babelfish schrieb:> Da machst Du ein Fass ohne Boden auf... mehrsprachlichkeit in der IT ist> etwas, das unendlich komplex werden kann.
Darum finde ich es ein sehr spannendes Thema!
Babelfish schrieb:> Plötzliche über den Rand einer Displayzeile rollende oder> abgeschnittene Texte
Das sieht man oft. Auch ein Grund, wieso viele Geräte bei mir auf
Englisch eingestellt sind.
Freundliche Grüsse,
Stefan
Stefan schrieb:> Hat da jemand Erfahrung aus einem industriellen Umfeld, bzgl. fest> programmierten Sprache und flexibler Sprachwahl (dafür mehr> Flashbedarf)?
Wieviel Flash hast du zur Verfügung, und welchen Anteil daran hat der
darzustellende Text? Wieviele Sprachen möchtest (musst) du unterstützen,
und um wieviele Geräte geht es in den jeweiligen Märkten? Brauchst du
mehr als einen Zeichensatz (westeuropäisch, kyrillisch, griechisch)?
Brauchst du mehr als ein Schriftsystem (arabisch, hebräisch, diverses
asiatisch)? Wo wird produziert/geflasht? Kannst du vom Benutzer
erwarten, das Gerät einmalig einzurichten und/oder zu flashen? Musst du
damit rechnen, dass der Benutzer möglicherweise die Landessprache des
Geräte-Aufstellungsorts nicht spricht?
Daraus ergeben sich die Randbedingungen, innerhalb derer du agieren
musst. Ohne passende Antworten darauf gibt es keine passende Lösung.
Der Linux-Kernel ist nur einsprachig, aber das Linux-Ökosystem ist
dynamisch mehrsprachig. Windows und dessen Ökosystem ist historisch
einsprachig, inzwischen geht da geringfügig mehr (aber eher schlecht).
Android/iOS und deren Ökosysteme sind grundsätzlich mehrsprachig, ebenso
die meisten moderneren - aber nicht alle - Geräte.
Stefan schrieb:> Das sieht man oft. Auch ein Grund, wieso viele Geräte bei mir auf> Englisch eingestellt sind.
Das ist mit einem einsprachigen Image nicht möglich. Allein schon
deswegen würde ich zu mehrsprachigen Images raten, sofern möglich.
Stefan schrieb:> Könntest Du das genauer erläutern?
Nur als Beispiel für Pascal-Programme, ich kennzeichne die Strings mit
{%, z.B. {%G ist deutsch, zunächst ist das in Pascal ein Kommentar. Für
andere Sprachen funktioniert das ähnlich.
1
Im Sourcefile steht z.B.
2
3
PROCEDURE wroffset;
4
BEGIN
5
scmode(0); gotoxy(9,4); szoom(1);
6
write (
7
{%G 'Abmessungen der Meisterlehre'}
8
);
9
10
In der Datenbank steht dazu:
11
12
{%G 'Abmessungen der Meisterlehre'}
13
{%F 'dimensions du calibre etalon'}
14
{%I 'Dimens. del Master di azzer.'}
15
{%E 'master gage dimensions '}
16
{%S 'Dimensioner fraen mall '}
17
{%R 'âßà.ïßæëäïú üñßêíìì. éßêçàïß'}
18
19
20
Nach dem Präprozessor für Englisch steht im PAS-File:
21
22
PROCEDURE wroffset;
23
BEGIN
24
scmode(0); gotoxy(9,4); szoom(1);
25
write (
26
'master gage dimensions '
27
);
und das wars. Das geht in einem Rutsch für hunderte Dateien mit ca.
100000 Zeilen Code. Mit Symbolnamen für die Strings und defines zu
arbeiten ist mir zu umständlich und zu fehleranfällig, der String selbst
ist auch die Adresse in der Datenbank.
Was man nicht vergessen darf: auch die Antwort etwa auf "Sind Sie
sicher?" ist natürlich sprachabhängig, z.B. J-a, Y-es oder O-ui, aber
das geht genauso.
Übrigens funktioniert die Ersetzung auch direkt, wenn im Src-File steht:
1
PROCEDURE wroffset;
2
BEGIN
3
scmode(0); gotoxy(9,4); szoom(1);
4
write (
5
{%G 'Abmessungen der Meisterlehre'}
6
{%E 'master gage dimensions '}
7
);
aber dann müsste ich hunderte Sourcefiles dem Übersetzungsbüro
übergeben, daher die Datenbanklösung, da bekommen die nur die Datenbank.
Georg
Stefan schrieb:> Hat da jemand Erfahrung aus einem industriellen Umfeld, bzgl. fest> programmierten Sprache und flexibler Sprachwahl (dafür mehr> Flashbedarf)?
Meine Geräte müssen mehrsprachig sein und das wird vor Ort vom Benutzer
ausgewählt. Deshalb ist an keinerlei Compilezeit-Lösung zu denken.
Stattdessen benutze ich im eigentlichen Menü lediglich Nummern und
lagere das Liefern des zur aktuell eingestellten Sprache passenden
Strings in einen separaten Unit aus. Auf diese Weise braucht man sich im
Menü überhaupt nicht darum zu kümmern, was der Benutzer grad für eine
Sprache eingestellt hat.
Das Abtrennen von solchen Lowlevel-Dingen von den eigentlichen
Algorithmen hat sich zumindest bei mir als außerordentlich hilfreich
erwiesen.
W.S.
Bei uns würde jeder der sagt:
"Da brauchst Du doch nur am Quellcode rumfummeln", standrechtlich
erschossen.
Wie gesagt:
>Ein Array ist, bei ein paar Textzeilen, die bei weitem effektivste>Lösung für Dein Problem.
Ein weiterer, hier unter den Tisch gekehrter Vorteil der i18n-Lösung
ist, dass die Übersetzung auch von Nicht-Programmierern, also Leuten,
die nur die zwei Sprachen können, erledigt werden kann.
Manche haben allerdings eine Gummiallergie - also auf keinen Fall eine
flexible Lösung.
Sebastian S. schrieb:> Manche haben allerdings eine Gummiallergie - also auf keinen Fall eine> flexible Lösung.
Diese Alergie ist allerdings manchmal begründet. Als Programmieranfänger
neigt man stark dazu "großartige" Frameworks für triviale Features
einzusetzen.
Man denkt sich "das bereiten wir jetzt hochflexibel vor denn das werden
wir dadurch garantiert alles so viel weiter verbessern können!!" und in
ein paar Monaten kommt ein neues Projekt und niemand wird die
Flexibilität je nutzen.
Wenn man schlussendlich selbst - oder schlimmstenfalls dank des Chefs -
mal merkt wie hoch der reale Nutzen dieses Aufwands war, hat man seine
Lektion gelernt.
Man sollte das KISS Prizip auch bei den nicht sichtbaren Features, im
Hinterkopf behalten.
Auch ein interessanter Gedanke: Wird es nach 6-12 Monaten Pause,
wirklich einfacher sein, sich in das aus dem Ärmel geschüttelte
"flexible System" wieder ein zu arbeiten, als eifnach die neuen Features
direkt rein zu coden?
Aber einer gewissen projektgröße birgt sicher auch das Risiko
langfristig auf die Nase zu fallen, aber man sollte es sich trotzdem
überlegen.
S. R. schrieb:> Das ist ganz einfach, statt '%' schreibst du '%n$', wobei n den> Argumentindex (gezählt ab 1) angibt:> printf("%02d.%02d.%04d", day, month, year);> printf("%1$02d.%2$02d.%3$04d", day, month, year);> printf("%3$04d-%2$02d-%1$02d", day, month, year);
Ok, kannte ich noch nicht. Das scheint aber kein ISO C zu sein, sondern
eine POSIX-Erweiterung. Von daher würde ich erstmal nicht davon
ausgehen, dass das auf einem µC auch verfügbar ist.
Alex G. schrieb:> Diese Alergie ist allerdings manchmal begründet. Als Programmieranfänger> neigt man stark dazu "großartige" Frameworks für triviale Features> einzusetzen.
Und wenn man ein zu gut durcharchitekturiertes Framework benutzt - wie
wir auf Arbeit - dann hat man damit einen auf Jahre hinweg nur
wachsenden, nicht wartbarenden Moloch geschaffen. Gut für die eigene
Arbeitsplatzsicherung, schlecht für Unternehmen und Kunde.
Rolf M. schrieb:> Das scheint aber kein ISO C zu sein, sondern> eine POSIX-Erweiterung. Von daher würde ich erstmal nicht davon> ausgehen, dass das auf einem µC auch verfügbar ist.
Das ist korrekt. Ich hab eben mal kurz in den Sourcen gewühlt und die
avr-libc unterstützt das auch tatsächlich nicht, die Newlib hingegen
schon.
Müsste man also auf dem Zielsystem einmal kurz austesten, wenn die
Unterstützung vorhanden ist, kann man sie nutzen. Ansonsten muss man mit
einer festen Reihenfolge der Argumente leben oder sich anderswo ein
passendes Template-System beschaffen.
S. R. schrieb:> Daraus ergeben sich die Randbedingungen, innerhalb derer du agieren> musst. Ohne passende Antworten darauf gibt es keine passende Lösung.
Ich verstehe. Also je nach Anwendung abzuwägen.
S. R. schrieb:> Stefan schrieb:>> Das sieht man oft. Auch ein Grund, wieso viele Geräte bei mir auf>> Englisch eingestellt sind.>> Das ist mit einem einsprachigen Image nicht möglich. Allein schon> deswegen würde ich zu mehrsprachigen Images raten, sofern möglich.
Das ist ein gutes Argument. So lässt man dem Benutzer offen, die
"ausreichend getestete" Sprache zu verwenden.
georg schrieb:> Mit Symbolnamen für die Strings und defines zu arbeiten ist mir zu> umständlich und zu fehleranfällig, der String selbst ist auch die> Adresse in der Datenbank.
Interessanter Ansatz! Danke für die Ausführungen.
Sebastian S. schrieb:> Bei uns würde jeder der sagt:> "Da brauchst Du doch nur am Quellcode rumfummeln", standrechtlich> erschossen.>> Wie gesagt:>> Ein Array ist, bei ein paar Textzeilen, die bei weitem effektivste>>>Lösung für Dein Problem.>> Ein weiterer, hier unter den Tisch gekehrter Vorteil der i18n-Lösung> ist, dass die Übersetzung auch von Nicht-Programmierern, also Leuten,> die nur die zwei Sprachen können, erledigt werden kann.
Das kann ich gut nachvollziehen. Nur ungern würde ich an
funktionierenden Sources "rumfummeln" wollen, um sprachliche Details zu
ändern. Das Argument, dass die Übersetzung von Nicht-Programmierern
durchgeführt werden kann (was vermutlich der Regelfall ist und mit dem
Übersetzungsbüro schon angesprochen wurde) ist auch nachvollziehbar.
Doch wahrscheinlich wird es schnell sehr aufwändig und fehleranfällig,
wenn man Details wie Pluralbildung, Datumsformat etc. auch auf eine
"Nicht-Programmierer-Ebene" bringen möchte.
Bei simpleren Übersetzungen würde ich nun auch die Array-Lösung (wie die
Beispiele oben) oder die Präprozessor-Variante mit einem separaten
"Sprach-File" verwenden, wenn eine speicheroptimierte Lösung gefordert
ist.
Freundliche Grüsse,
Stefan
Stefan schrieb:>> Das ist mit einem einsprachigen Image nicht möglich. Allein schon>> deswegen würde ich zu mehrsprachigen Images raten, sofern möglich.>> Das ist ein gutes Argument. So lässt man dem Benutzer offen, die> "ausreichend getestete" Sprache zu verwenden.
Vor allem erlaubt man Benutzern, mehrere Sprachen zu testen.
Insbesondere in größeren Firmen hat man immer den einen oder anderen
Ausländer (= Fremdmuttersprachler), der eine Übersetzung ganz nebenbei
testen kann. Bei sowas fallen die klassischen Fehler am billigsten auf.
Stefan schrieb:> Das Argument, dass die Übersetzung von Nicht-Programmierern> durchgeführt werden kann (was vermutlich der Regelfall ist und mit dem> Übersetzungsbüro schon angesprochen wurde) ist auch nachvollziehbar.
Ja, wobei man beachten muss, dass eine Übersetzung entweder sehr nah am
Original oder sinnvoll in den Kontext eingebettet werden kann. Im ersten
Fall bekommt man meist sehr hässliche Übersetzungen, in letzterem Fall
ist eine ungeplante Wiederverwertung meist schlicht falsch. Darauf
fallen auch Profis gerne rein, denn die kennen den Kontext nicht genau
genug.
Stefan schrieb:> Doch wahrscheinlich wird es schnell sehr aufwändig und fehleranfällig,> wenn man Details wie Pluralbildung, Datumsformat etc. auch auf eine> "Nicht-Programmierer-Ebene" bringen möchte.
Das hängt davon ab, wie komplex du das aufziehen möchtest. Eine
vollwertige Sprachgrammatik, die korrekt Sätze bilden kann, ist fast
immer unsinnig. Stattdessen würde ich Template-Strings benutzen, damit
kann man die meisten halbkomplexen Probleme erschlagen, ohne die
Übersetzer zu überfordern.
Irgendwo wirst du immer auf Probleme stoßen, die du nicht erwartet hast;
beispielsweise kennt Slowenisch neben Singular und Plural noch einen
Dual, oder eine Regierung verlangt plötzlich bestimmte Unterstützung für
alle >20 offiziellen Sprachen des Landes (Indien für Smartphones seit
2017).
Wichtig ist "testen, testen, testen".
Stefan schrieb:> Bei simpleren Übersetzungen würde ich nun auch die Array-Lösung (wie die> Beispiele oben) oder die Präprozessor-Variante mit einem separaten> "Sprach-File" verwenden, wenn eine speicheroptimierte Lösung gefordert> ist.
Die Array-Lösung kannst du auch bei speicheroptimierten Lösungen
benutzen. Du musst ja nicht alle möglichen Sprachen einkompilieren,
sondern nur die notwendigen Sprachen, also z.B. "en-de-fr" für DACH und
Frankreich, oder "en-fr-es" für Nordamerika und Kanada.
Zu guter Letzt solltest du auch nicht alles übersetzen, sondern nur die
normale Oberfläche. Debugmeldungen oder Servicemenüs sollten
sinnvollerweise immer Englisch sein. Das vereinfacht die Wartung und
Analyse von Problemen - aus diesem Grund ist der Linux-Kernel auch nur
einsprachig.
Stefan schrieb:> Interessanter Ansatz! Danke für die Ausführungen.
Den wichtigsten Vorteil habe ich garnicht erwähnt: da der deutsche Text
im Sourcefile steht, ist das Programm vollkommen lesbar. So etwas wie
print (string275) ist dagegen völlig unverständlich, besonders wenn es
sich um hunderte Texte handelt. Aber das ist wohl hier die allgemein
favorisierte Lösung.
Georg
georg schrieb:> Den wichtigsten Vorteil habe ich garnicht erwähnt: da der deutsche Text> im Sourcefile steht, ist das Programm vollkommen lesbar.
Deutsche Texte (oder auch Kommentare, Variablen- oder Methodennamen) im
Sourcefile sind für mich eher ein Grund zum brechen, programmiert wird
hier in Englisch. Aber das ist sicher Geschmackssache.
Mal davon abgesehen: Lesbar sollte das Programm auch so sein, sonst
machst du eh was falsch.
georg schrieb:> So etwas wie> print (string275) ist dagegen völlig unverständlich, besonders wenn es> sich um hunderte Texte handelt.
Wie gesagt: Wer ein Define oder Variable "string275" nimmt sollte
sowieso lieber die Finger von der Tastatur lassen.
Dominik S. schrieb:> Deutsche Texte (oder auch Kommentare, Variablen- oder Methodennamen) im> Sourcefile sind für mich eher ein Grund zum brechen
Die sind ja auch nicht für dich, sondern für die Arbeiter, die die
Maschinen bedienen. Du kannst meinetwegen stundenlang kotzen wenn dir
danach ist. Hauptsache du findest immer einen Grund andere
herunterzumachen.
Georg
georg schrieb:> Den wichtigsten Vorteil habe ich garnicht erwähnt: da der deutsche Text> im Sourcefile steht, ist das Programm vollkommen lesbar. So etwas wie> print (string275) ist dagegen völlig unverständlich,
Deutscher Text im Sourcefile ist völlig unverständlich, wenn der
Programmierer kein Deutsch versteht. Damit kämpft LibreOffice noch
immer, und die japanischen Kommentare auf Arbeit und im Bugtracker sind
auch nur eingeschränkt hilfreich.
Stattdessen sinnlose Bezeichner wie "string275" einzuführen, ist
ebenfalls eher ein Kündigungsgrund. Man kann IDs auch sprechende Namen
geben. Ein print_i18n(MSG_SAVEPROJECT) ist aussagekräftig genug.
Am besten sind allerdings die, die ihre Projekte ausschließlich nach
Codenamen oder Kollegen benennen. Unglaublich hilfreich. Oder Pokemon.
georg schrieb:>> Deutsche Texte (oder auch Kommentare, Variablen- oder Methodennamen) im>> Sourcefile sind für mich eher ein Grund zum brechen> Die sind ja auch nicht für dich, sondern für die Arbeiter, die die> Maschinen bedienen.
Seit wann liest ein Maschinenbediener denn die Quelltexte der
Maschinensteuerung? Der sieht die nie, und falls doch, kann er damit nix
anfangen.
S. R. schrieb:> Der sieht die nie, und falls doch, kann er damit nix> anfangen.
So was von Unverständnis ist ja schon krankhaft. Das sind Texte, die am
Bildschirm ausgegeben werden - aber da ist wohl jede Erklärung völlig
sinnlos. Glaubst du ernsthaft, eine Anweisung wie print ("Sind sie
sicher") ist ein Kommentar für Programmierer? Ganz offensichtlich bist
du keiner, wenn du nicht mal einfachste Anweisungen verstehst. Oder du
bist einfach bösartig und willst nur stänkern.
Also Schluss mit der Diskussion, an Pöbeleien beteilige ich micht nicht.
Schade, das war eigentlich eine ganz vernünftige Diskussion, aber es
findet sich halt immer jemand der das unbedingt kaputt machen will.
S. R. schrieb:> Der sieht die nie
Das ist ja schon intellektuell unterirdisch. Wer denn sonst?
Georg
georg schrieb:> S. R. schrieb:>> Der sieht die nie, und falls doch, kann er damit nix>> anfangen.>> So was von Unverständnis ist ja schon krankhaft. Das sind Texte, die am> Bildschirm ausgegeben werden - aber da ist wohl jede Erklärung völlig> sinnlos. Glaubst du ernsthaft, eine Anweisung wie print ("Sind sie> sicher") ist ein Kommentar für Programmierer? Ganz offensichtlich bist> du keiner, wenn du nicht mal einfachste Anweisungen verstehst. Oder du> bist einfach bösartig und willst nur stänkern.>> Also Schluss mit der Diskussion, an Pöbeleien beteilige ich micht nicht.> Schade, das war eigentlich eine ganz vernünftige Diskussion, aber es> findet sich halt immer jemand der das unbedingt kaputt machen will.>> S. R. schrieb:>> Der sieht die nie>> Das ist ja schon intellektuell unterirdisch. Wer denn sonst?>> Georg
o.O?
Du hast das völlig missverstanden.
Er sagte nur
> Deutsche Texte (oder auch Kommentare, Variablen- oder Methodennamen) im> Sourcefile sind für mich eher ein Grund zum brechen,
Also es geht um den Sourcecode und den sieht natürlich der Nutzer nicht.
Er hat nicht gesagt dass man keine übersetzten Texte an den Nutzer
ausgeben sollte...
Arrays fuer Strings gehen natuerlich nicht. Denn sonst muesste man eine
maximale Laenge vorgeben, und den Rest verplampern. Was aber effizient
waere ist ein Array mit Indices.
Also zB string[22] welcher dann umgebogen wird zu string_eng[22] und die
Strings sind jeweils ein Bandwurm, einen pro Sprache.
Alex G. schrieb:> Du hast das völlig missverstanden.
Da gibt es nichts misszuverstehen. Ich gebe deutsche Texte an den
Bediener der Steuerung aus, und das findet man hier zum Kotzen. Mal ganz
abgesehen davon dass das Kunden wie Ford oder Daimler ganz
selbstverständlich verlangen, die akzeptieren in ihrem Messlabor keine
Steuerungen mit englischer Bediensoftware.
Das hier war ein interessanter Thread, bis er geentert wurde um mit Hass
und Beleidigungen um sich zu werfen. Für mich ist das Thema damit
erledigt, es ist völlig unzumutbar, eine bewährte Software sachlich zu
erklären, wenn man dafür nur mit völlig hirnrissigen Behauptungen
niedergemacht wird. Leider ist das längerfristig das Schicksal fast
aller Threads in diesem Forum.
Natürlich ändere ich auch keinesfalls eine seit vielen Jahren bewährte
Software nur weil sie hier im Forum als totaler Mist beurteilt wird, das
ist für mich völlig irrelevant, weil es sowieso unmöglich ist eine
Software zu schreiben die hier nicht heruntergemacht wird. Massgebend
sind in jedem Fall die Kunden, nicht die Pöbler hier im Forum.
Georg
Plörensauger schrieb:> Arrays fuer Strings gehen natuerlich nicht. Denn sonst muesste man eine> maximale Laenge vorgeben, und den Rest verplampern. Was aber effizient> waere ist ein Array mit Indices.> Also zB string[22] welcher dann umgebogen wird zu string_eng[22] und die> Strings sind jeweils ein Bandwurm, einen pro Sprache.
Ist das nicht schon automatisch so?
Z.B. in meinem Beispiel ist es ein Array aus char-referenzen die jeweils
den Anfang des Strings darstellen.
@georg
Nein, lies dir nochmal durch was geschrieben wurde.
"Zum kotzen" war auch, auf sourcecode vieleicht übertrieben aber seltsam
ungewohnt ist das schon. Kann ich bestätigen.
Plörensauger schrieb:> Arrays fuer Strings gehen natuerlich nicht. Denn sonst muesste man eine> maximale Laenge vorgeben, und den Rest verplampern.
Wenn die Strings zur compile-time fest stehen (z.B. "ein text") wird
hier kein Platz verschwendet. Ein "String-Array" ist in C ja nur ein
Array von Pointern auf Strings (und die liegen an anderer Stelle und
belegen eben nur so viel Platz wie nötig).
georg schrieb:> Da gibt es nichts misszuverstehen. Ich gebe deutsche Texte an den> Bediener der Steuerung aus, und das findet man hier zum Kotzen.
Nein, tut man nicht. Les' doch einfach nochmal nach was ich oben
geschrieben habe.
Dominik S. schrieb:> Deutsche Texte (oder auch Kommentare, Variablen- oder Methodennamen) im> Sourcefile
"Im Sourcefile", nicht in der GUI.
Dominik S. schrieb:> programmiert wird> hier in Englisch
Zusätzlich schrieb ich ich, dass in Englisch programmiert wird. Ich habe
sogar dazu geschrieben, dass auch das Geschmacksache ist. Das die GUI
übersetzt werden muss steht doch außer Frage.
Ich verstehe nicht, dass du jetzt einen auf eingeschnappte Leberwurst
machst nur weil du etwas falsch verstanden hast.
Dominik S. schrieb:> Plörensauger schrieb:>> Arrays fuer Strings gehen natuerlich nicht. Denn sonst muesste man eine>> maximale Laenge vorgeben, und den Rest verplampern.>> Wenn die Strings zur compile-time fest stehen (z.B. "ein text") wird> hier kein Platz verschwendet. Ein "String-Array" ist in C ja nur ein> Array von Pointern auf Strings
Für ein "String-Array" gibt es zwei Möglichkeiten: Man kann entweder ein
Array aus char-Arrays machen, dann ist aber jedes Element so lang wie
der längste String, da alle Elemente gleich groß sein müssen, oder man
macht ein Array aus Zeigern, dann braucht man den zusätzlichen Platz für
diese Zeiger.
Alex G. schrieb:> "Zum kotzen" war auch, auf sourcecode vieleicht übertrieben aber seltsam> ungewohnt ist das schon. Kann ich bestätigen.
Ich habe früher im Praxissemester an Code arbeiten müssen, an dem schon
andere Studenten vor mir gearbeitet hatten. Die Kommentare und
Variablen- und Funktionsnamen waren in einem Mix aus Deutsch, Englisch
und Spanisch verfasst. Immerhin verstand ich zwei von den drei Sprachen.
Wenn ich nicht schon vorher beschlossen hätte, dass es sinnvoll ist, das
alles grundsätzlich in Englisch zu machen, wäre ich dadurch dazu bekehrt
worden.
georg schrieb:> Da gibt es nichts misszuverstehen. Ich gebe deutsche Texte an den> Bediener der Steuerung aus, und das findet man hier zum Kotzen.
Wenn in deinem Fall der "Bediener der Steuerung" gleichzeitig die Person
ist, die am Quelltext der Steuersoftware rumfuhrwerkt, dann hast du
Recht. Das ist so gut wie nie der Fall.
Dass in einem Messlabor (also da, wo Forschung und Entwicklung betrieben
wird!) keine englischsprachige Software akzeptiert wird, halte ich zudem
im Allgemeinen (und insbesondere bei Großkonzernen) für Unfug.
Aber reg dich nur weiter auf.
S. R. schrieb:> Dass in einem Messlabor...
Naja, also nach meiner Erfahrung ist das so, daß je kleiner das Land
ist, desto mehr achten die Kunden darauf, daß gerade ihre Sprache
implementiert ist. Noch verrückter ist es in der Schweiz, dort bestehen
die Leute in Genf auf französisch, obwohl sie dort fast alle auch
deutsch verstehen.
Bei den Quellen und den dortigen Kommentaren auf englisch bestehen zu
wollen, halte ich hingegen für völlig albern. Bei mir hat sich da eine
Art Halb-Denglisch mit der Zeit eingestellt. Sowas sollte man locker
sehen. Wer da von kotzen schreibt, zeigt nur die Dicke seines Brettes
vor'm Kopf.
Aber offenbar haben viele Leutchen die Ansicht, daß es chic sei, sich
englisch oder wenigstens denglish auszudrücken. Man beweist damit seine
"Weltmännischkeit" und empfindet die eigene Muttersprache als viel zu
provinziell.
OK, wenn wir ein kleines Völkchen mit einer abstrusen Sprache wären,
dann wäre der Hang zur Verkehrssprache zu verstehen, aber das trifft
auf's Deutsche nicht zu. Ich will jetzt nicht den bayrischen Kampfruf in
solchen Sachen zitieren, der findet in Berlin nur wenig Anklang.
W.S.
W.S. schrieb:> Naja, also nach meiner Erfahrung ist das so, daß je kleiner das Land> ist, desto mehr achten die Kunden darauf, daß gerade ihre Sprache> implementiert ist.
In meiner Erfahrung ist das alters- und umgebungsabhängig, die ältere
Generation besteht hier im Allgemeinen auf Schwedisch. Jüngere (und/oder
höher Gebildete) bevorzugen die zusätzliche Freiheit, wenn man sich
darauf nicht festnageln will, oder sind die manchmal unhandlichen
Übersetzungen einfach leid. ;-)
W.S. schrieb:> Bei den Quellen und den dortigen Kommentaren auf englisch bestehen zu> wollen, halte ich hingegen für völlig albern.
Das ist in dem Augenblick notwendig, wo die Sprache nicht von jedem
Entwickler verstanden wird. Wer sich in einem rein deutschsprachigen
Kleinunternehmen auf "Deutsch und Pascal" spezialisiert, kann auch damit
seinen Gewinn erzielen. Die zusätzlichen Möglichkeiten, die "Englisch
und C" bieten würden, sind vermutlich zu dem Zeitpunkt irrelevant. Für
die Zukunft muss das aber nicht gelten, siehe StarOffice.
W.S. schrieb:> OK, wenn wir ein kleines Völkchen mit einer abstrusen Sprache wären,> dann wäre der Hang zur Verkehrssprache zu verstehen, aber das trifft> auf's Deutsche nicht zu.
Hängt halt davon ab, mit wem man kommunizieren können möchte.
Rein deutscher Quelltext mit rein deutscher Dokumentation führt halt
eher dazu, dass der Kopierchinese damit nichts anfangen kann. Aber der
Amerikaner, der eine US-Zertifizierung durchführen soll, auch nicht.
Ich seh das nicht ganz so verbissen wie Dominik, stimme aber inhaltlich
vollumfänglich zu. Bin aber auch ein gebranntes Kind.
S. R. schrieb:> ... Schwedisch. Jüngere (und/oder> höher Gebildete) bevorzugen die zusätzliche Freiheit...
Da hast Du aber den großen Bonus, dass die Schweden aufgrund ihres
Fernsehprogramms - viele ausländische Filme laufen in Originalsprache
mit schwedischem Untertitel - schon gut auf Englisch trainiert sind.
Ich bin immer wieder erstaunt bis erschrocken, wie bescheiden Englisch
selbst bei jungen Leuten im europäischen Ausland vorhanden ist.
Frankreich blamabel, Italien nix, Polen eher noch Deutsch und in
Tschechien haben sie letztens das Handy mit Google Translate rausgeholt.
Ham die das nicht in der Schule?
S. R. schrieb:> Rein deutscher Quelltext mit rein deutscher Dokumentation führt halt> eher dazu, dass der Kopierchinese damit nichts anfangen kann.
Der Kopierchinese kann Google Translate auch umgekehrt benutzen. Oder
was glaubst Du, wie die "Produktbeschreibungen" der Chinahändler bei
Amazon zustande kommen?
Thread beobachten
Seitenaufteilung abschalten