From 2c4dd2594cc47ca0b5cd719b963304ec48aecba2 Mon Sep 17 00:00:00 2001
From: rugk <rugk+git@posteo.de>
Date: Thu, 13 Nov 2025 10:52:08 +0000
Subject: [PATCH] fix: do not encode source JSON translation string resulting
 in wrong display of special characters like '

Fixes #1712

Disclosure: Coded with help of Copiot. (description wrtten by me)

So this does indeed loosen the encoding a bit. However, IMHO, it was neither better before though. You could always bypass the encoding for `args{0]` when  you just include `<a` (or the other tag) somewhere or so.

**One important notice:** This was (due to the exceptions before and afterwards) valid before and also now: Translators **could** (and can) if they have malicious intent, inject/do "XSS attacks".
Thus, translations PRs (also from Crowdin) should be reviewed for wild HTML code inside translations. I suppose this is easy to fix, but anyway a valid risk.

But IMHO, we should teat the JSON files being part of our source code as a "trusted source". In the end, such an attak is basicaly just ends up being injecting malicious code. I hope such contributors would be detected.

References I explicitly checked again to not introduce an XSS here: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html and the PHP doc for he HTML encoding.

I feel the safter way obviously would be encoding the _whole_ string _after_ translation (just like you should apply DOMPurify after everything), but as explained it was not done before and would break compatibility. Also, I looked through the sources and I see no risk described by doing it only for the "dangerous" "untrusted" inputs.
Only here is a notice that `%s` shall not be used in some contexts, for example to define a tag: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#dangerous-contexts (obviously in such a case, attacks may be possible even with encoding; but again; this is nothing new)

The basic "problem" of it all is: We want HTML to be translated/be usable in our translation. If we'd get rid of that, we would get for sure rid of all such XSS attack possibilities. But that woud be a bigger refactoring, so IMHO, this here is fine for a fix for the issue at hand.

Ah another point: I think the `is_int` check is harmless, but it's also kinda useless. Maybe it is some kind of obscure performance optimisation. (Yeah ints have nothing to encode as they have nothing that could be used for XSS, but they could also just be passed through that function.)
---
 lib/I18n.php     | 13 ++++++-------
 tst/I18nTest.php | 15 ++++++++++++++-
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/lib/I18n.php b/lib/I18n.php
index 1bf20a2f..2e06ac51 100644
--- a/lib/I18n.php
+++ b/lib/I18n.php
@@ -127,14 +127,13 @@ class I18n
         } else {
             $args[0] = self::$_translations[$messageId];
         }
-        // encode any non-integer arguments and the message ID, if it doesn't contain a link or keyboard input
+        // encode any non-integer arguments, but not the message itself
+        // The message ID comes from trusted sources (code or translation JSON files),
+        // while parameters may come from untrusted sources and need HTML entity encoding
+        // to prevent XSS attacks when the message is inserted into HTML context
         $argsCount = count($args);
-        for ($i = 0; $i < $argsCount; ++$i) {
-            if ($i === 0) {
-                if (str_contains($args[0], '<a') || str_contains($args[0], '<kbd>')) {
-                    continue;
-                }
-            } elseif (is_int($args[$i])) {
+        for ($i = 1; $i < $argsCount; ++$i) {
+            if (is_int($args[$i])) {
                 continue;
             }
             $args[$i] = self::encode($args[$i]);
diff --git a/tst/I18nTest.php b/tst/I18nTest.php
index 9e196103..118fe23b 100644
--- a/tst/I18nTest.php
+++ b/tst/I18nTest.php
@@ -182,7 +182,20 @@ class I18nTest extends TestCase
         $result = htmlspecialchars($input, ENT_QUOTES | ENT_HTML5 | ENT_DISALLOWED, 'UTF-8', false);
         $this->assertEquals($result, I18n::encode($input), 'encodes HTML entities');
         $this->assertEquals('<a>some ' . $result . ' + 1</a>', I18n::_('<a>some %s + %d</a>', $input, 1), 'encodes parameters in translations');
-        $this->assertEquals($result . $result, I18n::_($input . '%s', $input), 'encodes message ID as well, when no link');
+        // Message ID should NOT be encoded (it comes from trusted source), only the parameter should be
+        $this->assertEquals($input . $result, I18n::_($input . '%s', $input), 'encodes only parameters, not message ID');
+    }
+
+    public function testFrenchApostropheInMessage()
+    {
+        $_SERVER['HTTP_ACCEPT_LANGUAGE'] = 'fr';
+        I18n::loadTranslations();
+        // The French translation should not have the apostrophe encoded
+        // Original: "Le document n'existe pas, a expiré, ou a été supprimé."
+        // Should NOT become: "Le document n&apos;existe pas, a expir&eacute;, ou a &eacute;t&eacute; supprim&eacute;."
+        $message = I18n::_('Document does not exist, has expired or has been deleted.');
+        $this->assertFalse(strpos($message, '&apos;') !== false, 'French apostrophe should not be encoded in translation message');
+        $this->assertTrue(strpos($message, "n'existe") !== false, 'French apostrophe should be present as literal character');
     }
 
     public function testFallbackAlwaysPresent()