[Lazarus] Resource string constants support in the Object Inspector

Mattias Gärtner nc-gaertnma at netcologne.de
Mon Mar 17 17:07:52 CET 2008


Zitat von Graeme Geldenhuys <graemeg.lists at gmail.com>:

> On 17/03/2008, Mattias Gärtner <nc-gaertnma at netcologne.de> wrote:
> >  For LCL applications the translator unit inits the default language from
> the
> >  environment vars. The timing depends on the position in the uses clause of
> the
> >  project. The language can be later set by the app.
> >  The question is, when should the .po files (or whatever) read to setup the
> >  resourcestrings. Application.Initialize is probably a good place for most
> apps.
>
>
> How does LCL applications handle translation of the LCL itself and the
> translation files of the application?
>
> eg:  LCL is translated to English and German. These translations can
> be reused in the LCL application, but the application will have
> specific translations as well (also English and German)?  Does LCL
> based applications load both (LCL and Application) translation files,
> or does it merge them somewhere into a single translation file etc...?

There is no standard yet.
For single binary apps both is possible, but single files may be nicer.
For apps using packages in dynamic libraries the translations should be at least
one file per library/package.
The naming and path conventions depend on the platform/installer-system.
A wiki page should be started and the various conventions should be collected.
Then we can decide a standard and implement some tools.


> In fpGUI I handle this by searching for the toolkit's translation file
> first (fpgui_XXX.po) and load it into the resourcestrings (this file
> can be shared between fpGUI based applications). Then I look for a
> translation file that has the same name as the application's executabe
> (eg; myapp_XXX.po) and in the same location as the executable and
> inserts that into GetText's translation array. Be careful here,
> because by default the second .po file will clear the original
> translation array.  All this occurs in Application.Initialize and
> seems to work quite well so far.

This is one solution. But some installer/package systems expect that translation
files should be in specific separate directories (e.g. sub directories).


Mattias




More information about the Lazarus mailing list