Bug édition d'une Tache (FR uniquement)

[Benjamin]

Dans la version FR (je n'ai testé que FR et EN), l'affichage d'une tâche rédigée par un autre user explose. Voir copie écran.

A défaut de trouver la solution, j'ai rétabli la version EN ... cependant je pense qu'il doit s'agir d'un simple problème de slash (/) ou d'apostrophe (') mal placé.

Cordialement.


I try an english version :
In FR version, the view of a task created by an other user is totally exploded (please, have a look to the screenshoots).
Maybe a slash or quote problem.

regards.
Benjamin.

[oxydum]

Bonjour Benjamin,

  Je ne reproduis pas ce problème avec la version FR. Pourrais-tu détailler ton problème, la copie d'écran est nulle part ?

[Benjamin]

Désolé pour l'oubli de la copie écran.




Le problème apparait uniquement lors de l'édition d'une tâche créée par un autre utilisateur.

[oxydum]

Bravo Benjamin,

C'est dans le fichier messages.php en ligne 325, "quelqu\'un" qui pose problème sans que j'en comprenne vraiment le pourquoi, à remplacer par "quelqu\\\'un" ainsi :

    'confirm subscribe' => 'Êtes-vous sûr de vouloir vous abonner à cet objet ? Vous recevrez un courriel chaque fois que quelqu\\\'un postera un commentaire sur cet objet.',

Curieux, non ?

[Benjamin]

Bravo à toi Oxydum ! ça marche maintenant !

merci et bonne continuation.

[larmarange]

Le même bug se rencontre en 1.1 RC1 concernant la page des propriétés d'un fichier (uniquement en français).

[larmarange]

Bug trouvé.

Dans le fichier de langue general.php, il faut modifier l'entrée 'confirm move to trash' ainsi :

'confirm move to trash' => 'Êtes-vous sûr de vouloir déplacer l\\\'objet sélectionné dans la corbeille ?',

[larmarange]

Et tant qu'on y est,
bug équivalent pour afficher laliste des utilisateurs dans l'administration.

Modif à effectuer dans actions.php :
   'update avatar' => 'Modifier l\\\'avatar',

et dans messages.php :
   'confirm delete user' => 'Êtes-vous sûr de vouloir supprimer ce compte utilisateur ?\nCette action supprimera aussi le contexte personnel de l\\\'utilisateur.',


Cela signifie-t-il que toutes les apostrophes doivent être précédes de \\\ ?

[oxydum]

Bonjour Joseph,

  Je confirme les problèmes d'apostrophes, mais surtout, ne pas les préfixer par des \\\, car à présent, le travail est effectué par l'outil de traduction \opengoo_1.1_RC1\public\tools\translate.php (une interface web donc à activer dans access.php) qui "échappe" les séquences \\\ et met correctement le bon format, et qui en plus a l'énorme avantage de ne plus toucher directement aux fichiers de traductions.

(Je conseille d'éditer ce translate.php et changer le $pagesize = 5; et tous les "5" par des valeurs plus grandes comme... 50.)

  Bref, toutes les apostrophes ne posent pas le problème, et celles qui boguent devraient être remplacée par un espace en attendant de résoudre cette curiosité.

Et merci pour ton implication, c'est important d'avoir des talents comme toi à nos côtés 

[larmarange]

Peut être faudrait-il signaler ce souci aux développeurs ?

[oxydum]

Oui, c'est fait. D'autre part, ce problème est reproductible en version anglaise, par exemple en ajoutant une apostrophe dans le texte du 'confirm move to trash', ainsi en ajoutant "don't" : 'Are you sure you don't want to move the selected object to the trash?'

[ignacio]

Hi, the problem seems to be that sometimes we are not escaping quotes when showing javascript messages. It's not a problem with the translations, you shouldn't need the extra slashes. We will try to correct it for version 1.1 but we may not fully solve it for that version.

Thanks.

[oxydum]

Merci Ignacio,
  Ce problème est corrigé avec la version 1.1RC2, it's OK, 

[afro]

Je ne sais pas si ça avait été rêglé mais effectivement, plusieurs fois sur la 1.1, mon design explosait, notamment lors de l'édition de tâche ou encore le listing des utilisateurs dans l'administration.
Dès que j'ai appliqué les solutions de Benjamin sur ce sujet d'aujourd'hui, plus de problème (enfin, pour l'instant)