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