Hi Przemek,
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.
Yes. Possibly new threads should inherit from parent threads. Cache should naturally stay global, and this will need mutex protection.
Please also remember that we have HB_SETLANGUAGE()/_SET_LANGUAGE. It can be used instead of introducing new settings.
Okay. If so, we need to move this whole thing to C level. This code is rather just a prototype anyway.
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?
No, I think the only means to change a translation body is to force a reload. We may add such cache flushing (not very elegant), or forced loading (not elegant either), or just passing a flag to the load function to signal if the translation is already cached and let the app decide what do to. Reload can be as easy as refill internals with passed in-memory table, if someone really needs dynamic stuff, but otherwise (in normal app code) translations very rarely change at runtime. So IMO, the design should allow it, but it shouldn't be optimized around it. Optimization should aim quick loading and quick text translation.
The next problem which should be resolved is CP support.
Well yeah.
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.
Dunno, I have my own conversion functions (slow, but they do the job), and relevant cp translation strings get loaded from the .lng files. This is not ideal, but does the job. We need to keep in mind that a given app can handle several languages at a time, f.e. while printing an invoice in English in Slovakia, obviously the progress message will be English, the rest Slovak (base lang HU). I didn't follow Harbour when CP support got implemented, so I don't know where it stands now, and if I could personally use it instead of local solution, or how could we connect to it. Anyhow it needs to be solved. I'm secretly hoping for Unicode, so part of this nightmare can be resolved forever. (part of because you still have parts of the world which needs non-unicode, like direct printing, so we will not get around the topic anytime soon).
Finally if we want to introduce to Harbour core code full i18n support then IMHO we should also add C API for it.
True.
I think that some upper level functions like translation tools or .potfiles manipulations can be written as .prg code so user can easy extendit. The low level functions and hb_i18n_gettext*() for RT performance should be written in C.
Yes, my C "fluency" is incomparable to yours, so maybe I'm not the best candidate for this job :) [ BTW, I'm currently very happy with the few low level functions now rewritten plus my local support for this area - in Clipper I was using a .dbf for translation -, so any Harbour development is fully detached from personal reasons, even the submitted code was made just for Harbour. Of course I'd be happier to use the Harbour parts as much as possible. ] I'll check where codepage support stands currently. See small attached test code for current state. Brgds, Viktor
testi18.prg
Description: Binary data
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
