Hallo Leute,
nun möchte ich ein Prog schreiben in dem man auch eine Spracheinstellung hat.
Ich will wie folgt vorgehen:
Im Exe-Verzeichnis werden einzelne Sprachdateien und eine Datei mit Programmeinstellungen abgelegt. Beim Start wird die Einstellungen Datei ausgelesen und abhängig von der Spracheinstellung die eine oder die andere Sprachdatei geladen. Dann werden die Controls(über Properties) in einer For-Schleife mit dem richtigen Capture versehen. Wie sieht es mit boolschen Elementen aus, da gibt es den ON/OFF Text. Dazu gibt es ja auch einen Property. Ok. Oder auch Skalenbeschriftungen. Ist es besser die Controls über Label zu identifizieren oder reicht schon eine For-Schleife, denn die Numerierung(Reihenfolge) bleibt ja immer gleich.
Alles kein Problem, nun wie macht ihr das? Gibt es vielleicht andere Wege um sowas zu machen?
Danke, eg
Hallo, Eugen,
im Prinzip mache ich das genau so, wie du es beschreibst. Sprich, es gibt bei mir mehrere Sprachdateien, in denen alle relevanten Texte für eine Sprache drinstehen. Die lade ich dann in eine FGV, je nach Voreinstellung (Parameter in einer Setup-Datei) bzw. nach User-Auswahl (ja, bei mir kann das der User auch noch zur Laufzeit ändern).
Dann werden alle Texte per Property-Node gesetzt. Du kommst an alle Texte per Property-Node dran: Captions für Bezeichnungen von Variablen (nicht vergessen, immer "Label" verstecken und "Caption" anzeigen), bei Bool-Controls nimmst du die Property Node "Strings[]", auch an die Achsenbezeichnungen, Plot-Namen usw. kommt man dran. Einzig freie Labels erfordern etwas mehr Aufwand. Aber die kann man ja auch durch einen String-Indikator ersetzen.
Ich würde zwecks besserer Lesbarkeit des Programmcodes jede Property-Node einzeln mit Variablennamen erstellen und auf For-Schleifen verzichten (Falls du hier mit deiner Frage die Property-Node gemeint hast, mit der man die Referenz auf alle FP-Elemente bekommt). Wenn du mal ein neues Control-Element auf dem FP hinzufügst, ändert sich nämlich die Reihenfolge. Das neue Element wird nämlich am Anfang der FP-Elemente-Referenz-Liste hinzugefügt.
MfG, Jens
' schrieb:Hallo, Eugen,
im Prinzip mache ich das genau so, wie du es beschreibst. Sprich, es gibt bei mir mehrere Sprachdateien, in denen alle relevanten Texte für eine Sprache drinstehen. Die lade ich dann in eine FGV, je nach Voreinstellung (Parameter in einer Setup-Datei) bzw. nach User-Auswahl (ja, bei mir kann das der User auch noch zur Laufzeit ändern).
Der Vorschlag mit FGV und Änderung zur Laufzeit ist gut. Wie sehen denn die Sprachdeiteien aus, wie sind diese am besten zu organisieren. Diese mussen bei mir von User editierbar sein. Ich denke an INI-Dateien, ist es ok? Oder besser Tabellendatei mit Label-Caption.
' schrieb:Dann werden alle Texte per Property-Node gesetzt. Du kommst an alle Texte per Property-Node dran: Captions für Bezeichnungen von Variablen (nicht vergessen, immer "Label" verstecken und "Caption" anzeigen), bei Bool-Controls nimmst du die Property Node "Strings[]", auch an die Achsenbezeichnungen, Plot-Namen usw. kommt man dran. Einzig freie Labels erfordern etwas mehr Aufwand. Aber die kann man ja auch durch einen String-Indikator ersetzen.
Das man an alle Texte über Props kommt ist klar, aber noch mal die Frage wie sind diese am besten zu organisieren? Man könnte z.B. am Label erkennen um welche Art des Controls oder Indicators es sich handelt, in dem man z.B. alle boolschen Labels mit einem Präfix "b_" versieht, oder ist es schon zu viel? Ich meine der Präfix stört dem User zu übersetzen. Ich wollte eine Art Wörterbuch machen:
Label(engl) - Caption(seine Sprache)
' schrieb:Ich würde zwecks besserer Lesbarkeit des Programmcodes jede Property-Node einzeln mit Variablennamen erstellen und auf For-Schleifen verzichten (Falls du hier mit deiner Frage die Property-Node gemeint hast, mit der man die Referenz auf alle FP-Elemente bekommt). Wenn du mal ein neues Control-Element auf dem FP hinzufügst, ändert sich nämlich die Reihenfolge. Das neue Element wird nämlich am Anfang der FP-Elemente-Referenz-Liste hinzugefügt.
MfG, Jens
Gut zu wissen dass sich die Reihenfolge doch ändert. Dann wäre es vielleicht doch besser über Labels zu arbeiten? Ich will auch nicht unbedingt für jedes Element einen Property Node erstellen, ich will bissel flexibler sein.
Eine andere Frage, werde ich mit japanischer Sprache Probleme bekommen? Ich meine es ist doch Unicode-Sprache und nicht die normale 1-Byte Sprache bzw. Schriftart.
Danke schön, Eugen
' schrieb:Der Vorschlag mit FGV und Änderung zur Laufzeit ist gut. Wie sehen denn die Sprachdeiteien aus, wie sind diese am besten zu organisieren. Diese mussen bei mir von User editierbar sein. Ich denke an INI-Dateien, ist es ok? Oder besser Tabellendatei mit Label-Caption.
Ini-Datei ist wahrscheinlich nicht schlecht, könnte es bei sehr vielen Texten aber etwas unübersichtlich machen. Ich hab mir was eigenes einfallen lassen, erst kommt bei mir eine Zahl, dann ein Bezeichner und dann erst der wahre Sprachtext. Zahl und Bezeichner sind natürlich in allen Dateien identisch, aber es macht das ganze übersichtlich
' schrieb:Das man an alle Texte über Props kommt ist klar, aber noch mal die Frage wie sind diese am besten zu organisieren? Man könnte z.B. am Label erkennen um welche Art des Controls oder Indicators es sich handelt, in dem man z.B. alle boolschen Labels mit einem Präfix "b_" versieht, oder ist es schon zu viel? Ich meine der Präfix stört dem User zu übersetzen. Ich wollte eine Art Wörterbuch machen:
Label(engl) - Caption(seine Sprache)
Ich würde sagen, dass musst du dir selber überlegen, wie es für dein Projekt am besten passt. Finde, da gibt es keine Vorgabe. Das mit Präfixes ist sicherlich eine nette Idee. Bei mir ist halt nicht unbedingt daran gedacht, dass der User selber was editiert, deshalb habe ich mir da keine so großen Gedanken gemacht.
' schrieb:Gut zu wissen dass sich die Reihenfolge doch ändert. Dann wäre es vielleicht doch besser über Labels zu arbeiten? Ich will auch nicht unbedingt für jedes Element einen Property Node erstellen, ich will bissel flexibler sein.
Tja, kommt halt darauf an, ich finde, mit Property-Node für jedes Element ist der Code besser zu debuggen und besser lesbar, aber das musst du für dich selber entscheiden.
' schrieb:Eine andere Frage, werde ich mit japanischer Sprache Probleme bekommen? Ich meine es ist doch Unicode-Sprache und nicht die normale 1-Byte Sprache bzw. Schriftart.
Da muss ich passen, ehrlich gesagt, keine Ahnung.
MfG, Jens
P.S.: Übrigens, Menüs, die von LV selber kommen (z.B. die Plot-Einstellungsmenüs usw.) richten sich ab LV8 bei Vollinstallation des RuntimeEngines nach den Ländersettings von Windows. Man kann das aber in der ini-Datei des entsprechenden Programms ändern, einfach die Zeile "AppLanguage=German" einfügen.
Vielleicht kann man es noch allgemeiner machen. In LV gibt es ja eine Such-Funktion für Strings. Könnte man auf diese zugreifen und die Strings einfach ersetzen? Ich glaube nicht, aber wer weiss.
Kennst du OpenG-Dictionary ? Was ist es?
eg
' schrieb:Vielleicht kann man es noch allgemeiner machen. In LV gibt es ja eine Such-Funktion für Strings. Könnte man auf diese zugreifen und die Strings einfach ersetzen? Ich glaube nicht, aber wer weiss.
Ach so, noch allgemeiner, sozusagen als global einsetzbares "Sprach-Setz-Tool". Das könnte schon hinhauen, wird aber bestimmt nicht ganz ohne.
Könnte mir da folgenden Ansatz vorstellen (noch sehr unausgegoren, nur so eine spontane Idee):
1. Per FP-Propertynode holt man sich die Referenz auf alle Controls (oder alle FP-Elemente).
2. Dann geht es natürlich in einer For-Schleife weiter.
3. Jetzt die Crux, wie stelle ich fest, was für eine Art von Control-Element habe ich den vorliegen, denn bei Bedarf muss ja die "allgemeine Control-Referenz" meinetwegen auf eine "Waveform-Graph"-Referenz geändert werden. Das könnte man damit erledigen, dass man bei der Vergabe der Labels eine eigene Konvention verfolgt (z.B. wie von dir vorgeschlagen, Button-Labels beginnnen mit b_, Numerics mit n_, ...). Aus der "allgemeinen Control-Referenz" kann man dann das Label lesen, dann entsprechend Referenz umändern, und dann bei Bedarf die entsprechenden Labels und zusätzlichen Beschriftungen ändern. Zwecks Zuordnung zum externen Textfile muss man sich da auch noch was Sinnvolles überlegen.
MfG, Jens
' schrieb:Ach so, noch allgemeiner, sozusagen als global einsetzbares "Sprach-Setz-Tool". Das könnte schon hinhauen, wird aber bestimmt nicht ganz ohne.
Könnte mir da folgenden Ansatz vorstellen (noch sehr unausgegoren, nur so eine spontane Idee):
1. Per FP-Propertynode holt man sich die Referenz auf alle Controls (oder alle FP-Elemente).
2. Dann geht es natürlich in einer For-Schleife weiter.
3. Jetzt die Crux, wie stelle ich fest, was für eine Art von Control-Element habe ich den vorliegen, denn bei Bedarf muss ja die "allgemeine Control-Referenz" meinetwegen auf eine "Waveform-Graph"-Referenz geändert werden. Das könnte man damit erledigen, dass man bei der Vergabe der Labels eine eigene Konvention verfolgt (z.B. wie von dir vorgeschlagen, Button-Labels beginnnen mit b_, Numerics mit n_, ...). Aus der "allgemeinen Control-Referenz" kann man dann das Label lesen, dann entsprechend Referenz umändern, und dann bei Bedarf die entsprechenden Labels und zusätzlichen Beschriftungen ändern. Zwecks Zuordnung zum externen Textfile muss man sich da auch noch was Sinnvolles überlegen.
MfG, Jens
Super, ich habe gewusst, dass da was interessantes rauskommt. Ich glaube ich werde es ungefähr so machen.
Ich werde mir ein Wörterbuch erstellen und dann alle Elemente nach Gruppe sortiert mit einer For-Schleife durchlaufen lassen und umbenennen.
Danke für die tolle Hilfe, eg
find ich krass, was ihr da vor habt. ich glaube es ist zu viel verlangt, aber könnt ihr evtl. mal von eurer Lösung ein kleines abgespecktes Beispiel-VI posten. Würde mich tierisch interessieren wie profis so ein problem lösen.
' schrieb:find ich krass, was ihr da vor habt. ich glaube es ist zu viel verlangt, aber könnt ihr evtl. mal von eurer Lösung ein kleines abgespecktes Beispiel-VI posten. Würde mich tierisch interessieren wie profis so ein problem lösen.
Hier mein Anfang. Jens will es ein wenig anders machen.
eg
P.S. gut, dass sich noch jemand ausser mich und Jens dafür interessiert.