On Wed, 03 Oct 2007 18:51:24 +0100
Luis Rodrigues <[EMAIL PROTECTED]> wrote:
> 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.
Maybe you misunderstand me: It should not work with both, it should
convert old settings to new settings.
I will do it.
> > > > 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.
> > > >
> > > > 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
Good.
But it also checks for non pascal files and it calls FileAge very
often. And the IDE provides some utility functions for faster checks.
I will improve it.
> > > >
> > > > 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
Fine.
> > > > 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.
Great and thanks for the help. But maybe wait a little until I committed
your patches with the mentioned improvements and minor fixes.
I'm currently testing the LRT code and found some odds:
- The grubber value as not initialized (crash) - Fixed
- It checked for doubles, but it didn't update the hash list, when
adding new values - Fixed. It is important, that .po files only contain
unique values, otherwise some po tools will crash.
- The OKStr function was very slow - Improved.
Never use Result:=Result+s[i]; to create a string, especially not to
create thousands of strings.
- The AddFiles2Po and UpdateProjectPOFile function did not return a
TModalResult value, to indicate if there was an error and if it was a
fatal error. Improved.
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.
> 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.
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
