• cf https://linuxfr.org/news/agregateur-leed-la-1-6-est-sortie#comment-1523478 apparemment ça peut ennuyer certains navigateurs de ne pas connaître la langue utilisée et donc de ne pas savoir quelle police/jeu de caractères utiliser. Dans le cas d'un lien vers du code/binaire/tar/etc., peut-être faut-il utiliser un code langue « x-code » plutôt que « wq » (d'après http://www.w3.org/TR/html401/struct/dirlang.html#langcodes ) ;
• on peut aussi se demander si on garde les drapeaux de langue ou pas. Cf Why flags do not represent languages (flagsarenotlanguages.com) et Flag as a symbol of language – stupidity or insult? (...)

Les commentaires notés négativement sont visibles par défaut si on n'est pas logué. Normalement ils devraient être repliés.

Lorsque la dépêche est soumise directement en modération, en étant authentifié ou non, les tags proposés ne sont pas affichés en prévisualisation (mais ils sont bien soumis).

Tentative d'ajout d'un lien vide sur une dépêche en modération (pas d'action sur le bouton OK, pas de message d'erreur) :

I, [2015-02-25T14:43:38.123775 #13116]  INFO -- :   Parameters: {..., "link"=>{"title"=>"", "url"=>"", "lang"=>"fr"}}
I, [2015-02-25T14:43:38.136408 #13116]  INFO -- : Completed 500 Internal Server Error in 13ms
F, [2015-02-25T14:43:38.138382 #13116] FATAL -- : 
URI::InvalidURIError (bad URI(is not URI?): ):
  app/models/link.rb:41:in `authorized_protocol'
  app/controllers/redaction/links_controller.rb:14:in `create'

Même chose avec "http://example.com " (espace à la fin) (plus difficile à détecter pour un utilisateur qui ferait un (...)

Exemple :

Il n'est pas évident qu'il s'agit d'un lien cassé vers une image et pas de simple texte. Un indicateur visuel de l'erreur serait pratique pour la modération.

Solutions possibles :

https://css-tricks.com/snippets/jquery/better-broken-image-handling/
https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-force-broken-image-icon
…

--
Envoyé depuis un stand RMLL

En cas de fausse manip', pour les non-modérateurs et non-admins, envoyer en modération une dépêche est sans retour (jusqu'à ce qu'un modéro/admin corrige et renvoie en rédaction). On pourrait ajouter une confirmation pour ce cas-là.

Sur la dépêche en modération Linux 4.2, un souci a été détecté sur la liste des modifications : il y a 4 révisions en double, numérotées 36, 48, 498 et 505. À noter que le n°48 comporte deux timestamps différents.

Révision n°505 - 09 septembre 2015 01:17:00
Révision n°505 - 09 septembre 2015 01:17:00
(...)
Révision n°498 - 09 septembre 2015 00:51:43
Révision n°498 - 09 septembre 2015 00:51:43
(...)
Révision n°48 - 21 juillet 2015 19:33:35
Révision n°48

(via http://jigsaw.w3.org/css-validator/ )

./app/assets/stylesheets/RonRonnement.css.scss: background-color: #cccccc66;

Propriété erronée : background-color #cccccc66 n'est pas une valeur de background-color : #cccccc66

./app/assets/stylesheets/RonRonnement.css.scss: li.comment > h2 > a.title { pointer-events: none; }

La propriété pointer-events n'existe pas : none

Dans l'espace de rédaction :

• après le titre « Dépêches en cours de modération », ajouter une phrase du type « L'accès à l'espace de modération est réservé aux modérateurs et aux administrateurs. Seuls les titres des dépêches en modération sont visibles des autres utilisateurs authentifiés. »
• rendre les titres cliquables pour les modérateurs/admins (et pas pour les autres donc)
• ajouter dans le titre le nombre de dépêches concernées ? (genre « Dépêches en cours de modération (2) »), et ajouter un titre « Dépêches en cours de (...)

Ce code produit un HTTP 500 sur un contenu ou un commentaire.

![Rien](<img src="http://coin)

Sur la page de statistiques de modération, on voit actuellement l'info pour chaque AMR.

Machin : 42 modérations, 23 votes et 69 éditions
Sur la page Modération (réservée aux AMR), je propose de compléter cette info ainsi :

Machin : 42 modérations, 23 votes et 69 éditions (dernière visite 20/11/2011 à 20:11) [champ libre éditable pour tout AMR pour indiquer en vacances, à l'hosto, révise ses exam', déménagement, accouchement...]


Il faudrait laisser libre la taille de l'image produite par les formules pour qu'elles restent lisibles.

Avec un dollar puis avec deux dollars :

Titre

Tentative d'ajout d'un lien dans une dépêche, avec comme URL https://riot.im/app/#/room/#

INFO -- : Started POST "/redaction/links" for xx.xx.xx.xx at 2017-07-20 23:44:14 +0200
INFO -- : Processing by Redaction::LinksController#create as HTML
INFO -- :   Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "news_id"=>"36926", "link"=>{"title"=>"Coin", "url"=>"https://riot.im/app/#/room/#", "lang"=>"fr"}}
INFO -- : Completed 500 Internal Server Error in 10ms (ActiveRecord: 1.5ms)
FATAL -- : 
URI::InvalidURIError (bad URI(is not URI?): https://riot.im/app/#/room/#):
  app/models/link.rb:33:in `url='
  app/controllers/redaction/links_controller.rb:12:in `create'

La dépêche Agenda du Libre semaine 18 2017 est publiée comme « Posté par Collectif le 30/04/17 à 05:08. Édité par Benoît Sibaud. Modéré par Yvan Munoz. Licence CC by-sa » (initialement créée par moi, puis réattribuée à Collectif).

Par contre dans le flux Atom /news.atom, <author><name>Benoît Sibaud</name></author>.

Un journal publié puis converti en dépêche contient un lien « protocol-relative » //linuxfr.org/users/machin/journaux/slug-slug-slug. Et ce lien est marqué en erreur si on essaie de réorganiser la dépêche, car il ne commence pas par http ou https. Les deux options me semblent être :

1. corriger la validation de formulaires pour accepter les liens « protocol-relative »
2. pousser de l'HTTPS plus largement, et donc mettre le lien https par défaut.

Je penche pour le 2 (pour un argumentaire voire par exemple). Dans app/models/diary.rb (...)