Great thanks for your fixes. My knowledge if the Lazarus internals is not that good :(
Before going on to packages I still have a problem: several components (including my TChat) have TStrings properties that should also be on the translation list. Should this be done for all od add a option in Project Options? Luís On Sat, 2007-10-06 at 16:04 +0200, Mattias Gaertner wrote: > 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 _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
