DBNavigator

[theo]

Das ist eine Idee; für den Rest seid ihr zuständig

Jaja. Schwache Leistung Socke. Ideen ohne Umsetzungswillen brauchen wir nicht.

[Socke]

Jaja. Schwache Leistung Socke. Ideen ohne Umsetzungswillen brauchen wir nicht.

Ich hab da eine Idee: Für die VWL-Klausur am Freitag lernen. Und die werde ich jetzt auch umsetzen.

[Maik81ftl]

Naja es ist halt nicht ganz einfach.
Wenn Lazarus die Übersetzungen automatisch einbindet, dann muss man das languages Verzeichnis mitliefern, was dann auch wieder nicht sofort verstanden wird.
Würde man alle Sprachen als Ressourcen einbinden, geht das Gejammer mit "EXE zu gross" los etc...

Thoe... Irgendwie kommt mir gerade der Punkt Sprachdatei mehr als bakannt vor. in den Projekten, die ich via CoDeSys betreue bin ich nun mehr und mehr dabei eine XML-File mit einzubinden, wäre dies ggf. auch eine Option unter Lazarus oder geht das da Schief?

[Socke]

Naja es ist halt nicht ganz einfach.
Wenn Lazarus die Übersetzungen automatisch einbindet, dann muss man das languages Verzeichnis mitliefern, was dann auch wieder nicht sofort verstanden wird.
Würde man alle Sprachen als Ressourcen einbinden, geht das Gejammer mit "EXE zu gross" los etc...

Zuerst muss man ja nur die Sprachen mitliefern, die auch die Anwendung abdeckt (besser alles in Englisch als Englisches Programm aber Chinesische Buttons in den Dialogen). Dann kann man das ganze komprimieren und landet bei 85-220 Kb für die LCL -- das ist jetzt nicht so viel verglichen mit der LCL an sich.

Thoe... Irgendwie kommt mir gerade der Punkt Sprachdatei mehr als bakannt vor. in den Projekten, die ich via CoDeSys betreue bin ich nun mehr und mehr dabei eine XML-File mit einzubinden, wäre dies ggf. auch eine Option unter Lazarus oder geht das da Schief?

Du kannst jegliche Daten in dein Programmeinbinden; die Frage ist: Was willst du damit erreichen?

[Maik81ftl]

Thoe... Irgendwie kommt mir gerade der Punkt Sprachdatei mehr als bakannt vor. in den Projekten, die ich via CoDeSys betreue bin ich nun mehr und mehr dabei eine XML-File mit einzubinden, wäre dies ggf. auch eine Option unter Lazarus oder geht das da Schief?

Du kannst jegliche Daten in dein Programmeinbinden; die Frage ist: Was willst du damit erreichen?

soll in den Punkt Multilanguage gedacht sein

[ruewa]

Erstmal ein freundliches Hallo in die Runde!

Mich hat 2 Stunden lang das banale Problem beschäftigt, wie man ein auf kind:=bkCancel gestelltes BitBtn dazu bringt, sein fröhliches "Abbrechen" nicht nur in der IDE, sondern auch in der Application zu verkünden, statt eines schnöden "Cancel". Nicht, daß das ein weltbewegendes Problem wäre, aber es ist halt nervig.

Eine Lokalisierung ist bereits vorhanden (z.B. lclstrconsts.de.po). Sie muß aber explizit von deinem Programm verwendet werden.

Soweit war ich auch schnell gekommen. Wie aber bindet man die nun unkompliziert ein, wenn man sein Programm nicht selbst aufwendig i18n-fähig machen will? Ich wollte in dem Fall einfach nur eine schnelle Lösung für ein Allerweltsproblem, das eigentlich fast jeden irgendwann streift und das die Lazarus-IDE bisher nicht befriedigend löst.

Ich hatte jetzt testweise die lcl/languages ins Project übernommen und die uses der .lpr um defaulttranslator ergänzt, Dann werden alle deutschen lcl-Text übernommen...

