> > > Can it be a solution to reserve a certain namespace which can be freely > used > > for such user-defined gettext functions? > > Like: hb_i18n_gettext[_strict|_noop]*() ? > > Where '*' can be any valid postfix (with length > 0). > > These function names would be handled similarly to > > hb_i18n_gettext[_strict|_noop](), but would not be defined by > > Harbour itself, they'd be left for the user programs. > > Any opinions? > > If you want to use your own i18n functions then you can always > divide compilation and generation of .pot file. > For compilation use some: > #xtranslate hb_i18n_gettext( <x,...> ) => my_i18n_gettext( <x> ) > For generating .pot files does not use above PP rules and use -s > compiler switch.
Thought about it but this requires two distinct passes of compilation, and in recent days I went for one-pass hbmk2 integrated .pot/.po generation. I've yet to test it in practice though. I'll do this now that my translated texts are generated. The .po generation is somewhat fragile, but I'll see how it goes in reality. > I plan to add method which allow to register some basic functions at C > level > used by HVM and HB_I18N_GETTEXT[_strict|_noop]() so user can create his > own independent I18N implementation. If internal representation of > translation tables in alternative i18n implementation is not compatible > with Harbour one then it cannot use other Harbour HB_I18N_ functions > and has to provide own set of functions giving necessary functionality. > I plan to add real gettext wrapper to Harbour using alternative i18n > implementation. Definitely sounds good. I've committed the postfix solution in the meanwhile, looks quite benign and without any impact at runtime. My other issue is that I have multiple local gettext call flavours, so simply overriding hb_i18n_gettext() isn't sufficient here. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
