Mattias Gaertner wrote:
> On Thu, 20 Oct 2005 23:36:38 +0200
> Vincent Snijders <[EMAIL PROTECTED]> wrote:
>
>
>>Mattias Gaertner wrote:
>>
>>>On Thu, 20 Oct 2005 14:11:37 +0200
>>>Vincent Snijders <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>>Alexandre Leclerc wrote:
>>>>
>>>>
>>>>>On 9/19/05, Mattias Gaertner <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>On Sun, 18 Sep 2005 19:09:35 -0400
>>>>>>Alexandre Leclerc <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On 9/16/05, Mattias Gaertner <[EMAIL PROTECTED]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Feel free to learn from the code. The code is too IDE specific, to
>>>
>>>put >>>>>it into the LCL, but if you want to use parts of it into your
>>>program, >>
>>>
>>>>>I >>>see no problem, because we will do the same eventually and then it
>>>>>will >>>be LGPL anyway.
>>>>>
>>>>>
>>>>>>>I would also be interested in such a tool somewhere in the futur for
>>>>>>>potential commercial applications. But LGPL would be a problem,
>>>
>>>unless >>>>it is released under the same modified clause as the LCL.
>>>
>>>>>>Sorry. When I said, it will be put into the LCL, it will of course get
>>>>>
>>>>>the >same license.
>>>>>
>>>>>
>>>>>Oh! I should have understand this one.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>(If someone lead the project, I might be able to give some help
>>>>>>>coding/testing in my free time.)
>>>>>>
>>>>>>This month I have not much time, but I will try answering questions.
>>>>>
>>>>>
>>>>>Ok, I stay avail. Raise a flag when you need some help.
>>>>>
>>>>
>>>>In order to fix issue 1278, LCL applications need to load the lcl.xx.po
>>>>file and use it to fill the resourcestrings (rsPickDate in this case).
>>>>
>>>>I took translations.pas, renamed it to lcltranslations and put it in my
>>>>project dir. Then I moved the function TranslateUnitResourceStrings to
>>>>the interface section and commented some bodies of unused procedures.
>>>>
>>>>I added:
>>>> TranslateUnitResourceStrings('LclStrConsts',
>>>> 'c:\lazarus\source\lazarus\lcl\languages\lcl.%s.po','it_IT','it');
>>>>to the main project source and then the Italian resourcestrings are
>>>>loaded.
>>>>
>>>>How do I proceed now?
>>>>
>>>>Should I clean up lcltranslations.pas a bit and add it to the LCL?
>>>>Mattias, will you (as author of translations.pas) change the license
>>>>then? Or had you different plans with translations in the LCL?
>>>
>>>
>>>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)
Best regards
Boguslaw Brandys
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
