Hi

> His problem is that he has his base class in a shared library and he
> wants to have a translation that applies to this library.
> The forms using this library adds some components to those forms /
> frames and also needs translation and belongs to another domain.
>
> So he want to translate the form parts that are in the library with the
> 'global' domain and the rest of form introduced in the 'real'
> application with the 'default' domain.

Right.

> But maybe it is better just to merge the global domain into the default
> domain?

I had that idea alreday but it didn't work as epxected. Is the merge function
really meant to merge two completely different mo files to one file?

Regards
Joe

Hi

> His problem is that he has his base class in a shared library and he
> wants to have a translation that applies to this library.
> The forms using this library adds some components to those forms /
> frames and also needs translation and belongs to another domain.
>
> So he want to translate the form parts that are in the library with the
> 'global' domain and the rest of form introduced in the 'real'
> application with the 'default' domain.

Right.

> But maybe it is better just to merge the global domain into the default
> domain?

I had that idea alreday but it didn't work as epxected. Is the merge function
really meant to merge two completely different mo files to one file?

Regards
Joe

His problem is that he has his base class in a shared library and he
wants to have a translation that applies to this library.
The forms using this library adds some components to those forms /
frames and also needs translation and belongs to another domain.

So he want to translate the form parts that are in the library with the
'global' domain and the rest of form introduced in the 'real'
application with the 'default' domain.

But maybe it is better just to merge the global domain into the default
domain?

Met vriendelijke groet,

Martijn van der Kooij B ICT software engineer
Stabiplan BV www.stabiplan.nl disclaimer:
http://www.stabiplan.nl/disclaimer


>-----Original Message-----
>From: dxgettext@yahoogroups.com
>[mailto:dxgettext@yahoogroups.com] On Behalf Of Olivier Sannier
>Sent: vrijdag 13 november 2009 8:43
>To: dxgettext@yahoogroups.com
>Subject: Re: [dxgettext] Re: Using several domains in one project
>
>Thomas Mueller wrote:
>>
>>
>> Where do you put the TranslateComponent call? I have put it
>into both
>> constructors which would result in the translation process to be
>> called twice, I guess that was what you meant. But it does
>not matter:
>> Since GetDomain is virtual, it will always return 'default',
>no matter
>> where the TranslateComponent call is done.
>>
>No that's not what I meant, I was saying to put just one
>TranslateComponent call in the TAncestorForm constructor.
>There is only the need for one as it will be called whatever
>actual class is used at the time.
>Maybe I don't get your situation properly, but I thought you
>had forms that either belong to one domain or another, but
>never use translation from two domains at a time.
>
>
>------------------------------------
>
>Yahoo! Groups Links
>
>
>
>

Thomas Mueller wrote:
>
>
> Where do you put the TranslateComponent call? I have put it into both
> constructors which would result in the translation process to be
> called twice, I guess that was what you meant. But it does not matter:
> Since GetDomain is virtual, it will always return 'default', no matter
> where the TranslateComponent call is done.
>
No that's not what I meant, I was saying to put just one
TranslateComponent call in the TAncestorForm constructor. There is only
the need for one as it will be called whatever actual class is used at
the time.
Maybe I don't get your situation properly, but I thought you had forms
that either belong to one domain or another, but never use translation
from two domains at a time.

Hi,

On Thu, Nov 12, 2009 at 11:07 PM, Olivier Sannier <obones@...> wrote:

> > > But you don't need to do that. Just like Thomas suggested, you
> > > can pass
> > > the domain name to the TranslateComponent function.
> > > And to solve your inheritance differences, just create a virtual
> > > function that returns the domain name to use.

> > > Then in any form that needs it, you override that function
> > > to return the appropriate domain name.

> > No, that won't work since TranslateComponent would always use the
> > overridden method that will return 'default' regardless to which class
> > the property to translate belongs. It won't work with a static method
> > either because then it would always call the method that returns
> > 'global'.

> Something very odd must be escaping me. The point of the overridden
> method is to return something different when a form belongs to another
> domain than "default".

Consider this code:

type
   TAncestorForm = class(TForm)
   protected
     function GetDomain: string virtual;
   public
     constructor Create(_Owner: TComponent); override;
   end;

function TAncestorForm.GetDomain: string;
begin
   Result := 'global';
end;

constructor TAncestorForm.Create(_Owner: TComponent);
begin
   inherited;
   TranslateComponent(Self, GetDomain);
end;

type
   TChildForm = class(TAncestorForm)
   protected
     function GetDomain: string; override;
   public
     constructor Create(_Owner: TComponent); override;
   end;

function TChildForm.GetDomain: string;
begin
   Result := 'default';
end;

constructor TChildForm.Create(_Owner: TComponent);
begin
   inherited;
   TranslateComponent(Self, GetDomain);
end;

Where do you put the TranslateComponent call? I have put it into both
constructors which would result in the translation process to be
called twice, I guess that was what you meant. But it does not matter:
Since GetDomain is virtual, it will always return 'default', no matter
where the TranslateComponent call is done.

If it were not virtual, it would result in the form being translated
twice, first within the domain 'global' (call to inherited in the
constructor) and again within the domain 'default'. This would
probably work most of the time unless there are incompatible or
circular translations as I described in my original post. But in that
case we could just pass the domain as a literal string and save the
trouble of writing the GetDomain function.

