Project

General

Profile

Actions

Bug #5329

closed

Descriptifs WYSIWYG de dossiers français obsolètes en anglais

Added by Emmanuel GRANGE about 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Urgent
Start date:
02/24/2014
Due date:
% Done:

100%

Estimated time:
Navigateur:
Firefox
Votre version de Silverpeas:
5.13.3
Système d'exploitation:
Votre base de données:
PostgreSQL
Livraison en TEST:
Livraison en PROD:

Description

Bonjour,

PROBLÈME URGENT :

Suite à la migration 5.11 vers 5.12, les descriptifs WYSIWYG français et anglais ne contiennent plus la même chose :
Dans les GED types que nous dupliquons pour tous les projets de toutes nos divisions, les descriptifs français et anglais sont différents alors qu'il ne devrait pas y avoir qu'une unique version française.
La version anglaise est en fait une version française obsolètes qui peut porter à confusions pour nos utilisateurs.

Par exemple :
En Français, le descriptif WYSIWYG avait été supprimé (sauf les drapeaux):

Alors qu'en anglais, une ancienne version français est visible :

Ce problème est URGENT, car les description ne sont plus du tout en adéquation avec les systèmes mis en place, et les utilisateurs ne comprennent plus rien.
Nous avons besoin d'une réponse et d'une solution rapide.

Merci


Files

Image_375.jpg (155 KB) Image_375.jpg Emmanuel GRANGE, 02/24/2014 09:49 AM
Image_376.jpg (257 KB) Image_376.jpg Emmanuel GRANGE, 02/24/2014 09:51 AM
Actions #1

Updated by David Lesimple about 7 years ago

  • Status changed from New to Feedback

Bonjour Emmanuel,

Est-ce qu'on peut faire un point sur les versions installées sur le serveur de prod ?
Vous etes passé en 5.13.3 ou pas ? si oui, depuis la 5.11.4 ?

D'autre part, vous n'aviez pas vu ce problème lors de la validation sur le serveur de test de la 5.13.3 ?
Est-ce que ce problème est présent sur tous les wysiwyg de dossiers ?

Actions #2

Updated by Yohann Chastagnier about 7 years ago

  • Status changed from Feedback to In progress...
Actions #3

Updated by Emmanuel GRANGE about 7 years ago

Les réponses à vos question en italique ci-dessous.

Sinon, j'ai effectué les restaurations de la GED kmelia9547 en version 5.11.4, et 5.12.2, comme demandé par mail par David.
Elles sont disponible sur le serveur de Production :
138M /tmp/kmelia9547_20131228
157M /tmp/kmelia9547_20140208

Avez-vous besoin que je les déplace sur le portail de test ?

David Lesimple a écrit :

Bonjour Emmanuel,

Est-ce qu'on peut faire un point sur les versions installées sur le serveur de prod ?
Vous etes passé en 5.13.3 ou pas ? si oui, depuis la 5.11.4 ?

Nous sommes en v5.13.3 depuis le 13/02/2014.

D'autre part, vous n'aviez pas vu ce problème lors de la validation sur le serveur de test de la 5.13.3 ?

Avant d'installer une mise à jour, nous essayons de tester toutes les fonctions critiques pour un bon fonctionnement de nos utilisateurs (Edition en ligne, WYSIWYG, Navigation mixte, Copier/coller de GED...) Nous en testons un maximum, mais nous ne pouvons pas tout tester.
Ce problème ne nous a été signalé que fin de semaine dernière

Est-ce que ce problème est présent sur tous les wysiwyg de dossiers ?

Malheureusement, je ne peux pas confirmer ceci pour toutes les GED. Pour les GED types projets, il semble que ce soit le cas, puisqu'il n'y a pas de traduction anglaise actuellement.

Actions #4

Updated by Yohann Chastagnier about 7 years ago

  • Status changed from In progress... to Feedback

