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
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
