In our previous episode, Rainer Stratmann said:
> > > In my case it can also be possible that there are not all words
> > > translated yet. Then the original text is shown or englich one. The
> > > translation can be made later. That is (also) an advantage.
> >
> > No it can't, since if two the same texts translate to a different texts in
> > another language, you need to add the identifiers and rebuild,
> > distribute/migrate etc.
> 
> Look at the top. The programmer must be aware of the two meanings and add a 
> unique identifyer in front of the text. What you want to discuss here is 
> specific and (more or less) deep. You want from me immediately a solution to 
> all this kind of specific things.

No. The route was this:

- In an earlier msg I mentioned this as dxgettext limitation (since I ran
 into it)
- In a later msg you said you got weary of dxgettext because of "problems"
   with it.
- I replied that it was not a problem, but a limitation of the concept, and
   that your system had it too.

I never asked you to have a solution for it. I don't see the particular
advantage of your system over gettext anyway.

> > > <-> utf8.
> >
> > What do you assume about the codepage of literals? Do you pass the right
> > -Fc parameters for that?
> 
> Please explain it more.

If there is a _('whatever')    (or whatever your notation is)

what do you assume about 'whatever' 's codepage?
 
> > > Another step more that means more work and less easiness (less
> > > userfriendly).
> >
> > Explain. You need to scan some way too.
> 
> Yes at programstart with searching the opcode for calls and loading the pchar 
> const in EAX.

_always_ ? Scary.

Anyway, my point was that you scan either which way. Source or binary.

The source has a build requirement, is architecture dependent and generally
more portable. Binary might be easier to only get the linkedin texts.

Actually proof of concept might be worthwhile for that purpose in combination
with gettext. OTOH, gettext alos translates stuff from resources (like
forms)

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to