Mattias Gaertner wrote:
On Sat, 22 Oct 2005 14:02:59 +0200
Bogus__aw Brandys <[EMAIL PROTECTED]> wrote:
Mattias Gaertner wrote:
On Thu, 20 Oct 2005 23:36:38 +0200
Vincent Snijders <[EMAIL PROTECTED]> wrote:
Mattias Gaertner wrote:
Parts of translations.pas can be moved to the LCL.
Shall I move ide\translations.pas to lcl\translations.pas and move ide
specific things to ide\laztranslations.pas?
Yes. Maybe rename the function to
TranslateUnitResourceStringsWithPoFile
so we will not get a name conflict when we add a more generic translate
function.
But there are some open issues:
- No absolute paths
- Application should be able to set the language
- When is the resource string table translated?
- Application should be able to set the .po file directory
I think these issues can be handled for the moment by having a public
TranslateUnitResourceStrings.
The application provides path and languages. An distributed lcl
application should distribute the lcl.*.po files too.
I think it is best to call TranslateUnitResourceStrings just before
Application.Initialize in the mean sources. In the future a languages
path can be added to Project properties, like there is now for the
Application.Title.
Ok
- Packages: Units with resource strings should be tried to
translate automatically. How?
I don't think this is easy, again it depends on the location of the *.po
and you don't know if they are distributed, if at all.
Of course we could make some default, say the languages subdir of
running executable or something like that. But I am not sure that will
work out nicely, for example on linux those po files are more at its
place somewhere below /usr/share instead of /usr/bin or /usr/lib.
That depends on the installation method. It can't be auto detected.
Either by command line or by config.
Mattias
I think that we could consider similiar way like in wxWidgets :
Consider this :
There are a few functions :
- to initialize all translation engine (without it no steps described
below are taken)
- for Lazarus it could be including gettext unit or other to
uses clause.
- to add one or more paths to search for .po files
- to get language from system (can be included into initialization step)
- to (eventually) set other language (not the same as system default)
- to load .po files and do translation : each one .po file should be
loaded by other function call (attempt to load lcl.xx.po can be
automatic)
If lcl.xx.po is find on requested path then all lcl components resource
strings are translated according to system default language or user
choice.
If requested other .po file (for example program.xx.po) is found the
it's loaded and translation is done (this time it's program only
translation)
As i remember those all functions are inside one class ,and
initialization is done be instantiatie class object (which is destroyed
automatically at the program end)
Agreed.
Notes:
- This is all non visual code, so eventually should go to the FCL/RTL.
- How to setup the default search paths for the various platforms.
- Packages can provide their own search paths for their own .po files.
- How to translate. The .po files via gettext uses the original text as key.
But sometimes it would be better to use the resourcestring name as key.
I have similar ideas, but no time to write them all down.
IMHO moving translations to the LCL is a first step.
I will start working on that first.
Vincent.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
