Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
wxSmith non i18N strings with international characters are not correctly managed
Bug Killer:
In nightly build 13186
In wxSmith/wxscodinglang.cpp
In wxString WxString(wxsCodingLang Lang, const wxString& Source, bool WithTranslation)
strings with international characters are not considered alphabetic. So, string prefix is always _( whichever is the prefix chosen in wxSmith settings for non i18N strings.
To fix comment out :
if (DoTranslation)
{
// Check if translation is really needed. For now, just check if it contains alphabetic chars
if (std::any_of(Source.begin(), Source.end(), [] (wxUniChar c) {return wxIsalpha(c);}))
{
Prefix = "_(";
Postfix = ")";
}
}
Miguel Gimenez:
Strings with international characters ARE alphabetic (wxIsalpha() returns true for them).
If you comment out that code no string from wxSmith will be translatable.
If this bothers you then disable global I18n support in wxSmith settings or disable local I18n support in the affected wxSmith window.
Bug Killer:
Thanks for the explanation. C::B 20.03 behaviour was different.
Is there a way to disable internationalization for all dialog, panels and frame ?
Why strings with international characters are not displayed when the prefix is _( ?
Miguel Gimenez:
--- Quote ---Is there a way to disable internationalization for all dialog, panels and frame ?
--- End quote ---
As said before, disable global I18n support in wxSmith settings or disable local I18n support in the affected wxSmith window.
--- Quote ---Why strings with international characters are not displayed when the prefix is _( ?
--- End quote ---
I do not know, probably wxWidgets' GetTranslatedString() does not accept non-ASCII strings.
sodev:
GetTranslatedString() works with any narrow string, it does not work with wide strings, but in case of error it simply returns the input value and not empty string.
On windows, two reasons come into my mind, but both apply to narrow strings, so not only the _() macro would be affected. Either the compiler uses a wrong encoding to read the source file and interprets the strings as garbage or the execution charset of the application cannot represent the characters. wxWidgets always assumes narrow strings use the execution charset and converts them to its internal unicode representation, if that fails, it produces an empty string.
Navigation
[0] Message Index
[#] Next page
Go to full version