4. Sprachen-Umschaltung

Sprachen-Umschaltung

  • A

    Ich möchte über einem Button von Deutsch auf Italienisch umschalten.
    Es geht dabei nicht um Datum, Währung und ähnliches,
    sondern nur um den Text.
    Wo finde ich entsprechende Informationen?
    Gruß, Harald

    0
  • J

    Schau mal im BCB im Menü unter Projekt->Sprachen.
    Zusätzlich kannst du dir auch das Beispiel zu RichEdit anschauen (BCB-DIR\Examples\Apps\RichEdit)

    0
  • K
    Mod

    Hallo

    ich habe gerade fuer einen Kunden eine Sprachumschaltung in ein BCB Programm eingebaut.

    Die Frage ist hier ganz klar -> nur in eine Sprache oder in mehrer
    wenn dir alle Sprachen, in die du Umschalten willst, bekannt sind
    ganz mein Vorredner (Recource usw) ansonsten auslagern in eine externe Datei.
    Diese Datei kann von jedem an die gewuenschte Sprache angepasst werden
    und das ohne das Programm neu zu uebersetzten.

    (echte Sprachumschaltung oder nur Flip/Flop)

    MfG
    Klaus

    0
  • A

    Echte Sprachumschaltung!
    mehrere Sprachen, also auslagern!
    Aber wie?

    0
  • ?

    hallo,

    ich schlage dir vor, mach eine komponente welche sich die fähigkeiten der rtti zu nutze macht. wir haben eine solche kompo, darf ich aber nicht weggeben wegen des copyrights. man kann damit beliebig viele sprachen verwenden, sind in script-dateien vorhanden:
    ;Skriptdatei:
    [german]
    BezLabel->Caption = 'Tastatur'

    [english]
    BezLabel->Caption = 'Keyboard'

    die kompo selber ist eine zur laufzeit unsichtbare wie zb timer. sie verfügt über zwei events: OnTranslate, OnCreate und vier propertys: language, name, script, tag. sie wurde also direkt von tcomponent abgeleitet und besteht aus ca. 300 zeilen code (dann kommt noch etwas dazu, um das ding perfekt in die ide zu integrieren, wie z. b. ein spezieller property-editor, etc, aber das zeug braucht man im prinzip nicht so dringend).
    unseren code darf ich wie gesagt nicht weitergeben, aber ich habe im netz des öfteren schon ähnliche kompos gesehen (auf diese weise entstand auch unsere, abgeschaut, erweitert, verfeinert :-).
    mfg
    m

    0
  • K
    Mod

    Hallo

    anderer Ansatz

    - jeder Text bekommt eine Nummer
    - zB deutsch.lng -> Text 1- Text xxx
    - -> englisch.lng
    - im Programm Texte aus Ini einlesen

    MfG
    Klaus

    0
  • W

    Ohne groß zu parsen hab ich noch eine einfache Möglichkeit für dich. Mach dir eine Struktur:

    struct TTranslation
{
   AnsiString textGerman;
   AnsiString textEnglish;
   AnsiString textFrench;
   ...
};

    Fülle für jedes Control mit Text, der übersetzt werden soll eine solche Struktur (auf dem Heap) aus und weise diese der Tag-Property des Controls zu:

    TTranslation* t = new TTranslation;
t->textGerman = "Öffnen";
t->textEnglish = "Open";
t->textFrench = "Ouvre";

btnOpen->Tag = (int*)t;

    Wenn jetzt übersetzt werden soll, einfach

    TTranslation* t = (TTranslation*)Button1->Tag;
