Error: Import of string <front> was skipped

Created on 15 October 2018, over 6 years ago
Updated 10 January 2025, 21 days ago

When enabling the module with Drush, I get the following error:

[ok] Checked translation for eu_cookie_compliance.
[ok] Checked translation for eu_cookie_compliance.
[ok] Checked translation for eu_cookie_compliance.
[ok] Checked translation for eu_cookie_compliance.
[ok] Downloaded translation for eu_cookie_compliance.
[ok] Imported translation for eu_cookie_compliance.
[ok] Downloaded translation for eu_cookie_compliance.
[error]  Import of string "<front>" was skipped because of disallowed or malformed HTML.
[ok] Imported translation for eu_cookie_compliance.
[ok] Downloaded translation for eu_cookie_compliance.
[ok] Imported translation for eu_cookie_compliance.
[ok] Downloaded translation for eu_cookie_compliance.
[ok] Imported translation for eu_cookie_compliance.
[notice] Translations imported: 77 added, 59 updated, 0 removed.
[warning] 1 disallowed HTML string(s) in files: translations://eu_cookie_compliance-8.x-1.2.de.po.
[warning] Message: One translation string was skipped because of disallowed or malformed HTML. 
See the log for details.

[notice] Message: 4 translation files imported. /77/ translations were added, /59/ translations 
were updated and /0/ translations were removed.
🐛 Bug report
Status

Closed: works as designed

Version

1.2

Component

Code

Created by

🇩🇪Germany markdc Hamburg

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇩🇪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.

Production build 0.71.5 2024