Numérotation des longueurs: on fait quoi ?

#35

Quoi une voie comme Camptocamp.org pouf… ça va être bon ?

Edit : Ou dès qu’il y a un L#-+N, les autres balises ne seront pas interprétées?

#36

Oui, cette page utilise la balise L#-**+**N qui sera (si on choisi cette proposition en l’état) recodée. C’est la balise L#-N que je pense etre inutile.

Réponse à ton edit : si le parseur trouve un L#-N, il ne fera rien : il vaut mieux pas d’interprétation, qu’une fausse interprétation.

#37

Oui donc pour la Proposition #2

Mais il s’occupera du reste ?

#38

Il ne fera rien pour les balises L# en général pour ne pas risquer de montrer une fausse numérotation, mais oui, le reste sera fait.

#39

Cela laisse combien de docs a traiter manuel (à la louche) ?

#40

A la louche, 159 :

On avait sorti les stats avec Alex ici (5eme colonne).

#41

Piece of cake (pardon cheese :grin: )

Oui pour la Proposition #2

@Modo_Topo_FR_contact

1 Like
#42

Je rappelle le lien :

Proposition #2

#43

Ok pour moi.

#44

OK pour moi aussi

#45

OK pour moi itou.

#46

Moi, aussi, je suis d’accord avec tout ce peut améliorer rapidement cette numérotation des longueurs ; et s’il y a des corrections manuelles à faire, je suis disponible.

#47

Je ne suis pas utilisateur des balises L#, je vous fait confiance mais j’ai l’impression que cette solution simplifie la tache sans réduire les possibilités essentielles: que du bon !

#48

OK pour moi aussi !
Et si ça prend un peu de temps de tout coder, peut-être prévoir une 1ère mise en prod avec les plus faciles, qui vont déjà décoder un certain nb d’iti supplémentaires, avant de faire les plus complexes.

2 Likes
#49

Merde, je vais devoir le café:smiley:
Très bien!

#50

Je suis contre.
Il n’y a pas d’interface d’édition confortable actuellement.
Autoriser les retours lignes entre les cellules permet d’aérer le code à l’édition, c’est plus facile de s’y retrouver.
De la même façon, on peut sauter une ligne entre les longueurs sans que ça crée un nouveau tableau.

Pour le lecteur, permettre un retour ligne dans le texte d’une cellule permet de mettre une info concernant toute la longueur mais à la fin de la description, tout en étant mieux visible qu’en la mettant tout à la fin (après la description du relais, qu’on ne lit pas tout de suite).

Exemple :
Il vaut mieux :

Remonter le couloir à gauche du gendarme jusqu’au pied du dièdre. Il comporte plusieurs ressauts athlétiques (un anneau de corde en place) avec des rétablissement délicats (replats avec pierres). R3 possible au fond du couloir ou sur un gros becquet un peu plus haut (sangle en place).
Attention, il y a parfois un nid de guêpes à proximité du dièdre.

que :

Remonter le couloir à gauche du gendarme jusqu’au pied du dièdre. Il comporte plusieurs ressauts athlétiques (un anneau de corde en place) avec des rétablissement délicats (replats avec pierres). R3 possible au fond du couloir ou sur un gros becquet un peu plus haut (sangle en place). Attention, il y a parfois un nid de guêpes à proximité du dièdre.

Dans le 1er cas, l’info sur le nid de guêpes est toujours en début de ligne, quel que soit la largeur de l’écran.

Ceci implique qu’il faille une ligne vide avant et après un bloc de longueurs pour le séparer du texte normal.
C’est la même contrainte que pour les listes à puces. C’est cohérent d’avoir le même fonctionnement entre une liste de longueurs et une liste à puce ou une liste numérotée.

#51

Je recopie ici la réponse que j’ai donné pour la meme question sur le forum interne :

une ligne de tableau L# sera codée sur une unique ligne, en effet potentiellement assez longue. Si tu veux avoir un retour à la ligne en rendu, tu devras mettre le code <br>.

Exemple, en prenant un cas ou ca sera bien plus chiant pour le rédacteur (imagine que le contenu est bien plus long) :

Avant :

    L# 
    | Cellule 1 
    | Cellule 2 
    | Cellule 3 avec
    Un retour à la ligne
    |Cellule 4
     
    L#  
    | Cellule 1 
    | Cellule 2 
    | Cellule 3 avec
    Un retour à la ligne
    |Cellule 4

Après :

    L#  | Cellule 1 | Cellule 2 | Cellule 3 avec <br> Un retour à la ligne |Cellule 4
    L#  | Cellule 1 | Cellule 2 | Cellule 3 avec <br> Un retour à la ligne |Cellule 4

Le reste du code n’est pas concerné.

Pourquoi je pense que ce choix une bonne solution :

  1. C’est certes plus chiant pour le contributeur, mais fonctionnellement, on ne perd rien
  2. Ca n’est pas une voie sans retour, on pourra toujours recoder cette possibilité un jour.
  3. Mais surtout, le parseur sera beaucoup plus simple à faire. Pour moi, la top prio est d’avoir des topos lisibles. J’ai du coder ce truc pour CampUI, et je pense que ce retour à la ligne représente 30% de la complexité, pour juste un peu de confort de rédaction. Le jeu n’en vaut pas la chandelle.

Tout cela dit, c’est Olivier qui s’y colle, si il se sent de le faire, il peut aussi donner son avis.

Mais mon avis, dans l’absolu, c’est keep it simple : même si quelqu’un se propose de coder ce retour à la ligne, pour la pérennité de camptocamp, on ne doit surtout pas le faire.

#52

Je rejoins @Bubu, autant que possible il faut keep it simple pour le contributeur. Ce <br> n’est pas intuitif et dans aucun doc de mise en page actuellement …

#53

C’est le « autant que possible » ou ça coince. Les personnes qui ont essayé de porter le parseur V5 sur la V6 n’ont pas réussi. Et c’est à cause de ça qu’on a des topos illisibles depuis un an, et encore pour un bout de temps.

Pour être clair, je trouve même que ma seconde proposition est encore trop complexe au vu de notre capacité de dev, car un seul développeur occasionnel maîtrisera ce code, c’est bien trop peu.

Si nous n’étions pas sur un projet collaboratif, et si j’étais chef de projet et que mon job en dépendrai, ce serait clairement la première proposition que je choisirai, et il n’y aurait pas de discussion possible :slight_smile:

2 Likes
#54

OK, je suis aussi pour une solution rapide même avec une petite perte de qualité plutôt que trainer des L# pendant des années …