btnOpen->Caption = t->textEnglish;

    machen. Eine neue Komponente wäre aber die schönere Lösung. Würd ich so machen. Vor allem ist sowas wiederverwendbar.

    0
  • J

    ...nur schade, dass zu der Compilezeit bei der Methode wieder bekannt sein muss, welche Sprachen verwendet werden solle? (:

    Ich persönlich würde den Weg über eine Resourcen DLL gehen und jeden auch noch so kleinen String aus den Resourcen laden. Dank tollen Funktion wie AnsiString::Format, etc. lässt sich damit was nettes flexibles gestalten.

    -junix

    0
  • W

    Also ich finde den Vorschlag von Klaus am besten, hab's selber schon auf die Art mit Ini-Dateien gemacht. Eine Resourcen-DLL kann ich niemanden schicken zum Übersetzen oder Korrigieren, eine Ini-Datei kann aber der Programm-User z.B. in Italien selber korrigieren ohne dass der Programm-Entwickler hier nochmal Hand anlegen muß.

    Gruß WoWe

    0
  • J

    Original erstellt von WoWe:
    Eine Resourcen-DLL kann ich niemanden schicken zum Übersetzen oder Korrigieren

    Du schickst dem Übersetzer einfach die Quell-Datei also z.B. eine .rc-Datei. Wem willst du denn das Verändern der Software nun überlassen? Dir selbst oder dem Enduser? Dann baut der Enduser scheisse, deine Software läuft nicht mehr richtig und dann find DA mal den fehler.

    Original erstellt von WoWe:
    eine Ini-Datei kann aber der Programm-User z.B. in Italien selber korrigieren

    ....ach du gehörst auch zu denen, welche den Final-Review der Software vom Endnutzer machen lassen, ja? (-;

    -junix

    0
  • K
    Mod

    Hallo

    @junix

    was machst du denn, wenn ein Kunde (zum Weitervetrieb) bei dir eine Software bestellt, die Weltweit in allen (???) Sprachen verwendet wird.

    Wenn du da bessere Loesungen siehst -> heraus damit 😉

    Deinem Einwand "alle Sprachen" setzte ich dagegen "natuerlich alle Sporachen die
    nicht wie Japanisch usw aufgebaut sind

    MfG
    Klaus

    0
  • W

    Hallo junix,

    welche Schuhgröße hast'n du 😃

    Das Verändern der Software liegt überhaupt nicht im Möglichen des Endusers. Aber es ist durchaus normal dem User die Möglichkeit zu bieten, die Labels und Menupunkte vom Text her selbst zu bestimmen, deswegen läuft das Programm trotzdem, auch wenn da in einem Label mal was unpassendes steht. Das Abfangen von Steuerzeichen, die evtl. in der Ini-Datei stehen können, kann man ja ins Programm einbauen bzw. irgendwelche Default-Text wenn der String zu lang ist etc. Aber flexibler als 20 mal neu compilieren ist es allemal, es sei denn du bist dir aller Sprachen mächtig und diktierst die Texte.

    Gruß WoWe

    0
  • ?

    Erst einmal vielen Dank für die vielen Tips. Muss ich erst einmal verarbeiten.
    Folgendes Problem habe ich allerdings:
    Es handelt sich um die Bedienungsoberfläche einer Verpackungsmaschine.
    Ein Service-Techniker der von Deutschland nach Italien fährt,
    möchte die Anzeige auf Deutsch umschalten, ohne das Programm neu zu starten.
    Bei Vorführungen auf Messen, möchte man mehrere Sprachen auswählen können.
    Es sollten also alle Sprachen möglichst immer vorhanden sein.
    Speicherplatz ist reichlich vorhanden!
    Gruß, Harald

    0
  • ?

    hallo,

    wie hier bereits erwähnt wurde, "sprachen müssen zur compilierzeit feststehen", das ist beim ansatz über die rtti (run time type information) nicht der fall.
    bei unserer kompo kann ich beliebig neue sprachen hinzufügen und entfernen, ohne die anwendung neu compilieren zu müssen. auch finde ich bei einigen der genannten möglichkeiten den aufwand viel zu brutal, man stelle sich mal eine mittelgroße anwendung mit ca. 70 000 zeilen quelltext und vielen forms und vielen oberflächenelementen vor, da würde mir persönlich das gausen kommen. bei meienr anwendung platziere ich lediglich die kompo auf dem form, fertig.
    alles andere steht in der skript-datei, und wie gesagt, wenn ich nach fertistellen der anwendung auf die idee komme, au englisch könnte ich auch noch einbauen, dann mache ich einfach:

    [english]
    Label1->Caption = 'drawing'
    Label1->Hint = 'draw-mode'

    ohne den ganzen quelltext kompilieren zu müssen, ohne gar nix kompilieren zu müssen, muß lediglich das skript speichern. es ist ja so, wenn die sprachvielfalt, zusätzlich noch im gesamten quelltext zu sehen ist wird alles noch komplitzierter zu lesen und neue fehler schleichen sich ein.
    und was macht webfritzi z. b. bei showmessage und messagedialogen etc. bei der kompo ist die so realisiert:
    skript:
    [german]
    showmsg_except_filenotfound = 'datei konnte nicht geöffnet werden, evtl. nicht vorhanden'
    [english]
    showmsg_except_filenotfound = 'file can'nt open, perhaps not exists'
    code:
    ShowMessage(MyLanguage->GetValue('showmsg_except_filenotfound'));

    was in der kompo allerdings nicht enthalten ist, das sind die systemeigenen einstellungen wie z. b. die standarddialoge, da müsste man sich was einfallen lassen, aber das problem ist bei allen hier vorgestellen lösungen auch vorhanden...

    murph

    0
Anmelden zum Antworten