twm

Thomas Mueller wrote:
>
>
> Hi,
>
> On Thu, Nov 12, 2009 at 8:58 AM, Olivier Sannier <obones@...
> <mailto:obones%40free.fr>> wrote:
>
> > But you don't need to do that. Just like Thomas suggested, you can pass
> > the domain name to the TranslateComponent function.
> > And to solve your inheritance differences, just create a virtual
> > function that returns the domain name to use.
>
> > Then in any form that needs it, you override that function to return the
> > appropriate domain name.
>
> No, that won't work since TranslateComponent would always use the
> overridden method that will return 'default' regardless to which class
> the property to translate belongs. It won't work with a static method
> either because then it would always call the method that returns
> 'global'.
>
> twm
>
Something very odd must be escaping me. The point of the overridden
method is to return something different when a form belongs to another
domain than "default".
Or maybe I don't fully understand your need.

Hi,

On Thu, Nov 12, 2009 at 8:58 AM, Olivier Sannier <obones@...> wrote:

> But you don't need to do that. Just like Thomas suggested, you can pass
> the domain name to the TranslateComponent function.
> And to solve your inheritance differences, just create a virtual
> function that returns the domain name to use.

> Then in any form that needs it, you override that function to return the
> appropriate domain name.

No, that won't work since TranslateComponent would always use the
overridden method that will return 'default' regardless to which class
the property to translate belongs. It won't work with a static method
either because then it would always call the method that returns
'global'.

twm

joegalinke wrote:
>
>
>
>
> Hi,
>
> --- In dxgettext@yahoogroups.com <mailto:dxgettext%40yahoogroups.com>,
> Thomas Mueller <dxgettext@...> wrote:
> > You could probably just write your own TranslateComponent function
> > (e.g. make it a method of the ancestor class) that calls
> > gnugettext.TranslateComponent first with the domain global and then
> > without a domain. This will only lead to problems, if your translation
> > can be translated again, e.g.:
> > bla --global--> blub --default--> bleep
> > or you have incompatible translations:
> > bla --global--> blub
> > bla --default--> bleep
>
> I soved it the way, that in TranslateProperty(), when
> ws := dgettext(textdomain,old);
>
> leads to ws=old, I go through the other domains to search for the
> translation. I've got to admit that I don't really like it.
>

But you don't need to do that. Just like Thomas suggested, you can pass
the domain name to the TranslateComponent function.
And to solve your inheritance differences, just create a virtual
function that returns the domain name to use.
Something like that:

TBaseForm
function GetDomainName: string: virtual;


Then in any form that needs it, you override that function to return the
appropriate domain name.

Hi,

--- In dxgettext@yahoogroups.com, Thomas Mueller <dxgettext@...> wrote:
> You could probably just write your own TranslateComponent function
> (e.g. make it a method of the ancestor class) that calls
> gnugettext.TranslateComponent first with the domain global and then
> without a domain. This will only lead to problems, if your translation
> can be translated again, e.g.:
> bla --global--> blub --default--> bleep
> or you have incompatible translations:
> bla --global--> blub
> bla --default--> bleep

I soved it the way, that in TranslateProperty(), when
ws := dgettext(textdomain,old);

leads to ws=old, I go through the other domains to search for the translation.
I've got to admit that I don't really like it.

Regards
Joe

Hi,

On Wed, Nov 11, 2009 at 11:33 AM, joegalinke <joegalinke@...> wrote:

> Lets say I have a hierarchy of forms to be used in several projects and
> some other global units which have to be translated.

> I extract the messages into a po file, let's call it global.po and translate
> them. Ok.

> I do the same with the project code to and generate a default.po.

> The use of TranslateComponent()leads to a call of dgettext() which only
> searches in one specified domain for a translation. But how can I search
> in global.mo?

The way I solve this is calling TranslateComponent with a specific
domain ('global' in your case), but apparently you can't do that
because you are using form inheritance.

> The thing is that with classes derived from an anchestor translated in
> global.po there are also parts translated in the projects po file.

> How do others solve this problem?

You could probably just write your own TranslateComponent function
(e.g. make it a method of the ancestor class) that calls
gnugettext.TranslateComponent first with the domain global and then
without a domain. This will only lead to problems, if your translation
can be translated again, e.g.:
bla --global--> blub --default--> bleep
or you have incompatible translations:
bla --global--> blub
bla --default--> bleep

twm

Hi,

as I don't understand the merge function to merge different translations to one
file I run into a problem.

Lets say I have a hierarchy of forms to be used in several projects and some
other global units which have to be translated.

I extract the messages into a po file, let's call it global.po and translate
them. Ok.

I do the same with the project code to and generate a default.po. Both get
compiled into mo files and are located in the appropiate folders below the
application.

The use of TranslateComponent()leads to a call of dgettext() which only searches
in one specified domain for a translation. But how can I search in global.mo?

The thing is that with classes derived from an anchestor translated in global.po
there are also parts translated in the projects po file.

How do others solve this problem? It's not a question of resource strings, so
AddDomainForResourceString() doesn't seem to be an option.

TIA
Joe