Missing arguments. (ArgumentCountError 9 arguments are required, 3 given)

[vicluber]

Hi Our editor has worked happily with translatelabels 2.2.1 under Typo3 11 for a while now. I have a site with 7 languages without having almost no issues. But last week we've added a new language (Japanese) and immediately after translating a page to Japanese, just the page, it doesn't have any content elements yet I've gotten this error on visiting that page:

ArgumentCountError

9 arguments are required, 3 given

in /var/www/html/public/typo3conf/ext/translatelabels/Classes/ViewHelpers/TranslateViewHelper.php line 144

if (ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isFrontend()) { $id = TranslationLabelUtility::getExtendLabelKeyWithLanguageFilePath($id, $extensionName); $value = TranslationLabelUtility::readLabelFromDatabase($id, $value); if (\is_array($translateArguments) && $value !== null) { $value = sprintf($value, ...array_values($translateArguments)) ?: sprintf('Error: could not translate key "%s" with value "%s" and %d argument(s)!', $key, $value, count($translateArguments)); } if (TranslationLabelUtility::isFrontendWithLoggedInBEUser($id, $extensionName)) { $value = TranslationLabelUtility::renderTranslationWithExtendedInformation($id, $value, $extensionName, $translateArguments, $arguments['languageKey'], $arguments['alternativeLanguageKeys']); } }

Indeed the $translateArguments variable is null. Is this a known issue? Is this a translatelabels issue even? Or am I just missing something?

[TB-effective]

Since I was collaborating with @vicluber on the project in question, and have just been able to get rid of the error, I have some updates.

The root cause appears to have been a combination of the cookieman extension we're using for cookie consent, translatelabels, and a localized URI for the privacy page with Japanese characters. Cookieman is using messages like 'Find more information regarding cookies on our %1$s and regarding us on the %2$s.' that get passed through sprintf() to interpolate the links to the "privacy" and "about us" pages. It seems that when the URI paths of those (in our case privacy in Japanese) contain non-URI-safe characters, these will (understandably) get percent-encoded. And apparently somehow that end result gets passed through the whole translatelabels or general translation and rendering pipeline again – I haven't been able to completely trace the exact flow of control there, but the upshot was either the ArgumentCountError shown above, since some of the percent-encoded characters in the URI get interpreted as conversion instructions by downstream sprintf() calls. Or, if the number of arguments still matches (in testing, I simply passed in additional null values just so it would have enough to fill in the placeholders), it might also complain about invalid format specifiers, for example '(1/1) ValueError Unknown format specifier "C"'. In any case, the percent-encoded characters in the input are what's breaking things.

The (somewhat hacky) fix we are now using is to avoid the link interpolation done by Cookieman, and instead simply hardcode the links to the privacy page in the message label. In that case, one can just leave non-percent-encoded native Japanese characters in the href attribute, since the browser will ultimately percent-encode those when the user follows the link.

I do think this is in a certain sense a bug in translatelabels. But I am not sure whether there is much that you can do to avoid this kind of issue, especially if other extensions are involved as well – at least I could imagine that taking care of it in a generic manner could become quite messy quickly, so if you decide to close this as wontfix or invalid I wouldn't be too shocked. ;-) Or you come to the conclusion it's not really a bug on your side.

Anyway, this is the info I can give you on how this seems to be playing out, make of it what you will.

If you would like additional info, let us know.

[TB-effective]

Ok just had another quick look over the way things work together to produce these errors, and maybe it should more appropriately be seen as a cookieman bug, or even one in the basic translation logic... The cookieman templates rendering that piece of content all look like this:

<p>
    {f:translate(
     key: 'introText',
     arguments: {
     1: "{dataProtectionDeclarationLink -> f:spaceless()}",
     2: "{imprintLink -> f:spaceless()}"
    }) -> f:format.raw()}
</p>

and the dataProtectionDeclarationLink gets resolved from plugin.tx_cookieman.settings.links.dataProtectionDeclarationPid. So either cookieman or f:translate should probably escape that URI appropriately so it won't contain anything that downstream sprintf() calls won't interpret them as conversion specifiers? Or is some translatelabels code involved again before it blows up?

[TB-effective]

Any thoughts on whether this should be considered a translatelabels or a cookieman bug? Or if there is anything you're planning to do about it? (We have worked around the concrete issue, but it's still a bug at some level.)

Just curious because there was no reaction whatsoever in almost a year.