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