On Sat, 01 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
> Pls find attached high level i18n_* functions. (untested) > hb_i18n_fnametemplate( [<newtemplate>] ) -> <oldtemplate> > hb_i18n_baselang( [<newlangid>] ) -> <oldlangid> > hb_i18n_activelang( [<newlangid>] ) -> <oldlangid> > hb_i18n_gettext( <cText> ) -> <cTranslatedText> > hb_i18n_gettextlang( <cText> [, <langid> ] -> <cTranslatedText> > Not strictly intended for the core as it has some > parts I wouldn't like to be included there, f.e. the > file template system. Maybe a callback block would > be better to pull a specific trs table however the > user wants it. Comments are welcome. Looks fine but domain support is a must. It has to be also updated for MT mode. Here we should define what is global and what thread local. Resources like translation tables should be global but base lang/active lang should be thread local. Please also remember that we have HB_SETLANGUAGE()/_SET_LANGUAGE. It can be used instead of introducing new settings. The MT access will have to be protected so we will have to define what can be changed at runtime, f.e. do we allow manipulations on translation table body? If yes then which ones? The next problem which should be resolved is CP support. I do not like to have copy of all translation tables for each CPs just like we have msg* modules so we should think about adding support for CP translation. To reduce RT overhead we can add function to translate existing trnaslation table. I do not think it will be big problem. Finally if we want to introduce to Harbour core code full i18n support then IMHO we should also add C API for it. I think that some upper level functions like translation tools or .pot files manipulations can be written as .prg code so user can easy extend it. The low level functions and hb_i18n_gettext*() for RT performance should be written in C. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour