Salut, ce n'est pas l'accès à LiveRC qui est limité suivant le statut mais les fonctionnalités. Il peut effectivement consulter l'interface mais pas révoquer de modifications. Cordialement, --Mattho69me joindre4 août 2014 à 09:47 (CEST)Répondre
Exact, Mattho69 a raison. LiveRC est accessible à tous, mais les fonctions d'édition automatiques (en bas à droite de la barre de titre de prévisualisation, cf ci-contre) sont réservées aux autopattrolled.
Salut, j'ai un problème avec LiveRC : les demandes sur les pages « Vandalisme en cours » et « Demande de suppression immédiate » n'aboutissent pas (ces pages ne sont pas éditées) malgré l'indication de l'interface qui affirme que c'est effectué. Aurais-tu un moment pour m'aider ? Cordialement, — JoleK (discuter) 19 août 2014 à 15:22 (CEST)Répondre
C'est un problème qui avait également été évoqué là, mais faute de pouvoir le reproduire, je n'avais rien pu faire.
Je vais essayé de me pencher sur le pb.
PS : la bonne page, c'est Discussion MediaWiki:Gadget-LiveRC.js. D'autres peuvent avoir le même problème et c'est mieux de centraliser les discussions là-bas.
Je ne patrouille plus en ce moment, mais j'ai depuis quelques semaines un problème avec certains gadgets js qui semble lié à des cookies du type frwikiPostEditRevision suivi d'un numéro que je suppose être celui de diff. Ça remarche normalement après suppression…
Dernier commentaire : il y a 10 ans6 commentaires4 participants à la discussion
Salut,
Depuis hier soir tôt ce matin il m'est impossible de révoquer une modification, faire une requête ou poser un bandeau via LiveRC. J'ai l'interface des utilisateurs non autopatrolled. Cordialement, --Mattho69me joindre21 août 2014 à 14:07 (CEST)Répondre
Since there are many config variables in use, you could save a few function calls (and a few bytes too) by keeping the values you need in a variable such as var conf = mw.config.get( [ 'wgUserName', 'wgTitle', ... ] ) (see a real example in another script) and then accessing conf.wgUserName, etc, in the code which uses them.
Yes, I did the most urgent by replacing all the old variables, both in main LiveRC code, developpment version and extensions. And I noticed the same : it would be good to factorise all these calls.
I already use a function for ArticlePath and Script URLs (see lrcGetPageURL() and lrcGetUglyPageURL()). In some places they are not used yet (this has to be fixed, and I think I should do the same for API URL (lrcGetAPIPageURL() ?).
Then, I will think about your suggestion, probably using the existing LiveRC_Config object. Is getting an item from an object really faster than using mw.config.get() ?
@User:Dr Brains: I was suggesting something more in the lines of accessing the properties of a local object instead of a custom getter function LiveRC_getVariable, but I decided to check with http://jsperf.com/many-mw-config-get-calls/2, and the results suggests that the best option would be using local variables for each value we obtain from mw.config.get directly.
Also, I think you should avoid re-implement functions for things which are provided by MediaWiki, such as mw.util.wikiScript and mw.util.getUrl. If you can get the desired behavior with those (which are already sent to users when the associated ResourceLoader modules are loaded), this will keep your gadget shorter and not risk having your implementation outdated compared with the default ones. Helder25 août 2014 à 18:09 (CEST)Répondre
I understand, LiveRC_getVariable function make it slower than directly call LiveRC_Config["MediawikiVariables"] items, but the advantage of this is to manage when the called variable has not been got from mw.config.get() yet.
So, I think this is the better way. In fact, I don't think that at this point performances really matters, because LiveRC works with ajax request and its peformance is limited by the request delays above all.
However, there is some stuffs not related to ajax that could be improved. I think mostly about the configuration panel opening (LiveRC_ManageParams_OpenMenu() and all related functions). If you have ideas...
Furthermore, there is still one outdated thing to be replaced : the addOnloadHook() call.
Dr Brains : but I don't see why you would need to copy the variables from mw.config to LiveRC_Config["MediawikiVariables"]. You can just get the values directly from there when needed (as in your first version) instead of using an additional getter (your function LiveRC_getVariable) to call getter of mw.config (notice that this has .get() method which provides access to its internal values, because it is an instance of a mw.Map). Helder25 août 2014 à 20:15 (CEST)Répondre
I though you said it was faster to get the variables once and store them. Never mind, I reverted.
I replaced all other deprecated functions (importScript, importStylesheetURI, etc...). The only one remaining is addOnloadHook. I tryed to replace it using jQuery, but none of the proposed syntax works... Any idea ?
@Dr Brains: it is indeed faster to access a local variable which holds the value obtained from a mw.config.get call than using the getter over and over again (compare the three approaches used here: http://jsperf.com/many-mw-config-get-calls/3). But if after storing the values you choose not to use the variables directly and instead to call a function to retrieve the values, then you go back to a situation analogous to using mw.config.get. But as you said above, the difference in performance should not be noticeable, so we might as well keep it as it is now. Helder25 août 2014 à 23:58 (CEST)Répondre
Petits bugs sous Chrome
Dernier commentaire : il y a 10 ans4 commentaires2 participants à la discussion
Bonjour.
Sous Chrome, je note deux petits bugs handicapants :
la sélection d'un élément d'une liste déroulante est difficile, car au bout de 2 ou 3 secondes, elle disparaît d'elle-même ; elle disparaît aussi dès que le curseur se « pointe » en-dehors de son cadre ;
le clic roulette de la souris n'ouvre pas les titres dans un nouvel onglet, mais les ouvre dans le menu de LiveRC...
La liste déroulante ne disparaît pas chez moi (Version 37.0.2062.103 m), sauf si :
je survole une checkbox désactivée
je quitte la liste
Ces deux choses sont normales (la checkbox désactivée, c'est embêtant mais c'est commun à tous les navigateur semble-t-il. Je n'y ai pas trouvé de solution).
Effectivement. Il ne semble pas y avoir d'autre solution que de cliquer-droit et de cliquer sur « Ouvrir le lien dans une nouvelle fenêtre »
(edit) : trouvé ceci. La solution est peut-être là.
Je regarderai ce que je peux faire plus tard car là j'ai des petits soucis d'ordinateur qui seront je l'espère vite réglés.
Ma version de Chrome est bloquée à 35.0.1916.153 m (mise à jour rendue impossible par quelque bug incompréhensible), mais chose curieuse, je viens de réaliser que le menu « Message » n'a pas ce problème... --Orikrin1998 (+) →blablatoir←8 septembre 2014 à 18:53 (CEST)Répondre
Pour le problème de liste déroulante, j'ai réussi à le reproduire.
Malheureusement, j'ai essayé différents trucs mais rien n'y a fait. En fouillant un peu, j'ai trouvé ceci, qui semble indiquer que c'est un bug connu de Chrome. J'espère qu'il sera bientôt corrigé. En attendant, il n'y a pas d'autre solution que d'utiliser un autre navigateur...
Dernier commentaire : il y a 10 ans2 commentaires2 participants à la discussion
Salut!
Je remarque que les icônes indiquant les messages "Test" reçus par les utilisateurs n'apparaissent plus dans LiveRC. Est-ce normal? Peut-on les réactiver soi-même? Merci d'avance pour votre aide. Amicalement, Letartean (discuter) 30 septembre 2014 à 17:03 (CEST)Répondre
Dernier commentaire : il y a 10 ans10 commentaires4 participants à la discussion
Coucou,
Depuis aujourd'hui, lorsque j'ai ouvert une ligne RC, elle ne passe plus dans une nouvelle couleur comme avant (ce qui permettait de facilement repérer les lignes déjà vues), seule la case à gauche avec la croix rouge devient verte (mais c'est trop peu visible pour « repérer facilement »). Comment se fait-ce ?
OK, donc j'avais visiblement oublié de mettre à jour le CSS en même temps que le JS après cette modif, ce qui aura été rattrapé par cette dernière modif.
Excuse-moi de te déranger encore avec ça, @Dr Brains, mais après avoir testé ce que tu suggérais (qui fonctionne), j'ai voulu simplement mettre un fond de couleur, mais ça marche pô. Quel est le code à insérer pour changer la couleur de fond de la ligne, si ce n'est pas background-color ? — JulesDiscuter20 octobre 2014 à 21:29 (CEST)Répondre
Dernier commentaire : il y a 10 ans10 commentaires2 participants à la discussion
Pour améliorer la patrouille sur tablette, il faudrait ajouter de quoi manipuler le volet de visualisation du diff manuellement, car on ne peut pas le faire glisser comme on le fait sur ordinateur. Après, je ne sais pas si c'est prioritaire pour toi de permettre la patrouille sur ce genre d’engins. ☺ --Orikrin1998 (+) →blablatoir←23 octobre 2014 à 14:52 (CEST)Répondre
Faute d'avoir une tablette, je ne peux pas tester. Tout ce que je sais c'est qu'avec ces modifs ça fonctionne normalement sur un pc.
Dans ton /common.js, remplace importScript('MediaWiki:Gadget-LiveRC.js'); par importScript('MediaWiki:Gadget-LiveRC.js/Dev.js');, et dis moi si cela fonctionne correctement sur ta tablette (n'oublie pas de recharger le cache de ton navigateur).
Il n’y aurait pas un .js en trop dans le texte de remplacement ? Quoi qu'il en soit, l’un comme l’autre fait disparaître l’onglet. Et puis j’ai un autre problème : on purge le cache comment, sur Chrome tablette ? Je devrai potasser...À suivre. --Orikrin1998 (+) →blablatoir←23 octobre 2014 à 21:16 (CEST)Répondre
Autre problème : sur Androïd, quand un bouton est trop petit, un zoom automatique s’opère dessus. Du coup, à chaque fois que je clique sur "défaire", je perds la moitié de l’écran LiveRC et je dois dézoomer manuellement. Comment éviter ça ? --Orikrin1998 (+) →blablatoir←9 novembre 2014 à 13:10 (CET)Répondre
J'imagine que tu dois pouvoir configurer ça dans ton navigateur. Côté code javascript, il n'y a rien à faire pour corriger ça.
Idem pour moi, dans l'après-midi ça fonctionnait mais pas ce soir (jusqu'a 19h30 c'était ok). Par contre, je n'ai rien modifié dans mes paramètres. — Rome2[Discuter], le 29 octobre 2014 à 20:14 (CET)Répondre
Pareil sur remarque de Rome2 via IRC comme quoi liverc ne marcher plus j'ai voulu voir et j'ai le message "Missing languages = (fr) [RAZ]". Je n'ai jamais modifier les paramètres de LiveRC.Saveur-du-sud (discuter) 29 octobre 2014 à 20:17 (CET)Répondre
Quand un bloc query-continue est présent, il est toujours placé avant la réponse [3]. Le remplacement des getElementsByTagName('query')[0].getElementsByTagName('truc')[0] par getElementsByTagName('truc')[0] risque donc de causer des problèmes survenant de façon imprévisible. Orlodrim (discuter) 30 octobre 2014 à 22:31 (CET)Répondre
En l'occurrence, ce sont les blocs <query> qui posaient problème, car ils sont dédoublés à cause du warning et placés avant la réponse, qu'on ne lisait donc plus. Mais effectivement, tu soulèves un problème. Je regarderai ce W-E pour les corriger, et préparer le script (principal et extensions) à la mise à jour future de l'API à ce niveau.
┌─────────────────────────────────────────────────┘
Je ne sais pas si c'est lié, mais j'ai remarqué à 12h que LiveRC ne se lançait plus sous Mozilla Firefox (alors qu'hier oui) mais par contre, ça fonctionne sous Google Chrome. Merci . — Rome2[Discuter], le 31 octobre 2014 à 12:07 (CET)Répondre
NB : Cela doit être chez moi, car chez certaines personnes ça fonctionne. Et pour moi, j'ai beaucoup de gadget de mon common.js (historique en couleurs, popups, LiveRC) qui ne fonctionnent plus. — Rome2[Discuter], le 31 octobre 2014 à 12:46 (CET)Répondre
Dernier commentaire : il y a 10 ans22 commentaires3 participants à la discussion
Bonjour,
Le gros du problème a été réglé la dernière fois vu que LiveRC refonctionne, mais je n'ai plus accès aux icônes qui permettaient de savoir où en était le vandale. Le Test 1Test 2 et Test 3 n'apparaissent plus. Serait-il possible de récupérer ce système ? merci . — Rome2[Discuter], le 3 novembre 2014 à 14:40 (CET)Répondre
Il se peut qu'il n'y ait pas beaucop d'avertissements. Essaye en laissant affiché les logs de filtrage. Au démarrage, quand tu as le gros paquet de logs qui déboule, mets en pause et attends que les requêtes de UserWarningsExtension soient revenues. Théoriquement, tu devrait voir quelques panneaux et têtes de Salebot.
Ouvre LiveRC (avec l'extension UserWarnings installée et le cache purgé) et lance les RC
Dans un autre onglet, ouvre ta pdd en modification, modifies-la (en ajoutant un espace, un saut de ligne, n'importe quoi) et mets en commentaire de modif « Spam Test 0 Test 1 Test 2 Test 3 »
Reviens immédiatement sur LiveRC après la publication de ta pdd, normalement ton nom d'utilisateur devrait être affublé de toutes les icônes correspondant au commentaire de modif.
Par défaut, les avertissements ne sont recherchés que sur les dernières 24 heures, donc dans peu de temps (si ce n'est déjà le cas), les patrouilleurs qui n'ont pas modifié cette préférence (et qui utilisent UserWarnings, bien sûr) ne devraient plus voir ton pseudo accompagné de toutes ces disgracieuses icônes qui te cataloguent comme un affreux vandale.
D'ailleurs, si tu n'as pas testé cela, et si tu ne voies toujours pas d'icônes sur les autres utilisateurs, fais ceci :
Lances LiveRC et ouvre le panneau de configuration
augmente la limite de recherche dans l'historique de la pdd de 24 à 240 heures
augmente la limite des RC (mets 300 par exemple)
active la requête des contributions de l'extension UserWarnings si elle ne l'est pas
désactive la requête de l'extension MostModified si tu l'utilises
modifie l'option pause pour que les RC ne se lancent pas immédiatement
Relance LiveRC après avoir purgé le cache
modifie les options pour afficher le journal des filtrages (et seulement ça) puis relâche la pause
remets en pause lorsque tu as un gros paquet de RC (lorsque le timestamp des dernières RC approche de l'heure en cours, ou si tu constates que les plus anciennes commencent à être supprimées)
Attends que toutes les requêtes soient terminées (l'icône du conteur d'édits doit être présent pour tous les utilisateurs)
théoriquement, tu devrais voir pas mal d'utilisateurs affublés d'icônes. En effet, les gens qui déclenchent les filtres ont plus de chances d'être des vandales, et donc d'avoir reçu des avertissements sur leur pdd.
J'ai reçu la notif, mais je ne vois pas quoi faire de plus. Pour moi ça marche, lorsqu'il s'agit de mon compte, d'un faux-nez ou d'un autre utilisateur (par exemple 204.82.191.111 a reçu un test 0).
Mais il est vrai que les avertissements (y compris les têtes de Salebot) sont rares, même dans les filtrages. C'est sans doute pour cela que tu n'en vois pas...
Dernier commentaire : il y a 10 ans5 commentaires3 participants à la discussion
Bonjour. J'ai un petit souci avec le LiveRC lorsque je demande la suppression immédiate d'un article. J'ai la notification comme quoi la modification de la page WP:DSI a bien été effectuée (en rouge en haut à droite) alors que je ne vois jamais la ligne apparaître dans la liste des modifications ; et quand je vais voir sur la page d demande de suppression, la demande n'y est pas. Le problème vient-il de moi ou est-il dû au LiveRC ? Adrien☎26 novembre 2014 à 21:01 (CET)Répondre
En fait, j'ai fait ces demandes manuellement, sans passer par le LiveRC. J'ai le même problème pour ajouter des bandeaux en tête d'article. Adrien☎26 novembre 2014 à 22:59 (CET)Répondre
Dernier commentaire : il y a 10 ans3 commentaires2 participants à la discussion
Bonjour, aujourd’hui lorsque j'ai envoyé une requête de suppression immédiate avec le motif « Décision PàS », un faux lien s'est créé et j'ai du le corriger. Le lien nous envoyait sur cette page. [5] Merci --SleaY (discuter) 29 novembre 2014 à 18:03 (CET)Répondre
Après vérification, ce n'est pas LiveRC qui pose problème, mais l'entrée "Décision PàS" du message système MediaWiki:Deletereason-dropdown ({{#ifexist:{{TALKPAGENAME}}/Suppression|[[{{TALKPAGENAME}}/Suppression|Décision PàS]]|[[Wikipédia:Pages à supprimer|Décision PàS]]}}). En effet, celui-ci est supposé s'appliquer sur la page à supprimer (avec URL action=delete), pas sur Wikipédia:Demande de suppression immédiate. Le résultat du mot magique {{TALKPAGENAME}} ne donne donc pas ce qui est attendu.
J'ai mis à jour LiveRC pour qu'il substitue les mots magiques qui pourraient être utilisés pour les raisons de l'outil de signalement/demande administrative.
Donc a priori, après purge du cache pour prendre en compte cette évolution, ton problème ne devrait plus revenir.
Dernier commentaire : il y a 10 ans12 commentaires2 participants à la discussion
Bonsoir,
Sur le conseil de Superjuju10 et d'Housterdam, je souhaite utiliser DiffExtension, mais sur mon écran en 1024x768, la barre dépasse la largeur de l'écran, ce qui m'oblige à déplacer la page vers la gauche pour voir la suite (c'est notamment le cas lorsque [éditeur précédent identique] et le bouton Révoquer s'affichent) : est-il possible de résoudre cet inconvénient ?
Pour aider, voici une copie d'écran, ou plutôt un montage fait à partir de deux copies d'écran puisque je ne peux voir la totalité de la barre (lorsque le diff s'affiche, je ne vois pas tout ce qui est à droite du "T" de Test0).
Par contre, je viens de faire un essai sur un écran en 1440x900 et là, c'est impéccable. Malheureusement, je patrouille à 99 % à partir du bureau, en 1024x768, et la vieille carte graphique ne permet pas d'aller au-delà .
Dr Brains : Grâce à vous, je viens de découvrir un outil très pratique dans Firefox (Tools > Web Developer > Responsive Design View) qui permet de tester une page web dans différentes résolutions. J'ai donc mis la page de diff en 1024x768, et le problème est toujours le même : la barre elle-même (arrière-plan gris) s'ajuste bien à la largeur, mais son contenu (boutons + listes de choix) prend toujours la même place, et déborde de la barre grise (et donc de l'écran), ce qui donne le même effet que dans l'image proposée ci-dessus à 12h27. Je ne vois d'ailleurs pas bien comment on pourrait obliger ces éléments à rester dans le cadre gris lorsqu'on diminue la résolution, à moins de réduire fortement leur taille et celle de la police, mais ça serait illisible. Ou alors augmenter la hauteur de la barre et mettre son contenu sur 2 lignes lorsque la résolution est en 1024x768 ?
Dr Brains : Ah oui, le contenu de la barre (ensemble bouton + listes) se déplace bien avec le pointeur. Mais comme le cadre gris, pas assez large, reste fixe, son contenu déborde à droite, ou à gauche, ou des 2 côtés (selon le positionnement du pointeur). Dans l'idéal, il faudrait que la largeur du cadre gris s'ajuste à la largeur de son contenu, et que le tout se déplace avec le pointeur. Crois-tu pouvoir le faire ?
Pour le moment, c'est le mieux que je puisse faire. Au moins tous les boutons sont-ils accessibles sans bouger la fenêtre.
Cette fonction est en effet déjà utilisée dans LiveRC pour la barre de contrôle des RC. Il faut pouvoir améliorer son utilisation dans DiffExtension sans casser la première utilisation. Ça va prendre du temps, et j'en ai peu, malheureusement.
Dr Brains : Oui, bien sûr, il ne faut pas dégrader ce qui marche bien dans LiveRC, et dans DiffExtension avec les résolutions actuelles. Surtout pour la minorité qui utilise encore du 1024x768 aujourd'hui Merci pour cette amélioration et bon dimanche.
Dr Brains : Bonjour, Je ne sais pas si tu as modifié quelque chose depuis, mais en essayant ce matin au boulot, donc en "vrai" 1024x768, le contenu de la barre se déplace à l'intérieur du cadre gris, et il n'y a donc plus de débordement en dehors de ce cadre. C'est donc très bien, merci encore Cordialement, BerAnth (discuter) 15 décembre 2014 à 10:06 (CET)Répondre
Taille des textes
Dernier commentaire : il y a 10 ans4 commentaires2 participants à la discussion
Salut, je n'ai pas trouvé comment changer la taille des textes...Cela peut-il se faire (de changer la taille des textes ou d'ajouter le paramètre correspondant) ?
Dernier commentaire : il y a 10 ans4 commentaires2 participants à la discussion
Bonjour,
Depuis que j'utilise la barre DiffExtension j'ai, sur certaines pages de diff, le message Missing languages = (fr) [RAZ] qui apparaît en rouge en haut à droite (popup) et, lorsque c'est le cas, la barre DiffExtension ne s'affiche pas. Si j'actualise ensuite la page (F5), la barre s'affiche normalement. Savez-vous pourquoi, et y a-t-il quelque chose (paramètre ?) que je puisse modifier pour empêcher cela ? Ou est-ce un bug ?
PS : a priori ça a un rapport avec les libellés des boutons ; dans la popup, si je clique sur [RAZ] (une bulle d'aide explique l'utilité du RAZ : Delete this alert and continue without translations), la barre DiffExtension apparaît, mais les libellés des boutons ressemblent à des mots clés : ils commencent tous par "<". BerAnth (discuter) 17 décembre 2014 à 13:20 (CET)Répondre
Le message d'erreur est normal. A priori, c'est dû à un temps de chargement trop long de la page où se trouvent les textes traduits (d'où un chargement correct la fois d'après, lorsque pas mal de trucs dans la page sont en cache).
Il n'y a malheureusement pas grand-chose à y faire.
Ce qui pose problème semble être les doubles deux-points de l'IP 2001:660:5001:a188::163. L'IP n'est ainsi pas reconnue comme une IPv6 dans la fonction LiveRC_ManageIPv6(). J'ignorais qu'une IPv6 pouvait être codée ainsi. La solution est de revoir la regexp. ceci devrait régler le souci.
Ceci dit, la pop-up peut aussi survenir si la modif a déjà été revertée, ou si il y a eu une modif d'un autre utilisateur entre-temps. En effet, elle apparaît lorsqu'il y a incompatibilité entre l'utilisateur qu'on demande à LiveRC de reverter et l'utilisateur auteur de la dernière modif (lorsqu'on requiert l'historique de la page pour savoir jusqu'à quel oldid il faut reverter).
En effet à ma connaissance, je pense ne jamais avoir vu de telles IPv6. Pour le second point que tu soulèves, certes en effet, mais j’étais le seul actant sur le présent diff - essayant nombre de fois en prenant de grand intervalles de temps - et le même problème survenait. PS : Bizarre, mais dans le diff, lorsqu'on clique sur l'adresse IP 2001:660:5001:a188::163, il y a une sorte de redirection, sous Contributions, on à « Pour 2001:660:5001:A188:0:0:0:163 » (L'IPv6 est différente ?! Et plus de deux-points !). Amicalement, HousterdamDiscuter, le 10 janvier 2015 à 17:11 (CET)Répondre
Effectivement, c'est très bizarre. Du coup, ce que j'ai fait ne règle sans doute pas le souci. Le problème doit provenir de Mediawiki qui "raccourcit" les IP dans les diffs. Je ne comprends pas pourquoi...
Dr Brains : À priori, tout fonctionne normalement, spécifiquement en matière de révocations des IPv6 - comme là ou encore là - bien qu'elles soient dépourvues des doubles deux-points . Bonne journée à toi et merci encore, HousterdamDiscuter, le 17 janvier 2015 à 13:52 (CET)Répondre
Bandeau de suppression immédiate
Dernier commentaire : il y a 10 ans5 commentaires2 participants à la discussion
Bonjour, serait-il possible que, lorsqu'une requête de suppression immédiate est envoyée, LiveRC mette également le bandeau {{Suppression immédiate}} dans l'article en question avec le bon motif? La raison est que parfois, lorsqu'une telle requête est envoyée, la page est également blanchie et donc le créateur de la page (un nouveau) ne comprend pas toujours ce qui se passe. Il recrée donc l'article en croyant à un bug ou à un blanchiment malhonnête. --SleaY (discuter) 19 janvier 2015 à 03:21 (CET)Répondre
Il est possible de placer le bandeau {{Suppression immédiate}} via le formulaire "bandeaux" (s'il n'est pas dans la liste, il peut être ajouté). Il n'est pas souhaitable à mon avis de l'intégrer à la demande de suppression, car on y perdrait la souplesse de l'outil.
Dr Brains : Ok, mais la liste de bandeaux ne permet pas d'ajouter le motif, est-ce qu'il y une manière de personnaliser LiveRC pour qu'il mette le bandeau avec le bon motif en même temps que la requête de SI ? --SleaY (discuter) 21 janvier 2015 à 06:06 (CET)Répondre
Dans la définition des bandeaux, tu peux en mettre plusieurs :
template:Suppression Immédiate|raison=X string:SI : X withDate:
template:Suppression Immédiate|raison=Y string:SI : Y withDate:
template:Suppression Immédiate|raison=Z string:SI : Z withDate:
Merci de l'astuce, mais est-ce qu'il y a quelque chose à faire après avoir cliqué sur « valider » ? J’essaie de purger le cache mais rien ne tien alors j'ai modifier mon code directement [6]. Dernière chose, est-ce possible de modifier le résumé (comme j'ai essayé avec 'resume':'text') ? --SleaY (discuter) 22 janvier 2015 à 01:52 (CET)Répondre
Ne marche pas sur fr.wiktionary
Dernier commentaire : il y a 6 ans24 commentaires5 participants à la discussion
Bonjour,
Malgré que les informations données dans Wikipédia:LiveRC/Documentation/Installation/fr#Installation aient été suivies [7], le gadget ne marche pas sur le Wiktionnaire : l'interface est illisible à cause d'un chevauchement d'informations (listes des icônes avec leur légende & la liste des contributions (qui d'ailleurs ne subissent aucune mise à jour)). Le bouton de configuration est grisé, et rien ne se passe au clic. Quelque chose n'aurait pas été fait correctement ? — Automatik (discuter) 20 janvier 2015 à 23:44 (CET)Répondre
Si, les modifs faites automatiquement avec InstallAndConfigLiveRCExtension seront valables pour tous les utilisateurs, puisque effectuées sur wikt:MediaWiki:Gadget-LiveRC.js. C'est là que tous les bandeaux, résumés de modifs, icônes, etc... doivent/peuvent être configurés en fonction du site. D'ailleurs le nom du modèle {{Catégorisation JS}} comme ça.
Suis à la lettre les indications de la doc de l'extension et cela devrait bien se passer.
J'ai fait toutes les étapes jusqu'à l'étape 5 au début, au moment où il est dit : Une fois retourné sur la page d'installation : après avoir cliqué sur le lien Config je retourne sur MediaWiki:Gadget-LiveRC.js (page dite d'installation ?), et je n'ai pas de bouton "Configuration MW".
Par ailleurs, j'ai du mal à comprendre pourquoi on nous demande dans InstallAndConfigLiveRCExtension de metrte dans common.js personnel le gadget puisqu'on a déjà ajouté le gadget dans nos préférences selon Installation (ce qui résulte en deux liens LiveRC sur la gauche). C'est ça qui m'a repoussé à suivre les recommandations de configuration - qui demandent en outre de mettre quelque chose d'autres dans MediaWiki:Gadget-LiveRC.js, écrasant donc ce qu'on venait de faire à l'instant par l'installation. Automatik (discuter) 22 janvier 2015 à 00:51 (CET)Répondre
dans wikt:MediaWiki:Gadget-LiveRC.js, copier l'intégralité de MediaWiki:Gadget-LiveRC-frWP.js + ajouter tout à la fin de la page la ligne mw.loader.load('//fr.wikipedia.org/w/index.php?title=MediaWiki:Gadget-LiveRC.js&action=raw&ctype=text/javascript', 'text/javascript', false);.
Tu partiras alors d'une installation identique à fr-WP, avec donc tout plein de paramètres à adapter (en premier, s'occuper de l'onglet Configuration LiveRC)
Dr Brains : : par vide, j'entendais que la page wikt:MediaWiki:Gadget:LiveRC.js (où on arrive après avoir cliqué sur "Config") n'a qu'un titre, et pas de contenu.
J'ai bien fait l'étape 4.6, et ça ne crée pas cette page. Cliquer sur "Configuration MW" n'a pour effet de créer aucune page sur fr.wikt, en suivant bien les instructions. Automatik (discuter) 24 janvier 2015 à 23:47 (CET)Répondre
Dr Brains : OK, je me disais bien qu'il pouvait y avoir un problème de ce côté-là mais je n'avais pas trouvé d'où ça venait - faut dire que j'avais pas cherché dans la page du gadget d'origine. Maintenant j'en suis à Une fois retourné sur la page d'installation, que je ne comprends pas : quelle est la page d'installation ? Ce qui est sûr, c'est que wikt:MediaWiki:Gadget-LiveRC.js ne présente aucun lien "Configuration MW". Automatik (discuter) 25 janvier 2015 à 00:45 (CET)Répondre
Il me tarde d'assister à la mise en place d'une version fonctionnelle de LiveRC sur le wiktionnaire. Dans cette optique, j'aimerais vous aider, malgré mes piètres compétences en programmation, quel que soit le langage. N'hésitez pas à me faire part de points sur lesquels je pourrais vous rendre service.
Récemment, je me suis piqué d'« installer » LiveRC, en le cochant dans mes préférences du wiktionnaire — faisant ainsi fi de la recommandation « ne pas installer ». J'ai ainsi pu constater que l'essentiel du script devait déjà être en place, seuls quelques points importants restant à régler, parmi lesquels :
Comme pour la plupart des gadgets, le développement de LiveRC n'a jamais vraiment été organisé ; les contributions sont faites en fonction des attentes ponctuelles (correction de bug, intégration d'une nouvelle fonctionnalité de MediaWiki, etc.) et de l'intérêt qu'y trouvent les différentes personnes ayant les compétences pour les faire.
Je ne peux rien promettre car je manque cruellement de temps pour ça, mais je vais voir si je peux résoudre quelques problèmes rencontrés sur le Wikitionnaire avec des fonctionnalités qui ne posent pas de problème sur la Wikipédia francophone — j'insiste sur ce pré-requis, car c'est une garantie de faisabilité.
J'ai jeté un coup d'œil au point qui me semblait le plus problématique, à savoir l'impossibilité de révoquer / blanchir / etc. J'ai l'impression que c'est lié au fait qu'il faille être autopatrolled avant de pouvoir utiliser ces fonctionnalités — ce que tu n'es pas (et moi non plus, d'ailleurs). JackPotte, pourrais-tu confirmer, s'il te plaît ?
JackPotte: alors ça, c'est surprenant ! Merci pour ta réponse. Il semblerait que tu ne sois pas autopatrolled non plus En fait, il y a à peine 181 utilisateurs autopatrolled sur le Wiktionnaire. La configuration ne contient aucun critère d'attribution automatique du statut ; j'en déduis qu'il ne peut être attribué qu'explicitement par les bureaucrates…
Peut-être serait-il opportun de modifier sur le Wiktionnaire le groupe requis pour l'utilisation complète de LiveRC ?
En fait en tant que bureaucrate on doit attribuer l'autopatrolled aux élus, puis le retirer quand ils sont promus "patroller" car les droits du groupe sont inclus, que l'on retire pour les admins car ce groupe inclus les droits des patrouilleurs à son tour... JackPotte ($♠) 1 février 2019 à 16:33 (CET)Répondre
J'ignorais qu'il fallait être autopatrolled pour pouvoir accéder aux fonctionnalités de LiveRC telles que la révocation et le blanchiment, ces opérations étant autorisées, hors LiveRC, même aux utilisateurs anonymes (sous IP).
En tout cas, cette absence du bouton de révocation est bien le point le plus problématique (mais d'autres problèmes me semblent presque aussi gênants). S'il est dû à mon modeste statut sur le wiktionnaire, je vous saurais gré de me le confirmer.--Braaark (discuter) 1 février 2019 à 17:17 (CET)Répondre
Braaark: L'absence du bouton semble bien liée au statut. Est-ce que cela est souhaité dans ton cas par la communauté du Wiktionnaire, ce n'est pas à moi de le dire, mais il me semble très improbable que celle-ci souhaite en limiter l'accès à seulement 181 personnes, dont ne font pas partie les administrateurs et bureaucrates. Sur la Wikipédia francophone, le problème ne se pose pas, puisque le statut est auto-attribué sur la base de l'ancienneté et du nombre d'éditions du compte.
// -- Droits de limitation des fonctions d’édition automatique --LiveRC_Config["LimitationsRight"]["Default"]='autopatrol';LiveRC_Config["LimitationsRight"]["Revert"]='autopatrol';LiveRC_Config["LimitationsRight"]["Blank"]='autopatrol';LiveRC_Config["LimitationsRight"]["Tag"]='autopatrol';LiveRC_Config["LimitationsRight"]["Message"]='autopatrol';LiveRC_Config["LimitationsRight"]["Thank"]='autopatrol';LiveRC_Config["LimitationsRight"]["Report"]='autopatrol';LiveRC_Config["LimitationsRight"]["AskForRevisionDeleteFromHist"]='autopatrol';
Merci Arkanosis pour cette information. Il me vient à l'esprit que si jamais le wiktionnaire devait limiter l'utilisation de ces fonctionnalités de LiveRC aux utilisateurs ayant au minimum 500 contributions à leur actif, il me faudrait sûrement au moins un an pour pouvoir y accéder . D'ailleurs, comme je l'ai évoqué plus haut, j'ignorais qu'un telle restriction avait cours sur Wikipédia (et elle me paraît, à première vue, superflue). En tout cas, voilà déjà un point de clarifié.--Braaark (discuter) 3 février 2019 à 19:44 (CET)Répondre
Bonjour Arkanosis, apparemment dans le code il y a à la fois les droits qui sont pris en compte (autopatrol) et les groupes (autopatroller) ? Etant donné que la gestion des groupes diverge d'un wiki à l'autre - il y a en effet peu d'« autopatroller » sur le Wiktionnaire mais beaucoup plus d'utilisateurs avec le droit autopatrol -, ce serait sans doute plus efficace de considérer exclusivement les droits, qui eux ont une sémantique invariante d'un wiki à l'autre. Le code est balèze, je n'ai pas encore identifié où il serait requis un groupe autopatrolled pour exécuter une action. Mais je veux bien apporter les modifications nécessaires si des indices me sont éventuellement fournis. — Automatik (discuter) 4 février 2019 à 18:50 (CET)Répondre
RevertDiff : problème avec l'outil de masquage pour les sysops
Dernier commentaire : il y a 10 ans4 commentaires2 participants à la discussion
Bonjour !
Je constate que DiffExtension ne fonctionne pas lorsque le nom d'utilisateur à été masqué par un administrateur. Aucun outil ne marche : impossible de défaire/révoquer un diff (bon dans le exemples que je donne -ci-après, cela va sans dire mais bien évidement, en temps "normal", il me serait impossible d'annuler une modif car ceci entrerait en conflit avec les modifications intermédiaires), d'apposer un bandeau, un message, de faire une requête aux sysops de suppression, de blocage, ni de blanchir la page ; bref, les outils ont tous disparus si ce n'est la barre d'arrière fond qui reste. Il semble que ce qui perturbe RevertDiff est le fait que le nom d'utilisateur ait été purgé/retiré. Des exemple : ce diff et aussi celui-ci. À noter que je n'ai pas « eu affaire » à ces diffs lors d'une patrouille avec LiveRC, donc je en sais pas ce que ça aurait donné. Bonne journée ! Amicalement, HousterdamDiscuter, le 4 février 2015 à 11:15 (CET)Répondre
Effectivement, il y avait un bug. Je l'ai corrigé et les formulaires "bandeau", "blanchir", "message" et "requête" sont revenus.
Toutefois, il reste un problème si d'aventure le nom d'utilisateur est masqué (dans ton premier diff, passe à la révision précédente): les formulaires "message" et "requête" (si le nom d'utilisateur est nécessaire au type de requête) restent présents et posent problème. Je vais voir ce que je peux faire pour corriger cela.
L'image en lien présente trois entrées du journal des check-user, supposé accessible seulement aux check-users. Tu devrais la supprimer ou au moins la recadrer pour qu'on ne voie plus ces lignes.
Dernier commentaire : il y a 10 ans13 commentaires10 participants à la discussion
Bonjour,
Pour info, j'ai modifié aujourd'hui LiveRC pour être complètement débarrassé des anciennes fonctions obsolètes (qui risquaient d'être supprimées sans préavis).
Ce faisant, il a fallu que je modifie la façon dont les extensions sont installées dans le /LiveRCparam.js et par conséquent il est possible et même probable que LiveRC ne voie plus les extensions que vous avez installées. Elles sont encore là, elles fonctionnent (pour certaines), mais risquent d'être zappées à la prochaine mise à jour de vos paramètres.
Donc, pour éviter tout souci :
ouvrez LiveRC,
allez dans le menu de configuration,
refaites votre sélection d'extensions,
sauvegardez
rechargez le cache
Vous devriez obtenir quelque chose ressemblant à ceci.
Dernier commentaire : il y a 10 ans4 commentaires2 participants à la discussion
Bonjour,
je ne vois plus que les modifications des utilisateurs, alors qu'avant je pouvais juste regarder celles des utilisateurs débutants si je le souhaitais. Comment remettre comme avant ? Macadam1Miaou ?30 mars 2015 à 20:12 (CEST)Répondre
Depuis quelque temps, il faut confirmer le marquage comme relue d'une modification, ce qui est particulièrement pénible (un clic de plus, ainsi que des fenêtres pop-up gênantes visuellement). Je comprends que cela soit nécessaire pour le marquage comme douteuse/à vérifier, où un « résumé de marquage » est utile. Mais je ne vois pas ce que cela apporte pour le marquage comme relu. Serait-il possible de se passer de cette confirmation, s'il te plaît ?
Tu as cette demande de confirmation seulement si tu utilises l'extension MarkQuestionable. Mais il est vrai que cela pourrait être évité pour une modif non douteuse (relecture "normale").
L'idée est de "refaire" LiveRC en tant qu'extension de Mediawiki.
Avantages :
Faire de la page de lancement une vraie page spéciale (Special:LiveRC)
Traductions de textes gérées par des messages système (et créées via translatewiki.net)
Suppression de toute la partie "chargement d'infos" (entre LiveRC_Init() et le premier lancement de liveRC()), qui peut être gérée bien plus efficacement en PHP (certains paramètres, comme les paramètres d'installation de certaines extensions, sont impossibles à avoir en javascript via l'API)
Gestion de l'installation locale via une page spéciale dédiée (Special:LiveRC/config)
Problème sur l'API. Bug T96361 ouvert. N'hésitez pas à y aller et voter pour que ce soit résolu ("subscribe"). En attendant, les filtres ne sont plus pris en compte, exactement comme si l'extension Abuse Filter n'était pas installée.
Désolé du retard à la réaction. J'ai passé deux jours sans internet, et j'ai crû mourir...
Dernier commentaire : il y a 10 ans1 commentaire1 participant à la discussion
Bonjour.
Sur tablette, LRC ne marche plus. Je ne peux pas être précis mais le programme met très longtemps à prendre en compte un « clic ». Dommage, ça marchait il n’y a pas longtemps.
Dernier commentaire : il y a 10 ans3 commentaires2 participants à la discussion
Bonjour,
Je remarque un bug avec le modèle {{merci IP}} quand il est apposé par LiveRC : le paramètre 1, qui devrait être ~~~~ est en fait le nom de la page éditée : voir ici par exemple.
Dernier commentaire : il y a 9 ans3 commentaires3 participants à la discussion
Bonjour, ce script est importé en JavaScript, au moins sur le Wiktionnaire, Wikilivres et la Wikiversité. Or, son comportement varie là-bas : la fonction lrcGetNamespaceName(2) renvoie null. Comme je n'arrive pas à le corriger de là-bas, je voudrais savoir si quelqu'un pouvait ajouter la première ligne suivante juste avant la deuxième svp :
Je n'ai pas réussi à reproduire le problème. Si j'active le gadget "LiveRC" sur le Wiktionnaire, il se charge correctement (les modifications défilent normalement).
Le problème est-il au chargement ou ailleurs ?
Une différence qui pourrait expliquer le problème : sur Wikipédia, la configuration est sauvegardée dans MediaWiki:Gadget-LiveRCSiteConfig.js, mais pas sur le Wiktionnaire, de sorte que la valeur de lrcGetNamespaceName est lue à chaque chargement sur le Wiktionnaire. Si j'ai bien compris (je n'ai pas essayé de valider), cette configuration peut être mise à jour en démarrant LiveRC, en allant dans la configuration (troisième bouton de la barre d'outils), puis en cliquant sur le bouton "Configuration MW". Il faut être admin.
Dernier commentaire : il y a 9 ans1 commentaire1 participant à la discussion
bonjour, je suis nouvellement inscrit sur wiki après avoir constaté que plusieurs articles sur des actualités majeures sont absentes dont la crise au burundi.
Je ne sais pas trop par ou commencer et si possible me trouver un parrain wiki.
J'Aimerais aussi savoir si il est possible d'avoir un accès à un chat en temps réel.
Merci et au plaisir de travailler pour améliorer wiki.
Dernier commentaire : il y a 9 ans1 commentaire1 participant à la discussion
Bonjour,
J'adore l'extension qui permet de voir les avertissements. Elle permet de se rappeler qui a reçu quoi sans avoir à retenir plein de nom d'IP. Cependant, cette fonction ne fonctionne plus chez moi. J'ai fait la mise à jour des paramètres de LiveRC mais sans résultat. Est-il possible de m'aider à réactiver cette fonction pour voir à côté du nom d'utilisateur les avertissements reçus dans LiveRC. Merci d'avance. Amicalement, Letartean (discuter) 11 novembre 2015 à 16:05 (CET)Répondre
Ajout supplémentaire
Dernier commentaire : il y a 9 ans9 commentaires3 participants à la discussion
Bonjour.
Un modèle Test? a été créé dans le but de prévenir un utilisateur que sa modification était annulée car considérée comme suspecte.
Peut-être serait-il intéressant de l'introduire parmi les autres dans le gadget.
Bonne continuation, Mathis73[dialoguer] - 20 décembre 2015 à 16:34 (CET).Répondre
Hello Mathis73, je n'ai pas reçu ta notif (j'avais heureusement cette page en LdS). À quelles situations est destiné ce modèle exactement ? Il me semble essentiellement être une version simplifiée de {{Faut sourcer}}, non ? À noter aussi qu'il existe déjà {{Faut sourcer 2}}. PS : n'hésite pas à laisser un mot sur le BULPAT à ce sujet . Amicalement, — JulesDiscuter22 décembre 2015 à 13:33 (CET)Répondre
« Faut sourcer » ne précise pas que la modification a été annulée, donc ne vaudrait-il pas mieux faire une version {{Pas sourcé}} qui reprenne grosso modo le contenu de ton (joli) {{Test ?}} (axé sur la question du sourçage, donc sans l'aspect conventions de style) ? — JulesDiscuter22 décembre 2015 à 13:36 (CET)Répondre
Merci de ta réponse Jules78120. J'en avais déjà un peu parlé lors de la création du modèle sur le BULPAT (voir). En fait, c'est un modèle qui se place entre le vandalisme et le non-sourcé. En effet, nombre de patrouilleurs (moi en tout cas :)) voient des ajouts suspects, douteux.
Peut-être : "les anecdotes, les renseignements de type « annuaire », les simples définitions de dictionnaire, les messages personnels, les publicités" (ce n'était pas trop ce côté là que je voyais en fait, le modèle Test ? est un peu confus alors). Mathis73[dialoguer] - 22 décembre 2015 à 13:46 (CET)Répondre
J'ai ajouté un bandeau, mais après plusieurs actualisations et purges de cache, Mathis73 et moi ne le voyons pas apparaître sur LiveRC. J'ai loupé une étape ?
Dernier commentaire : il y a 9 ans2 commentaires2 participants à la discussion
En cas de déclenchement d'un filtre global, le texte et le lien en sont pas bon : Déclenchement du filtre global-110: undefined (Actions :Baliser)), au lieu de Déclenchement du filtre global-110: Adding emoji unicode characters (Actions :Baliser)). Je me serais bien penché sur le souci mais il va falloir m'expliquer comment LiveRC a été modifié, ça a bien changé. Soisyc Croisic (discuter) 15 janvier 2016 à 20:27 (CET)Répondre
Dernier commentaire : il y a 9 ans3 commentaires2 participants à la discussion
Bonjour à tous,
j'utilise LiveRC sur la wikipedia italienne et l'icone bot (robot) apparait à côté de mes modifs normalement quand elles sont "cachées" (flood editor). Cependant, une fois la fonction désactivée, les modifs successives continuent à apparaitre comme cachées. C'est une histoire de cache à effacer ou autre chose? merci --Ruthven(msg)24 janvier 2016 à 06:40 (CET)Répondre
Ruthven: Bonjour C'est au minimum mis en cache pour la session courante, effectivement, mais il ne me semble pas qu'on garde le résultat entre différentes sessions de LiveRC (contrairement à ce qui se fait avec DeluxeHistory, par exemple). Redémarrer LiveRC ne résout-il pas le problème ?
Bonjour Arkanosis; en effet redémarrer résout le problème. Désactiver l'icone quand la fonction flood editor n'est plus utilisée pourrait être utile pour suivre les modifications des autres sysop (pour les miennes, je sais déjà quand la fonction est désactivée). --Ruthven(msg)18 février 2016 à 15:41 (CET)Répondre
LiveRC ne charge pas
Dernier commentaire : il y a 9 ans2 commentaires1 participant à la discussion
Je reste bloqué sur la page de chargement et rien ne bouge, que ce soit sur Firefox ou sur une install fraiche de Chrome. J'ai bien activé le gadget dans les préférences (et uniquement là), les outils de développement me montrent que Gatget-LiveRC.js est chargé, il a visiblement été exécuté (eg window.LiveRC_Version est définie et vaut "1.0.5" et je n'ai pas d'erreur js dans la console. Une idée ? — Evp∅k Me parler16 février 2016 à 11:20 (CET)Répondre
Dernier commentaire : il y a 9 ans1 commentaire1 participant à la discussion
Bonjour . J'ai essayé à plusieurs reprises de modifier le délai de rafraîchissement des RC, d'abord via LiveRC, puis directement sur ma page LiveRCparam.js. À chaque fois j'ai modifié la donnée, validé, et puis la donnée est restée à 10. J'ai essayé d'augmenter le délai, et il y a le même problème. Quelqu'un aurait une idée de comment changer cette option ? Merci d'avance. ← Fugitron‹… ›, le 11 mai 2016 à 20:45 (CEST)Répondre
Pas en français
Dernier commentaire : il y a 9 ans1 commentaire1 participant à la discussion
Erreurs JavaScript dues à un nouveau rc_type non implémenté
Dernier commentaire : il y a 8 ans4 commentaires1 participant à la discussion
Ligne 11704, document.getElementById('showRC_'+rc.type) donne quelquefois null, lorsque rc.type vaut "categorize". Il s'agit d'une nouvelle valeur de rc_type, introduite dans MediaWiki 1.27, voir mw:Manual:Recentchanges table#rc_type. Le correctif serait donc d'ajouter la checkbox correspondante et/ou d'ajouter des tests de sorte à ne pas rencontrer d'erreur en cas de nouvel ajout ultérieur dans l'API. od†n ↗blah18 mai 2016 à 10:27 (CEST)Répondre
Implémenté une nouvelle checkbox pour afficher/masquer "RC > Changements de catégories", activé par défaut. Et un traitement plus graceful en cas de nouveaux ajouts ultérieurs à l'API. N'hésitez pas à me notifier si besoin est. od†n ↗blah31 mai 2016 à 13:30 (CEST)Répondre
J'aurais besoin de vos avis pour savoir si vous préférez que ces changements soient affichés ou non par défaut. Merci d'avance pour vos réponses. od†n ↗blah1 juin 2016 à 06:14 (CEST)Répondre
J'ai modifié pour masquer par défaut les changements de catégories. Ces changements floodent pas mal la liste, et cela permet de mettre un peu "sous le tapis" la fonctionnalité pour l'instant, car le filtrage est assez perfectible (notamment de par la confusion entre la page catégorisée et la catégorie elle-même). od†n ↗blah2 juin 2016 à 07:03 (CEST)Répondre
Appel à retours d'utilisateurs expérimentés de LiveRC
Dernier commentaire : il y a 8 ans1 commentaire1 participant à la discussion
Rebonjour, j'aurais aussi besoin de vos retours sur un autre point. Lorsque vous filtrez les RC à afficher (ou plutôt à charger, en l'occurrence) avec les moult checkboxes idoines, constatez-vous des inconsistances, des situations du genre que vous souhaitez afficher/masquer certains éléments mais que vous n'avez pas le résultat escompté ? J'ai l'impression qu'il y a quelques bugs à ce niveau, donc si vous avez des cas précis à exposer, je suis tout ouïe. od†n ↗blah1 juin 2016 à 09:02 (CEST)Répondre
Mes révocations sont abandonnées sur le LiveRC (mais pas en revert normal)
Dernier commentaire : il y a 8 ans7 commentaires3 participants à la discussion
Bonjour, depuis hier soir, je ne peux plus me servir du liveRC pour effectuer des actions. J'ai essayé sur Firefox et sur Chrome, sans succès. Je peux toujours faire des modifs autre part. Quelqu'un a une idée de la possible origine du problème ? J'ai réussi à m'en servir quelques heures avant cette "panne"... Du reste, tout fonctionne normalement, c'est à dire que je vois les diff défiler. Merci et Cordialement — GrandCelinienQuestions - Aide ?9 septembre 2016 à 14:08 (CEST)Répondre
Bon, d'après ce que je vois, c'est parce que les liens pour révoquer, remercier, mettre des test0 etc. ne sont plus valides car ils contiennent la balise <bdi> nom de l’utilisateur<bdi>, j’ai le même problème quand je veux utiliser le gadget d'avertissement RevertDiff, qui me dit que l’action est impossible. Je notifie les pros : 0x010C et Od1n : z'avez une idée ? Je peux vous faire des screen si besoin. Je pense pas que ça vienne de moi parce que j’ai rien touché entre le moment où ça marchait et celui où ça ne fonctionne plus. Amicalement — GrandCelinienQuestions - Aide ?9 septembre 2016 à 14:33 (CEST)Répondre
Orlodrim : Bonjour, en patrouille j'utilise uniquement le gadget LiveRC « DiffExtension » et depuis hier j'ai le même problème sauf que ça ne marche toujours pas actuellement. Si vous pouviez faire quelque chose pour rétablir le fonctionnement de ce gadget, ça serait super ! Merci d'avance, — BerAnth(m'écrire)10 septembre 2016 à 17:16 (CEST)Répondre
Dernier commentaire : il y a 7 ans7 commentaires3 participants à la discussion
Bonjour,
Quand la on active le curseur de révision dans les préférences bêta, ce dernier s'affiche également (mal) dans LiveRC. Ce qui n'est pas très pratique pour voir le diff. Y a t'il un moyen de le cacher juste au sein du gadget ? Merci. Prométhée (discuter) 25 septembre 2016 à 11:20 (CEST)Répondre
Prométhée : Salut, c'est une fonctionnalité béta donc je ne sais pas combien de temps ma solution de contournement fonctionnera mais je la propose tout de même : Dans ta page personnelle de personnalisation du CSS LiveRC, il te faut rajouter le code suivant qui permet de ne pas afficher le curseur de révision :
Pour info, si on utilise DiffExtension pour avoir les fonctions automatiques de LiveRC dans les diff "normaux" et que l'on souhaite conserver le curseur de révision sur les pages de diff, il faut plutôt utiliser ce code :
Salut Mathis B, c'est bizarre, je n'ai pas ton problème chez moi. Testé sous Windows 10 (Chromium, Firefox et Edge) et tout semble fonctionner. J'ai bien DiffExtension, je vois aussi le revision slider et je peux utiliser les boutons de LiveRC. Tu utilises quel navigateur ? Tu as essayé de désactiver RevisionSlider dans les préférences ("Ne pas montrer RevisionSlider" dans l'onglet Apparence) ? Shawn (discuter) 4 novembre 2017 à 18:24 (CET)Répondre
Astuce : bouton pour masquer les modifications qui sont "autopatrolled" et celles marquées comme "relues"
Dernier commentaire : il y a 8 ans1 commentaire1 participant à la discussion
Salut, je vous propose cette astuce que j'ai utilisée dans ma configuration de LiveRC et qui permet d'ajouter un bouton de suppression de ligne (les petites croix en haut à gauche de la liste des diff).
Ce bouton permet de retirer de la liste les révisions qui ont été faites par des utilisateurs "autopatrolled" et celles marquées comme "relues". Ceci permet de ne pas patrouiller des modifications qui ont déjà été relues.
Voici la procédure à suivre :
Dans le panneau de configuration de LiveRC, aller dans l'onglet "Onglets"
Cocher "Paramètres pour boutons de suppression de lignes" (nécessite de rafraichir la page pour être pris en compte il me semble)
Dans le nouvel onglet "Suppression RC" qui apparait, ajouter la configuration suivante : textId:HIDE_PATROLLED color:#b2b2b2 class:RcPatrolled separator:
Valider et recharger la page.
Voilà, normalement un nouveau bouton de suppression de ligne est apparu. Il retirera de la liste les lignes déjà relues (celles qui ont le nom d'utilisateur sur fond gris).
Dernier commentaire : il y a 8 ans3 commentaires2 participants à la discussion
Bug report from itwiki: in diff view, the link "mark as patrolled" (in italian "Segna come verificata") doesn't work anymore. Whenever you click on it, the edit remains not patrolled. --Rotpunkt (discuter) 3 janvier 2017 à 18:54 (CET)Répondre
Dernier commentaire : il y a 8 ans1 commentaire1 participant à la discussion
Bonjour
L'équipe Collaboration a mis en place un flux de données appelé ReviewStream destiné à améliorer l'effort de vérification des modifications récentes. Il inclut les prédictions de ORES (non disponibles sur Wikipédia en français pour le moment, mais existant pour d'autres langues où LiveRC est utilisé) et la mise en place de niveaux d'expérience pour les éditeurs.
N'hésitez pas à me contacter si vous souhaitez intégrer ReviewStream à LiveRC.
Dernier commentaire : il y a 7 ans6 commentaires4 participants à la discussion
Il semblerait que LRC soit incompatible au nouveau thème Timeless. C'est normal, il n'est pas fait pour. Bien que ce ne soit pas urgent, pour fixer simplement le problème, il serait pratique pour les utilisateurs d'avoir une vérification au démarrage de LRC : si Timeless est détecté, recharger la page en utilisant le paramètre &useskin=vector afin de forcer l'utilisation du thème par défaut, vector, seulement sur la page courante. GrandCelinien, Bastenbas et Litterae :. --Framawiki✉19 septembre 2017 à 22:35 (CEST)Répondre
Dernier commentaire : il y a 7 ans5 commentaires3 participants à la discussion
Bonsoir, en me connectant ce soir à LiveRC, j'ai eu l'agréable surprise de voir que l'icône bot était affichée à coté de mes diffs (voir le rendu : 1, 2). Certains autres utilisateurs, comme Lomita et Bastenbas (j'en oublie sûrement) ont vu la même chose que moi, d'autres non. Cela est pour le moins étrange, je n'ai pas de bot, je n'en suis pas un (!), je ne comprends pas pourquoi il y a eu ce bug. Après bidouillage, tout est revenu à la normale, mais je voulais vous rapporter cette étrange apparition pour savoir si c'est un problème connu. Cordialement. VateGV◦ taper la discut’ ◦6 novembre 2017 à 20:00 (CET)Répondre
Par principe, j'ai vérifié que ça ne vient pas de médiawiki sur cette diff rapportée par Lomita comme marquée bot :
SELECT rc_id, rc_bot FROM frwiki_p.recentchanges_userindex where rc_user_text = 'VateGV' and rc_timestamp > 20171106000000 and rc_title rlike 'Fonds' limit 10;
Sous FF Quantum 57.0.3 (Windows 10), après avoir cliqué sur un diff, si je veux sélectionner dans la boîte déroulante (sous le champ « Défaire ») un motif pré-établi de revert, lorsque mon curseur survole l'un des motifs, il se met à clignoter (en réalité : le focus alterne très rapidement entre le motif survolé et la ligne blanche en haut de la boîte déroulante servant à laisser un motif vide, personnalisable) puis la boîte déroulante se referme après environ une seconde. Ce qui oblige d'être rapide pour cliquer sur le bon motif.
Y a-t-il un moyen de réparer ce bug, qui n'est pas critique, mais gênant ?
J'ai un fort soupçon vis-à-vis du hack dans LiveRC_BlankExtension_Toggle qui fait qu'on ne cache pas immédiatement le menu déroulant, mais qu'on en diminue progressivement l'opacité via LiveRC_alert_setOpacity, de 5 points toutes les 50 millisecondes après une première pause 200 millisecondes, jusqu'à le fermer complètement. Ça colle avec le fait que le clignotement ne débute que si on se déplace hors du « titre » du menu déroulant et avec le lag initial, la fréquence du clignotement, et la fermeture forcée qui suit.
Si on pouvait se débarrasser complètement du hack, ce serait l'idéal, mais j'imagine qu'on doit pouvoir faire en sorte que la fermeture ne soit pas branchée sur le onmouseout du select mais sur un événement plus approprié. À creuser…
J'ai contourné le problème, mais je ne suis pas satisfait de l'approche (d'autant que le risque est maintenant d'avoir le menu replié qui reste affiché trop longtemps — même si ça me semble moins gênant). En théorie, on devrait utiliser onmouseleave plutôt que onmouseout pour ne pas que l'événement soit déclenché en allant balader la souris sur les option du select, mais Firefox n'a pas l'air d'implémenter ça correctement (en tout cas, avec la version 58.0b13).
Je notifie à tout hasard Od1n, qu'il ait au moins le « pourquoi » avant de faire une syncope à la vue du diff .
Je n'ai pas d'apriori positif ou négatif sur OOjs, mais ça ne peut pas être pire que le setTimeout actuel
Reste à voir si ça n'entre pas en conflit avec le mouseover qui gère le déplacement du séparateur horizontal (un autre hack moins poilu mais plus impactant sur l'ensemble de l'interface).
Dernier commentaire : il y a 7 ans1 commentaire1 participant à la discussion
Bonsoir, j'ai depuis ce soir , fait une fausse manipulation sur la configuration de liverc, depuis quelques heures, je me retrouve avec les deux boutons qui permet de passer entre Le visuel et le wikitexte dans la prévisualisation des diffs. J'ai cru avoir résolu le problème mais avec échec. (Nb: j'utilise la beta "Diffusions visuels" qui est très pratique en edition normal et en patrouilleur mais le bouton de changement de vision sur live rc me dérange) Merci :) Tomybrz(Une discussion?)16 février 2018 à 20:17 (CET)Répondre
Paramétrage
Dernier commentaire : il y a 6 ans1 commentaire1 participant à la discussion
Hello.
J'ai mis à jour mes paramètres LiveRC hier et le gadget s'est mis à afficher les journaux de suivi, ainsi que les lignes « patrol ». Dans le premier cas, décocher l'option ne change rien. Dans le deuxième cas, j'ignore comment les faire disparaître. J'ai annulé mon paramétrage mais rien n'a changé.
i18n for AbuseFilter actions is not rendered correctly
Dernier commentaire : il y a 6 ans3 commentaires2 participants à la discussion
Hi everyone, I'm sorry for writing in english but I can't really communicate well in French. While using LiveRC I noticed that, if there's a filter set to "block" AND "tag", the action message is rendered wrong: you'll see "Actions: <abusefilter-action-tag,block>". It's easy to see that the function window.getFilterAction receives "tag,block" as a comma-imploded list of actions, but is instead treated as a normal string and concatenated to "abusefilter-action-", thus the wrong display. I'm not sure if this is a LiveRC problem, or it's due to some AbuseFilter bug, but anyway I'm reporting it here (and will fix it in AbuseFilter code if needed). Thanks, --Daimona Eaytoy (discuter) 10 octobre 2018 à 13:16 (CEST)Répondre
Dernier commentaire : il y a 6 ans1 commentaire1 participant à la discussion
Hi, sorry but I don't speak French.
I was wondering if there's currently a way to mark an edit as minor. My understanding is that the feature was added in version 0.4.2, but then removed in 1.0.0, or is there an option somewhere else that I can't find? Thanks in advance. --Titore (discuter) 12 novembre 2018 à 18:42 (CET)Répondre
Semi-protection étendue
Dernier commentaire : il y a 6 ans1 commentaire1 participant à la discussion
Dernier commentaire : il y a 5 ans3 commentaires2 participants à la discussion
Bonjour,
Pour info, il semble y avoir un bug (rare j'imagine) lors de la visualisation de diff.
Je ne sais pas comment le reproduire, mais je vois dans la colonne de droite des modifications de la modif concernée "'''''Mona Lisa''''', est un tableau est un tableau officiellement attribué à l'atelier de".
Hors après vérif via l'historique de l'article il n'y a jamais eu "est un tableau est un tableau" avant mon annulation.
Je ne vois pas d'explication, la seule particularité que je vois est que mon "défaire" s'est comporté comme une annulation en un coup de deux modifications (mais ça n'explique pas en rien diff qui s'affiche).
TramwaySuspendu : Si si, il y a bien eu "est un tableau est un tableau", une première fois ici -> [8], une seconde fois là ->[9], la deuxième fois ça a été corrigé très vite (entre le moment de l'erreur et ton reverte), ton annulation a peut-être non pas annulé l'erreur mais la dernière modif de l'article, la correction donc. -- Sebk(discuter)12 juin 2019 à 03:37 (CEST)Répondre
Merci pour cette réponse. Effectivement. Mon annulation ne semble pas avoir annulé le diff sous mes yeux lors du clic, ni aucune modification unique d'ailleurs, mais la combinaison de deux (d'où le +28 sur l'opération balisée LiveRC alors qu'il n'y a pas -28 avant). ✍TramwaySuspendu (talk) 13 juin 2019 à 01:03 (CEST)Répondre
Atelier Wikipoétique
Dernier commentaire : il y a 4 ans1 commentaire1 participant à la discussion
Bonjour !
Les Midis de la Poésie organisent cet après-midi à Bruxelles un Wikiatelier consacré aux poétesses contemporaines. Je serai en charge de la formation et de l'encadrement des nouvelles contributrices et nouveaux contributeurs. Merci d'être bienveillants vis-à-vis de la création des articles autour de cette thématique, n'hésitez-pas à venir déposer un message sur ma page de discussion en cas de problème. Merci de ne pas supprimer ou révoquer plus vite que votre ombre ; essayez, dans la mesure du possible, d'être pédagogues et d'expliquer les problèmes sur la PdD de l'article ou de la contributrice/du contributeur qui y travaille. Je serai particulièrement attentif aux critères d'admissibilité, mais il est possible que certains articles soient dans la zone grise. Merci de ne pas lancer trop rapidement de procédure de suppression et de laisser le temps aux contributrices et contributeurs de rassembler de nouvelles sources.
Vous êtes évidemment les bienvenus pour travailler avec nous sur cette thématique .
TypeError: data.CallBack is not a function. (In 'data.CallBack()', 'data.CallBack' is undefined)
Dernier commentaire : il y a 4 ans2 commentaires2 participants à la discussion
Apologies for writing in English.
There were a few instances of the above error in our production logs today but I'm not sure exactly where they are coming from. Stack trace points to this script inside at httpComplete. Could you please take a look? Jon (WMF) (discuter) 20 octobre 2020 à 21:01 (CEST)Répondre
Dernier commentaire : il y a 4 ans8 commentaires2 participants à la discussion
Bonjour,
Suite à ce message, que ma PdD, je me demandais s'il y avait le moyen que lorsque l'on fait la requête pour une suppression immédiate, qu'elle y insère le bandeau {{SI}}, sur la page en question.
J'ai trouvé le code permettant d'ajouter le bandeau mais lorsque j'ai analysé le code source de LiveRC, j'ai trouvé le problème que je vais essayer de résumer : pour les actions de suppressions, blocages..., elle est résumé dans un code JSON en haut de page, et plus bas vers la fin (ligne 14667), il est dit en gros pour telle action tu me modifie la page indiqué dans le JSON, avec le modèle indiqué dans le JSON... J'espère avoir été compréhensible, si ce n'est pas le cas n'hésite pas à me le dire. Mais bref... cela fait qu'on ne peut pas mettre un code spécifique pour les SI, comparé au DPP... Donc je vais voir si je peux trouver une autre solution, mais je pense que comme tu dis, il faudra passer par une extension.
Dernier commentaire : il y a 4 ans1 commentaire1 participant à la discussion
Bonjour, Est-ce un bug? ma boite de discussion affiche le message suivant: "Flow\Exception\InvalidDataException" après activation du nouveau système de discussion structurée. De ce fait je n'ai plus accès à aucun des messages qui me sont adressés, et il m'est impossible de revenir à la version antérieure. Peut-on m'indiquer la procédure qui rétablirait ma page discussion? Bien cordialement Merci Pierre André (talk)
merci pour votre message. Je contacte rapidement la page indiquée. Bien cordialement Merci Pierre André (talk)
Problème Whois Toolforge
Dernier commentaire : il y a 4 ans2 commentaires2 participants à la discussion
Bonjour, je poste ce message afin de vous informer d'un problème avec l'outil "Whois" dans LiveRC.
En effet, lorsqu'une IP fait une modification, il est possible de cliquer sur le "?" à côté de l'adresse IP afin d'accéder à un "whois". Cependant, l'URL du site utilisé (tools.wmflabs.org/whois/) est mauvaise et je suis redirigé vers un "404 not found". En allant voir des mes paramétrages LiveRC, j'ai vu que l'adresse utilisée pour le Whois était par défaut "https://tools.wmflabs.org/whois/$1/lookup" ($1 = IP).
J'ai donc trouvé l'URL qui fonctionne, et la position de l'adresse IP dans celle-ci.
Je vous informe donc de ce problème qui semble généralisé puisque c'est un paramétrage par défaut de LiveRC (cf. MediaWiki:Gadget-LiveRC-frWP.js, paramètre "WhoisURL").
Dernier commentaire : il y a 3 ans3 commentaires2 participants à la discussion
Bonjour,
Une requête DIMS a été initiée en 2019 (!) pour remplacer une icône PNG par sa version SVG, puis la requête a évolué vers un remplacement global des icônes PNG par des versions SVG. Le problème est que le projet est resté inachevé, laissant une DIMS qui traîne depuis plus de deux ans…
Le choix des icônes de remplacement semble avoir déjà bien avancé. Pour ceux qui le souhaiteraient, vous pouvez poursuivre la discussion ici et poster une nouvelle DIMS lorsque tout aura été défini.
C'est très dommage que cette requête n'ait pas abouti, le remplacement d'icône était complet. Dans ma mémoire, il n'y avait plus qu'à en faire le CSS officiel, mais ça n'a jamais été fait et je n'ai pas compris pourquoi. Thomas Linard (discuter) 23 septembre 2021 à 18:43 (CEST)Répondre
La page DIMS est vraiment pour les requêtes entièrement prêtes et validées, de sorte qu'il ne reste plus à l'admin qu'à appliquer les modifications demandées. Si toutes les icônes ont été choisies et que cela aboutit à une charte homogène, il reste possible de poster une nouvelle DIMS, mais cette fois en fournissant le nouveau code demandé ; parce que là, l'admin devait aller chercher et remplacer le nom de chaque image lui-même, très laborieux ce qui explique certainement pourquoi personne n'a pris en charge la requête.
De plus, il faudrait aussi "mettre en valeur" la requête, genre en ajoutant une capture d'écran du résultat, en fournissant un CSS permettant d'essayer localement le nouveau design ; parce que là de ce qu'en vois, il y a plein d'icônes qui sont… en noir et blanc. Je devine une refonte semblabe à ce qu'il y a eu par exemple sur le site MDN, c'est-à-dire une nouvelle mode qui nous vient de chez Google, et qui ne va pas vraiment dans le bon sens du point de vue de l'esthétique. C'est pourquoi, avant de poster une nouvelle DIMS il pourrait être judicieux de déjà réaliser ces points, surtout la possibilité d'essayer localement le design avec un CSS supplémentaire, pour pouvoir éventuellement apporter des retouches.
À la suite de 192070091 j'ai remarqué qu'il manquait quelquefois des styles CSS dans les aperçus, par exemple les en-têtes des pages de diff.
C'est parce qu'auparavant, la page en aperçu était entièrement (oui, le document HTML entier) stockée dans un <div> en "display:none", attaché au DOM de la page LiveRC. De cet élément masqué, on extrayait le contenu qui nous intéressait pour l'insérer dans l'interface de LiveRC. Mais tout le reste était encore dans le <div> invisible, notamment les styles présents dans la page en aperçu, et qui étaient donc effectif sur la page LiveRC.
La première solution à laquelle j'avais pensé était d'ajouter des mw.loader.load('mediawiki.diff.styles'), etc. mais la liste des modules nécessaires aurait été laborieuse à établir, et pire encore, cela aurait été une horreur à maintenir (c'est le genre de truc qui n'arrête pas de changer dans MediaWiki).
J'en suis donc, après pas mal de réflexion, arrivé à cette solution.
Après avoir effectué quelques recherches, en l'état actuel des specs HTML5, il est maintenant tout à fait permis (car apparemment cela n'était pas permis à un moment) d'ajouter des éléments metadata <link> dans le <body>, même à l'intérieur d'un autre élément, dans un <div> ou même dans un dans un <span> si ça nous chante.
Un avantage avec la présente solution est qu'elle reste simple : getPageContent() continue de simplement retourner un node, et lorsque l'on supprime ce node plus tard, les styles sont automatiquement supprimés aussi.
Le seul problème auquel je peux penser, hormis le fait qu'on se retrouve avec du CSS redondant, est que les styles ajoutés, de par leur position dans le DOM, pourraient prendre la priorité sur d'autres styles. Il serait peut-être préférable de les insérer à la fin du <head> ou au début du <body> de la page LiveRC ; mais du coup il faudrait gérer leur suppression en même temps que la suppression ou le remplacement de la prévisualisation, autrement ils iraient s'accumuler.
Il aurait été possible de refaire un système de <div> invisible, et supprimé à chaque nouvel appel de getPageContent(), comme il y avait avant 192070091, mais qui n'aurait contenu que les stylesheets et non le document entier. Et en prenant soin de le placer au début du <body> et non à la fin. Mais de toute façon, cela ne résoudrait rien : les autres styles ajoutés dynamiquement sont placés à la fin du <head>, après les styles de départ, et c'est entre ces deux-là qu'il faudrait idéalement placer nos stylesheets extraites de la prévisualisation. De plus, auparavant les styles de la prévisualisation étaient positionné à la fin du <body> de la page LiveRC, donc avec la plus haute priorité, et cela n'a apparemment jamais posé problème, donc en pratique il ne doit pas y avoir de problème de priorité. Avec ma présente solution, les styles sont déjà plus haut dans le DOM qu'auparavant (et pourraient donc laisser la priorité aux TemplateStyles), et je pense que cela devrait être suffisant en pratique.
Tout cela n'est nécessaire que si le contenu rapatrié est affiché. Si le DOM de ce contenu n'est pas affiché (exemples : ces deux fonctions qui ne font que récupérer les données du formulaire, ou bien encore l'élément CatMaintenance_PageRequete dans le script MaintenanceCategorie.js), il n'est pas utile de bricoler pour ajouter les styles.
Hello @od1n. Ça n'a peut-être rien à voir, mais depuis ce jour, dans LiveRC, les diffs ne s'affichent plus comme avant : les ajouts et les retraits ne sont plus sur fond blanc, mais sur fond gris ou transparent (le gris est celui du background de l'ensemble de LiveRC). Bàt, — Jules*discuter29 mars 2022 à 19:14 (CEST)Répondre
Salut @Jules*, j'ai effectivement fait une modification tout à l'heure, suite à laquelle on a effectivement un background-color:white; en moins (vu qu'il a depuis lors été supprimé dans les styles upstream que l'on charge), mais je viens d'effectuer quelques tests et je ne constate aucune différence. Pourrais-tu décrire plus précisément où le fond blanc a disparu ? Quelle skin (vector, vector legacy, monobook…) utilises-tu (vu que cela peut avoir un impact) ? od†n ↗blah29 mars 2022 à 20:07 (CEST)Répondre
@Od1n. Je suis sous Vector. Voici une capture d'écran [10]. Le paragraphe concerné par la suppression/l'ajout, avec les bordures jaune (gauche du diff) et bleue (droite du diff) sont sur fond gris, contrairement aux paragraphes non modifiés, sur fond blanc. Avant, tout était sur fond blanc.
J'ai ajouté ceci à ton CSS pour rétablir le fond blanc. Avec les "background:none" dans ton CSS, LiveRC affiche les prévisualisations avec la couleur de background d'un élément parent .LiveRC_PreviewBG (gris), alors qu'habituellement LiveRC les affiche avec la couleur de background de .livePreviewBG (blanc).
Tu peux me croire, ces histoires de CSS des prévisualisations dans LiveRC c'est un bazar pas croyable !
À propos, une grande partie de tes styles pour LiveRC ne sont en fait pas appliqués, car suite au renommage de la page, tous les sélecteurs commençant par .page-Utilisateur_EDUCA33E_LiveRC ne sont plus effectifs.
Merci, c'est de nouveau comme avant . J'ai dû définir ces styles personnalisés il y a des années… Sinon, j'ai l'impression que LiveRC en général est un bazar pas croyable ! — Jules*discuter30 mars 2022 à 13:21 (CEST)Répondre
Amélioration du wikicode des messages de requête déposés
Dernier commentaire : il y a 2 ans5 commentaires4 participants à la discussion
l'ajout inutile de trois lignes vides entre le titre de section et le début de la liste, ce qui ne facilite pas l'identification des sections lors de la lecture du wikicode. Une ligne suffirait amplement.
l'insertion d'un Recréation d'une page supprimée suite à une {{#ifexist:{{TALKPAGENAME}}/Admissibilité|[[{{TALKPAGENAME}}/Admissibilité|décision communautaire]]|[[Wikipédia:Débat d'admissibilité|décision communautaire]]}} qui n'est pas approprié car la page des suppressions immédiates n'est pas celle faisant l'objet du débat d'admissibilité. Je ne sais pas si ce second point est le résultat d'une erreur lors de la rédaction du message ou d'une erreur dans le gadget LiveRC. À priori ce texte provient de la page MediaWiki:Deletereason-dropdown. D'ailleurs, un problème similaire a déjà été soulevé antérieurement (cf. #Mauvais lien) et apparemment résolu en 2014.
Merci beaucoup DreZhsh pour la réponse ultra-rapide. Le double passage à la ligne semble un résidu d'utilisation antérieure de « EditParam["appendtext"] » choix d'édition qui les nécessitait. Maintenant, on utilise « EditParam["section"] = "new"; », "sectiontitle" et "text". J'espère juste que le retrait proposé du \n\n ne posera pas de problème pour la fonction d'édition (ligne 14772, wpajax.http({url:lrcGetAPIURL('action=edit'),…) si la valeur du titre de section n'est pas spécifiée/vide (ligne 14758, (EditParam["sectiontitle"]=summary;), ce qui n'est peut-être jamais le cas dans le gadget. La flemme de décortiquer tout le code. Mais de toute façon, l'API gère l'ajout de contenu sans titre de section. — Ideawipik (discuter) 3 novembre 2022 à 17:23 (CET)Répondre
Dernier commentaire : il y a 2 ans5 commentaires4 participants à la discussion
Hi! I'm from itwiki, sorry for writing in English. As you may know, the LTA known as Piermark/HoY is active on both itwiki and frwiki.[11] Since a few days some users started noticing that LiveRC stops working for a while when HoY is active. At first we thought this was a coincidence, but today I noticed that this may happen when a steward suppresses his user name from the block logs (as just happened here). When the bug occurs the browser console log shows that log.title is undefined in https://fr.wikipedia.org/wiki/MediaWiki:Gadget-LiveRC.js. Please ping me if you need more info. --Titore (discuter) 23 janvier 2023 à 18:25 (CET)Répondre
Bonjour, je suis un contributeur de la Wikipédia en italien. Comme vous le savez peut-être, le vandale longue durée Piermark/HoY est actif sur it et fr. Depuis quelques jours, certains patrouilleurs ont signalé que LiveRC s'arrête de fonctionner quand il est actif. Au début on pensait à une coïcidence, mais aujourd'hui j'ai remarqué que ça peut arriver quand un steward masque lourdement son nom d'utilisateur dans le journal des blocages. Quand le bug se produit, la console du navigateur affiche log.title is undefined in https://fr.wikipedia.org/wiki/MediaWiki:Gadget-LiveRC.js. Notifiez mois si vous avez besoin de plus d'infos.
Merci beaucoup! On further analysis, the block logs in question are suppressed automatically by the filter to avoid leaking the account IPs (phab:T152394). Technically it is still an oversight-level deletion, so the fix still applies. Pinging @LD because, as I understand, he's been using a similar filter and he may have noticed something similar. Titore (discuter) 24 janvier 2023 à 15:31 (CET)Répondre
@Titore Thanks for pinging. On fr-wiki, precisely $wgAbuseFilterActions, block, rangeblock and even degroup are set to false. We indeed use several filters based on accountname, but we rather target account names (not IPs) or edits. Some manual oversight-level actions are still required for some accountnames but I didn't notice any change on LiveRC (we rarely use those actions though).
Our user « Filtro anti abusi » is then only active for global filters, contrary to yours, more active overall.
For the record, we use another kind of "logs", even if based on abusefilter logs, which is less impacted by suppress and rename : Wikipédia:AbuseFilter/Modifications bloquées : suppressed/renamed accounts are still displayed, unless they have been automatically suppressed (which may not happen often as block is set to false). LD (d) 24 janvier 2023 à 17:30 (CET)Répondre
Suppression du lien wiki au sujet de l'avis sur la page de discussion de l'utilisateur
Dernier commentaire : il y a 1 an1 commentaire1 participant à la discussion
Bonsoir et merci beaucoup d'avoir développé cet outil, est-il possible de faire en sorte que le message d'avertissement laissé à l'utilisateur n'inclue pas le lien wiki vers la page ? Merci d'avance, cordialement Nilo1926 (discuter) 15 février 2024 à 17:52 (CET)Répondre
LiveRC et le nouveau message d'annulation
Dernier commentaire : il y a 9 mois3 commentaires2 participants à la discussion
EN:
Hello! It's me again, sorry to bother you. About a year ago MediaWiki implemented plural and gender in MediaWiki:Revertpage, but it looks like LiveRC cannot handle the new message. Users on itwiki reported that the message was not correctly expanded (it just showed LiveRC: {{PLURAL:$7|Annullata la modifica|Annullate le modifiche}} di..., example here).
I did a quick check on frwiki recent changes, and it looks like you're not affected, but that is because we updated MediaWiki:Gadget-LiveRCSiteConfig.js, while you didn't yet. As a workaround, we're using the old message on our local LiveRC config, but every time someone updates it, it gets of course overwritten and the issue resurfaces.
Thank you!
FR translation by DeepL:
Bonjour ! C'est encore moi, désolé de vous déranger. Il y a environ un an, MediaWiki a implémenté le pluriel et le genre dans MediaWiki:Revertpage, mais il semble que LiveRC ne puisse pas gérer le nouveau message. Les utilisateurs d'itwiki ont signalé que le message n'était pas correctement développé (il montrait juste LiveRC: {{PLURAL:$7|Annullata la modifica|Annullate le modifiche}} di..., exemple ici).
J'ai fait une vérification rapide sur frwiki modifications récentes, et il semble que vous ne soyez pas concernés, mais c'est parce que nous avons mis à jour MediaWiki:Gadget-LiveRCSiteConfig.js, alors que vous ne l'avez pas encore fait. Comme solution de contournement, nous utilisons l'ancien message sur notre configuration LiveRC locale, mais à chaque fois que quelqu'un le met à jour, il est bien sûr écrasé et le problème refait surface.
I have developed some code that, as a workaround, replaces a given message function with a branch taken from it:
replaceMessageFunction()
mw.loader.using('mediawiki.util',function(){/* * Replace MediaWiki message function with the branch we want from it. * * The branch to take is specified by the JavaScript calling code, not properly by the MediaWiki message function. */functionreplaceMessageFunction(input,functionName,functionArgument,desiredBranch,fallbackBranch,replacements){// PLURAL → [Pp][Ll][Uu][Rr][Aa][Ll]constciFunctionName=Array.from(functionName).map(letter=>'['+letter.toUpperCase()+letter.toLowerCase()+']').join('');// $1 → \$1constescapedArgument=mw.util.escapeRegExp(functionArgument);// - empty branches are valid and have to be captured// - nested functions, magic words, etc. inside branches are not supportedconstregex=newRegExp(String.raw`\{\{\s*${ciFunctionName}:\s*${escapedArgument}\s*((?:\|[^|{}]*)*)\}\}`,'g');returninput.replaceAll(regex,function(match,p1){if(p1===''){// no branches, e.g. {{GENDER:$2}} (useless, but writers are not prevented from doing that)return'';}constbranches={};// 1-indexed object, trimmed valuesp1.substring(1).split('|').forEach((value,index)=>{branches[index+1]=value.trim();});letresult;if(Object.hasOwn(branches,desiredBranch)){result=branches[desiredBranch];}elseif(fallbackBranch&&Object.hasOwn(branches,fallbackBranch)){result=branches[fallbackBranch];}else{return'';}if(replacements){for(const[placeholder,value]ofObject.entries(replacements)){result=result.replaceAll(placeholder,value);}}returnresult;});}// d{{PLURAL:$7|’une|e $7}} → de 42console.log(replaceMessageFunction('d{{PLURAL:$7|’une|e $7}}','PLURAL','$7',2,null,{'$7':42}));// {{GENDER:$2|he|she|they}} → theyconsole.log(replaceMessageFunction('{{GENDER:$2|he|she|they}}','GENDER','$2',3,1));});
The code itself is quite clean, but what it does isn't…
A more appropriate way would be to fetch and process the message using the provided JavaScript function, see Using messages in JavaScript. I can fetch the message, but then, despite my various attempts, when trying to use it I always get « ⧼Revertpage⧽ » as the returned value…
I know the purpose of that code might be a bit difficult to understand… Maybe the following use case could help to clarify:
replaceMessageFunction() use case
// message content:// Révocation {{PLURAL:$7|d’une modification réalisée|de $7 modifications réalisées}} par {{GENDER:$2|}}[[Special:Contributions/$2|$2]] ([[User talk:$2|discussion]]) et restauration de la dernière version réalisée par {{GENDER:$1|}}[[User:$1|$1]]letmessage=lrcGetMediawikiMessage("revertpage");// that "nbRevertedEdits" variable is made up, for demonstration purposeif(nbRevertedEdits===1){message=replaceMessageFunction(message,'PLURAL','$7',1);}else{message=replaceMessageFunction(message,'PLURAL','$7',2,null,{'$7':nbRevertedEdits});}// presumably, we can't know the genders in the code, so using "unspecified" then "male"message=replaceMessageFunction(message,'GENDER','$1',3,1);message=replaceMessageFunction(message,'GENDER','$2',3,1);// the following have to be executed after the replaceMessageFunction() callsmessage=summary.replaceAll('$1',oldUser);message=summary.replaceAll('$2',data.user);
_(fr).png)
_(fr).png)
.png)
![[2]](http://www.partage-facile.com/8EPNYKB9QJ/screenshot_2014_10_12_19_31_48.png.html){kind=link}
