Le fix fonctionne et la nouveauté -t aussi, merci !!
Autre idée, pouvoir ajouter des exceptions… exemple pour un plugin j’utilise nodejs et le démon contient un dossier node_modules qui contient pleiiiin de sous dossier, et ca devient vite le foutoir 
ca serait sympa de pouvoir indiquer un mot à exclure dans le chemin (genre node_modules ou autre) voir plusieurs si besoin
OK pour le principe de l’exclusion.
Mais est que tes fichiers contiennent vraiment ces textes entre doubles accolades {{....}} ou dans une fonction __("texte",__FILE) ou s’agit-il d’un bug supplémentaire dans mon script?
S’il s’agit d’un bug, peux-tu me fournir un de ces fichiers?
non ca semble correct (prettier/doc.js):
on dirait une notation pour la documentation automatique
ou d’autres systèmes de templates
Hello @mguyard,
j’utilise aussi cette méthode, pour finir, tu fais comment pour les traductions ? si je met des {{}} dans mon .json, pas certain que le core les remplaces après si ? ton __($command[‹ name ›], FILE) fonctionne ? (aussi bien avec le core que avec le script qui d’après ce que tu disais l’excluait)
Hello @nebz,
Je ne met pas le format de traduction dans le json. Je laisse les name en FR dans le JSON et quand je crée la commande je fais :
$cmd->setName(__($command['name'], __FILE__));
ok donc c’est pas relevé par le script
Si le script les trouves bien de souvenir
mmm je vois pas comment traduitjdm pourrait faire le lien, il va pas interpreter le code pour savoir ce qui se trouve dans ton array pour lister toutes les possibilités dans le fichier langue, tu dois donc les ajouter toi-même ? car oui il parse les .json mais s’il y a pas de {{}} dedans, je suppose qu’il les prend pas (ou sinon comment détecterait-il que c’est de la traduction et pas un package.json par ex)
Oui tu as raison. J’ai dû les ajouter manuellement et simplement demander qu’il ne les ajoute pas si c’était une variable le texte de traduction.
1 « J'aime »
Pas tester, mais je pense que les textes dans tes fichiers data.json seront détectés par traduitjdm qui les mettra dans les fichiers de traduction <langue>.json en utilisant les noms de tes fichiers comme clés.
Tu devrait alors tenter de faire la traduction dans le code de ton plugin avec le fonction:
$cmd->setName(__($command['name'],<chemin du fichier data.json>));
J’ai pas testé @nebz sur les commandes mais je le fais pour traduire mes textes statiques dans mon template.
Si tu lis le JSON et le converti avec translate::exec(contenuJSON, filename)
Puis tu converti le json en array
Ça devrait le faire car ton code dans le core qui reçoit l’array aura déjà était traduit
1 « J'aime »
Je crois que ta proposition a plus de chance de fonctionner que la mienne. 
1 « J'aime »
je pense que le second param doit contenir le nom du plugin dans ce cas, je vais tenter ca merci !
Le second param c’est le nom du fichier JSON tel qu’il est dans le fichier de traduction
1 « J'aime »
Je pense modifier traduitjdm pour qu’il ne prenne en compte que les textes entre deux ' ou ".
Les texte entre deux ' ne devront pas contenir de ' et les textes entre deux " ne devront pas contenir de "
Le texte
__("texte a traduire" ,__FILE) sera traduit
alors que
__("Le contenu de var est " . $var . " comme prévu", __FILE__)
ne le sera pas
mmm pas sur que ca puisse exister (que ca soit géré par le core)… il faut faire deux chaines
Je pense aussi mais fait ça ne fait pas de mal d’éviter quelque chose qui ne doit normalement pas être rencontré. Ça évitera d’éventuelles effets de bord du genre de ce qui se trouve dans des fichiers surprise du genre de tes node_module.
comme disait @mguyard tout $ dans {{}} ou __(…, FILE) doit être ignoré non ?
Moi j’avais demandé si ça commençait par un $ uniquement.
Je pense que c’est ça qui a était mis.
Moi aussi je fais 2 chaines si j’ai une variable au milieu de mes textes. C’est à mon avis la seule bonne methode