![]() |
gettext sucht nur im default.mo
Hi all,
habe das Problem schon im Forum "Sonstige Fragen zu Delphi" unter dem Titel "Übersetzungstexte werden nur in der default.mo gesucht" gestellt. Entweder ist es dort falsch oder ????? Ich poste es hier aber besser nicht nochmal. Für etwas Hilfe wäre ich trotzdem sehr verbunden. Danke Charly |
AW: gettext sucht nur im default.mo
mittels AddDomainForResourceString kann man weitere Dateien hinzufügen.
z.B. delphi.mo AddDomainForResourceString ('delphi'); |
AW: gettext sucht nur im default.mo
AddDomainForResourceString hatte er bereits benutzt, aber scheint nicht zu funktionieren.
Ja, der TE hätte natürlich seinen anderen Beitrag verlinken können, damit du es dort hättest sehen können. Wenn du denkst falsch zu sein, dann kannst drüben gern auf den Report-Knopf drücken und es eventuell verschieben lassen. Ja, das "Fragen zu Delphi", also zur IDE und Sprache selbst, passt nicht wirklich, wobei ich denke "Sonstige Werkzeuge" würde gut passen. (aber nun nicht noch einen Post eröffnen) Und hier in "GUI-Design mit VCL / FireMonkey / Common Controls" bist'e auch falsch. Wie patziere ich Komponenten auf der Form und was verwende ich (Usability) und wie verwende ich die "Standard"-Komponenten, welche mitgeliefert wurden? Weiter erstmal dort: ![]() |
AW: gettext sucht nur im default.mo
Zitat:
Üblicherweise benutzt man Domains aber eigentlich auch, um Übersetzungen für verschiedene Zwecke zu trennen. Z.B. wenn man eine Spezialanwendung für Straßenzustandserfassung und Bewertung schreibt, dann gibt es eine Domain "ZEB", die die ganzen Fachbegriffe umfasst, bei denen es auf wortgenaue Überstzungen ankommt, damit der Anwender sicher ist, worum es geht. Und dann benutzt man auch DGetText(s, 'ZEB') bzw. TranslateComponent(..., 'ZEB') für die Übersetzung. Es gibt noch die Funktion TextDomain, die die Default-Domain auf eine andere umstellt TextDomain('ZEB') würde dazu führen, dass alle nachfolgenden GetText-Aufrufe die Domain "ZEB" verwenden (und keine Übersetzungen aus der Domain "default" mehr finden würden). In diesem Fall ist es gar nicht gewünscht, dass Übersetzungen aus anderen Domains verwendet werden. Soweit ich mich erinnere, gibt es kein Analog zu AddDomainForResourceString für GetText-Aufrufe. Wir reden doch hier von gxgettext (bzw. dem Original GnuGettext), oder? Wenn nein, ignoriert alles, was ich geschrieben habe. |
AW: gettext sucht nur im default.mo
Hallo
Zitat:
Delphi-Quellcode:
und im Programm sieht es so aus
// Changes J. Rathlev (kontakt(a)rathlev-home.de)
// see: JR - 2011-07-29 / 2012-09-10 // All Delphi version related compiler switches removed - needs at least Delphi XE2 // Information about this file: // $LastChangedDate: 2010-08-25 15:40:17 +0200 (mer., 25 août 2010) $ // $LastChangedRevision: 220 $ // $HeadURL: http://svn.berlios.de/svnroot/repos/dxgettext/trunk/dxgettext/sample/gnugettext.pas $
Delphi-Quellcode:
unit XXXX_Help; Das ist aber KEIN Formular!!!!! procedure Do_TiPoolTimer(Sender: TObject; Ident: Word; Counter: Integer; projAktiv: Boolean); begin etwas code txt:= FormatDateTime(_('mm/dd/yyyy'),Now)+' '+FormatDateTime(_('hh:mm AM/PM'),Now); end; ich hoffe jetzt sind die Randbedinungen alle bekannt? Und noch die grundsätzliche Frage zu meinem Problem: Wenn ich dem System mehrere Domains bekannt mache, wird dann von _(xxx) automatisch in allen gesucht, oder sollte zumindest in allen gesucht werden? Danke Charly |
AW: gettext sucht nur im default.mo
Zitat:
Die aktuelle Version gibt's auf Sourceforge ![]() Zitat:
Man kann natürlich selbst eine _()-Funktion schreiben, die mittels DGetText alle Domains durchgeht, bis eine Übersetzung geliefert wird:
Delphi-Quellcode:
Diese muss man dann aber in eine Unit packen, in der sie vor der Funktion in gnugetext.pas gefunden wird.
function _(const _s: string): string;
begin Result := gettext(_s); if Result = _s then begin Result := dgettext(_s, domain1); if Result = _s then begin Result := dgettext(_s, domain2); // usw. fuer weitere Domains. end; end; end; Am besten dupliziert man die Funktionen aus gnugetext, die man benutzt, (also in der Regel _() und TranslateComponent) in eine eigene Unit mytranslation und bindet nur in dieser Unit gnugettext ein, in allen anderen benutzt man mytranslation statt gnugettext, so dass man sicher ist, welche _()-Funktion aufgerufen wird. |
AW: gettext sucht nur im default.mo
Hi
erstmal sorry für die späte Antwort. Da gabs ja mal richtig viel Info. Danke! Zitat:
AddDomainForComponent('Base'); aber garnicht. Oder wirkt das wiederum nur bei TranslateComponent(self) ? Vieleicht sollte ich mich doch mal mit der gnugettext befassen. ;-) Gruß Charly |
AW: gettext sucht nur im default.mo
Zitat:
Delphi-Quellcode:
Wenn man dann mal nachschaut, was die Prozedur macht, nämlich eine Domain zur Liste ComponentDomainList hinzufügen, stellt man fest, dass das auch nicht hilft. Diese Liste wird nur in ComponentGetText verwendet, dies wiederum wird nur aufgerufen, wenn eine Property übersetzt wird, welches wiederum nur aus TranslateComponent aufgerufen wird.
// Add more domains that component strings can be extracted from. If a translation
// is not found in the default domain, this domain will be searched, too. // This is useful when an application inherits components from a 3rd // party component libraries procedure AddDomainForComponent (const domain:DomainString); procedure RemoveDomainForComponent (const domain:DomainString); Mit anderen Worten: Nein, wieder kein Blumenstrauß. |
AW: gettext sucht nur im default.mo
Hallo
vielen Dank trotzdem. Ich wühle gerade in diversen gnugettext herum. Es gibt auch noch was von git (jvgnugettext.pas) und wohl diverse Varianten von dem im SVN. Wäre es nicht sinnvoll wieder den Header zu pflegen? So mit Änderungsdatum usw. schönen Gruß charly |
AW: gettext sucht nur im default.mo
Zitat:
Das Projekt wäre schon länger tot, wenn ich nicht noch Schreibzugriff auf das SVN Repository hätte und je nach Lust und Laune mal Bugs fixe (in der Regel nur, wenn mir jemand einen Patch zukommen lässt, oder wenn ich selbst betroffen bin) oder es an neue Delphi-Versionen anpasse. Und ich habe ehrlich gesagt keinen Bock für dieses Projekt auf solche Formalismen zu achten. |
AW: gettext sucht nur im default.mo
Problem gelöst!
Delphi-Quellcode:
So banal, daß man sich schon fast schämen muß
function TGnuGettextInstance.gettext(
const szMsgId: MsgIdString): TranslatedUnicodeString; var domain: DomainString; domainIndex: Integer; begin Result := dgettext(curmsgdomain, szMsgId); if SearchAllDomains and (szMsgId <> '') then begin <------------- !!!! domainIndex := 0; while (Result = szMsgId) and (domainIndex < domainlist.count) do begin domain := domainlist[domainIndex]; Result := dgettext(domain, szMsgId); Inc(domainIndex); end; end; end; Im xxxx.dpr DefaultInstance.SearchAllDomains:= TRUE; setzen Und wer setzt jetzt die "offene Frage" zurück? Schöne Grüße Charly |
AW: gettext sucht nur im default.mo
In den JEDI gibt es doch auch noch ein GnuGetText?
|
AW: gettext sucht nur im default.mo
Hi
Zitat:
Im JEDI habe ich ![]() Das ist genau das was auch im SVN ![]() steht. Dann habe ich vor längerem schon mal was bei JEDI gefunden was aber stark von den anderen beiden abweicht. Hat auch einen eigenen Text im Header von wegen Anpassungen und Namensänderung die JEDI gemacht hat.
Delphi-Quellcode:
Die Version finde ich aber garnicht mehr.
{*------------------------------------------------------------------------------
GNU gettext translation system for Delphi, Kylix, C++ Builder and others. All parts of the translation system are kept in this unit. @author Lars B. Dybdahl and others @version $LastChangedRevision$ @see http://dybdahl.dk/dxgettext/ -------------------------------------------------------------------------------} unit JvGnugettext; (**************************************************************) (* *) (* (C) Copyright by Lars B. Dybdahl and others *) (* E-mail: Lars@dybdahl.dk, phone +45 70201241 *) (* *) (* Contributors: Peter Thornqvist, Troy Wolbrink, *) (* Frank Andreas de Groot, Igor Siticov, *) (* Jacques Garcia Vazquez, Igor Gitman, *) (* Arvid Winkelsdorf, Andreas Hausladen, *) (* Olivier Sannier *) (* *) (* See http://dybdahl.dk/dxgettext/ for more information *) (* *) (**************************************************************) {*------------------------------------------------------------------------------ NOTE ON JVCL INTEGRATION: The original file name is "gnugexttext.pas" but has been renamed to JvGnugettext.pas so as to not conflict with other packages that might use the gnugettext.pas file directly In order to ease the synchronization with the public version of gnugettext.pas the style guide for the JVCL is not enforced here. ------------------------------------------------------------------------------*} Ich blick halt in der JEDI / git - Umgebung auch nicht so richtig durch. Vieleicht weis der Thomas Müller ja noch was dazu, der committed da öfters was. Ich verwende jetzt die Version aus dem SVN-Link. Ciao Charly |
AW: gettext sucht nur im default.mo
Die letzten zwei oder drei Contributors laufen hier im Forum auch ab und an mal rum und lesen vielleicht mit.
z.B. Andreas Hausladen = Mister IdeFixPack :wink: |
AW: gettext sucht nur im default.mo
Zitat:
|
AW: gettext sucht nur im default.mo
Zitat:
Zumal dxgettext für FMX und die "neuen" Platformen sowieso nicht mehr funktioniert. Und da ich derzeit ausschließlich für VCL und Win32 entwickle, habe ich auch keine große Motivation, daran was zu ändern. Meine Zeit ist begrenzt und GExperts macht mehr Spaß als dxgettext. |
AW: gettext sucht nur im default.mo
Ok, lassen wir es ruhen. :-)
Vielen Dank an alle für Eure Hilfe. Nur noch eine Frage verwaltungstechnischer Art. Wer macht jetzt den Thread zu? Und muss noch irgendwie der Vorspann "Offene Frage" rausgenommen werden? Ihr merkt schon, ich habe bei der Handhabung des Forums so meine Problemchen. Gruß Charly |
AW: gettext sucht nur im default.mo
Das mit der offenen Frage hat sich gerade erledigt.
Charly |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:52 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