force to Unix line endings

So that would be a submission function to replace Windows line ending with Unix line endings? How can we do an update function for this in a sensible way?

Is this the reason for #999092: Import duplicate check broken in fact?

+++ l10n_community/l10n_community.module
@@ -557,6 +557,9 @@ function l10n_community_get_contexts() {
+    $translation = str_replace(array("\r\n", "\r"), "\n", $translation);
+    ¶

Extra tab, you should run your patch on your patch :)

Powered by Dreditor.

Okay nice simple patch let's wait Gabor.

Looks good. What is going to happen to existing translations which might be wrong?

We better need to trim them once and for all, just once. Then will leave it to this patch to filter the new ones.

Awesome! just a minor issue:

+++ b/l10n_community/l10n_community.module
@@ -557,6 +557,9 @@ function l10n_community_get_contexts() {
+	// Convert line break from CR or CRLF to LF.
+	$translation = str_replace(array("\r\n", "\r"), "\n", $translation);
+

TABS :) replace with spaces.

Powered by Dreditor.

I think it's ready.

Patch #11 applied, everything is ok for me.

I was wondering though, what about the possible duplicates generated by the update?

We need to add the duplicate removal to the update function, as this module is used on other sites.

l10n_community.install from #11 is also missing a new line at end of file

This is still a problem, also in 3.0.x. Browsers send the line breaks of a text area as \r\n, so currently every translation of more than one line that is saved on the web gets \r\n, on Windows and elsewhere. In the database copy of localize.drupal.org of August 2026, 9,207 active translations in 91 languages had a carriage return that their source string did not have. 6,173 of them were approved, and 411 of them were added in 2026. They make the exported .po files fail the gettext checks (#2842984: Add the Language and X-Generator headers to the exported .po files).

Proposed resolution addresses #8, #16 and #18 in two commits:

• With the branch, L10nPo::trim() changes \r\n and \r to \n in a new translation when its source string has no carriage return. The web form and the import both save through it, before the duplicate check. A translation of a source string with a carriage return keeps it.
• A new drush command, l10n_server:normalize-line-breaks (with --dry-run), changes the existing translations the same way. It keeps their changed time, so the packager does not package the releases of these strings again for this. l10n_server:merge-duplicate-translations (#3628846: Duplicate translations: merge them after the migration with their history, then keep translations unique) merges the copies that differed only in their line breaks, so the site should run it after this command in the migration. A count on the August 2026 copy found 13,948 translations to change, declined ones included, and 116 strings with copies of a text in a language after the change.

A new unit test (L10nPoTrimTest) checks the line breaks of new translations, and fail without the fix. A new kernel test (MergeDuplicateTranslationsTest::testNormalizeLineBreaks) checks the command, and that the merge merges the copies afterwards. The pre-existing suggestion, import, moderation history and merge tests still pass.

Not covered: the remote API of l10n_remote saves translations without L10nPo::addSuggestion(), so without this trim, and also without the duplicate check, the lock and the history. That should be fixed with the remote API.

Moving to 3.0.x.

LLM disclosure

LLM was used to find, diagnose, explain and fix this issue. With human review.