Problem/Motivation

As described in #3157707: Prevent strings unsafe for translation in code Drupal runs the function locale_string_is_safe (locale.module:1028) on strings before importing them. If this function returns FALSE then the translations are not imported.

The following list is used as allowed tags:

'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'

An example of a problematic string can be seen in https://www.drupal.org/project/drupal/issues/3157707#comment-13807217 which contains disallowed div tags and additionally contains styling information in the classes which shouldn't be translated.

When the Drupal core issue lands, PHPUnit tests will start failing when translatable markup is rendered with an invalid translatable string. However, since Open Social uses Behat for its tests we can not rely on this check and must come up with an alternative solution.

Steps to reproduce

Proposed resolution

Since we have all translatable strings in Open Social extracted to a .pot file already we could very easily make a small script within Drupal that runs all the strings from this file through the locale_string_is_safe function and reports any errors that we can file bugs for.

In the long term we may either want to contribute such a change to the POTX tool for Drupal's localisation infrastructure and/or include something in our own flow.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Kingdutch created an issue. See original summary.

kingdutch’s picture

kingdutch
he/him
Primary language English
commented

Thanks to Nico Grienauer for bringing this to our attention on Slack.

Kingdutch credited Grienauer.

kingdutch’s picture

kingdutch
he/him
Primary language English
commented

This time with the correct username for issue credits :D

grienauer’s picture

grienauer
he/him
Primary language German
Location Vienna
commented

thx for putting the issue together.
Some more Examples:
https://localize.drupal.org/translate/languages/de/translate?sid=2545777

<h4 class="section-title">Member results</h4><p>If you are searching for content, <a href="/search/content/{{ arguments.search_api_fulltext }}">click here</a></p>

could be split in several translateable strings like:
just "Member results" without the markup and classname and also the second sentence without the wrapper.

or https://localize.drupal.org/translate/languages/de/translate?sid=2744246

<p><a href="[message:author:url:absolute]">[message:author:display-name]</a> commented on a post on your <a href="[message:recipient-user-url]">profile</a></p>
<div class="comments">
<div class="post"><em>[social_comment:comment_author]</em> <small>• [social_comment:comment_date]</small>
<p>[social_comment:comment_text]</p>
</div>
</div>
<table class="btn-wrapp">
	<tbody>
		<tr>
			<td class="align-center"><a class="btn-link btn-link-bg btn-link-one" href="[social_comment:comment_reply_link_html]">Reply to this comment </a></td>
		</tr>
	</tbody>
</table>

could be easily converted in just:
[message:author:display-name]</a> commented on a post on your <a href="[message:recipient-user-url]">profile</a>
and Reply to this comment to remove all the table and markup stuff at all.

joachim namyslo’s picture

joachim namyslo
Primary language German
Location Kulmbach 🇩🇪 🇪🇺
commented

I don't want to grumble, but I like to gain some more attention here, please.

Over five years is a long time for a UI review. Is there a possibility of running this excellent feature here, at least against the current version of Open Social?

https://api.drupal.org/api/drupal/core%21modules%21locale%21locale.modul...

It would be nice if we could actively offer such a great product like Open Social in other languages in the future without having to do a lot of rework. And it would also be very welcome if we could close #2936699 after an in-depth review.

We still have The following SIDs not fixed:

https://localize.drupal.org/translate/languages/de/translate?sid=2545775
https://localize.drupal.org/translate/languages/de/translate?sid=2545777
https://localize.drupal.org/translate/languages/de/translate?sid=2553397
https://localize.drupal.org/translate/languages/de/translate?sid=2553399
https://localize.drupal.org/translate/languages/de/translate?sid=2553401
https://localize.drupal.org/translate/languages/de/translate?sid=2553403
https://localize.drupal.org/translate/languages/de/translate?sid=2565797
https://localize.drupal.org/translate/languages/de/translate?sid=2803455
https://localize.drupal.org/translate/languages/de/translate?sid=2803464
https://localize.drupal.org/translate/languages/de/translate?sid=2803469
https://localize.drupal.org/translate/languages/de/translate?sid=2844636
https://localize.drupal.org/translate/languages/de/translate?sid=2853570
https://localize.drupal.org/translate/languages/de/translate?sid=2853571
https://localize.drupal.org/translate/languages/de/translate?sid=2858209
https://localize.drupal.org/translate/languages/de/translate?sid=2866275
https://localize.drupal.org/translate/languages/de/translate?sid=2880363
https://localize.drupal.org/translate/languages/de/translate?sid=2888085

In practice, this means that after installing Open Social in a language other than English, you must manually translate 18 strings because even if they were allowed on the translation server, they could not be imported. To clarify the problem. If I offer Open Social to 10 customers, I must do manual translations 180 times. This is not necessarily nice from a quality assurance point of view.

In addition to that, everybody could translate that strings in every language over and over again by using the localisation server. So If those strings got replaced and the problem is resolved, they should be patched out, so we no longer have them on localize.drupal.org.

By now, those malformed strings would stay on localize.drupal.org forever, and we will have to watch out for them every time Open Social adds new UI strings. So that's an unnecessary workload for all translators out there. We need to fix that someday.

Finally, I'd like to mention that open social isn't the only distro/module having such kind of issues because there are no coding standards regarding translation source strings yet. Nevertheless, it should be ensured that such strings do not occur on Drupal's translation server.