OK so example:
$editing_menus .= '<ul><li>' . __( 'Add one or several items at once by <strong>selecting the checkbox next to each item and clicking Add to Menu</strong>' ) . '</li>';
There are no weird entities in this string at all.
Now check crowdin for that string in German language:
The punctuation warning is OK, the “Translation does not have space after ;” is not OK and is due to the unexpected
„ appearing in the translation but not in the source
This issue repeats for hundreds of strings.
Theright thing is to have apostrophes here because the string should read
'Add one or several items at once by <strong>selecting the checkbox next to each item and clicking "Add to Menu"</strong>, to denote the “Add To Menu”, but it is not the case in the source and thus, there is no reason at all for it to appear in a proposed translation.
The issue is not limited to German.
the only I can imagine is that the original translation PO uploaded does have those apostrophes but those get badly formatted by crowdin (since we probably shouldn’t encode them?)
I am not sure.
What I am sure, is that we need to document an approach to be taken for those, and then apply the same rule in all cases.
IMO, if the original has no apostrophe the translation should not either
With the exception of things like “L’immagine” or such things, but, that is also not a cool way to write Italian, its strictly speaking lazy grammar, proper school grammar is “La immagine”.
Only that no one actually uses the long form… so again here we need a rule as of how those apostrophes must be encoded or written out plain?
<q> or any other HTML in general should not work in a translation if properly escaped.
So unless the original source has HTML in it, we should never add HTML to a translation. It’s the whole point of esc_html_e or esc_html__ to remove those tags, and it is is (or should?) be widely used on localised strings.
Only if not possible in any other way HTML should be localised.
I know that core does literally not care about this and does often not even escape strings that are localised, but dare you deliver a plugin with such string!
So we should probably just not do it in core either, being it the “be an example” tool/source and all that