+- MyBB.support, le portail francophone de MyBB (https://mybb.support)
+-- Forum : Traduction francophone (https://mybb.support/forum-7.html)
+--- Forum : Traduction francophone (https://mybb.support/forum-8.html)
+--- Sujet : Rapports traduction 1.8 fr (/thread-7030.html)
RE: Rapports traduction 1.8 fr - exdiogene - 24-09-2014
Je peux confirmer que les variables de langue sont lues directement du fichier et ajoutées au "array" $lang sans aucune manipulation.
La fonction stripslashes() n'est donc pas utilisée.
RE: Rapports traduction 1.8 fr - exdiogene - 24-09-2014
J'avais déjà suggéré d'utiliser les entitées HTML pour se débarrasser des soucis du codage UTF8 dans les fichiers texte. Il pourrait en être de même avec l'apostrophe en la remplaçant par "'".
RE: Rapports traduction 1.8 fr - exdiogene - 24-09-2014
Je viens de m'apercevoir que les entitées ne sont pas reconnues dans le Javascript...
RE: Rapports traduction 1.8 fr - spyto - 24-09-2014
Tout en conservant l'encodage UTF-8 ou en encodant tout en ANSI ?
N'obtenant aucune réponse sur mybb.com, j'ai relancé le sujet, sachant maintenant que leur solution n'est pas bonne :
http://community.mybb.com/thread-159498-post-1105544.html#pid1105544
On verra leur réaction...
RE: Rapports traduction 1.8 fr - spyto - 24-09-2014
Quelqu'un a répondu !
Et il reconnaît qu'il "croyait" que PHP traitait automatiquement '\' comme caractère d'échappement.
Mais ce n'est pas un membre du staff. J'aurais aimé qu'un développeur réponde.
RE: Rapports traduction 1.8 fr - spyto - 24-09-2014
(24-09-2014, 14:12)exdiogene a écrit : Je viens de m'apercevoir que les entitées ne sont pas reconnues dans le Javascript...
Je n'avais pas vu ce message.
Ce qui signifie qu'il va falloir se "farcir" la liste des variables.
Et comme ils ont dit là-bas, ma suggestion de préfixer par js_ n'est pas viable car :
- tous les traducteurs devraient tout reprendre, je conçois que c'est dur pour eux.
- les variables aujourd'hui non utilisées par JS pourraient l'être dans de futures versions.
Rassure-moi : PHP ne traite pas "automatiquement" '\' comme caractère d'échappement ? Il faut bien utiliser stripslashes ?
Ce qui signifie que la suggestion des membres de mybb.com de tout échapper n'est pas non plus valide.
La situation est assez complexe. Je ne sais plus quoi faire, sinon continuer patiemment à échapper les apostrophes en balayant ce monstrueux listing.
RE: Rapports traduction 1.8 fr - Saphir - 24-09-2014
Comme je dirais précédemment, tu peux tester en local le comportement de PHP : rechercher \' et remplacer par ' puis rechercher ' et remplacer par \'
Si tu te retrouves avec des \' sur le forum de test, c'est que PHP ne considère pas systématiquement le \ comme un caractère d'échappement. Si tu n'as que des apostrophes, c'est gagné...
RE: Rapports traduction 1.8 fr - spyto - 24-09-2014
Je sais bien, mais ici, je n'ai pas mon PC de bureau et mes outils habituels. Il faudrait que j'installe XAMPP et tout le toutim.
Alors ça attendra la semaine prochaine.
De toute façon, exdiogene dit : "La fonction stripslashes() n'est donc pas utilisée." ce qui sous-entend que PHP ne traite pas systématiquement '\' comme caractère d’échappement. Sinon à quoi servirait la fonction stripslashes() ?
Edit :
Citation :rechercher \' et remplacer par 'ok, facile...
Citation :rechercher ' et remplacer par \'plus compliqué ! Quid des apostrophes dans le nom de la variable ?...
RE: Rapports traduction 1.8 fr - Saphir - 24-09-2014
Ah oui... J'avais oublié ce détail, il faudrait le faire en regex.
Et comme tu l'as dit, si PHP considérait toujours \ comme caractère d'échappement, stripslashes ne servirait à rien...
Bref, du pain sur la planche. :s
RE: Rapports traduction 1.8 fr - spyto - 24-09-2014
GRRRRRRRRRRRRRRRRRR !!!
J'ai fait une vaste c..... !!!
J'ai voulu tester en local avec des '\' partout (j'ai installé XAMPP).
J'ai trouvé pour remplacer ' par \'. J'ai d'abord remplace tous les ' par \', puis j'ai remplacé [\' par ['et \'] par '].
Évidemment ça ne marche pas ! PHP affiche bravement par exemple : "Session d\'administration invalide."
Oui mais voilà j'ai cru copier mes fichiers originaux dans www de Xampp.... je les ai DÉPLACÉS ! C'était sur le même disque et j'ai pas fait gaffe. GRRRRRRR !
Résultat, tout à refaire... Re-supprimer les '\' inutiles (il y en a partout) en comparant avec l'archive la + récente (15/09 comme un c..) où toutes les erreurs n'avaient pas été corrigées. Et voilà c'est toujours comme ça, je n'avais pas mis l'archive à jour en local !
@exdiogene : au fur et à mesure que j’enlève les \' je vérifie si la variable est dans le fichier que tu m'as transmis..
Mais il me semble qu’il y a des erreurs.... Il n’y a pas QUE les variables de langue utilisées par JS !?
Par exemple :
ligne 9413 : install/resources/mybb_theme.xml:<td class="trow2" colspan="2">{$lang->forum_password_note}</td>
tu es sur que $lang->forum_password_note est utilisé par JS ???? C'est plutôt par PHP, non ?
Sur mybb.com, ils ont l'air de prendre ce problème "par-dessus la jambe". C'est pourtant assez ch... !!!!
RE: Rapports traduction 1.8 fr - Saphir - 24-09-2014
tools_adminlog.lang.php
Ligne 10 : [...] la panneau de contrôle.
-> [...] le panneau de contrôle.
Ligne 41 : (Je ne trouve pas ça très cohérent, tu es sûr que c'est les suivis de PLUS de 24h qui ne peuvent pas être supprimés ?)
Ligne 61 : Calendrier #{1 supprimé} ({2}).
-> Calendrier #{1} supprimé ({2}).
Ligne 95 : Plusieur [...]
-> Plusieurs [...]
Lignes 129, 130 et 131 : (Comme pour les autres lignes, le '#{1}' devrait se trouver avant l'adjectif.)
Ligne 157 : [...] forum#{2} [...]
-> [...] forum #{2} [...]
Ligne 166 : Templates #{1} [...]
-> Template #{1} [...]
Ligne 183 : [...] supprimé/rétabli [...]
-> [...] supprimée/rétablie [...]
Ligne 185 : Définir le thème #{1} ({2}) par défaut.
-> Thème #{1} ({2}) défini par défaut.
Ligne 200 : #{2}. supprimés
-> #{2} supprimés.
Ligne 210 : Rechargement du cache ({1})
-> Cache rechargé ({1}).
Ligne 264 : [...] #{1 ajouté} [...]
-> [...] #{1} ajouté [...]
Ligne 281 : Fusionné l'utilisateur #{1} ({2}) avec l'utilisateur #{3} ({4}).
-> Utilisateur #{1} ({2}) fusionné avec l'utilisateur #{3} ({4}).
Ligne 283 : {1} utilisateur(s) modifié(s) groupe primaire/additionnel/affichage
-> Groupe(s) primaire/additionnel(s)/d'affichage de {1} utilisateur(s) modifié(s).
Ligne 285 : [...] banni(s)définitivement
-> [...] banni(s) définitivement
Ligne 292 : [...] Adminitrateur pour l\'utilistauer #{1} ({2}) bloquée.
-> [...] administrateur pour l\'utilisateur #{1} ({2}) bloquée.
tools_maillogs.lang.php
Ligne 16 : Addresse IP
-> Adresse IP
tools_modlog.lang.php
Ligne 41 : dans
-> dans l'ordre
Ligne 42 : ordre
->
(Si je ne me trompe pas, ça permettrait de donner 'dans l'ordre [Croissant/Décroissant]' au lieu de 'dans [Croissant/Décroissant] ordre', non ?)
Ligne 49 : (Idem que tools_adminlog.lang.php ligne 41...)
tools_module_meta.lang.php
Ligne 33 : Peut gérer les sauvegardes BDD ?
-> Peut gérer les sauvegardes de la BDD ?
Soit je continue ce soir, soit ce sera suite et fin demain soir. Pour l'heure, je vais essayer de trouver un restaurant, parce que la nourriture de l'hôtel... Enfin bon, c'est ma vie ça... :-D
RE: Rapports traduction 1.8 fr - exdiogene - 25-09-2014
Tu m'avais demandé la liste des variables, je n'ai rien lu considérant une liste des variables utilisées uniquement en Javascript!
Maintenant concernant PHP, si ta variable est contenue entre guillemets tu ne dois échapper que les guillemets intérieures. Si ta variable est contenue entre apostrophes tu ne dois échapper que les apostrophes intérieures.
La différence entre les apostrophes et les guillemets est que les variables PHP sont interprétées seulement à l'intérieur des guillemets.
Alors "Mon texte et ma $variable" sera affiché comme "Mon texte et ma vie" si $variable contient "vie".
Tandis que 'Mon texte et ma $variable' sera affiché comme 'Mon texte et ma $variable'.
Alors maintenant pour te compliquer la vie, si dans MyBB tu as une phrase du genre :
'Erreur : {$lang->error}'
et que la variable de langue contient :
"L'état de votre session est suspendu!"
Il sera nécessaire d'échapper l'apostrophe de la variable de langue.
Mais si la phrase est plutôt :
"Erreur : {$lang->error}"
Il serait important de ne pas échapper l'apostrophe.
Alors vois-tu le dilemne?
RE: Rapports traduction 1.8 fr - exdiogene - 25-09-2014
Une solution simple et rapide pour ne pas avoir à échapper les apostrophes est d'utiliser sa version UTF8 :
’
RE: Rapports traduction 1.8 fr - spyto - 25-09-2014
J'ai bien conscience du dilemme !
J'y suis "planté" dedans !Citation :Tu m'avais demandé la liste des variables, je n'ai rien lu considérant une liste des variables utilisées uniquement en Javascript!Si ! Regarde m demande là :
http://www.mybb.fr/thread-7048-post-40664.html#pid40664
Elle citait simplement ce que j'avais demandé sur mybb.com là :
http://community.mybb.com/thread-159498-post-1103102.html#pid1103102
Pour moi, il était implicite que ce qui m’intéressait c'étaient les variables utilisées par J !
Et comme je n'ai toujours pas de réponse sur mybb.com, j'ai posté hier soir dans Private Inquiries... sans réponse encore bien sûr !
Ils semblent considérer ça comme un problème mineur, c'est pourtant essentiel si on veut un affichage correct !
Le challenge est de déterminer quelles variables sont utilisées par JS pour échapper les apostrophes uniquement dans ces variables, même entre guillemets doubles !
En effet, pour reprendre ton exemple :
Citation :Alors "Mon texte et ma $variable" sera affiché comme "Mon texte et ma vie" si $variable contient "vie".Mais "Mon texte et $variable" sera affiché comme "Mon texte et c\'est la vie" si $variable contient "c\'est la vie".
Des "pingouins" là-bas m'ont répondu qu'il suffisait d'échapper toutes les apostrophes. Ils pensaient que PHP considérait systématiquement '\' comme caractère d'échappement :
http://community.mybb.com/thread-159498-post-1105079.html#pid1105079
Les entités nommés, ça ne va pas non plus puisque JS ne les prend pas en compte.
Reste ton idée de ’ ...
L'autre challenge c'est qu'une variable non utilisée actuellement par JS est susceptible de l'être à l'avenir !
Oups... une idée me vient à l'esprit. Et si j'encadrais TOUTES les variables par des guillemets simples au lieu des doubles en échappant toutes les apostrophes et guillemets internes ?
Serait-ce correctement interprété par PHP ? Et par JS ?
RE: Rapports traduction 1.8 fr - Saphir - 25-09-2014
Je pense que ce serait une bonne idée d'essayer ça. PHP serait obligé d'interpréter les antislashs correctement. Pour ce qui est de JS... Suspens ! :p
RE: Rapports traduction 1.8 fr - spyto - 25-09-2014
Citation :Si j'encadrais TOUTES les variables par des guillemets simples au lieu des doubles en échappant toutes les apostrophes et guillemets internes ?Testé en local. Pour PHP c’est OK.
Serait-ce correctement interprété par PHP ? Et par JS ?
Pour JS, je ne sas pas... Où pourrais-je tester ?
Donne-moi un truc affiché par JS..
RE: Rapports traduction 1.8 fr - Saphir - 25-09-2014
Tout ce qui est éditeur MyCode, déjà ?
Les vérifications des champs du formulaire d'inscription...
RE: Rapports traduction 1.8 fr - spyto - 25-09-2014
Non justement !
Que ce soit pour l'éditer MyCode ou le formulaire d'inscription, les erreurs sont affichées "inline" via PHP !
Je ne trouve rien pour vérifier si c'est ok pour JS !
Edit : Dans le popup de connexion, après identification, il est bien affiché "Vous allez être redirigé vers la page d'où vous provenez" donc l’apostrophe est OK, si c'est du JS...
RE: Rapports traduction 1.8 fr - exdiogene - 25-09-2014
Je persiste à croire que l'utilisation du code UTF8 "’" serait le standard idéal, vu que tous les accents français sont déjà codés de cette façon.
RE: Rapports traduction 1.8 fr - spyto - 25-09-2014
’ est-il correctement interprété par JS ?
Dans mon éditeur de texte, je n’ai pas d'option pour afficher ce genre de signe cabalistique. Je suis obligé de rouvrir le fichier en ANSI pour voir ces signes et donc ensuite de l'enregistrer aussi en ANSI.
Ce n'est pas très lisible pour les corrections et s'il faut réfléchir quel code employer pour chaque caractère accentué, c'est fort peu pratique.
La version testée avec les chaînes encadrées pas des guillemets simples est fonctionnelle et me semble plus simple à gérer.