Auch das hat mir nicht wirklich weitergeholfen. WIE hast Du "die lcl/languages ins Project übernommen"?

Danke für Eure Hilfe.
wenn man's weiß funktioniert' s ja auch.

Das ist wohl wahr... Ich bitte Euch: Habt doch ein bißchen Erbarmen mit den Gelegenheitsprogrammierern. Bitte bedenkt, daß ein solches Forum zwar einerseits der lockeren Unterhaltung der Akteure dient (was ja völlig okay ist), andererseits aber auch von (ganz unterschiedlich beschlagenen) Lesern auf der Suche nach Problemanalyse und -lösungen genutzt wird. Mich hat etwa das Googeln nach "lazarus lclstrconsts.de.po" (nahezu exklusiv) auf diesen Thread verschlagen...

Versteht das bitte nicht als Gemecker. Es ist, wie es ist: So toll Lazarus und FreePascal sind, man wird halt doch immer wieder mit den Grenzen der Dokumentation konfrontiert. Am Ende habe ich doch eine Lösung gefunden, und ich verfasse dieses Posting eigentlich nur, um späteren Lesern, denen es so geht wie mir, (u.U. stundenlange) Sucherei zu ersparen. Geholfen hat diese Seite: http://wiki.lazarus.freepascal.org/Gett ... s_right/de

Diese Routine habe ich in die [MyProg].lpr (von der ich ansonsten die Finger zu lassen gelernt habe) übernommen:

Code: Alles auswählen

{uses
  ...}
  Translations, LCLProc;
 
procedure TranslateLCL;
var
  PODirectory, Lang, FallbackLang: String;
begin
  PODirectory:='/path/to/lazarus/lcl/languages/';     {in meinem Fall '/usr/share/lazarus/1.2.0/lcl/languages/'}
  Lang:='';
  FallbackLang:='';
  LCLGetLanguageIDs(Lang,FallbackLang); // in der Unit LCLProc
  Translations.TranslateUnitResourceStrings('LCLStrConsts',
                      PODirectory+'lclstrconsts.%s.po',Lang,FallbackLang);
  // ... fügen Sie hier einen Aufruf von TranslateUnitResourceStrings für jede .po-Datei hinzu ...
end;
 
{begin}
  TranslateLCL;
{  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.}

Einen herzlichen Dank an dieser Stelle an die unbekannten Wiki-Autoren! Das funktioniert auch dann, wenn man in den Projekteinstellungen "i18n" ausgeschaltet läßt. Warum man Lang und FallbackLang einen Leerstring übergibt, habe ich nun nicht weiter ergründet, es hat dennoch genau so auf Anhieb funktioniert. Auch wenn ich noch meilenweit davon entfernt bin, den dahinterliegenden Mechanismus zu verstehen. Egal: Problem fürs Erste gelöst, ich hoffe, der eine oder andere kann von diesem Posting profitieren.

Gruß Rüdiger

(Lazarus 1.2.0, fpc 2.6.2, Debian Linux)

[ruewa]

Okay, es erfordert doch noch einen zweiten Blick. Von wegen "schnelle Lösung für ein Allerweltsproblem"...

Die obige Lösung funktioniert zwar, hat aber einen entscheidenden Haken: Sie funktioniert nur auf dem eigenen Rechner... Denn die .po-Datei wird erst zur Laufzeit eingebunden. Will man sein Programm weitergeben, muß man die lclstrconsts.de.po (oder die entsprechenden Dateien für andere Sprachen) mitliefern und auch sicherstellen, daß das Programm dann deren Pfad findet. Es ist also entweder nur eine "selbstgenügsame" Lösung, oder eine unkomfortable.

Abgesehen davon, ist es aber auch nicht nötig, sie in der Projekt.lpr zu plazieren, die OnCreate-Methode der Mainform tut es genauso. Will man außerdem von vorne herein nur eine ganz bestimmte Sprache (etwa Deutsch) einbauen, läßt sich das Ganze auf einen simplen Anderthalbzeiler abspecken:

