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?
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.
- 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.
Vincent.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
