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.

ImGuiFileDialog/ImGuiFileDialog.cpp

Line 3919 in a7847af

if (IMGUI_BUTTON(okButtonString "##validationdialog", ImVec2(okButtonWidth, 0.0f)) || m_FileDialogInternal.isOk) {

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.