Code: Alles auswählen

uses
  Translations;
 
procedure TMainForm.FormCreate(Sender: TObject); 
begin
   Translations.TranslateUnitResourceStrings('LCLStrConsts',
          '/usr/share/lazarus/1.2.0/lcl/languages/lclstrconsts.%s.po','de','de');  
end;
 

Oder was auch immer der jeweilige Pfad zur lclstrconsts.de.po ist.

Will man die Übersetzung hingegen beim Kompilieren in das Programm einbinden, muß man etwas mehr Aufwand betreiben. Da gibt es zwar eine Anleitung in der Wiki: http://wiki.lazarus.freepascal.org/Tran ... ompilieren , nur ist die a) ziemlich verwirrend ("Erzeugen Sie eine neue Unit" - und dann? Die .de.po da reinkopieren? Wozu überhaupt eine extra Unit? Und wozu sollte das "resourcestring MyCaption = 'Caption';" gut sein?). Und b) funktioniert sie mit der lclstrconsts.de.po schlicht und ergreifend nicht, und zwar wegen eines (wie ich vermute) Bugs in der Unit translations.

Der Bug besteht darin: in der lclstrconsts.de.po sind nicht alle ressourcestrings der originalen LCLStrConsts.pas übersetzt, einige Zeilen werden mit einem Leerstring "übersetzt", was vermutlich bewirken soll, daß der englische Originalstring anstelle einer Übersetzung weiterbenutzt werden soll. Das betrifft im Wesentlichen nur ein paar abgelegene IDE-Meldungen, die nur im Entwicklungsprozeß, nicht aber in einem normalen Programm auftauchen. Soweit, sogut. Aber an der Stelle bockt die translations-Unit: Deren TPOFile.Translate-Funktion (ab Zeile 781) bekommt in solchen Fällen einen leeren Übersetzungsstring und quittiert den mit einer Exception und der Meldung einer "TPOFile.Translate Inconsistency".

1) Nun könnte man versuchen, in der translations.pas rumzupfuschen. Aber davon sollte man tunlichst die Finger lassen, denn wer versteht schon, was die Unit in ihren hintersten Windungen anstellt. Irgendwo zwischen vielleicht und ziemlich sicher hat die Exception ja ihren guten Grund. Mein Workaround bestand vielmehr darin, die lclstrconsts.de.po zu editieren (als Root in Linux) und alle leeren Übersetzungsstrings mit dem englischen Original aufzufüllen. Und nun endlich funktionierts... Die editierte Datei habe ich in .../lcl/language/ belassen und in "lclstrconsts_modified.de.po" umbenannt.

Weil die Anleitung in der Wiki wie gesagt etwas arg verwirrend ist, hier die weiteren Schritte:

2) Umwandeln der lclstrconsts_modified.de.po in eine .lrs-Datei mittels lazres, einem Kommandozeilenprogramm, das im Lazarus-Verzeichnis unter /tools/ zu finden ist. Ich habe lazres (unter Debian Linux) kurzerhand nach /usr/bin/ kopiert, um mich nicht weiter mit dem Programmpfad herumschlagen zu müssen. Dann in der bash:

Code: Alles auswählen

me@debian:~$ lazres /home/me/.../MyProject/lclstrconsts_modified_de.lrs /usr/share/lazarus/1.2.0/lcl/languages/lclstrconsts_modified.de.po

D.h. ich habe eine Datei namens lclstrconsts_modified_de.lrs erzeugt, die ich direkt in mein Projektverzeichnis gelegt habe.

3) Die Routine aus der Wiki kann man so übernehmen (und dabei das Drumherum mit der "neuen Unit" getrost ignorieren):

EDIT: Diese Routine ist fehlerhaft, sh. übernächstes Posting.

Code: Alles auswählen

uses
  translations, LResources;
 
function TranslateUnitResourceStrings: boolean;
var
  r: TLResource;
  POFile: TPOFile;
