Translations: Use substitutions instead of concatenations

[hoffie]

Describe the improvement

Some strings currently use concatenations. Example:

jamulus/src/clientsettingsdlg.cpp

Line 183 in 41be42d

QString strSndCardDriverSetupTT = tr ( "Opens the driver settings. Note: " ) + APP_NAME +

To Reproduce

Could probably use something like grep -Po 'tr\s*\(.*\).*\+.*' src/* to find other places (this will still yield false positives such as HTML concatenation, which should be OK I think).

Expected behavior

This was suggested by @pljones in #1097 (comment):

Would it not be easier for a translator to have the full text with substitutions (so, QString ( tr ( "Hello, %1" ) ).arg( getName() )..., giving the context)? Here there are three pieces, one starting with a measurement unit.

Additional context
Must only be changed after 3.7.0 is completed.

[hoffie]

Hmm, even HTML concatenations may lead to inconsistent spacing:

jamulus/src/clientsettingsdlg.cpp

Line 223 in 41be42d

"<li>" + tr ( "Enabling " ) + "<b>" + tr ( "Stereo" ) + "</b> " + tr ( " mode "

In this case, it's a double space and will most like not matter in practice as I assume it will be condensed to one as it would be in ordinary HTML. But still...

[pljones]

Which would have to become something like...

QString ( tr ( "%1Enabling %2Stereo%3 mode%4" ) ).arg ( "<li>" ).arg ( "<b>" ).arg ( "</b>" ).arg ( "</li>" );

... I think... And the the translator sees "%1Enabling %2Stereo%3 mode%4" without the args... does that help? Hm.

Would providing tr( "Enabling <b>Stereo</b> mode" ) be easier? If more complex translations (this seems like it's not one...) are needed, then having the flexibility to adjust where the formatting occurs might be useful. But does the XML support embedded HTML?

[hoffie]

And the the translator sees "%1Enabling %2Stereo%3 mode%4" without the args... does that help? Hm.

I don't think so. :(

Would providing tr( "Enabling <b>Stereo</b> mode" ) be easier? If more complex translations (this seems like it's not one...) are needed, then having the flexibility to adjust where the formatting occurs might be useful.

As long as we stick to simple HTML (I guess bold formatting and line breaks are the most common reason for using it?), this would be way more readable (although we would have to check translation PRs thoroughly for them not to break HTML).

But does the XML support embedded HTML?

Don't know / haven't tried.

I'm not currently working on this and I'm therefore removing myself as the assignee.

[ann0see]

@BLumia since you we’re the last person doing a full translation of the software. How many places do need to be updated in order not to have split out tr()?

I think this issue should also be documented in the style guide in CONTRIBUTING.md

[pljones]

I think this issue should also be documented in the style guide in CONTRIBUTING.md

I think that is probably the best idea in this issue :).

[BLumia]

this will still yield false positives such as HTML concatenation, which should be OK I think

jamulus/src/clientsettingsdlg.cpp

Line 223 in 41be42d

"<li>" + tr ( "Enabling " ) + "<b>" + tr ( "Stereo" ) + "</b> " + tr ( " mode "

This should also be avoided. If using HTML markup is a must, just also include HTML tags in the source strings. Letting translators see these markup tags is not a bad thing.

e.g. tr("Enabling <b>Stereo</b> mode") is better than tr("Enabling %1 mode").args("<b>"+tr("Stereo")+"</b>") IMO. Translator will know the word Stereo is emphasized and all they need to know is keep the HTML tag in their translated string. Programmer also won't need to write a lot of args() only because of there are HTML tags in the source string.

How many places do need to be updated in order not to have split out tr()?

I already updated those I can find that have this issue, there might still be some strings that need to be corrected but I'm not sure about the amount.

I think this issue should also be documented in the style guide in CONTRIBUTING.md

Totally agree since there are some strings with this issue introduced in new commits, contributors should be aware this can be an issue when they want to add new strings to the program.

[BLumia]

Additionally, if the place we need to display rich text is a QLabel or QMessageBox, and we are on Qt version >= 5.14, we can also use markdown :)

QLabel* label = new QLabel("test *markdown*");
label->setTextFormat(Qt::MarkdownText);
label->show();

[hoffie]

Additionally, if the place we need to display rich text is a QLabel or QMessageBox, and we are on Qt version >= 5.14, we can also use markdown :)

That's certainly good to know. Currently we still support older Qt versions though.

[softins]

this will still yield false positives such as HTML concatenation, which should be OK I think

jamulus/src/clientsettingsdlg.cpp

Line 223 in 41be42d

"<li>" + tr ( "Enabling " ) + "<b>" + tr ( "Stereo" ) + "</b> " + tr ( " mode "

This should also be avoided. If using HTML markup is a must, just also include HTML tags in the source strings. Letting translators see these markup tags is not a bad thing.

e.g. tr("Enabling <b>Stereo</b> mode") is better than tr("Enabling %1 mode").args("<b>"+tr("Stereo")+"</b>") IMO. Translator will know the word Stereo is emphasized and all they need to know is keep the HTML tag in their translated string. Programmer also won't need to write a lot of args() only because of there are HTML tags in the source string.

Yes, agree 100%, and Qt Linguist fully supports this too. It recognises and highlights embedded HTML:

Although it doesn't appear to warn the user if the translated string differs in the HTML markup.

It might be quite an undertaking to change this project-wide though (although probably worthwhile). It would need to be done while other activity is fairly quiet and then included without delay, or rebasing could be very arduous!

[pljones]

Although it doesn't appear to warn the user if the translated string differs in the HTML markup.

That's not necessarily bad -- if, say, there was a German translation of the qJackCtl documentation, changing the href of the link might be appropriate.