Analyse de la GED I10009H et du dossier PDM de l'anomalie remontée.

Identifiants techniques :
  • GED I10009H = kmelia9547
  • Dossier PDM de la GED = 86325

Etat des lieux sur le système de fichiers et dans la table sb_attachment_attachment de la version 5.11.x

Au niveau de la base de données :

  • enregistrement de Node_86325wysiwyg_fr.txt d'une taille de 4673 le 2013/06/07
  • enregistrement de Node_86325wysiwyg_en.txt d'une taille de 2451 le 2013/06/07
  • enregistrement de Node_86325wysiwyg_fr.txt d'une taille de 420 le 2013/11/14

A la date du 14 novembre 2013, le contenu français à été mis à jour et est passé d'une taille de 2451 octets à 420 octets (contient certainement les drapeaux dont vous faites mention). Cependant, le contenu anglais, lui, reste non modifié et a une taille de 2451 octets.

Au niveau du système de fichier :

Dans le répertoire /tmp/kmelia9547_20131228/Attachment/wysiwyg, que vous nous avez mis à disposition sur votre serveur, il existe bien les deux fichiers en relation avec les informations de la base de données :
  • 2451 7 juin 2013 Node_86325wysiwyg_en.txt
  • 420 14 nov. 17:29 Node_86325wysiwyg_fr.txt

Les contenus sont différents, mais les deux sont écrits en français (je ne sais pas pourquoi le fichier "anglais" contient du texte en français ...).

Dans cette situation là, les contenus français et anglais (même si les deux au final sont en français) devaient bien être exposés aux utilisateurs, c'est à dire les drapeaux lorsque les contenus français étaient sélectionnés (via les pictos FR / EN), et les drapeaux plus le texte en français lorsque les contenus anglais étaient sélectionnés.


Etat des lieux sur le système de fichiers de la version 5.13.2

A partir de cette version, les contenus wysiwyg ne sont plus gérés via la table sb_attachment_attachment.
Ils sont intégralement gérés par la JCR de Silverpeas.

