Thinking about it maybe retaining comments and marking addition date/time isn't that important, as it's just as easy to search for 'msgstr ""' strings. So that section of my prev mail can be ignored.
Brgds, Viktor On Tue, May 5, 2009 at 1:42 PM, Viktor Szakáts <harbour...@syenar.hu> wrote: > Hi Przemek, > I'd be happy if we could further streamline the workflow. > Now I realized some practical issue with current Harbour -j > option. While it works perfectly well, I think it'd better to > integrate it with hbi18n -a option and also to keep old > translations. > > First I was thinking if we could somehow pull the -j functionality > into a callable library function: __i18n_extractstring() (name > tentative). This way we could integrate it into hbi18n, so the > process could be made as one step instead of the current flow, > which looks like this: > > 1) harbour -j for each file to generate one .pot for each source > 2) hbi18n.exe -a new.pot <all new.pots> <all old.pots> > 3) rename new.pot to unified app .pot name (f.e. app_hu_HU.pot) > 4) delete old and new pots except app_hu_HU.pot. > > Instead it could be something like this: > 1) hbi18n.exe *.prg *.ch -oapp_hu_HU.pot -del=app_hu_HU.unused.pot > (this would automatically pickup existing app_hu_HU.pot and use > it to merge existing translations, maybe some comments and even > ordering of items, if possible). > > Some more thoughts I've bumped into along the way: > - Date/time of addition of new translation entries would be a useful > info to see in comments. > - To work smoothly with translation files (like making diffs and > moving inside the file with familiarity) IMO it's best to retain > some sort of ordering of the entries, plus also to retain certain types > of comment (like date/time of addition). Currently the order of > msgid/msgstr pairs will change completely after doing a > refresh-from-source > session. > > Maybe there are better ideas. Current system have one advantage: > source file to .pot conversion can be integrated in normal build process, > which is good to keep unified .pot updated, but IMO the rest of the > process is not easy enough to automatize. In my experience though, > .pot files aren't rebuilt all the time with the source code itself, it's > rather something rebuilt occasionally before translation sessions. > Well, any thought is welcome in this area. > > Brgds, > Viktor > > On Tue, May 5, 2009 at 11:06 AM, Przemyslaw Czerpak <dru...@acn.waw.pl>wrote: > >> On Tue, 05 May 2009, Szak�ts Viktor wrote: >> >> Hi, >> >> > Thanks a lot, it works great. I've successfully updated hbmk2 HU >> > translation with it already. >> >> Thanks for the confirmation. >> It works in a little bit different way then the option you were talking >> about. It allows to use any existing translations also from different >> programs to make some automatic translation. >> You were asking also about a little bit different functionality: >> compare two .pot files (current empty one and the old one with >> translations), translate in the current .pot file sentences which >> are translated in the old one and store unused translations in old >> .pot file in some new file which can be used as translation source >> for manual or automatic translation in the future. >> If you think it's really important then we can try to add also such >> option to hbi18n though user can reach similar functionality by merging >> all .pot files with translation into one big file to use it as dictionary >> for -a option. >> >> best regards, >> Przemek >> _______________________________________________ >> Harbour mailing list >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > >
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