begin
  r:=LazarusResources.Find('lclstrconsts_modified.de','PO');
  POFile:=TPOFile.Create;
  try
    POFile.ReadPOText(r.Value);
    Result:=Translations.TranslateUnitResourceStrings('LCLStrConsts',POFile);
  finally
    POFile.Free;
  end;
end;

Und schließlich in den Initialisierung-Teil der Haupt-Form einfügen:

Code: Alles auswählen

initialization
  {$I lclstrconsts_modified_de.lrs}
  TranslateUnitResourceStrings;
  (...)
end.
 

Leider läßt die Forumssoftware das Hochladen der modifizierten .po-Datei nicht zu und ich will nicht gleich gegen die Ettikette verstoßen und sie einfach umbenennen... Gibts da eine Möglichkeit?

Ich hoffe, dem einen oder anderen hilft diese Lösung weiter.

Gruß Rüdiger

[Soner]

Rüdiger,
Ich danke dir. Das hat mir sehr geholfen. Bisher war ich zu faul/lustlos mich um Übersetzung der Programme heranzuwagen. Deshlab waren die Programme meist Denglisch.
Du hast mir viel Arbeit gespart.

[ruewa]

Hallo Soner: Freut mich, danke!

Der Bug hat sich inzwischen (halbwegs) geklärt: Der Fehler liegt nicht in der Unit Translations, sondern in der Wiki (http://wiki.lazarus.freepascal.org/Tran ... ompilieren). Genauer gesagt verwendet die Wiki-Routine einen ungeeigneten constructor TPOFile.Create, der eine entscheidende Variable (FAllEntries) auf true statt auf false setzt. Erstaunlicherweise scheint das bei der Übergabe eines leeren Übersetzungsstrings nur Linux-Umgebungen außer Gefecht zu setzen, während es unter Windows scheinbar toleriert wird (was ich vom Quelltext her nicht nachvollziehen, aber mangels Windows auch nicht testen kann). Genaueres siehe http://bugs.freepascal.org/view.php?id=26021

Das tieferliegende Problem dabei ist, daß die Translate-Unit so gut wie nicht dokumentiert (und auch nicht gerade leicht zu lesen) ist. Man hat also kaum eine andere Möglichkeit, als die Wiki-Beispiele blind abzukupfern und auf das Beste zu hoffen.

Jedenfalls: Sauber ist die obige Routine nicht. Hier die Alternative, die nun auch eine unmodifizierte lclstrconsts.de.po klaglos verarbeitet (mit Dank an Bart Broersma):

Code: Alles auswählen

type
  TTranslateFromResourceResult = (trSuccess, trResourceNotFound, trTranslationError);
 
function TranslateFromResource(AResourceName, ALanguage : String): TTranslateFromResourceResult;
var
  LRes : TLResource;
  POFile : TPOFile = nil;
  SStream : TStringStream = nil;
begin
  Result := trResourceNotFound;
  LRes := LazarusResources.Find(AResourceName + '.' + ALanguage, 'PO');
  if LRes <> nil then
  try
    SStream := TStringStream.Create(LRes.Value);
    POFile := TPoFile.Create(SStream, False);
    try
      if TranslateUnitResourceStrings(AResourceName, POFile) then Result := trSuccess
      else Result := trTranslationError;
    except
      Result := trTranslationError;
    end;
  finally
    if Assigned(SStream) then SStream.Free;
    if Assigned(POFile) then POFile.Free;
  end;
end;
 

Diese Lösung setzt lediglich eine übereinstimmende Namengebung der Dateien voraus: Also abcdef.pas >> abcdef.lg.po >> abcdef.lg.lrs
Einpflegen kann man das z.B. in den Initialisierungsteil der MainForm, oder auch in eine eigene Unit:

Code: Alles auswählen

initialization
  {$I lclstrconsts.de.lrs}
  TranslateFromResource('lclstrconsts', 'de');
end.
 

Es besteht so also keine Notwendigkeit mehr, unvollständige po-Dateien eigenhändig zu editieren. Wohl aber noch die Wiki...

Gruß Rüdiger