La JCR propose une gestion nodale.
Rapidement, la structure des informations pour les wysiwyg est la suivante : pour chaque contenu wysiwyg associé à une ressource (la ressource étant le dossier dans notre cas) existe un noeud "principal" dans la JCR et à partir de ce noeud sont accédées les versions française ou anglaise (ou autre d'ailleurs).

Lors de la migration des wysiwyg, il aurait dû être créé un seul noeud pour le dossier en question. A partir de ce noeud serait alors accédé le contenu en français ou anglais selon le choix de l'utilisateur.

Suite à la migration, deux noeuds "principaux" ont été créés pour le dossier en question et pour chacun les contenus wysiwyg sont identifiés en français (donc celui anglais est à ce moment là perçu techniquement en français). Les identifiants de ces deux noeuds principaux, dans la JCR, sont les suivants :
  • Node_86325wysiwyg_fr.txt : simpledoc_284653
  • Node_86325wysiwyg_en.txt : simpledoc_284654
Les contenus physiques sont quant à eux toujours stockés sur le système de fichiers, mais la structure pour y accéder est différente de la version 5.11.x :
  • /tmp/kmelia9547_20140208/simpledoc_284653/0_0/fr/Node_86325wysiwyg_fr.txt
  • /tmp/kmelia9547_20140208/simpledoc_284654/0_0/fr/Node_86325wysiwyg_en.txt

Les contenus des deux fichiers sont identiques par rapport à la version 5.11.x, mais le contenu anglais (perçu comme du français) n'est plus exposé et Silverpeas expose le contenu français d'un des deux noeuds principaux qui existent. Il semble que cela soit ici celui souhaité qui est affiché pour la langue française.

A ce niveau, nous sommes effectivement d'accord qu'il y a bien deux soucis :
  1. il n'y aurait dû exister qu'un seul noeud "principal" (le serveur Silverpeas s'attend à n'en trouver qu'un seul)
  2. le contenu anglais, quel qu'il soit, devrait être perçu comme tel (et donc pas en français)
En fait ces deux problèmes sont de même nature que ceux remontés par le REDMINE https://tracker.silverpeas.org/issues/5197 (problème sur les pages web qui présentaient des versions obsolètes). Même s'il est vrai que cette anomalie ne faisait pas référence à des contenus multi-langues.
La solution mise en place pour la résoudre (la 5197) a été de créer pour le passage de Silverpeas en 5.12.7 ou 5.13.3 un traitement d'ajustement des contenus wysiwyg "mal restitués" dans l'application.
Ce traitement a abouti notamment :
  • à l'existence d'un seul noeud "principal" pour chaque contenu wysiwyg
  • à l'identification des contenus anglais de nouveau fonctionnelle

C'est ce que nous allons constater dans le prochain point.


Etat des lieux sur le système de fichiers de la version actuelle, la 5.13.3

Il n'existe pour le dossier PDM plus qu'un seul noeud "princpal" pour les contenus wysiwyg : simpledoc_284653 (l'autre a été supprimé).
Ce dernier contient un contenu en français et un autre anglais (d'un point de vue technique) :
  • [...]/data/workspaces/kmelia9547/simpledoc_284653/0_0/fr/Node_86325wysiwyg_fr.txt
  • [...]/data/workspaces/kmelia9547/simpledoc_284653/0_0/en/Node_86325wysiwyg_en.txt

Ces contenus sont quasiment identiques à ceux des versions précédentes de Silverpeas, mis à part les URL qui permettent d'afficher un drapeau français et anglais qui différent.

J'ai également remarqué que dans chacun des répertoires listés ci-dessus, il existe un fichier qui se nomme de la même manière que le wysiwyg mais suffixé de ".bak" (par exemple, Node_86325wysiwyg_fr.txt.bak, comme pour indiquer une sorte de sauvegarde). Je ne sais pas d'où viennent ces fichiers suffixés de cette manière, mais en analysant leur contenu je peux formuler une hypothèse.

Je pense qu'une opération massive de renommage des liens, permettant d'afficher les petits drapeaux français et anglais, a été effectuée dans les fichiers wysiwyg. Chaque fichier pour lequel le renommage a été effectif a occasionné la création d'une sauvegarde du contenu précédent du fichier. Le nom du fichier de la sauvegarde est constitué du nom du fichier sauvegardé et de l'extension .bak.


Quelles solutions à votre problème ?

Nous pouvons constater que l'opération mise en place pour la 5.12.7 et 5.13.3 a bien fonctionné dans le sens où il existe bien dans la JCR un seul noeud "principal" et où les contenus anglais sont bien perçus comme tel.

Sauf que dans votre cas, comme vous le signalez dans cette demande, ces contenus anglais de nouveau restitués vous posent parfois problème.

Nous ne pouvons malheureusement pas, de notre côté, réaliser et intégrer un traitement massif pour une prochaine version corrective de Silverpeas car il n'existe pas de règle technique permettant de savoir si le contenu anglais aurait dû être rétabli ou non. Dans le doute, nous avons préféré faire apparaître de nouveau le contenu anglais.

En revanche, si l'hypothèse que j'ai formulée dans le point précédent est bonne, vous avez peut-être la possiblité d'établir des règles techniques et fonctionnelles qui vous permettraient de modifier massivement le contenu de tous les wysiwyg qui ne sont pas corrects.

Par exemple, il pourrait être imaginé de forcer le contenu de tous les fichiers qui respectent l'ensemble des règles suivantes :
  • le nom de son répertoire parent doit être strictement "en" (pour ne cibler que les contenu anglais)
  • sa date de dernière modification doit être au 14 février
  • son nom doit commencer par "Node_" (permet de ne cibler que les wysiwyg associés à des dossiers)
  • un fichier comportant le même nom, mais en plus suffixé de ".bak", doit exister dans le même répertoire
  • il doit contenir toutes les phrases clés suivantes :
    • weblib/images/fr.gif
    • weblib/images/uk.gif
    • <p>Le pilote des documents contenu dans ce thème est le Responsable Etudes. <br/>Les

Le contenu forcé serait celui qui semble être le contenu type :

<div class="drapeau">
  <a href=""><strong><img alt="" src="/weblib/images/fr.gif"/></strong></a>
  <a href=""><strong><img alt="" src="/weblib/images/uk.gif"/></strong></a>
</div>

Il ne faudrait par contre pas réaliser de nouvelle sauvegarde en ".bak" pour ne pas supprimer la sauvegarde du fichier d'origine.


Pour finir, je ne peux pas garantir que dans la durée ces fichiers ".bak" n'engendrent pas de souci de gestion des contenus wysiwyg dans Silverpeas.

Actions #5

Updated by Emmanuel GRANGE about 7 years ago

Merci pour votre analyse.

Suite à votre remarque, je désire faire le nettoyage des fichier bak , comme vous l'aviez bien deviné, générés pendant à un changement massif des chemins drapeaux.

Par contre, je m'étonne de trouver des nouveaux fichiers par rapport à la liste des modifications que j'avais modifiés "*wysiwyg*.txt.bak".
Je suppose donc, que lors de la copie d'une GED, tous les fichiers sont copiés même s'ils ne sont pas utilisés.

Pouvez-vous me confirmer cela ?

Merci

Actions #6

Updated by Yohann Chastagnier about 7 years ago

En effet, car dans le cadre de la copie d'une GED ce sont les noeuds principaux de la JCR qui sont copiés.
Sur le système de fichiers et pour un wysiwyg, par exemple, cela reviendrait à une copie du répertoire [...]/data/workspaces/kmelia9547/simpledoc_284653 vers [...]/data/workspaces/[identifiant autre kmelia]/[nouvel identifiant JCR].

Actions #7

Updated by Emmanuel GRANGE about 7 years ago

URGENT :

J'ai voulu corriger une publication WYSIWYG en supprimant la version anglaise incorrecte, mais plutôt que de m'afficher la version française, il m'affichait une page blanche, et l'édition de la page WYSIWYG m'affiche une erreur d'initialisation !

Comment puis-je corriger ces pages, si je ne peut pas simplement supprimer la mauvaise version du fichier ?
Pour régler rapidement le problème, j'ai dû copier le contenu FR dans le fichier EN. Mais ce n'est pas une bonne solution, car, dans ce cas, j'ai toujours 2 versions de mon édition WYSIWYG.

Merci de me répondre rapidement sur ce sujet critique

Actions #8

Updated by Yohann Chastagnier about 7 years ago

Bonjour,

En effet, supprimer le fichier WYSIWYG directement du système de fichier ne fonctionne pas car il réside toujours dans les informations de la JCR de Silverpeas une référence sur ce fichier. Lorsque le contenu dans la langue sélectionnée est demandée et qu'il existe dans la JCR, mais pas sur le système de fichier, une erreur technique se produit.

Malheureusement, à ma connaissance, il n'existe pas à ce jour de fonctionnalité, aussi bien depuis l'application GED que depuis la partie administration de Silverpeas, permettant de supprimer un WYSIWYG.

La solution que vous avez mis en oeuvre est aujourd'hui la seule possible et fonctionnelle.

Actions #9

Updated by Emmanuel GRANGE about 7 years ago

Ce n'est pas envisageable de gérer le problème comme ça.

Nous ne pouvons pas demander à nos utilisateur de modifier 2 fois le même fichier dans les 2 langues à chaque fois qu'ils ont une "virgule" à corriger dans leur descriptif WYSIWYG.

De plus, il est impossible, dans nos cas, d'accéder en édition à la deuxième version, quelque soit la langue dans laquelle nous sommes.

Actions #10

Updated by David Lesimple about 7 years ago

Bonjour Emmanuel,

Est-ce qu'il est possible d'établir une règle de gestion pour cette suppression des contenus wysiwyg de dossier de GED ?
En d'autres termes, est-ce qu'il faut supprimer TOUS les contenus wysiwyg en Anglais de dossier, est-ce qu'on peut les lier à une liste d'espaces ?

Actions #11

Updated by Emmanuel GRANGE about 7 years ago

Je pensais justement à une règle du style : Si la GED contient un dossier "FICHES DES CRITERES DE RECHERCHE".
Est-ce que ce serait possible ?
Il faut que je fasse valider ça.

Par contre, ça réglera le problème pour nos GED projets, mais pas pour toutes les autres. Car ce ne sont pas les seules GED a être impacté par ce problème.
Par exemple, nous (la DSI) avons créé beaucoup de publications (support utilisateurs, procédures administratives...) à base de WYSIWYG. Et rien qu'aujourd'hui, nous sommes tombé sur ce cas.
Mais nous avons quand même des procédures dans les 2 langues.
Nous ne pourrons de toute façon pas référencer tous les WYSIWYG ayant ce problème.

N'est il pas possible de proposer une option dans le menu "Que voulez-vous faire ?" pour supprimer une des langues des wysiwyg dans la GED/dossier/publication que les gestionnaires/administrateurs pourront utiliser individuellement ?

Actions #12

Updated by Emmanuel GRANGE about 7 years ago

J'ai trouvé un point commun aux publications dont le contenu WYSIWYG est erronés :

- Il existe un contenu WYSIWYG alors que la publication n'a pas d'entête dans cette langue.
Par exemple, le WYSIWYG d'une publication est différente si l'on y accède en EN ou en FR, mais il n'est pas possible de switcher de FR à EN (car il n'apparait pas l'autre langue), ni même de modifier le contenu WYSIWYG (on accède toujours au contenu de la même langue). La publication n'a d'ailleurs pas de traduction dans l'autre langue.

Par contre, cela ne règle pas le problème pour les descriptifs WYSIWYG des dossiers d'une GED.
Il n'est pas possible de supprimer totalement le descriptif WYSIWYG des dossiers dans une seule langue. On peut vider ce contenu, mais ensuite, il apparaitra vide, plutôt que d'afficher celui de l'autre langue. Alors que si l'on créé un descriptif que dans une langue, ce même descriptif s'affichera quelque soit la langue de navigation.

Actions #13

Updated by Yohann Chastagnier almost 7 years ago

Aujourd'hui, dans le cas d'un premier enregistrement de contenu WYSIWYG, et si ce dernier est vide, aucun enregistrement n'est en réalité effectué.
Dans un cadre correctif, ce principe a été mis en place pour le cas de la mise à jour d'un contenu WYSIWYG. Cela donne la possibilité de supprimer des contenus WYSIWYG depuis n'importe quelles fonctionnalités qui les utilisent.
Maintenant dès lors que l'utilisateur met à jour un document WYSIWYG avec un contenu vide (aucun caractère, donc une taille à zéro en octet), ce dernier n'est en réalité par sauvegardé mais supprimé par rapport à la langue de contenu sélectionnée.

Ci-dessous, plusieurs cas de figures pour illustrer ce nouveau comportement :
afin d'alléger l'écriture des cas ci-dessous, pour chacun, merci de considérer les points suivants
- les cas portent sur n'importe quelle ressource qui utilise les contenus WYSIWYG (par exemple, un dossier d'une GED)
- la notation description [LANGUE|LANGUE|LANGUE] indique l'existence d'une description riche pour une ressource en autant de contenus différents que de langues indiquées, par exemple, description FR|EN indique qu'il existe un contenu de la description d'une ressource dans la langue FR et un autre dans la langue EN
- la notation [LANGUE] sélectionnée indique quelle est la langue sélectionnée pour l'affichage des contenus, par exemple, EN sélectionnée indique que les contenus sont affichés dans la langue anglaise (s'il existent, sinon dans la première langue pour laquelle un contenu existe)
- la notation suppression contenu courant indique que l'utilisateur rentre en modification du contenu WYSIWYG pour enregistrer une version vide de ce dernier, ceci afin de le supprimer par rapport à @[LANGUE] sélectionnée@
  • cas description FR et FR sélectionnée : si suppression contenu courant, plus aucune description n'est présentée, quelle que soit la langue de contenu sélectionnée
  • cas description FR et EN sélectionnée : si suppression contenu courant (aucun contenu EN n'est supprimé puisqu'il n'en existait pas), le contenu de la langue FR reste présenté
  • cas description FR|EN et FR sélectionnée : si suppression contenu courant, le contenu de la langue EN est présenté
  • cas description FR|EN et EN sélectionnée : si suppression contenu courant, le contenu de la langue FR est présenté

Par la suite et dans le cadre d'une demande d'évolution, il pourra être imaginé d'ajouter d'autres outils autour de la suppression de contenus WYSIWYG.

Actions #14

Updated by Yohann Chastagnier almost 7 years ago

  • Status changed from Feedback to Resolved
  • Assignee set to Yohann Chastagnier
  • % Done changed from 0 to 100
Actions #15

Updated by Emmanuel GRANGE almost 7 years ago

  • Status changed from Resolved to Feedback

Nous avons installé la version 5.13.4, il y quelques semaines maintenant.
La procédure pour corriger le problème de façon unitaire semble dans la théorie correcte, mais comme je l'ai précisé dans ma mise à jour précédente :

Il n'est pas possible de supprimer totalement le descriptif WYSIWYG des dossiers dans une seule langue

Donc, nous n'avons pour l'instant AUCUN MOYEN de corriger les descriptifs WYSIWYG des dossiers.

De plus, nous ne pouvons définitivement pas parcourir TOUS les descriptifs WYSIWYG de tout le portail pour vérifier si le problème est présent.

Avez vous une solution pour faire une recherche, afin de trouver les endroits à corriger ?

Actions #16

Updated by Yohann Chastagnier almost 7 years ago

  • Target version set to Version 5.13.5

Oui, en version 5.13.4, il n'existe pas de moyen de supprimer un contenu WYSIWYG dans une langue (notamment sur les dossiers).
C'est pourquoi nous avons mis en place le nouveau comportement, celui décrit dans la note n°13 de cette demande REDMINE, pour donner cette possibilité depuis l'application.

Afin d'être cohérent avec la création ou la mise à jour d'un contenu WYSIWYG vide (0 octets), nous avons également fait en sorte que les contenus WYSIWYG vides ne soient plus pris en compte dans l'affichage des contenus WYSIWYG.

Enfin, pour essayer de répondre à votre problématique principale, nous pouvons essayer de mettre en place un script de reprise des données de la JCR qui supprimerait les contenus WYSIWYG vides, ou les contenus WYSIWYG identiques entre les différentes langues, liés à une même ressource.
Les règles seraient simples. Pour chaque ressource (un dossier, une publication, etc.) serait recherché le contenu WYSIWYG dans ses différentes langues, et s'il en existe au moins un dans une langue, l'une des règles ci-dessous serait appliquée :
  • si le contenu WYSIWYG pour une langue est vide (strictement 0 octet), alors il est supprimé
  • si le contenu WYSIWYG est identique entre chacune des langues, alors un seul est gardé et les autres sont supprimés

Est-ce que ce script de reprise vous conviendrait-il ?

Actions #17

Updated by Emmanuel GRANGE almost 7 years ago

Ce serait un bon début, mais il manque un point important.
Il est beaucoup plus grave d'avoir une information fausse que d'avoir une information vide.

Le plus important est surtout de pouvoir identifier les contenus wysiwyg qui sont faux/obsolète.
En faisant un export des fichiers \*wysiwyg\*.txt, j'ai 17479 fichiers :
6934 fichiers en anglais, et 10479 en français.

Comment puis-je faire le tri de tout cela ?
De plus, même si je suis capable de faire le tri de ces fichiers wysiwyg, je suis incapable de savoir à quel dossier ils appartiennent, depuis le passage en JCR.

Actions #18

Updated by Yohann Chastagnier almost 7 years ago

  • Status changed from Feedback to Rejected

Le script de purge indiqué à la note 16 est en cours d'intégration.
A celui-ci a été ajouté un traitement de renommage des fichiers WYSIWYG sur le système de fichier. En effet, le suffixe des noms de ces fichiers peuvent parfois ne pas être en accord avec la réelle langue du contenu.
Par exemple, kmelia26/simpledoc_38/0_0/en/2607wysiwyg_fr.txt sera renommé en kmelia26/simpledoc_38/0_0/en/2607wysiwyg_en.txt car le fichier se trouve dans le répertoire des contenus anglais (information juste) et que son extension indique un contenu français (extension fausse).

Le chemin d'accès d'un contenu WYSIWYG est constitué des éléments suivants : [identifiant de l'instance de l'application]/[identifiant du noeud JCR principal associé à une ressource dans Silverpeas (un dossier par exemple)]/[version du contenu (toujours 0_0 pour les WYSIWYG)]/[signe de la langue du contenu]/[nom du fichier wysiwyg].
Le nom d'un fichier WYSIWYG est constitué des éléments suivants : [identifiant de la ressource dans Silverpeas (une publication par exemple)]wysiwyg_[langue du contenu].txt. A noter que :
  • la partie _[langue du contenu] est parfois non présente, cela indique en principe un contenu français
  • le préfixe du nom du fichier WYSIWYG :
    • pour une publication, l'identifiant en base d'une publication est utilisée. Par exemple, si l'identifiant en base d'une publication est 1234, alors pour un contenu WYSIWYG français, le nom du fichier est 1234wysiwyg_fr.txt (ou 1234wysiwyg.txt dans le cas de contenus anciens en français)
    • pour un dossier, la concaténation de Node_ avec l'identifiant en base du dossier est utilisée. Par exemple, si l'identifiant en base d'un dossier est 4321, alors pour un contenu WYSIWYG anglais, le nom du fichier est Node_4321wysiwyg_en.txt

Avec l'ensemble de ces indications, il est possible de retrouver à quelle ressource dans Silverpeas un contenu WYSIWYG est rattaché à partir de son chemin d'accès.

Concernant l'identification des contenus WYSIWYG faux ou obsolètes, comme vu dans l'ensemble des notes précédentes, nous n'avons pas de règle fonctionnelle nous permettant de les identifier dans le cadre d'un script de reprise intégré au produit Silverpeas.

Actions #19

Updated by Yohann Chastagnier almost 7 years ago

  • Status changed from Rejected to Resolved
Actions #20

Updated by Miguel Moquillon almost 7 years ago

  • Status changed from Resolved to Closed
Actions #21

Updated by Miguel Moquillon almost 7 years ago

Attention :
si le contenu WYSIWYG d'une publication est identique dans deux langues, dont le français, suite à la migration, c'est le contenu marqué français qui est gardé et fait référence pour l'autre langue.

Ceci signifie donc que si à l'origine le contenu identique a été rédigé en anglais, alors suite à la migration le contenu de référence (marqué français) sera donc en anglais. Aussi, si l'utilisateur, voyant le texte en anglais, décide de donner une traduction en français, comme le contenu de référence est celui marqué français, le nouveau texte va alors écraser celui précédent et le contenu dans les deux langues (français et anglais) sera alors celui du nouveau texte, en français.

Actions

Also available in: Atom PDF