Request for conversion of QString("raw string") to QStringLiteral() or tr() methods

[SlySven]

Following on from #54 may I ask if it is possible to go through the whole edbee-lib library and convert all the uses of QString("some string possibly with %1 or more variable argument replacement").arg(1) to use either the:

• QStringLiteral(...) form if the string is used internally and not user visible
• tr(...) form if it will be user visible and require translation for use in non English(American) locales

Where a non-user visible constant QString is used as an argument to a function/method where a QLatin1String is a valid argument type the alternative QLatin1String(...) is also viable but it does not support the %1-%9 type variable (positional) replacement arguments that QStringLiteral(...) does.

Ideally for the second type above if the string is a form where plurals are significant e.g. "You have just deleted X paragraph(s)." it would be best if the %n form is used, i.e.:

tr("You have just deleted %n paragraph(s).", "", variableContainingValueForX)

I am requesting this because I am working on several aspects of I18n for the Mudlet project and in the near future I wish to add (run-time) GUI language selection (i.e. the user interface will be changeable to use another language) and part of that will use the Qt system for doing that which uses QObject::tr(); QCoreApplication::translate() or QApplication::translate() in C++ code to provide previously created translated versions of the (presumably "EN-us" or English{American}) source code strings. Obviously it would be beneficial if the editor can also support such a language change {ideally it will respond to receipt of QEvent::LanguageChange events to recreate any affected persistent texts - by regenerated them by reusing tr(...) but for strings that are frequently changed anyway e.g. status-lines it probably will not need that level of coding and things will work well enough just by using tr(...) each time such a string is modified}.

<aside> This is where #define QT_NO_CAST_FROM_ASCII is useful - if the macro is present in the source code it will cause any QString initialisations from raw strings to fail to compile (the compiler will moan about the constructor being private and thus inaccessible) and allow them to be pin-pointed and "fixed"...</aside>

[gamecreature]

I guess this is nice to have in edbee... 😃 Improving I18n abilities

[SlySven]

I was initially surprised how few of those strings count as User-visible and thus need translation for other languages but then as an editor widget I realised it was all about the users' text and really only help or warning messages would be seen from the widget itself...! 😮

One thing to be careful of where they are with tr(...) or translate(...) is to avoid building up sentences by appending fragments a bit at a time - that may not be workable where the order of those fragments actually need to change depending on the language - the Qt Documentation for their translation systems actually gives some examples of this Using Numbered Arguments - the example I recall compares the order of a couple of replacement variables (e.g. %1 and %2) and showing how they have to be the opposite order in Norwegian compared to English!

[gamecreature]

Thanks for your comment. I double checked the TextEditorController::updateStatusText. (This is probably the only place with real I18n in edbee.). It seems like QObject::tr is used correctly. It's true that the complete statusbar is build in fragments. But every fragment is a self-dependent piece with %1 and %2.

If you think something needs to be changed, please feel free tell me..

[SlySven]

Probably I'll get back to you when I have got Mudlet changing languages on the fly - and then it'll be seeking .ts files with completed translations that we can merge into our project... 😈

<aside>I need to write QEvent handlers into all the classes with a form/dialogue that will respond to QEvent::LanguageChange events by calling retranslateUi(this); to change the texts created in the class constructor {with the setupUi(this) call plus a separate method to regenerate any persistent (on widgets that are present long-term in the application) GUI texts that the application creates/modifies as it runs}...</aside>