translation strings were skipped because they contain disallowed HTML.

The function that tests if the translation string is safe can be found in /includes/locale.inc on line 828:

/**
 * Check that a string is safe to be added or imported as a translation.
 *
 * This test can be used to detect possibly bad translation strings. It should
 * not have any false positives. But it is only a test, not a transformation,
 * as it destroys valid HTML. We cannot reliably filter translation strings
 * on inport becuase some strings are irreversibly corrupted. For example,
 * a & in the translation would get encoded to & by filter_xss()
 * before being put in the database, and thus would be displayed incorrectly.
 *
 * The allowed tag list is like filter_xss_admin(), but omitting div and img as
 * not needed for translation and likely to cause layout issues (div) or a
 * possible attack vector (img).
 */
function locale_string_is_safe($string) {
  return decode_entities($string) == decode_entities(filter_xss($string, array('a', 'abbr', 'acronym', 'address', 'b', 'bdo', 'big', 'blockquote', 'br', 'caption', 'cite', 'code', 'col', 'colgroup', 'dd', 'del', 'dfn', 'dl', 'dt', 'em', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'hr', 'i', 'ins', 'kbd', 'li', 'ol', 'p', 'pre', 'q', 'samp', 'small', 'span', 'strong', 'sub', 'sup', 'table', 'tbody', 'td', 'tfoot', 'th', 'thead', 'tr', 'tt', 'ul', 'var')));
}

Testing the string you provided (both the german and the english) in a PHP block both return true. So it looks like these are not the stings that are causing this problem.

Please post back how this works out for you.

- Arie

Yes these are the allowed tags, all other tags are disallowed.

Since you can't reproduce the problem I'm setting this to fixed for now.

Feel free to reopen if the problem occurs again.

- Arie

Just in case that somebody stumbles about this here:

I can report this error when using "iso-8859-1" encoded po-files using German "Umlaute" (Ä,Ü,Ö). Just changed to UTF-8 encoding and everything get's nicely imported.

Just changed to UTF-8 encoding and everything get's nicely imported.

That comment just saved my posteror from troubles

before it said : 1811 translation strings were skipped... disallowed HTML.

after it said: 5 translation strings were skipped

Thanks!

I encountered this problem when importing the french 6.15 translation file, and I experienced 1650 or so strings skipped. I am running under windows. Changing the file's carriage returns to UNIX format fixed this problem for me - 4 strings only problematic now.

to JimP :

I have met the same issue :
How do you change the file's carriage returns to UNIX format ??

EDIT : Solved : on windows platform, use PsPad freeware (on http://www.pspad.com/)

I have the same problem. My translation contains HTML code and Drupal say's

x translation strings were skipped because they contain disallowed HTML.

I deleted the HTML tags in my translation and some are not imported yet :-(

All formats are lost, even with the help of where code appears :-(

Example from login_destination:
URL: (<b>IMPORTANT! If using a WYSWYG editor - ensure that you use its plain text mode! There is a link below the text box.</b> )

My translation without HTML tags :-(
URL: (WARNUNG! Wenn Sie einen WYSIWYG-Editor verwenden - stellen Sie sicher, dass dieser auf Reintext gestellt ist! Dort ist ein Link unterhalb des Textfeldes)

I can't use this part:
Es sollte entweder ein String-Wert oder ein Array wie in: return array('path' => 'node/add/video or alias', 'query' => 'param1=100&param2=200'); geben.

That's pity :-(

On admin/modules/install there is a original string that contains <br/> - missing space.
If you are having problems with translation - make sure to add it in a form of <br />.

Source code is:

To install a new module or theme, either enter the URL of an archive file you wish to install, or upload the archive file that you have downloaded. You can find <a href="@module_url">modules</a> and <a href="@theme_url">themes</a> at <a href="@drupal_org_url">http://drupal.org</a>.<br/>The following archive extensions are supported: %extensions.

In my case it also complain if i have used XHTML break: <br/>
when i switched to <br> it worked fine.

@#15 - The <br/> tag will work XHTML style, but it needs a space before the closing character like so: <br />