On Tue, 05 May 2009, Szak�ts Viktor wrote:
Hi,
> 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.
I think the above procedure is wrong. -a option cannot replace -m one
used to merge many different files into single one.
I used different procedure. I compile my .prg files generating .pot
files into some directory, f.e.:
hhcmp -n -w3 -es2 myprg1 -ji18n/
hhcmp -n -w3 -es2 myprg2 -ji18n/
Then I merge all files into single one:
hbi18n -m -omyprog.pot i18n/*.pot
and I have myprog.pot which can be distributed with my application and
updated by users. If some wants to merge it with old translation then he
can simply make
hbi18n -m new/myprog.pot old/myprog.pot
Now he can also make:
hbi18n -a new/myprog.pot old/myprog.pot
or even:
hbi18n -a new/myprog.pot old/myprog.hbl
to add only still existing translations from the old file.
> 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).
I do not think it's good idea to separate compilation process from
generating .pot files. It will reduce the functionality like automatic
updating of generating PCODE and can be source of mistakes like .pot
files generated for different .prg code then PCODE due to some modifications.
I also do not think it's possible to implement it without integrating
compiler and PP with hbi18n, f.e.:
#command OUT <*msg*> => QOUT( hb_i18n_gettext( #<msg> ) )
OUT Hello World !!!
or:
#ifdef NO_I18N
#xtranslate _( <msg,...> ) => hb_i18n_gettext_noop( <msg> )
#elif defined( I18N_TEST )
#xtranslate _( <msg,...> ) => hb_i18n_gettext_strict( <msg> )
#else
#xtranslate _( <msg,...> ) => hb_i18n_gettext( <msg> )
#endif
#ifdef VER_1
? _( "Hello World !!!" )
#else
? _( "Hello Jimmy !!!" )
#endif
It means that the new hbi18n will have to replicate nearly whole compiler
job with exactly the same compile time switches which can interacts with
existing macros and conditional code compilation.
I do not see any improvement in such solution but rather potential source
of problems. The only one think which can be usable in some cases is adding
special additive mode to -j switch so existing .pot file will be open and
new translations added. It can be used for clean compilation to collect
translation strings from many different .prg files into single .pot file
without calling hbi18n with -m option. It will eliminate one step but
if the old .pot files is not erased at compilation startup then it will
collect some garbage information like old and not longer existing
translations or wrong source code line numbers mixed with current ones
so it's also not perfect solution. Just an alternative option which may
be usable in some cases if some does not want to call:
hbi18n -m -omyprog.pot i18n/*.pot
> 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.
We will have to agree some type of comments in .pot files which will
be merged.
> - 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.
It will depend on the method of updating the .pot files.
For me it does not change at all.
> 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,
We can add any extensions we will find interesting and usable but
personally I do not see any way to separate .pot file generation
from preprocessing and compilation process without intorducing very
serious for me limitations/problems.
> .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.
I always used to build them during compilation process when I create
final binaries to be sure that they are synced with source code.
Only in some developing process I do not generate them but in such case
I simply do not use -j switch.
BTW I've found one problem with current -j<dirname>/ switch.
If you pass more then one .prg file to harbour compiler then
only the 1-st one uses -j<dirname>/ and all others use -j.
It should be fixed.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
