Traduction __() et ltrim(): Argument #1 ($string) must be of type string

Bonjour,
Pour la traduction j’utilise :

 $instructions= __('Aucun fichier trouvé', __FILE__);

en 4.4.19 debian 11 pas de souci

en 4.5 debian 12 et en 4.4.19 debian 12 j’ai cette erreur :

ltrim(): Argument #1 ($string) must be of type string, array given

ltrim(): Argument #1 ($string) must be of type string, array given

si je choisi une autre langue que Français.

J’utilise peut_être mal __(

Bonjour,

Le problème que vous rencontrez est très probablement lié à la montée de version de PHP entre Debian 11 et 12. En passant à PHP 8.x (présent sur Debian 12), PHP est devenu beaucoup plus strict sur le typage des variables. Là où PHP 7.x (Debian 11) était plus permissif et tentait de faire des conversions implicites, PHP 8.x signale ces problèmes de type via des erreurs explicites.

C’est pour cela que vous voyez l’erreur :

ltrim(): Argument #1 ($string) must be of type string, array given

Pour corriger le problème, il faut utiliser la fonction de traduction correctement en entourant le texte à traduire avec des accolades doubles :

$instructions = __('{{Aucun fichier trouvé}}', __FILE__);

Ou mieux encore pour une traduction du core :

$instructions = __('{{Aucun fichier trouvé}}', 'core');

Cette syntaxe garantira que la fonction reçoit bien une chaîne de caractères à traiter et évitera l’erreur de typage stricte de PHP 8.x.

Cette erreur était probablement déjà présente sur Debian 11 mais passait inaperçue grâce à la plus grande permissivité de PHP 7.x. La montée en version de PHP a simplement rendu le problème visible.

Bonjour,

image
image

c’est déjà fait par la class translate en fait…

et le ltrim est dans le exec.

Effectivement, en regardant le code de plus près, je pense que le problème vient du preg_match_all().

C’est étonnant qu’on n’ait pas eu de retour sur cette erreur plus tôt ! D’habitude ce genre de problème est remonté assez rapidement, surtout sur des fonctions aussi utilisées que la traduction.

Est-ce que vous pourriez me partager le contenu du fichier de traduction que vous utilisez quand l’erreur se produit ? Ça nous aiderait à comprendre pourquoi ça ne pose problème qu’avec les autres langues que le français.

Voilà en pièce jointe vu la taille (.json → .txt )
es_ES.txt (141,8 Ko)

ah mais ça c’est pas bon :

image

c’est un array donc… et ça ne doit pas

bizarre aussi le nom du fichier

OK
J’utilise traduitjdm qui génère le fichier donc je regarde ça surtout que depuis il y a une autre solution.

Concernant le nom du fichier c’est es_ES.json je ne vois pas le souci.

non je veux dire la clé du nom du fichier wifilightV2.class.null.php

vu!

merci pour vos retour.

Hello,
Content de voir que traduitjdm est encore utile mais je te conseille de jeter un coup d’œil sur ce sujet:

Github action pour traduire vos plugins 🌐

Cette manière de traduire les plugin, proposée par @Mips, reprend les principes de traduitjdm et les implémente directement dans le flux de traitement de github. De plus, il utilise « deepl.com » pour les traductions.

Oui j’ai vu ça je ne m’y suis pas intéressé car le flux est complexe/traduitjdm

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.