Re: [Foxgui-users]about multilanguage fox lib

[S. A. <san...@on...>]

We  solved this problem (Windows and unix) using runtime loading  as follow :

1) A text file contains all text messages as follow in the preferred language :
"english.txt"
0:text 1
[st_texte_1]
1:Yes
[st_es]


2) A task loads this file in a shared memory  area once, and compacts it.
      you have only to load the right text file (english,french...)
3) each program using language texts will link to this shared area at startup
4) a C++ description file allows a link from the text file to shared memory ptr :
"langue.h" file :
#define st_texte_1  mess[0]
#define st_yes          mess[1]
.
.
.

4) in the C++ code, to use it :
#include "langue.h"   -> text - ptr definition

#include "init_mess.h" -> API that links to the shared memory ptr

// enjoy using texts
printf(st_texte_1); ....


Advantages :
Texts are not duplicated in each files, since they are stored in a shared memory
area.
Easy to use , e.g. to add a text :
a)add the text to each language dependent  text file.
b) setup the ptr number in the langue.h file,
c) use it in your program !

It works, we did it !

Bye
Steph.





Theo Veenker wrote:

> On Fri, 7 Dec 2001, Jeroen van der Zijp wrote:
>
> > On Friday 07 December 2001 09:52, you wrote:
> > > jeroen wrote:
> > > > On Friday 07 December 2001 06:38, you wrote:
> > > > > Hi,
> > > > >
> > > > > Is it possible to collect english text in fox in a header file ?
> > > > > Then we can use this header's translated versions when compiling
> > > > > library for required language.
> > > > > This way we can collect translated text for future real (gettext?)
> > > > > implementation.
> > > > >
> > > > > Is it doable by some macro magic?
> > > > >
> > > > > ie:
> > > > > usage:     FXL("Cancel")
> > > > > in central header:
> > > > >     #if FXLANGUAGE=="TR"
> > > > >        #include "FXlangTR.h"
> > > > >    #elif FXLANGUAGE=="SP"
> > > > >       #include "FXlangSP.h"
> > > > >   ...
> > > > >   #else
> > > > >      #include "FXlangEN.h"
> > > > >   #endif
> > > > >
> > > > > What do you think ?
> > > >
> > > > I don't think the language should be a compile-time issue.  It should
> > > > be flexible enough to change it at runtime, so that recipients of
> > > > FOX applications do not have to recompile.
> > > >
> > > > As I have mentioned earlier a couple of days ago, there was some good
> > > > news:- GNU gettext has its license changed from GPL to LGFL.
> > > >
> > > > Many people, including yours truely, use FOX for commercial applications,
> > > > and linking to a GPL-licensed library like gettext() was impossible due
> > > > to the viral nature of GPL.
> > > >
> > > > Now that gettext is Lesser GPL, its license matches that of FOX and we
> > > > can incorporate it into FOX w/o any problem.
> > > >
> > > > GNU gettext allows me to write the code in english, but if certain
> > > > environment variables have been set, the english is used as lookup key
> > > > for the translated messages; if no translation is found the default
> > > > english is used.
> > > >
> > > > IMHO this is much better than a "message catalog" of some kind because
> > > >
> > > >         (1) various libraries from different sources may not have unique
> > > >             message string id's.
> > > >
> > > >         (2) if not everything is translated that's OK the application
> > > > will still work [for example, you could be lazy and forget about some
> > > > obscure error messages].
> > >
> > > Recently I've been studying gettext a little bit. Gettext also involves
> > > loading a message catalog so (1) applies to gettext too. Generally (1)
> >
> > No, what I mean is there is not a single table for the application; an
> > application is made up out of parts, and some of these parts may be
> > used in other applications.
> >
> > For example, the FOX library has some messages too, as do "custom"
> > widgets and dialogs which developers make into libraries to share
> > between different applications.
>
> That's obvious. To me a message catalog is not a synonym of a string
> table or something, therefore I misunderstood. I agree with you, that
> a (single) string table thing (key in, string out) is a too naive
> solution.
>
> > > is not a problem; not for gettext nor for any other well designed message
> > > lookup system. And (2) applies to any other message lookup system that
> > > uses a fallback string (most do).
> > >
> > > Because, as Jeroen said, gettext uses the (English) source message text
> > > as lookup key, the gettext API is very simple, and that is a pro. But,
> > > there are some drawbacks:
> > >
> > > 1) A message is not particularly suitable as a lookup key, because in an
> > >    application you may have several identical English messages (used in
> > >    different contexts), causing gettext to give you the same translation
> > >    for all cases, although some languages (or translators) require context
> > >    colored messages.
> >
> > It seems to work well enough; there are some provisions for potential
> > conflicts (text domains, and so on).
> >
> >
> >
> > > 2) Once you have choosen an English source text, and the app has been
> > >    translated to many languages, you can't go and change a message text
> > >    without updating the all PO/MO catalog files. A similar problem applies
> > >    to message lookup systems where a numeric key is used to index a message
> > >    when message enumeration is shuffled.
> >
> > Of course!  However with gettext end users will at least see the new english
> > message, until all the other languages have been updated; plus, only the one
> > message is likely to be affected, since english message is used as hash key
> > and if the other english messages have not changed, they will still hash the
> > same.
> >
> > With an enumeration-based system, you will have the problem of keeping the
> > enumeration straight [if this is even possible! imagine linking in several
> > DLL's each with their own message catalogs!].
>
> Fully agree.
>
> >
> > The important part is that the application will work regardsless of having
> > a complete or incomplete set of translations.
>
> Again, of course! Anything less would be unacceptable.
>
> >
> > The back of the "gettext" manual has some history, and it appears that they
> > have thought things out pretty well, and authors were evidently aware of prior
> > efforts in this direction.
> >
>
> Surely they gave it a lot of thought and GNU gettext is used by many
> applications. But personally I felt I was going back 10 years in time
> when reading the gettext material. No C++ support class, no multi-locale
> support, it is only about translating messages (while there is more
> to localizing an app then just that), and the creation/maintainance
> of the message catalogs is rather complicated (pot-files, pox-files,
> gmo-files, po-files, mo-files, enough to make a translator endup in a
> mental institution, I guess). No modern C++ programmer would have
> implemented it the way they did. The simple API is good, the rest
> stinks (excuse me).
>
> This is just my personal opinion and I have to admit I'm not a very
> objective person concerning these matters. To feed the discussion, I
> hope to announce my own i18n coding efforts somewhere next week.
>
> Have a nice weekend,
> Theo
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users