- 🇩🇪Germany joachim namyslo Kulmbach 🇩🇪 🇪🇺
Although the issue is now closed, I feel the need to contribute some context here.
A non-imported string within a translation, regardless of the language, always has a very negative connotation.
In order for translators to be able to translate a module 100% into another language, strings like should not be inside t() when a module is published. Translations are often made by beginners who may not know that all html tags that are not in https://api.drupal.org/api/drupal/core%21modules%21locale%21locale.modul... are rejected when imported into Drupal.
Therefore, in well-written modules, this should not be declared as a translation in the first place, just like div class=...
Once such a string has been read by the Potx module, it must remain unsuperseded, which means that the module in question cannot be translated 100%.
Basically, such errors as in this case are
1. to be reported in the issue que affected language and
2. to adapt the relevant place in the codec of the module concerned so that translators have the opportunity to translate the affected texts and the non-importable translation can be removed by the project supervisors of the respective language, without a part of the UI necessarily having to remain English if the language affected by the error has been activated as the display language on a website.Therefore, the statement that this is merely a warning that can simply be ignored is not correct.
Drupal currently supports over 100 languages. Therefore, a string that can be rejected during import because there is a possibility that it can be overridden, allowed and rejected during import is always a source of over 100 potential errors.
The workaround we have chosen here is to use HTML entities instead of tags during translation. This suppresses the warning message during import.
https://localize.drupal.org/translate/languages/de/translate?sid=1752228
In the best case scenario, the string should not end up on the translation server at all.