Oui, mais pas si le $ est dans une chaîne de caractères délimitée par des 'ou ".
Je regarde ça de plus près ce soir…
1 « J'aime »
il y a aussi
sprintf (__("Le contenu de var est %s comme prévu", __FILE__),$var)
1 « J'aime »
parfait, en mettant des {{}} dans les json et en faisant ça :
ca fonctionne :
et le script a bien pris :
1 « J'aime »
Nouvelle version (v0.10.0) disponible.
- Pas de changement pour les occurrences
{{texte}} - les textes dans les fonctions
__()doivent être encadrés par un couple de quotes ou double quotes ('texte'ou"texte"), le caractère d’encadrement ne doit pas être trouvé dans le texte.-
'Ce texte n'est pas traduit'(contient le déliminateur'dans le texte) -
'Ce texte n\'est pas mieux'(l’antislash n’est pas (encore) pris en compte. 'Ce texte texte est "OK"'
-
Suite aux discussions de ce jour, le deuxième argument des fonctions __() ne doit plus être __FILE__ mais une chaîne de caractères sans espace. Cet argument peut donc être un nom de fichier et une variable qui contient un nom de fichier.
Ah j’ai pas tout compris alors…
Suite aux échanges d’aujourd’hui, je me suis dit qu’il est possible d’avoir des appels à __() avec autre chose que __FILE__ comme deuxième argument. j’ai donc tenté d’anticiper.
Ah ok j’avais compris ta phrase comme quoi on devait modifier les appels et que ça ne devait plus être __FILE__ mais autre chose
Oui, je me suis mal exprimé.
Il ne serait inadmissible de devoir adapter le code des plugins pour le rendre compatible à un utilitaire quelconque (même si j’en suis l’auteur 
).
1 « J'aime »
C’est une régression ? Car moi j’utilise ça dès que j’ai une quote et cela fonctionnait
1 « J'aime »
Aïe,
Je pensais traiter ce point plus tard.
Je vais m’y mettre.
Merci. Je vais pas passer en traduction avant quelques jours 
A titre d’info pourquoi avoir revu les notions de quote dans les __() ?
Je préfère vérifier que l’on a bien une chaîne de caractère littérale délimitée par des ' ou " conformément au langage plutôt que d’interdire l’utilisation de $ dans les chaînes de caractères.
Il n’est pas impossible que quelqu’un aie besoin une fois ou l’autre de mettre un nom de variable message. Pour du debug par exemple.
Oui je le fais même beaucoup. Mais pour moi, la bonne pratique de cet usage c’est de mettre la variable hors du __()
Exemple :
log::add(__CLASS__, 'info', __FUNCTION__ . '::' . __('Mise à jour suite à une sauvegarde de l\'équipement', __FILE__) . ' ' . $this->getName());
J’ai même des cas plus tordu car je considère qu’un espace avant une variable ne doit pas être mis dans le string d’avant sinon on risque de la zappé sur une traduction donc je fais comme ça :
log::add(__CLASS__, 'info', __FUNCTION__ . '::Pool' . ' ' . __('sonde EcO', __FILE__) . ' ' . $pool['title'] . ' (' . $pool['id'] . ') ' . __('ajoutée', __FILE__));
La traduction est la pour gérer du statique. Une variable n’a pas lieu d’être traduite en générale.
Le nom des commandes comme nous parlions au dessus est un cas spécifique de variable à traduire.
Enfin moi c’est comme ça que je le vois. C’est peut être une vision uniquement personnelle
Comment tu gères actuellement une variable au milieu de ton __() ? Tu la découpe en 2 chaîne côté fichier de traduction ?
Moi, j’ai plutôt tendance à utiliser du sprinf() j’ai donc de texte avec des choses du genre %s.
Quoi qu’il en soit, les textes qui contiennent un nom de variable ne seront certainement pas trouvés dans les traduction du core. Il faudra donc les traduire manuellement et l’on pourra conserver les noms de variables. L’avantage est que la variable n’a pas forcément à être à la même position pour toutes les langues.
1 « J'aime »
Nouvelle version (0.10.1) publiée.
- Optimisation de la recherche des texte dans les function php
__() - Les texte délimités par des
"ne peuvent contenir des"que s’ils sont précédés d’un\ - Les texte délimités par des
'ne peuvent contenir des'que s’ils sont précédés d’un\
1 « J'aime »
Génial 
Cet outil devient de mieux en mieux !
Vivement les exclusions
Si tout va bien, j’attaque les exclusions la semaine prochaine.
J’en profiterai pour mettre une exclusion pour core/i18n/* 
1 « J'aime »
C’est clair. 
Et après, l’envoi des champs non traduits à un dico ou API de trad 
1 « J'aime »
L’api google trad ? Noooon @ktn va pas aller aussi loin…
Si on tous les @Developpeurs utiliseront son script
Je préfère l’API de Microsoft (Je la paye pas)
Mais sinon je suis en train de faire en sorte que cela soit utilisable par github action, donc en auto pendant les push. Il manque plus que la traduction soit automatique
Cdt
Thibaut
1 « J'aime »