Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi nonVCL Anwendung lokalisieren (https://www.delphipraxis.net/143699-nonvcl-anwendung-lokalisieren.html)

Mithrandir 21. Nov 2009 11:31


nonVCL Anwendung lokalisieren
 
Hi ihr,

es geht um SmallTune. Ich möchte die Anwendung gerne lokalisieren/übersetzen. Da ich sowas von Anfang an geplant habe, war ich schlau und habe alle Strings im Programm als "Resourcestrings" definiert. Dann dachte ich mir, ich nutze dxgettext, und alles wird gut. :)

Leider habe ich mich zu früh gefreut. DXGetText nutzt exzessiv SysUtils und Classes, bekanntlich Gift für jede nonVCL-Anwendung. Hat jemand eine Idee (gerade die, die sonst mit nonVCL arbeiten), wie man sonst einfach eine Übersetzung hin bekommt, bei der man auch noch zur Laufzeit die Sprache ändern kann und trotzdem die RES-Strings noch nutzen kann?

himitsu 21. Nov 2009 11:45

Re: nonVCL Anwendung lokalisieren
 
Wenn du die Stringresourcen selber anlegst, dann kannst du dir aussuchen, von wo du sie lädst

z.B. von einer DLLs mit den übersetzen Resourcen und da Resourcen auch mit eine LangID versehen sind, könnte man auch mehrere Versionen in einer EXE/DLL ablegen und müßte dann nur noch die passende Sprach-Version laden.

kannst ja gern mal in meinem alten Hier im Forum suchenFileSplitter nachschauen, ob du da was verwenden kannst.

Mithrandir 21. Nov 2009 11:55

Re: nonVCL Anwendung lokalisieren
 
Ich überlege die ganze Zeit, ob ich die dxgettext nicht so zerpflücken kann, dass ich die mo/po-Dateien doch noch nutzen kann... :gruebel:

@himi: Danke, werde mal gucken... :)

himitsu 21. Nov 2009 12:21

Re: nonVCL Anwendung lokalisieren
 
Das dort ist aber ein eigenentwickeltes System
und die ganzen Texte/Resourcen sind manuell übersetzt
(k.A. ob man das auf die mo/po-Datei erweitern kann ... weiß garnicht, wie es mit diesen genau funktioniert)

Im Prinzip hab ich mir LoadString und die anderen Resourcen-Funktionen so erweitert, daß sie entpsrechend der Spracheinstellung die passenden Resourcen laden.
Es wurden auch die Fenster ala MSDN-Library durchsuchenCreateDialog übersetzt.


Hier bin ich in etwa den Weg von Delphi gegangen:
http://www.delphipraxis.net/internal...t.php?t=164238
Dort liegen alle Texte in einer Unit, wo dann vor dem Kompilieren die Unit getauscht würde.

Mithrandir 21. Nov 2009 12:38

Re: nonVCL Anwendung lokalisieren
 
Hm, ok, dann muss ich nochmal nachhaken und ausholen:

Ich möchte, dass der Benutzer selbst eigene Übersetzungen erstellen kann. Dafür bekommt er die englische Originalübersetzung in welcher Weise auch immer mitgeliefert. Es wäre also sinnig, wenn die Strings aus einer Datei ausgelesen werden könnten. Und wenn der Benutzer dann zur Laufzeit die Sprache ändert, müsste ich nur den Inhalt der Resourcestrings austauschen, oder?*

Wobei ich dann aber das Gefühl habe, wieder bei einem eigenen System zu landen... :? Zumal ich dann auch allen Fenstern (Buttons, Labels, etc.) manuell denn neuen Inhalt zuweisen müsste, wenn ich einen Neustart der Anwendung verhindern will, oder?

//Edit:
*Is natürlich Schwachsinn, ich kann ja schlecht eine laufende Exe ändern...
:wall:

himitsu 21. Nov 2009 13:16

Re: nonVCL Anwendung lokalisieren
 
Du könntest aber beim Laden der Texte entscheiden
- Texte aus Resourcen
- oder Texte externer Datei

turboPASCAL 21. Nov 2009 15:15

Re: nonVCL Anwendung lokalisieren
 
Zitat:

Ich überlege die ganze Zeit, ob ich die dxgettext nicht so zerpflücken kann ...
Das braucht du nicht und dxgettext auch nicht.
:P

Zitat:

Zitat von himitsu
Du könntest aber beim Laden der Texte entscheiden
- Texte aus Resourcen
- oder Texte externer Datei

Genau.

Die Übersetzungen kommen in eine oder mehrere Ini.-Dateien.
Man kann natürlich auch die Hauptsprachen (zB.: en & de) in die Exe mit aufnehmen.
Der Rest kommt dann ebend in dem entsprechende Inifiles mit meinetwegen ländersp. Extensionen oder der gleichen.

Man kann nun mit Hilfe von, wie hiess das :gruebel: , GetSysLanguageName die Systemsprache ausspionieren und diese, falls
vorhanden laden.

Mithrandir 21. Nov 2009 15:34

Re: nonVCL Anwendung lokalisieren
 
Japp, so dachte ich mir das jetzt auch. Und der Übung wegen schreibe ich mir dafür einen kleinen Parser, der das Format liest, was ich mir da zusammengefrickelt habe:

Delphi-Quellcode:
// Translation File for SmallTune
// Language: German
// Author: Daniel Gilbert
// Mail: [email]xxx@yyyyyyyy.zzz[/email]

// Must match Application Minor Version
// e.g. "0.3" will work for SmallTune 0.3.0, SmallTune 0.3.1, SmallTune 0.3.2 and so on, but not SmallTune 0.4.0...
TRANS_FILE_VERSION=0.3;

//Short Description:
//
//The default Format is:
//
//index:'Text';
//
//In case you need a ' in your text (e.g.: isn't), you can write it like this:
//
//0:'This isn''t a problem';
//
//In case you need a linebreak, this can be done this way:
//
//0:'This is the first line' + #13#10 + 'this is the next line';
//
// NEVER EVER change the index and the line order. Doing so will result in an error and the language won't be loaded

//Windows XP or NT 4.0 needed!
0:'Windows XP or NT 4.0 needed!';
//[Playing]
1:'[Playing]';
//[Pause]
2:'[Pause]';
//[Stop]
3:'[Stop]';
//Adding files... please wait...
4:'Adding files... please wait...';
//Previous track
5:'Previous track';
Gewinnt vielleicht keinen Design-Award, aber funktioniert (hoffentlich). :)

turboPASCAL 21. Nov 2009 16:30

Re: nonVCL Anwendung lokalisieren
 
Warum nimmst du nicht einfach (Windows.)GetPrivateProfileString ? :gruebel:

Mithrandir 21. Nov 2009 16:37

Re: nonVCL Anwendung lokalisieren
 
Zitat:

This function is provided only for compatibility with 16-bit Windows-based applications
Und wir sind ja jetzt schon bei 64bit... :angel2:

Wie gesagt, hab schon lange keinen richtigen Parser mehr geschrieben. ;)


Alle Zeitangaben in WEZ +1. Es ist jetzt 06:26 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz