![]() |
Ich denke das Laden ist dabie wohl der größte Aufwand. Ich meine, wenn jemand ein Programm mit 30 Buttons, 55 Labels, einen Lizenztext und und und hat, is das ne sch*** Arbeit.
|
Nicht unbedingt.
Unter nonVCL kann ich ID's vergeben, wenn die Controlls die gleiche ID haben wie die korrespondierende ID von dem String aus dem Stringtable, kann ich alles in einem Rutsch mit einer for-Schleife beschriften. Mit der VCL könnte man das mit der Tag-Property lösen. |
Ja Luckie, mach mich fertig. Ich bin grademal auf Seite 120 von
"Delphi Grundlagen und Profiwissen". Da muss ich sowas doch noch nich wissen, oder. :wink: Man liest sich, Stanlay :D |
Ich möchte mal zu bedenken geben, daß es nicht reicht, ein paar eigene Strings zu übersetzen, sondern auch alle von Delphi miteingebrachten Resourcestrings (z.B. Laufzeit Meldungen) müssen schließlich auch übersetzt werden (Überleg mal du sitzt vor einem Programm mit deuteschem Interface und plötzlich poppt da ne russische Meldung hoch, nur so als frei gewähltes Beispiel).
Außerdem müssen da noch Dinge im Interface angepaßt werden, weil die verschiedenenen Sprachen unterschiedlich viel Platz brauchen. ich hab mit der Translation Engine von Delphi noch nicht wirklich ein ganzes Projekt durchgezogen, aber auf den ersten Blick scheint sie doch ein extrem hilfreicher Ansatz zu sein, da sie versucht, selbst alle zu übersetzenden (oder sonstwie zu modifiezierenden ) Resourcen übersichtlich aufzulisten und automatisch zu warten. Vor irgendwelchen vollautomatischen Übersetzungen würde ich warnen, nicht nur wegen der Qualität, sondern woher soll die arme Maschine wissen, was sie nicht übersetzen darf, und man denke an die Anmerkung in den Quelltexten 'do not localize', plötzlich wird z. B. der name der zu ladenden DLL übersetzt, ich hatte sowas schon mal bei einem Wizzard in Delphi im Com+ Bereich ... |
Wenn du die Messagebox nimmst, haben die Buttons automatsich die Windows-Sprache. Bei den Boxen aus der Unit Dialogs nicht. RaiseLastOSError sowieso Windows-Sprache.
|
hi,
ich bin nun einwenig verwirrt. So tief stecke ich in der Programmierung wohl nicht drin. Mit dem dynamischen Laden der Stringressourcen finde ich eigentlich interessant. Zitat:
Code:
Muß ich den Text nun zweimal mit verschiedenen Namen definieren b.s.
unit ResStrngs;
interface resourcestring SsaveFile = 'Datei sichern'; implementation end.
Code:
Und wie spreche ich sie im Programm dann dynamisch an ? Oder kann ich per spezieller Anweisungen Code-Blöcke mit gleicher StringResourcen-Namen aktivieren ?
SsaveFileDE = 'Datei sichern';
SsaveFileEN = 'Save File'; :? :? vielleicht kann mir jemand konkretes sagen ? Und wie mache ich es mit Texten auf den Formen ? grüsse hacki |
Nein du brauchst eine richtige Ressourcen-Datei.
Wie man die von hand erstellt kann ich dir leider nicht sagen, ichmache es immer mit dem Ressourcen-Editor vom VC. Du lädst den String nur über die ID, die Sprache wählt Windows aus. |
Ich sprach ja auch von Delphi Runtime Meldungen:
also deutsches Delphi, englisches Windows, diese Meldungen und viele, viele mehr, kämen alle auf deutsch, zumindest teilt die ITE hier meine Meinung: SUnknown = '<unbekannt>'; SInvalidInteger = '''%s'' ist kein gültiger Integerwert'; SInvalidFloat = '''%s'' ist kein gültiger Gleitkommawert'; SInvalidCurrency = '''%s'' ist kein gültiger Währungwert'; SInvalidDate = '''%s'' ist kein gültiges Datum'; SInvalidTime = '''%s'' ist keine gültige Uhrzeit'; SInvalidDateTime = '''%s'' ist kein gültiger Datums- und Zeitwert'; SInvalidDateTimeFloat = '''%g'' kein gültiger Datums- und Zeitwet'; SInvalidTimeStamp = '''%d.%d'' ist kein gültiger Zeitstempel'; SInvalidGUID = '''%s'' kein gültiger Wert für GUID'; SInvalidBoolean = '''%s'' ist kein gültiger boolescher Wert'; etc |
Das mit dem autmoatischen Beispiel war eigentlich auch nicht als wirklich Idee gedacht. Zumal man ja ständig Online sein müsste....
|
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz