[Harbour] SF.net SVN: harbour-project:[10979] trunk/harbour

[Szakáts Viktor]

Okay I see your points. I'll rethink the process.

For me reordering occured for hbmk2.prg which is a one
file project, I'm not sure what I'm doing wrong, but it
was completely changed after doing a merge with -m. It's
also visible in my committed diff.

One other problem is that i18n/*.pot option does only
work on *nix systems. I'd be great to add equal support
for rest of OSes.

Brgds,
Viktor

> 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 at harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour