Hi Przemek, > Do you think it's possible to speed that up? It may be an option to > > merge POTMerge() and AutoTrans() into one, as they are called next > > to each other in this scenario. ( That may also need reverse logic > > to retain existing translations. ) > > It should not give noticeable improvement. If you try to execute autotrans > for each .pot file then maybe in the most optimistic case you will reduce > the time by half - IMHO not worth to make the internal logic more > complicated > then necessary. If you first merge all .pot files and then call autotrans > for such merged new and old file then it can give rather very small > improvement which can be reduced if you compile the old .pot file to .hbl > and use it instead of the new one. > Merging all .pot file into single one before executing autotrans seems to > be optimal solution and can be easy adopted work with -j+<file> compile > time switch if we add it. -j+<file> means add new translation to the ones > which already exist in <file> what should finally give the same translation > set as after merging all .pot file generated for each .prg module.
Sounds like a useful option. There is one problem again though: Incremental builds. In this mode -j+ would only create .pots for files actually recompiled, while we'd need the full set in order to make it work with current autotrans logic. Here maybe reversing the logic so that existing .po becomes the main input and merged .pots are processed into the existing one by adding new items, and optionally deleting no longer existing items, could give better results. > Probably the one thing which can give important speed improvement when > you merge many .pot files is reusing hIndex in __I18N_POTARRAYJOIN() for > each next file. This can be done in few lines and I'll commit it ASAP. > Please check how it will change the time of: > hb18n -m *.pot -oresult.po > executed against your 500 .pot files. I've retested hbmk2 (after applying your change to it) and it dramatically increased performance, many thanks for the quick tweak. Now it's usable for full rebuilds, but we'd still need to do something about incremental builds, the delay is too high (extra ~15s) for simple rebuilds, even if only source file has changed. > After this modification it will be hard to find sth what can reduce > the cost by better algorithm. We can still reduce it a little bit, f.e. > by replacing some [AH]Clone() with simple assign or reusing some already > decoded data but it will not reduce the cost level. > Anyhow the whole process can be still improved by rewriting it in C using > different internal structures. The question is if we want to make it. > Current .prg code give us a chance that we will find developers who add > some extensions like tools for manual translations of .pot files by users. > Just simply not everyone knows C. See my above thoughs. Do you think it's possible to do the 'reverse' logic I was referring to? To put it simply, I'd like to be able to update my full .po (containing translation) with one simple .pot file. In this mode only new strings should be added. In another (full-sync) mode, which can only occure with merged .pot files, deleted items are also dropped (this is basically what we already have). So what we'd need is a new method to update .po with one source .pot. [ Here the compromise is that the .po file will contain even deleted strings until we don't issue a full sync, but in practice this seems to be okay to me. ] Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
