"i18n" with Qt?

[m-7761]

I'm trying to divorce Qt from the i18n code.

translate.h defines transll (I don't know what the LL part stands for... it's in caps in TransLLCallbackF) but Qt uses some very specialized practices like QT_TRANSLATE_NOOP and tr and translate methods.

I'm wondering if this can be flattened out for the libmm3d and mm3dcore code to just use "TRANSLATE_NOOP" and either a revised "transll" or "translate" API instead. Or maybe ideally TRANSLATE instead, to illustrate that it's a decoration and not a function (so that transll doesn't have to be called wrapped in TRANSLATE_NOOP.)

To make this so whatever process is used to generate the message catalog (some custom Qt stuff?) needs to be told to use these new macros. I assume if Qt doesn't use gettext it can be reconfigured at least.

For the implui code it doesn't matter since that's at the UI level, but it should be able to use the same hook.

I'm also concerned that TransLLCallbackF uses std::string and feel that it should return an internal buffer to const char * and maybe keep up to three buffers, rotating, but generally consumers should assume this buffer is shared and do their own buffering if it's sensed to be a problem.

[m-7761]

EDITED: Brain went into autopilot.... what I meant to say RE:

I'm also concerned that TransLLCallbackF uses std::string and feel that it should return an internal buffer to const char * and maybe keep up to three buffers, rotating, but generally consumers should assume this buffer is shared and do their own buffering if it's sensed to be a problem.

Is that normally a message catalog is a table of prepared strings, which can simply be returned as is. If that's not the case, then it can be buffered. But in practice, by default, using std::string is a bad fit.