Not localizable

[d-musique]

Hello. This package is impossible to localize as it is into other languages.

One may attempt to redefine the strings in a custom header and wrap these into gettext() calls. There is an obstacle: the code relies on these strings being defined as literals, and build fails.

Besides, it would be more helpful if texts were already wrapped in _("text") fashion; then the translation tools can readily scan these strings, making the task a lot simpler.

[aiekick]

Hello,

what do you mean by "as it is into other languages" ?

you have a Config file where you can redefine all literals to that form _("text") if you want.

that not an issue.

[d-musique]

Look here for instance.

https://github.com/aiekick/ImGuiFileDialog/blob/a7847af76cd7c7335d33a9ff741a5cbf58471436/ImGuiFileDialog.cpp#L3919

Given that this code uses preprocessor-based string concatenation, replacing it with a dynamic expression fails. This scheme occurs multiple times.

I'm not sure, but maybe these ID concatenations could be replaced by PushID() / PopID() pairs.

[aiekick]

maybe you need one config file per localisation, because you will have the same issue for many other ImGui based lib.

theses funcs uses const char* event if i remove this "##tag" you will have the issue..

but what is your localisation system ? what language / framework ?

[d-musique]

My file ImGuiFileDialogCustomConfig.h is similiar to this

#include "Utility/I18n.h"

#define createDirButtonString "+"
#define okButtonString _("OK")
#define cancelButtonString _("Cancel")
[...]

and the macro _ is defined to gettext. Gettext goes read the translated string from a file on disk and returns it as a char*.

In fact, I can affirm that rewriting that "##tag" concatenation in a compatible way will fix the problem. But the edited code I have in my tree is kinda unclean for now, I can remake it into a clean PR later.

[aiekick]

you localization system seem to be a performance killer. Are you sure you understand how ImGui is working ?

you system seem ok with many classic gui like QT, who is not call these _() each time. but for ImGui its crazy...

So you need to be smarter and pre calc the most of things for a fast display.. like have a class with many const char*, but a call to _() at each frames ???

[d-musique]

There isn't slowness. Texts will always be cached after the first access. It's just implementation detail anyway. This is how state-of-the-art i18n works.