Malformed HTML in translatable string (block_content_help)

Good catch... and given that the malformed HTML is a bigger issue than the need for fixing the translation of same, I'd argue that it might better be fixed now, rather than waiting for the 8.4 release. I don't think fixing this is particularly disruptive compared to the benefit of fixing it and it would mean that any translations of this string that are made between now and then would not be broken (at a later time).

I hesitate to change the "version" selector, but I really do think that it's more appropriate to commit this bugfix earlier than the next major release, rather than wait just because of the translation issue.

Anyway, I think this looks safe to mark as RTBC. :-) (Note that the code copied to the issue description already has the correction applied, so might be confusing to people who are looking for the problem. ;-) )

Someone more knowledgeable with the Locale / Potx / l.d.o setup should confirm this, but as far as I know strings with invalid HTML are ignored the translation extractor anyway, so this would actually be a string addition, not a string change.

Fix looks good by the way.

@tstoeckler I think that only strings which include disallowed HTML tags are not extracted. (Edit: I looked at the corresponding de.po file and found that string does not exist at all—and there are many untranslated strings, so I assume you are right and the translation, below, found in the es.po file was manually added. Seems like the Spanish translation team has covered almost everything, including fixing this malformed HTML in their translation.)

So I still think it's better to fix it earlier than wait for many other languages to have a translation of this malformed HTML. I'll change the target to 8.3.x-dev and see what core committers think about this instance.

This is an excerpt from the drupal-8.3.0.es.po file currently available on https://localize.drupal.org/download:

"The Custom Block module allows you to create and manage custom "
"<em>block types</em> and <em>content-containing blocks</em> from the "
"<a href = \":block-library\" >Custom block library<a/> page. Custom "
"block types have fields; see the <a href=\":field-help\">Field module "
"help</a> for more information. Once created, custom blocks can be "
"placed in regions just like blocks provided by other modules; see the "
"<a href=\":blocks\">Block module help</a> page for details. For more "
"information, see the <a href=\":online-help\">online documentation for "
"the Custom Block module</a>."
msgstr ""
"El módulo de bloques personalizados te permite crear y administar "
"<em>tipos de bloques personalizados</em> y <em>bloques de "
"contenido</em> de la <a href=\":block-library\">Librería de bloques "
"personalizados</a>. Los tipos de bloques personalizados contienen "
"campos; ver la <a href=\":field-help\">ayuda del módulo Campos</a> "
"para mayor información. Una vez creados, los bloques personalizados "
"pueden ser colocados en regiones justo como los bloques provistos por "
"otros módulos; ver la página de la <a href=\":blocks\">ayuda del "
"módulo Bloques</a> para detalles. Para mayor información, ver la <a "
"href=\":online-help\">documentación en línea para el módulo de "
"Bloques Personalizados</a>."

Changing target for delivery of this fix to the current dev branch (8.3.x-dev), since the affected string is not automatically parsed and this change should not affect many translations. Hopefully we can just fix the few translations that would be affected (ones where this string was manually added by a translation team).

Committed and pushed 38c553d to 8.4.x and 3ec9fb5 to 8.3.x. Thanks!

Since this is a bug fix we need to fix this in 8.3.x - normally we don't change translatable strings in a patch release. Nice discussion and sleuthing of the backportability @LoMo.

@alexpott Great! I've gone ahead and downloaded other larger .po files and searched them to see which of the other very active translation teams had already translated (and corrected) that string and found eight other languages besides Spanish, so I'll go ahead and contact an active member on each of those nine translation teams to let them know that the "new string" is already translated. That should help minimize the disruption that back-porting this fix might cause. ;-)

@zaporylie Oh, of course... I didn't think of that, but it's not surprising, given you reported and fixed this. ;-)

That said, I did contact someone on the .pl translation team who appeared to be active (just so that they would know that this had been committed and would break translations of the malformed string... and to help make sure nobody spent time re-translating when the "new string" appeared).