On Tue, 2007-10-02 at 16:54 +0200, Mattias Gärtner wrote:
> Zitat von Luis Rodrigues <[EMAIL PROTECTED]>:
> 
> > > Basically you enable the experimental LRT code *and* remove the working 
> > > and
> > used
> > > RST code. So it breaks existing packages/projects. This must be improved.
> > See
> > > below.
> >
> > I didn't remove the RST code, .rst is generated by fpc so it still gets
> > generated. I only updated the generation of the PO files, I just
> > replaced TMainIDE.ConvertProjectRSTFiles by a UpdateProjectPO
> 
> At the moment the IDE converts the .rst files to .po files for packages and
> projects into the RST Out directory, which can be setup by the user. This is
> what I meant with RST code.
> The new code must at least provide something similar, otherwise it is a
> regression bug.

Ok just reverted to old dialog. But I'm still not sure this is this
usefull.

> 
> 
> > > 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.

> 
> 
> > >
> > > It always recreate the .po file, even if nothing changed. It should at
> > least
> > > check the .po file. Otherwise a readonly file will stop the update.
> >
> > It just updates the .po with the strings with are not there, now I added
> > a check to only rewrite the file if changed.
> 
> Maybe a check should be added, if any of the input files (.lrt/.po) is newer
> than the output file. If not then skip the update. Or even better: It should
> only read the changed input files to update the output file.

Now checks with fileage, only updates if file newer that .po

> 
> 
> > >
> > > Some error checks and dialogs are missing (e.g. failing to read/write a
> > file).
> >
> > Should I check if the .rst .lrt were correctly opened and if could write
> > the .po?
> 
> You can enclose the TStringList.LoadFile/SaveFile with try..except dialog end;
> or use the functions of the ide/dialogprocs.pas unit.

Done, also created SaveStringListToFile

> 
> 
> > > The .po file is created in the source directory and has the name of the
> > project.
> > > This should be configurable. For example the .po file should have the same
> > name
> > > as the target executable, and/or the .po files should be placed into a sub
> > > directory. It should at least check if the old 'RST/OutDir' config 
> > > variable
> > > exists and use that as default.
> >
> > Ok now I respect RST/OutDir (if available) and save the .po as
> > ExecutableName.po.
> >
> > Since  DefaultTranslator.po checks for the existence of a
> > ExecutableName.po file the .po file will always have to be called
> > ExecutableName.po
> >
> >
> > > I forgot:
> > > What about packages?
> > >
> > > The old RST code works with packages too. If a package is compiled, the
> > package
> > > files should be checked, not the project files.
> > >
> > As stated above the RST is working. I will look into packages next.
> 
> Great.

About packages I will do the same this as for projects.

How should the packages .po files be integrated into the
application .po?
Should they just be called packages.po and merged all together?
Is some languages are already translated how should that be handled?

regards,

Luís

> 
> Mattias
> 
> _________________________________________________________________
>      To unsubscribe: mail [EMAIL PROTECTED] with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives

Attachment: t2.patch.gz
Description: GNU Zip compressed data

Reply via email to