On Sat, 6 Oct 2007 14:47:59 +0200
Mattias Gaertner <[EMAIL PROTECTED]> wrote:
> On Wed, 03 Oct 2007 18:51:24 +0100
> Luis Rodrigues <[EMAIL PROTECTED]> wrote:
>
>[...]
> > > > > It collects the .rst and .lrt file for each project file -
> > > > > even if the file
> > > > does
> > > > > not belong to the project. Add a check
> > > > > (Project1.Files[i].IsPartOfProject).
> > > >
> > > > thanks done
> > > >
> > > > > It puts them all together into one stringlist and checks with
> > > > > a linear
> > > > search
> > > > > for doubles. That's too slow for the several thousand strings.
> > > >
> > > > You are right. just rewrote it, but the insert into .po is still
> > > > O(n*m) where m=number of items in .po and n number of total
> > > > strings in forms
> > > >
> > > > Do you think as is is acceptable or should I implement a better
> > > > method? I did it like this so I would not overwrite whatever the
> > > > user as already changed in .po between compiles.
> > >
> > > Too slow. For example the IDE has more than 3000 strings for 70
> > > forms. Other projects have hundreds of forms. So, it should work
> > > with m=10.000 and n=10.000. So, goal is O((n+m)*log(m)).
> >
> > I should have thought about that. Now I load everything into a
> > hashtable so it's O(m) where M is number of strings in modified
> > files.
>
> Good idea, but TStringHashList will not work in this case. Its
> internal hash function only uses the first 30 characters for the
> hash, but the lrt identifiers are often longer and starts with the
> same 30 characters. For example:
> TCustomApplicationOptionsForm.EClassName....
> So the TStringHashList will be a linear search here.
> Maybe I will improve it.
Sorry, I just saw, that it looks up the values, not the names. I guess
for values the problem is not that big.
>[...]
> Minor ToDos:
> - AddFiles2Po: Reduce the amount of temporary strings.
> - Replace TStringHashList with a TStringToStringTree or a hash list
> with a better hash function.
> - Use AddFiles2Po and something similar to UpdateProjectPOFile for
> packages. The existing packages, that already have .po files must
> combine the existing translations for the new system. This must be
> announced and described in the wiki.
>
> I just tested it, and found a design flaw.
> The currently created lrt files look like this:
> TFORM1.CAPTION=Form1
> TBUTTON.CAPTION=Button1
> TBUTTON.CAPTION=Button2
>
> Obviously the property paths are ambiguous. The only guaranteed path
> would be the full lfm path:
> TForm1.ComponentName.SubComponentName...SubPersistent.PropertyName
>
> I will improve it.
Done.
> > How should the packages .po files be integrated into the
> > application .po?
> > Should they just be called packages.po and merged all together?
>
> Good questions.
> In big project using third party packages you will easily get value
> clashes. And the same value must be translated differently depending
> on the context. So merging would be fatal.
> I'm not sure, how the lcltranslator should know, where to lookup up
> the translations for each unit. Maybe the IDE should create lists
> which unit belongs to which package/project and put this for example
> into an include file.
>
>
> > Is some languages are already translated how should that be handled?
>
> There is the tools/updatepofiles tool. It is not yet integrated
> into the IDE.
Has anybody ideas, suggestions, remarks?
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
