Wiktionnaire:Questions techniques/mars 2013

Dernier commentaire : il y a 10 ans par Gronky dans le sujet Traductions en Lua

Page mensuelle des questions techniques posées en mars 2013. Page précédente : février 2013Page suivante : avril 2013Modifier ce cadre


Lua modifier

Attente de Lua :  

Ce mois-ci, Lua arrive (au cas où vous n'auriez pas vu les nombreux messages que j'ai écrits à ce sujet  ). Je vais essayer de dresser une liste de ce qui pourra être amélioré avec Lua.

  • Les langue ; plus précisément, leur nom et leurs différentes caractéristiques. Actuellement on a un modèle de langue pour chacune, qui porte comme nom le code ISO de la langue ({{fr}} pour le français). En Lua, il sera possible de lister toutes les langues dans un fichier unique (au lieu de milliers éparpillés), et de donner des informations supplémentaires (encodage par exemple), comme ce qu'avait proposé Verdy_p en son temps. Il suffira de récupérer les informations de la langue en invoquant le module comportant la liste pour récupérer facilement toutes les infos.
  • Les modèles complexes, répétitifs, avec beaucoup de paramètres. Ces trois caractéristiques donnent un code illisible et difficile à maintenir convenablement avec un code wiki classique (même pour les contributeurs experts en code wiki). Exemples typiques : {{fr-conj}}, {{fr-accord}}.
  • Les modèles d'accord, de déclinaison et de conjugaison. Lua permettra d'extraire par exemple un radical d'un mot comme animal (radical anim-), ce qui permettra d'enlever un ou plusieurs paramètres. On peut aussi détecter l'élision devant les voyelles (paramètre '), voire le groupe d'un verbe (marcher se finit par -er : verbe du premier groupe). Il ne faudra peut-être pas tout laisser faire au modèle, de crainte de n'avoir qu'une boîte noire qui remplit les modèles sans qu'on sache vraiment à quoi s'attendre.
  • Les modèles de section. Dans mon projet de changement des modèles de section pour les rendre modifiables, il serait raisonnable de remplacer tous les modèles de type {{-nom-}} par un modèle générique qui gérerait tous les types de mots dans un même modèle (avec alias, flexions et tout), de même pour toutes les sous-setions de mot. Ceci est possible et assez simple à faire avec des modules Lua.
  • Les modèles de {{clé de tri}}. Dans une certaine mesure, on pourrait laisser le soin aux clés de tri de calculer d'elles-mêmes la clé de tri d'une entrée (essentiellement pour le français et les langues). Bien sûr si une clé est explicitement donnée, le comportement du modèle sera le même qu'actuellement.

Liste à étoffer. — Dakdada 1 mars 2013 à 19:45 (UTC)Répondre

Je pense à {{fr-accord-rég2}} qui avaient été refusé car trop lourd. JackPotte ($) 2 mars 2013 à 20:01 (UTC)Répondre

Questions sur le contenu de la liste modifier

Que signifie la phrase « de crainte de n'avoir qu'une boîte noire qui remplit les modèles sans qu'on sache vraiment à quoi s'attendre. », je n'ai pas compris que représente la boite noire ? Merci d'avance, Automatik (discussion) 2 mars 2013 à 19:58 (UTC)Répondre

Une boîte noire est une machine dont on ne sait rien de son fonctionnement interne, et donc dont on ne sait pas forcément ce qu'elle va sortir. Si j'ai un modèle {{fr-accord-régulier}} par exemple, et que je ne place dans une page animal, je ne sais pas ce que le modèle va sortir : un pluriel en als, ou un pluriel en -aux ? Si on ne peut pas prédire facilement ce que le modèle va afficher, alors c'est une boite noire. Dans ce genre de cas ambigu, il faut donc utiliser des modèles spécialisés (comme {{fr-accord-al}}) ou bien des paramètres supplémentaires ({{fr-accord-régulier|pluriel=aux}}). — Dakdada 2 mars 2013 à 20:54 (UTC)Répondre
Si j'utilise le modèle {{fr-accord-régulier}} dans la page animal, il est vraisemblable que le pluriel sorti sera animals, non ? Automatik (discussion) 2 mars 2013 à 21:22 (UTC)Répondre
Sachant que le pluriel régulier des mots en -al est -aux, tout dépendra de comment on conçoit le modèle : si on choisit de laisser la possibilité au modèle de deviner quel pluriel devrait être utilisé, alors il pourrait donner animaux. Maintenant si on veut que le modèle se comporte de manière absolument prévisible, alors il faut que les seuls pluriels automatiques soient en -s (ou invariables en -x, -z, -s), et dans les autres cas (-aux, -eux...) il faudra des paramètres explicites. — Dakdada 2 mars 2013 à 22:04 (UTC)Répondre
Ok, je vois. Je ne vois pas le problème de faire calculer par le modèle les pluriels en -al, -eux, etc., ça reste prévisible. Automatik (discussion) 2 mars 2013 à 22:32 (UTC)Répondre
Tant que c’est bien documenté. D’ailleurs, boîte noire n’est pas synonyme d’imprévisible, ça veut juste dire que tu ne sais pas, et n’as pas à savoir, comment c’est fait dedans, mais c’est censé faire exactement ce qui est écrit dans le cahier des charges (la doc).
Et la doc peut dire que dans tel cas le résultat n’est pas garanti (pas spécifié), dans ce cas l’imprévisibilité est parfaitement prévisible. --GaAs 5 mars 2013 à 16:20 (UTC)Répondre
C'est ce que je me suis dit après avoir été lire l'article boîte noire. Ce dont je parle est bien de la prévisibilité des modèles, non une histoire de boîte noire. — Dakdada 5 mars 2013 à 16:35 (UTC)Répondre

w:Projet:Scribunto modifier

À propos, il y a un w:Projet:Scribunto sur Wikipédia pour organiser les modules là-bas. Je prévois de suivre les mêmes règles d'organisation pour faciliter les échanges entre projets. — Dakdada 7 mars 2013 à 09:14 (UTC)Répondre

WT:Scribunto modifier

J'ai créé une page dédiée à Scribunto, surtout pour réunir les liens utiles. — Dakdada 12 mars 2013 à 09:46 (UTC)Répondre

class="plainlinks" modifier

Pourquoi j’y arrive pas sur Wiktionnaire:Page d’accueil/À la une/RelLink ? --GaAs 3 mars 2013 à 20:02 (UTC)Répondre

Les div sont des blocs avec retour à la ligne. Pour rester sur la ligne, il faut utiliser span. — Dakdada 3 mars 2013 à 20:08 (UTC)Répondre
Merci. --GaAs 4 mars 2013 à 20:23 (UTC)Répondre

Syntaxe html dans Modèle:Cadre à onglets modifier

Ce modèle commence par

<div id="mb{{{id|0}}}" class="mb{{{couleur|Violet}}}" ">

Le dernier guillemet avant la fermeture de la balise n’est-il pas une erreur ? Et si oui, comment se fait-il que ça marche quand même ? --GaAs 5 mars 2013 à 15:59 (UTC)Répondre

Réponse : oui, mais les navigateurs sont tolérants. Ça ne m'étonnerais pas qu'ils émettent un « warning » (à voir dans les outils de débogage). — Dakdada 5 mars 2013 à 16:30 (UTC)Répondre
  Corrigé. --GaAs 7 mars 2013 à 19:00 (UTC)Répondre

&action=raw en retard d'une version modifier

J’ai modifié -nom- en -adj- à 12:31 UTC sur contrastif. Mais https://fr.wiktionary.org/w/index.php?title=contrastif&action=raw continue à renvoyer la version précédente, 3 heures et demi et diverses tentatives de purge après. Ce n’est pas la première fois que je constate ça.

Du coup, MediaWiki:Gadget-CreerFlexionFr.js, qui utilise cette méthode, propose une ânerie pour la création des flexions. Une idée ? --GaAs 5 mars 2013 à 16:10 (UTC)Répondre

Correction : https://fr.wiktionary.org/w/index.php?title=contrastif&action=purge vient de fonctionner (mais un null edit précédent n’avait pas fonctionné). Je ne vais quand même pas faire une purge systématique dans le gadget ? --GaAs 5 mars 2013 à 16:12 (UTC)Répondre
Il faudrait voir la doc de raw, s'il y en a une, mais sinon je sèche : il faut voir avec les développeurs de Mediawiki (peut-être sur irc Wikitech). — Dakdada 5 mars 2013 à 16:32 (UTC)Répondre
mw:Manual:Parameters_to_index.php#Raw : tu as une idée de ce que font maxage et smaxage ? J’ai trouvé ça : [1], mais c’est pas lumineux. --GaAs 6 mars 2013 à 12:19 (UTC)Répondre
Tu as fait des essais ? Genre avec les deux =0 ? — Dakdada 6 mars 2013 à 13:14 (UTC)Répondre
Il faudrait que j’arrive à le reproduire. --GaAs 6 mars 2013 à 16:48 (UTC)Répondre
À priori ça fonctionne [2]. Il faudra voir à l’usage. --GaAs 6 mars 2013 à 22:15 (UTC)Répondre
En fait non, ça ne fonctionne toujours pas correctement. --GaAs 7 mars 2013 à 18:50 (UTC)Répondre

Butineurs modifier

Pour info, je devais n’avoir rien à faire, alors j’ai testé le Wiktionnaire avec le web browser de Matlab , et bien le bouton "publier" bogue [3]. --GaAs 6 mars 2013 à 12:25 (UTC)Répondre

Sachant le nombre de personnes ridicule qui doit essayer de modifier un wiki avec ce type de navigateur, je pense que chercher à résoudre ce problème sera une perte de temps plus qu'autre chose (tu peux toujours créer un bug pour Mediawiki, mais ça m'étonnerais que quelqu'un s'y intéresse... sauf peut-être un fou de MatLab). — Dakdada 7 mars 2013 à 08:55 (UTC)Répondre
Bien sûr que c’était une blague.  D’ailleurs il est probable que que le pb vient de Mathworks. Quand je m’ennuierai vraiment profondément, j’irai peut-être leur en toucher un mot. Ne cherchez pas, je n’y suis pas connu sous le nom de GaAs, ni de Yair Altman — les bidouilleurs ici devraient néanmoins lire ce gars, on y apprend plein de choses. --GaAs 7 mars 2013 à 18:48 (UTC)Répondre

Mais au fait, comment fonctionne Modèle:Cadre à onglets ? modifier

Je suis en train de créer des onglets pour MediaWiki:Gadget-CreerNouveauMot.js actuellement sur Utilisateur:ArséniureDeGallium/Gadget-CreerNouveauMot.js, je ne modifie pas en direct le gadget, bien sur que non !. Mais je ne comprends pas comment marche le changement d’aspect des boutons des onglets, pourriez-vous m’expliquer ? --GaAs 7 mars 2013 à 19:08 (UTC)Répondre

Ce qui n'est pas dit dans le modèle c'est que les onglets sont changés avec du javascript, cf Mediawiki:Common.js. — Dakdada 7 mars 2013 à 19:28 (UTC)Répondre
En effet, et le CSS aussi. JackPotte ($) 7 mars 2013 à 19:38 (UTC)Répondre
Bien évidemment, le pb est que le fonctionnement n’est absolument pas documenté. Et JackPotte est le coupable n°1. JackPotte , quand est-ce que tu rédiges la doc, au lieu de donner des liens inutiles ? --GaAs 7 mars 2013 à 19:44 (UTC)Répondre
Je finis un petit truc et j’arrive. JackPotte ($) 7 mars 2013 à 20:13 (UTC)Répondre
Je sais qu’on peut compter sur toi, mais tu es encore plus réfractaire que moi pour la rédaction des docs, et donc je t’en veux encore plus qu’à moi-même. --GaAs 7 mars 2013 à 20:18 (UTC)Répondre

IRC modifier

Bonjour,

Quelqu’un s’y connaîtrait-il en IRC ? J’ai essayé Chatzilla, Pidgin, les aides, les commandes sur le chat, je continue toutefois d’avoir du fil à retordre avec ce logiciel. J’essaie juste de me connecter légalement (avec un pseudo fixe, et un mot de passe). Sachant qu’Automatik est un pseudo déjà utilisé (sûrement par moi, mais je ne sais pas me connecter avec). Merci d’avance. Automatik (discussion) 7 mars 2013 à 20:39 (UTC)Répondre

Aide:IRC/commandes sur l’encyclopédie Wikipédia  . JackPotte ($) 7 mars 2013 à 21:14 (UTC)Répondre
Tu as deux parties : 1) l'enregistrement de ton pseudo auprès de Freenode 2) ton identification à chaque fois que tu rejoins freenode (quelque soit ton client IRC).
Pour le 1) connecte-toi avec le pseudo que tu souhaites enregistrer (ou change ton pseudo avec /nick nouveau_pseudo) et lance la commande :
/msg NickServ REGISTER ''password'' ''youremail{{@}}example.com''
en remplaçant password et youremail example.com par un bon mot de passe (un truc un tant soit peu complexe >10 caractères, note le bien) et une adresse mail valide à laquelle tu peux répondre (ils t'envoient un mail de confirmation). Ceci fait, chaque fois que tu te connecteras à un canaux, quel que soit ton client IRC, 2) il te faudra taper :
/msg NickServ IDENTIFY ''password''
pour être identifié (en remplaçant ton mot de passe). Selon les clients, tu peux te connecter automatiquement sans avoir à écrire ça à la main, mais c'est plus compliqué à décrire de manière générale. — Dakdada 7 mars 2013 à 21:22 (UTC)Répondre
Le résultat obtenu en tapant /nick Automatik est :
===	The nickname “Automatik” is already in use, use the /nick command to pick a new one.
Automatik (discussion) 7 mars 2013 à 21:40 (UTC)Répondre
Comme indiqué, ça veut dire que le pseudo est déjà pris sur Freenode : tu dois t'en choisir un autre. — Dakdada 7 mars 2013 à 22:37 (UTC)Répondre
OK. Pas moyen de récupérer le mot de passe vu que je suis sûr de l’avoir utilisé un jour ce pseudo ? Automatik (discussion) 7 mars 2013 à 22:50 (UTC)Répondre
Par des raisons miraculeuses et mystérieuses, j’ai retrouvé mon pseudo original après avoir tapé la commande malgré le message d’erreur ci-dessus. Tout devrait aller maintenant j’espère. Automatik (discussion) 8 mars 2013 à 04:53 (UTC)Répondre

  Résolu. Tout marche, même le cloak   Merci pour votre aide qui m'a été précieuse. Automatik (discussion) 12 mars 2013 à 14:14 (UTC)Répondre

Substitution récursive modifier

Salut. Dans l’espoir (est-il vain ?) de pouvoir substituer le modèle {{composé de}} pour en retirer un code simple dans l’interface de modification, j’ai commencé à tester le modèle dans une sous-page, en utilisant un modèle pour générer l’espace normal à la place de &#32. J’espère ainsi parvenir à effectuer une substitution récursive qui remplace et le modèle composé de, et le modèle utilisé par composé de pour générer l’espace avant le « et ».

Là où je ne comprends plus, c’est pourquoi la substitution récursive ne marche pas. En effet, le code affiché est le suivant et le rendu est celui-ci : il y a bien un espace avant le « et », grâce à ce modèle de test. J’ai pourtant utilisé {{{|safesubst:}}} avant Utilisateur:Automatik/test3 dans le modèle de test de composé de.

Des idées pour que la substitution récursive marche ? Merci d’avance. Automatik (discussion) 8 mars 2013 à 05:24 (UTC)Répondre

Tu devrais plutôt utiliser AWB pour gagner du temps. JackPotte ($) 8 mars 2013 à 12:30 (UTC)Répondre
J’utilise AWB, mais substituer avec AWB revient à marquer subst:, et en marquant seulement subst:, la substitution ne marche que pour composé de, et pas pour les modèles qu’il inclue — d’où l’intérêt de chercher à ce que le modèle impose lui-même la substitution récursive lorsqu’il est lui-même substitué. Automatik (discussion) 8 mars 2013 à 14:49 (UTC)Répondre
Je ne pensais pas à la substitution AWB mais à son regex. Si tu veux que je le fasse ce soir je te donnerai la solution. JackPotte ($) 8 mars 2013 à 14:53 (UTC)Répondre
Avec plaisir  , ce n’est pas urgent bien évidemment. Automatik (discussion) 8 mars 2013 à 15:27 (UTC)Répondre
En y réfléchissant une deuxième fois je suis toujours contre sa suppression car il permettait d’identifier à coup sûr les formants (le contraire de {{-drv-}}), ce que ne permet pas {{cf}}. Comme je manque de temps et que ce n’est pas moi qui l’ai tagué obsolète, je vais laisser les autres assumer leurs choix eux-mêmes.
Pour le regex, tout est là : Catégorie:Expression rationnelle dans la bibliothèque Wikilivres  . JackPotte ($) 8 mars 2013 à 19:55 (UTC)Répondre
C’est quel langage de programmation qui est accepté pour les regex avec AWB ?
Dans quels cas récupérer de manière automatique les formants d’un mot peut être utile ? Automatik (discussion) 9 mars 2013 à 19:26 (UTC)Répondre
PS: La section "étymologie" de paraboloïde utilise explicitement le mot formant sans utiliser le modèle "composé de" (et il semble que ce ne soit même pas possible de donner toute léinformation rpésente avec le modèle composé de.
En C++ mais la plupart des symboles sont universels. Pour l’intérêt il s’agit de synchroniser les {{-étym-}} avec les {{-drv-}} de leurs étymons, et aussi pour cartographier tout ceci. JackPotte ($) 9 mars 2013 à 22:06 (UTC)Répondre
Merci. Je m’abstiendrai de faire ces modifs si {{composé de}} peut être utilisé à des fins heureuses. Automatik (discussion) 9 mars 2013 à 22:57 (UTC)Répondre
C'est comme {{étyl}} en fait : mieux vaut un modèle dédié qui catégorie plutôt qu'un modèle fourre-tout qui rend le code dur à lire. — Dakdada 11 mars 2013 à 19:27 (UTC)Répondre

Modèles polyvalents modifier

J'aime la simplicité de fabrication des modèles par Wikidata : d:Template:Smiley  . (Je me demande même si c'est techniquement pas mieux de faire ainsi.) Automatik (discussion) 10 mars 2013 à 23:13 (UTC)Répondre

Minimiser le temps de chargement du javascript (pour CreerNouveauMot, mais ça peut servir ailleurs) modifier

Le gadget CreerNouveauMot comporte du code qui n’est pas utilisé pour la langue choisie. Et la taille de ce code inutilisé est proportionnelle au nombre de langues gérées par le gadget, donc potentiellement considérable (~6ko par langue, pour l’instant).

C’est pourquoi j’ai mis ces parties de code, spécifiques à la langue, dans des sous-modules, comme MediaWiki:Gadget-CreerNouveauMot.js/oc.js. Mon idée initiale était de ne charger les sous-modules que quand l’utilisateur changeait de langue. Mais j’ai compris que importScript() était un processus asynchrone, et que donc si on fait

importScript("MediaWiki:Gadget-CreerNouveauMot.js/oc.js")
titi = CrNoMo_DialogHtml_oc();

on a toutes les chances que ça échoue car CrNoMo_DialogHtml_oc() n’existe pas vu que importScript() n’est probablement pas fini. On peut toujours mettre un setTimeout(), mais la tempo sera tjs trop courte pour certains et trop longue pour les autres…

J’ai donc laissé tomber pour l’instant, et chargé systématiquement tous les sous-modules (la liste de langue étant encore assez courte, mais ça n’a pas vocation à durer). Auriez-vous des solutions ?

Dans cette veine, je suis en train de lire avec intérêt https://developers.google.com/speed/docs/best-practices/caching et ses pages liées (il y en a un paquet, je n’ai pas fini). Ces pages sont intéressantes car Google évite d’y parler seulement de Chrome. Mais je n’y ai pas trouvé de réponse claire.

--GaAs 11 mars 2013 à 19:01 (UTC)Répondre

Faire des gadgets spécifiques à chaque langue, complémentaire du gadget principal ? On ne cocherait que ceux qu'on pense utiliser. — Dakdada 11 mars 2013 à 19:25 (UTC)Répondre
Je suis contre : la liste des gadgets est déjà tellement longue qu’un utilisateur normal s’enfuit en la voyant. --GaAs 11 mars 2013 à 20:02 (UTC)Répondre
C'est juste une question de mise en page et d'organisation. — Dakdada 11 mars 2013 à 20:07 (UTC)Répondre
Mise en page impossible, j’ai déjà tenté le coup. --GaAs 11 mars 2013 à 20:10 (UTC)Répondre
Dans ce cas c'est un bug. — Dakdada 11 mars 2013 à 20:12 (UTC)Répondre
Extension:Gadgets ne le permet pas. Si c’est un bug, c’est un bug de l’extension. --GaAs 11 mars 2013 à 20:16 (UTC)Répondre

J’ai posé la question sur w:Discussion_Projet:JavaScript#Minimiser le temps de chargement du javascript, quand il comporte une grande partie de code inutile à un moment donné, mais je n’espère pas de miracle. --GaAs 11 mars 2013 à 20:00 (UTC)Répondre

Magic word ou autre permettant de lâcher son nom d'utilisateur (ou sa pdd) modifier

Bonjour.

Existe-t-il un mot magique ou une autre méthode permettant d'écrire son pseudo ? Exemple : il existe un mot magique pour lâcher la date. Je cherche pareil pour la PU et la PDD.

J'arrive à signer automatiquement (avec ~~<noinclude></noinclude>~~), mais pour ce qui est uniquement du nom d'utilisateur ou de la pdd de l'utilisateur, je suis perdu. Est-ce possible ? Automatik (discussion) 12 mars 2013 à 17:42 (UTC)Répondre

Avec 3 ~ on écrit seulement le pseudo sans la date. — Dakdada 12 mars 2013 à 19:09 (UTC)Répondre
Pseudo + pdd, mais je cherche l'un ou l'autre seul. Automatik (discussion) 12 mars 2013 à 19:34 (UTC)Répondre
Ce n'est pas possible. Sauf à ne choisir que l'un des deux et à l'écrire en signature brute (cf ma signature par exemple). — Dakdada 12 mars 2013 à 22:07 (UTC)Répondre
Ok, merci. Automatik (discussion) 12 mars 2013 à 22:10 (UTC)Répondre

J’ai trouvé que {{subst:REVISIONUSER}} permettait de le faire. Automatik (discussion) 11 juin 2013 à 13:10 (UTC)Répondre

De la vitesse des bots modifier

Salut. Avec l'arrivée très récente de Wikidata, certains bots qui interagissent avec Wikidata (indirectement ou directement) se montrent extrêmement rapides - ils envoient par moments jusqu'à 100 requêtes par minute au serveur [4] (pour compter automatiquement le nombre de contributions par minute il suffit de copier les lignes correspondant à la minute de votre choix dans un de ces cadres : [5] - voir à 2h53 par exemple). Alors mes questions sont :

  1. Les serveurs peuvent-ils supporter ça ?
  2. Et avec plusieurs bots qui font la même chose, ils l'accepteraient aussi ?
  3. À partir de quand un serveur « sature » ?
  4. Pourquoi sur le Wiktionnaire on conseille aux dresseurs réguliers de ne pas mettre d'intervalle trop petit entre deux modifications (j'ai déjà dû lire 5 voire 10 secondes) ?
  5. Ne pourrait-on pas accepter qu'eux aussi [les dresseurs du Wiktionnaire] aillent plus rapidement ?

Merci d'avance pour vos réponses ; Automatik (discussion) 14 mars 2013 à 02:13 (UTC)Répondre

La vraie limite est le retard du serveur (lag) que tout bot devrait prendre en compte de manière automatique. Voir mw:Manual:Maxlag parameter. Par exemple, avec pywikipediabot, quelle que soit la limite fixée (throttle), le bot sera suspendu dès qu'il détectera un retard.
Les bots pour Wikidata sont spécialement conçus pour importer des données et sont très surveillés.
Pour nous, à moins que la vitesse ne soit une priorité (par exemple si un bot doit passer sur tous les articles), mieux vaut ne pas aller trop vite. Ça permet notamment de détecter et corriger les éventuelles erreurs. — Dakdada 14 mars 2013 à 09:30 (UTC)Répondre
Merci. Automatik (discussion) 17 mars 2013 à 17:54 (UTC)Répondre

Nouveaux modèles de section modifier

Maintenant que Lua est là je me lance dans la création des nouveaux modèles de section notamment nécessaires pour rendre les sections modifiables.

Je crois avoir fait le tour des modèles dont on aura besoin, je les ai créés et réunis dans Catégorie:Modèles de titres de sections de prochaine génération. Cela représente une dizaine de modèles de base, à comparer aux ~150 modèles actuels.

La réduction du nombre est due à la réunion des modèles de type de mot (comme {{-nom-}}) dans {{entrée}}, et des modèles de sous-section de type de mot (comme {{-syn-}}) dans {{section}}.

  • {{entrée}} est déjà partiellement écrit en Lua. Ce qui manque encore est la liste des langues dans une page unique (au lieu des milliers de modèles actuels disséminés), ainsi que la liste des types de mot autorisés.
  • {{section}} se contente pour l'instant d'afficher bêtement le titre fourni, mais je vais également le convertir en Lua pour qu'il n'affiche que des titres agréés. Je pense qu'on pourrait ajouter Homophones et paronymes dans ce cas, plutôt que de leur faire un modèle dédié.

Au final on aura donc moins d'une dizaine de modèles de section, avec une poignée de modules associés. Bien plus facile à gérer que des milliers de modèles disséminés.

Pour un aperçu (ce n'est pas encore parfait), voyez Utilisateur:Darkdadaah/Test:Sections. — Dakdada 14 mars 2013 à 10:22 (UTC)Répondre

Sans vouloir critiquer, je constate que ==== {{section|traductions}} ==== est tout de même trois fois plus long que le {{-trad-}} que tout le monde connait (33 vs 10). JackPotte ($) 14 mars 2013 à 19:47 (UTC)Répondre
Correction : que seuls les contributeurs réguliers connaissent  . Personne n'aura à le taper ou à le connaître par cœur quand on utilisera les gadgets d'aide à la rédaction, pas plus j'espère que les autres sections (et puis, il y aura vraisemblablement des alias, genre {{section|trad}}). Par contre les signes = de part et d'autre sont inévitables, mais les gens qui viennent des autres wikis comprendront. Cela étant, toute suggestion est bienvenue. — Dakdada 14 mars 2013 à 20:03 (UTC)Répondre
Désolé de ne pas avoir tout compris, mais pourquoi exactement utiliser section|traductions plutôt que traduction ? Je sais, ça limite le nombre de modèles, mais il y a bien autre chose ? Automatik (discussion) 16 mars 2013 à 23:18 (UTC)Répondre
C'est aussi par homogénéité, pour que toutes les sous-sections de mot soient écrites avec le modèle {{section}} (sauf si on écrit toutes les sous-sections avec leur modèle propre, bien sûr).
C'est aussi une histoire d'accessibilité : en utilisant un modèle général, on peut vérifier le nom de la section et permettre des alias, ou afficher un message d'erreur.
Imaginons un contributeur qui veut rajouter une section (en supposant qu'il n'utilise pas les barres d'outils qui l'y auraient aidé) : avec le modèle {{section}} il pourra écrire {{section|Antonyme}} et avoir une section correcte, alors que si on avait un modèle, il lui faudrait chercher le bon nom du modèle, qui pourrait aussi bien être {{antonymes}}, {{Antonymes}}, {{antonyme}}, {{Antonyme}}. Et si le nom qu'il donne n'est pas reconnu même avec un alias, le modèle {{section}} pourra lui proposer un lien vers la liste des sections autorisées (et catégoriser la page pour que l'on sache qu'elle contient une section au nom inconnu).
C'est en tout cas ce que je prévois, mais je suis ouvert à d'autres solutions, notamment aux solutions qui simplifient le plus la tâche des contributeurs (puisque la complexité des modèles n'est plus vraiment un problème). — Dakdada 17 mars 2013 à 00:03 (UTC)Répondre
Pour quelle raison, à la base, le Wiktionnaire français s’est dirigé vers un format entièrement commandé par des modèles, alors que le Wiktionnaire anglais a gardé le format de Wikipédia, qui consiste à écrire en clair le titre des sections (=== Étymologie ===) ? Je serais curieux de savoir. Merci à celui qui pourra m’éclairer. Automatik (discussion) 17 mars 2013 à 17:40 (UTC)Répondre
Les modèles de section ont été utilisés au tout début du Wiktionnaire, dans le but d'avoir une structure homogène. Malheureusement, le fait d'intégrer les sections directement dans les modèle fut une mauvaise idée, que je voudrais réparer. Les modèles de section ont pourtant des avantages certains par rapport à l'écriture sans modèle à l'anglaise : standardisation des noms, liens ancrés, catégorisation, extraction aisée des données... — Dakdada 18 mars 2013 à 16:06 (UTC)Répondre

Ces titres devraient pouvoir remplir Catégorie:Lettres rares en français, et aussi les clés de tri spécifiques à chaque langue. JackPotte ($) 17 mars 2013 à 14:42 (UTC)Répondre

Pour les lettres rares, c'est plutôt le modèle {{langue}} qu'il faudrait utiliser (puisque les sections de type de mot ne feraient que se répéter). Pour les clés de tri c'est à voir. Il faudrait commencer par réécrire {{clé de tri}} (avec un Module:clé de tri), et voir ensuite pour quelles langues il faut des clés spéciales auquel cas c'est plutôt le modèle de section de langue, encore une fois, qu'il faudrait utiliser. Bref, je pense qu'on peut travailler sur les sections de types de mots sans se soucier de ces deux points (ne serait-ce que pour éviter de s'éparpiller). — Dakdada 17 mars 2013 à 14:50 (UTC)Répondre
  J’ai créé le module, qui fonctionne au moins pour les langues suivantes : français, anglais, allemand, espagnol, portugais, italien, et espéranto (il y a l’arabe, le grec et le russe mais je n’ai pas encore testé). Une fois en exploitation je pourrai me pencher sur l’hindi. JackPotte ($) 17 mars 2013 à 19:05 (UTC)Répondre

XHTML modifier

Salut.

D'aucuns utilisent <br /> alors que <br/> semble marcher tout aussi bien. Quelqu'un connaît-il la raison ?

Merci d'avance. Automatik (discussion) 14 mars 2013 à 19:40 (UTC)Répondre

Le slash est facultatif, il permet d’insister sur le fait que la balise n’est ni ouvrante ni fermante. Quant-à l’espace, c’est une question d’esthétique : rien dans la DTD ne la normalise. JackPotte ($) 14 mars 2013 à 19:51 (UTC)Répondre
Le slash est obligatoire si on parle en XHTML (X = XML) il me semble. — Dakdada 14 mars 2013 à 20:07 (UTC)Répondre
Justement non, sinon il perd sa compatibilité ascendante avec l’HTML. JackPotte ($) 14 mars 2013 à 20:16 (UTC)Répondre
Et dans le wikicode, c’est de toute façon traité par le parseur de Mediawiki, qui les remplace toutes par <br />. --GaAs 15 mars 2013 à 13:27 (UTC)Répondre
On n'a donc pas à se préoccuper de compatibilités, et comme Mediawiki les remplace par <br />, autant les écrire directement comme ça. — Dakdada 15 mars 2013 à 14:13 (UTC)Répondre
Je crois que ce que voulait dire JackPotte, c’est que lorsqu’on écrit en XHTML, on peut aussi bien utiliser le <br> que le <br />, et qu’on n’est pas obligé d’utiliser le slash pour rester en XHTML. Si je puis me permettre d’illustrer, c’est un peu comme si je mettais un jeu de PS2 dans ma PS3 : il va marcher, et pourtant j’utilise bien la PS3 (et pas la PS2). Automatik (discussion) 16 mars 2013 à 23:10 (UTC)Répondre
Cela dit, merci pour vos réponses. Automatik (discussion) 16 mars 2013 à 23:11 (UTC)Répondre
Pour la petite histoire, la norme xhtml dit clairement que le slash n’est pas facultatif mais bien obligatoire. La plupart des navigateurs l’interpréterons tout de même correctement, mais ton document ne sera pas un fichier xml valide. --Psychoslave (discussion) 3 avril 2013 à 07:39 (UTC)Répondre

Module lua de fonctions pour chaines de caractères modifier

J’aurais besoin d’une fonction pour découper une chaine en une liste de sous-chaines, à chaque occurrence de qqch (équivalent de split() en JS). Mais d’une manière générale, je pense qu’il faudrait créer un Module:chaines ou rassembler ce genre de fonctions, car je pense qu’on en aura pas mal à créer. --GaAs 15 mars 2013 à 13:55 (UTC)Répondre

Cadeau : mw:Extension:Scribunto/Lua_reference_manual#mw.text.split. — Dakdada 15 mars 2013 à 14:16 (UTC)Répondre
Il y a déjà tellement de fonctions de manipulation de chaînes qu'on ne devrait pas avoir à faire grand chose. — Dakdada 15 mars 2013 à 14:16 (UTC)Répondre
Cool, j’avais pas pensé à regarder là. --GaAs 15 mars 2013 à 14:19 (UTC) PS : pour ta dernière remarque, je te fais remarquer que tu en as déjà créé une (ucfirst). --GaAs 15 mars 2013 à 14:20 (UTC)Répondre
Oui, s'il y en a peu on peut les laisser dans Module:bases. — Dakdada 15 mars 2013 à 14:22 (UTC)Répondre
Et une fonction qui met tous les chiffres romains en petites majuscules dans une chaine, tu la mets où ? Je pense que je saurais faire le code, mais je ne sais pas comment organiser ça. --GaAs 17 mars 2013 à 17:44 (UTC)Répondre
Commence par faire un module séparé Module:chiffres romains. Si on trouve d'autres fonctions simples du même genre, on pourra les réunir dans un module plus tard. — Dakdada 17 mars 2013 à 17:50 (UTC)Répondre

Gadget SpecialChars incompatible avec l'aperçu rapide ? modifier

Salut. Après de nombreux tests, j'aimerais vous demander si vous pouvez confirmer ou infirmer l'hypothèse soulevée par ce titre. L'aperçu rapide qui nécessite JS étant dans Spécial:Préférences#mw-prefsection-editing (l'avant-dernier des options avancées). Merci d'avance. Automatik (discussion) 15 mars 2013 à 17:38 (UTC)Répondre

Très possible. --GaAs 17 mars 2013 à 17:31 (UTC)Répondre
Chez moi c’est le cas en tout cas, mais seul c’est dur d’être sûr. Enfin je suppose que oui, sauf avis contraire. Automatik (discussion) 17 mars 2013 à 17:34 (UTC)Répondre

Modèle:voir en Lua modifier

Salut, voici un premier modèle Lua en conditions réelles (lourd en fonctions parseur, mais simple à faire).

Je voudrais des testeurs pour comparer le modèle {{voir}} (actuel, code wiki) et le modèle {{voir2}} (Réécrit en Lua). En termes de performances, le second est bien meilleur (pas étonnant quand on sait que {{voir}} est un des modèles les plus lourds en fonction parseur) :

Version wiki Version Lua
NewPP limit report
Preprocessor visited node count: 737/1000000
Preprocessor generated node count: 5778/1500000
Post-expand include size: 1139/2048000 bytes
Template argument size: 59/2048000 bytes
Highest expansion depth: 6/40
Expensive parser function count: 0/500
NewPP limit report
Preprocessor visited node count: 12/1000000
Preprocessor generated node count: 85/1500000
Post-expand include size: 390/2048000 bytes
Template argument size: 0/2048000 bytes
Highest expansion depth: 2/40
Expensive parser function count: 0/500
Lua time usage: 0.004s
Lua memory usage: 365 KB

En outre, le modèle n'est plus limité à 100 paramètres (j'ai déplacé la limite à 200, mais je doute qu'on y arrive un jour). J'en ai profité pour déplacer le style du bandeau dans Mediawiki:Common.css (pour les deux modèles).

Du point de vue des tests : il faut que le modèle se comporte correctement dans tous les cas normaux d'utilisation, et il ne doit jamais renvoyer d'erreur (gros message en rouge), quels que soient les paramètres que l'on rentre (testez !). Vous pouvez voir comment le modèle se comporte dans la page de test Discussion module:voir. — Dakdada 16 mars 2013 à 19:16 (UTC)Répondre

Les tests que j’ai faits se sont montrés concluants. --Automatik (discussion) 16 mars 2013 à 21:21 (UTC)Répondre
J’ai surtout une question : qd c’est validé, on remplace le code du modèle actuellement utilisé par le #invoke, et ça marche ? --GaAs 17 mars 2013 à 17:34 (UTC)Répondre
Oui, celui qu'on trouve dans {{voir2}}. — Dakdada 17 mars 2013 à 17:38 (UTC)Répondre


Le modèle {{voir}} utilise désormais la version Scribunto. — Dakdada 24 mars 2013 à 14:05 (UTC)Répondre

Traductions en Lua modifier

Je suis en train de réfléchir à une manière différente de gérer nos traductions. L'idée serait d'avoir un modèle unique, auquel on donnerait les traductions selon les langues.

Code actuel Modèle Lua
{{trad-début|Liquide}}
* {{T|kpo}} : {{trad|kpo|ɪvɪ}}
* {{T|avt}} : {{trad|avt|tipar}}
* {{T|anw}} : {{trad|anw|ḿ-múɔ́ŋ}}
* {{T|ard}} : {{trad|ard|kutha}}
* {{T|wyr}} : {{trad|wyr|ɨgɨ}}
* {{T|aqz}} : {{trad|aqz|oˈko}}, {{trad|aqz|oˈku}}
* {{T|de}} : {{trad+|de|Wasser}} {{n}}
* {{T|onw}} : {{trad--|onw|ⲁⲥⲥⲉ|R=asse}}
{{trad-fin}}
{{table de traductions|Liquide|
| anw = ḿ-múɔ́ŋ
| aqz = oˈko, oˈku
| ard = kutha
| avt = tipar
| de  = Wasser
| kpo = ɪvɪ
| onw = ⲁⲥⲥⲉ (asse)
| wyr = ɨgɨ
}}

Notez plusieurs choses :

  • Le modèle Lua sera unique, sans modèles obscurs (T, trad-- ?), plus concis, plus simple à écrire et à lire.
  • Le modèle inclura les modèles trad-début trad-fin.
  • Le modèle trierait les lignes d'après le nom de la langue, sans prendre en compte l'ordre des arguments. Du coup autant ajouter les lignes en respectant l'ordre alphabétique des codes.
  • On pourrait ranger automatiquement les langues selon d'autres critères que alphabétique, comme le script utilisé, ou les familles de langue.
  • On pourrait même présenter les langues en table plutôt qu'en liste, si on voulait.
  • Cette approche devrait être bien plus performante et moins coûteuse qu'actuellement.
  • Ça pourrait faciliter l'affichage sélectif des langues selon les utilisateurs.
  • Le modèle pourrait faire d'autres choses automatiquement, comme :
    • les translittérations (besoin d'un module de translittération)
    • les correspondances vers les articles qui existent peut-être dans les autres Wiktionnaires à l'aide de Wikidata (pas pour tout de suite), ou à tout le moins avec la liste des Wiktionnaire existants.
    • Mais à défaut, et en attendant, il suffira de donner des paramètres comme lang_tr= lang_R=, lang_genre=, lang_existe=non, lang_note=commentaire
  • Limites
    • Pour modifier une entrée, on ne pourra pas se fier à l'ordre si on ne connaît pas son code. Un assistant sera probablement nécessaire (ce qui pourrait être faciliter si on arrive un jour à avoir l'assistant de en:). Cela dit, je ne suis pas sûr qu'actuellement ce soit beaucoup plus facile.

Je n'ai encore rien programmé, mais je pense que je pourrais faire un essai (ça n'est pas difficile à programmer), ne serait-ce que pour tester l'idée avec la page monstre Utilisateur:Pamputt/eau. — Dakdada 18 mars 2013 à 12:28 (UTC)Répondre

Pour moi le genre grammatical du mot traduit (que tu montres pour l’allemand) n’a rien à faire dans la table de traductions (parfois homme/femme ou mâle/femelle peuvent néanmoins être pertinents). --GaAs 18 mars 2013 à 16:23 (UTC)Répondre
+1 Unsui Discuter 18 mars 2013 à 16:45 (UTC)Répondre
Je suis d’accord, si on crée un lien vers l’article, il est alors redondant d’apporter l’information dans la boîte de traductions même — alors qu’elle est déjà lourde. Automatik (discussion) 18 mars 2013 à 17:05 (UTC)Répondre
Je l'ai mis parce que c'est un paramètre (caché ?) de {{trad}}. Mais je suis plutôt d'accord.
En complément : on pourra aussi permettre une certaine souplesse dans la rédaction, comme par exemple écrire |en=small [[bird]] (pour oisillon). — Dakdada 18 mars 2013 à 17:07 (UTC)Répondre

Notons tout de même que certaines personnes peuvent trouver le genre du mot utile (exemple : [6]). Il faudrait se concerter davantage pour prendre une décision là-dessus. Automatik (discussion) 1 juin 2013 à 22:37 (UTC)Répondre

Oui! Je trouve les genres dans la table de traductions très utiles, pour plusieurs raisons:
  • D'abord, c'est souvent exactement ce que je cherche lorsque je viens ici, parce que j'essaie d'utiliser le mot dans une phrase. Si je devais cliquer et lire une autre page, ça serait beaucoup moins pratique (et pour quoi faire? Pour alléger la table de traduction par quelques lettres? Par contre, je trouverais acceptable si au lieu d'écrire «masculin», on écrivait simplement m - au moins pour les langues qui n'ont que les trois genres m/f/n)
  • Deuxièmement, certains mots ont des sens différents selon le genre. Si j'essaie de lire dans une langue que je ne maîtrise pas, alors je risque de m'y perdre si je dois cliquer et lire la page dans cette langue pour distinguer entre les deux sens possibles.
  • Dernièrement, c'est simplement efficace. Avec une seule lettre (ou un mot maximum), on peut donner une pièce d'information très utile. On a rarement la possibilité augmenter l'utilé pour un coût aussi modique.
.Gronky (discussion) 5 octobre 2013 à 13:13 (UTC)Répondre

Questions diverses modifier

Je suis très ravi de voir qu’on peut envisager une telle diminution de modèles ; j’aurais quelques questions par rapport aux retombées de l’utilisation de ce modèle :

  1.   Ce modèle facilitera-t-il le déboguage de MediaWiki:Gadget-editor.js ou au contraire, comme on s’éloigne de la manière de faire des Anglophones, il compliquera la confection du gadget ?
  2.   Le tri automatique des langues lors de l’affichage du modèle ne ralentira-t-il pas trop le chargement de la page ?
    • S'il n'y a que quelques milliers de langues, non...
      • Je n’ai pas les compétences nécessaires pour détecter le fond de cette réponse  
        • Je veux dire que Lua gère très bien les grandes tables de données. Comme ces tables ne seront pas calculées beaucoup par page, ce sera plus rapide d'utiliser ce modèle que des modèles séparés.
  3.   Pourquoi les paramètres se nomment-t-il langue_R, langue_tr, etc. au lieu de R, tr… ?
    • Parce que ce sont des paramètres relatifs à une traduction dans une langue donnée : de=Wasser -> de_genre=neutre.
      • J’ai changé ma question entre-temps, mais tu avais cliqué sur modifier avant. Du coup, pourquoi langue_R plutôt que R ?
        Parce que la romanisation R= et la translittération tr= sont associées à une traduction dans une langue donnée (et qu'il ne peut y avoir qu'un seul paramètre R pour tout le modèle).
        Merci. Automatik (discussion) 18 mars 2013 à 22:35 (UTC)Répondre
  4.   Question + générale : Les tirets (dans de_genre par exemple) permettent-ils à la page d’être chargée + vite (même de façon minime) ? Je ne comprends pas pourquoi certaines fois on a des tirets, d’autres non.
    • Non ce sont de simples séparateurs pour distinguer les paramètres.
      • L’espace ne les distingue-t-elle pas aussi bien ? D’autant plus que dans de_genre il n’y a qu’un paramètre, pas deux, donc je ne comprends pas vraiment.
        • Pour reprendre l'exemple : de est un paramètre qui indique la langue de la traduction. de_genre est un paramètre qui indique le genre de la traduction donné avec de.
          • Je ne sais pas si on parle de la même chose. Toi tu parles des séparateurs pour distinguer les paramètres, donc de la pipe si je ne m’abuse, or moi je parle du tiret du 8 sur le clavier (en général), qui sépare les mots de et genre ; question tatillonne sûrement (?)
  5.   « les correspondances vers les articles qui existent peut-être dans les autres Wiktionnaires à l'aide de Wikidata (pas pour tout de suite), ou à tout le moins avec la liste des Wiktionnaire existants. » Wikidata liste de toute façon la liste des Wiktionnaires existants, donc quelle est la différence ? Désolé de ne pas avoir saisi.
    • Il y a une différence entre avoir une liste des Wiktionnaire (= on sait que l'article peut exister dans ces autres Wiktionnaires), et une liste des articles existant (= on sait que l'article existe dans ces autres Wiktionnaires).
      • Il n’y a donc pas moyen de faire des liens automatiques comme actuellement sans Wikidata ?
        • Actuellement ce n'est pas automatique : ça dépend du modèle qu'on utilise ({{trad+}}, {{trad-}}, {{trad--}}). Le fait d'avoir une liste des Wiktionnaires nous permettra de nous débarasser de {{trad--}}. Par contre, tant qu'on ne sait pas si l'article existe dans l'autre Wiktionnaire, il faudra le préciser nous-même (dans le cas du modèle suggéré, il faudra un paramètre supplémentaire probablement).

J’en aurai peut-être d’autres encore   Automatik (discussion) 18 mars 2013 à 14:12 (UTC)Répondre

Démonstration modifier

J'ai ajouté une petite fonction à Module:traduction et j'ai recopié les données de Utilisateur:Pamputt/eau dans Utilisateur:Darkdadaah/eau (en simplifiant et adaptant les données). Le résultat est sans appel : moins d'une seconde pour créer toute la page avec le modèle unique en Lua. Pour comparaison, le remplacement des modèles T et trad par T2 et trad2 (en Lua) prend près de 7 secondes, ce qui n'est pas si mal comparé à la page actuelle en code wiki qui prend beaucoup plus (et n'est pas chargée en totalité). — Dakdada 18 mars 2013 à 20:18 (UTC)Répondre

Module(s ?) pour manipuler les chaînes de caractères modifier

Bonjour.

Après avoir jeté un coup d’œil sur le Module:String de la Wikipédia anglaise, je me demande ce qu’il vaut mieux faire : un module rassemblant les différentes fonctions de chaîne de caractères, ou plusieurs modules gérant chacun une fonction ? Si on fait come en.wp, pourquoi ferait-on différents modules pour les clés de tri (à quoi est due cette différence de traitement ?) Merci d’avance pour l’assistance. Automatik (discussion) 18 mars 2013 à 23:05 (UTC)Répondre

Il faut d'abord clarifier quelque chose : Lua possède déjà toutes les fonctions pour manipuler les chaînes sans module supplémentaire. Un module spécial pour manipuler les chaînes n'aurait d'utilité que pour les modèles écrits en code wiki normal, mais dans ce cas, le modèle est nécessairement bricolé, illisible et inefficace, donc c'est le modèle lui-même qu'il faudra convertir en Lua, et pas ses fonctions. Sur le Wiktionnaire on n'a heureusement pas beaucoup de modèles qui utilisent ces fonctions.
Pour les clés de tri, il est plus avantageux d'avoir un seul module (ou deux, pour stocker les données). Il est plus pertinent de réunir des fonctions proches dans un même module. — Dakdada 19 mars 2013 à 10:07 (UTC)Répondre
Ok, ça marche pour rassembler ensemble ce qui va ensemble. Pour le module qui manipule les chaînes de caractères, je voulais juste faire allusion au fait que, par exemple le module string de WP, implémente une fonction qui permet de trouver un caractère dans un titre, pour le remplacer automatiquement par un autre ; les fonctions Lua sont utilisées pour fabriquer ce module, et ce sont des fonctions de manipulation de chaîne de caractères entre autres, mais cela fait in fine du w:module:String un module qui permet de manipuler des chaines de caractères, il me semble, d’où le nom que je lui ai donné. Automatik (discussion) 20 mars 2013 à 00:55 (UTC)Répondre
Lua possède déjà toutes les fonctions pour manipuler les chaînes sans module supplémentaire ? Oui pour les chaines d’octets, mais non pour les chaines de caractères Unicode que nous utilisons sur les projets Wikimedia. On doit utiliser la bibliothèque Ustring. — TAKASUGI Shinji (d) 22 mars 2013 à 01:50 (UTC)Répondre
Oui, c'est ce que j'entendais par là (pour être précis, c'est Scribunto qu'on utilise). — Dakdada 22 mars 2013 à 08:45 (UTC)Répondre

PS: À ce sujet Dakdada, est-ce des pages de test comme on en voit dans l’en-tête de w:en:module:string que tu voulais ?

Pas exactement. Ces pages-là comparent un texte créé avec un texte attendu, et disent si le test a marché ou pas. Ça marche bien avec les petites fonctions, mais on peut difficilement utiliser cette approche pour tester de gros modèles. Les pages de test que j'utilisent permettent à n'importe qui de tester l'affichage des modèles en testant autant de paramétrages que l'on veut (en vérifiant le résultat à l'œil). — Dakdada 19 mars 2013 à 10:07 (UTC)Répondre

class=plainlinks sur toute une page modifier

Bonjour.

Par inattention, j’ai oublié de fermer la balise div du modèle {{NavigBP}} ce qui fait que, le modèle étant inclue dans Wiktionnaire:Bulletin des patrouilleurs/2013, tous les liens externes sont en mode « plainlinks ». Est-ce mal de laisser une balise ouverte à l’infini ? Sur Wikipédia il existe des modèles pour donner des diffs et utilisant volontairement la classe plainlinks, je serai donc curieux de savoir pourquoi ne vaut-il pas mieux ouvrir une balise en début de page qu’on ne ferme pas. Automatik (discussion) 24 mars 2013 à 02:18 (UTC)Répondre

Simplement : ne pas fermer une balise, c'est comme ne pas terminer une phrase par un point. C'est une mauvaise pratique, qui peut avoir des conséquences imprévisibles sur tout le reste de la page. — Dakdada 24 mars 2013 à 14:02 (UTC)Répondre
Je vais corriger ces erreurs. Automatik (discussion) 27 mars 2013 à 20:54 (UTC)Répondre

Commentaires Lua modifier

Bonjour.

Est-il dommageable (techniquement parlant) de mettre des commentaires à chaque fin de ligne expliquant précisément chaque détail du code - cela peut-il induire un temps de chargement plus long - ou alors ça n’a strictement aucune conséquence sur le programme ?

Merci d’avance pour votre aide, Automatik (discussion) 24 mars 2013 à 03:19 (UTC)Répondre

Généralement les compilateurs ne tiennent pas compte des commentaires, et d’ailleurs utiliser un décompilateur ne permet jamais de les retrouver. JackPotte ($) 24 mars 2013 à 13:33 (UTC)Répondre
Ouep, c'est pas les commentaires qui vont ralentir un programme. Cela dit il ne faut pas non plus trop en mettre, pour que le code reste lisible. — Dakdada 24 mars 2013 à 14:04 (UTC)Répondre
Par contre ce qui serait peut-être intéressant à faire ce serait d’expliciter (désosser) le code avec des commentaires sur la page de discussion. Ainsi même les néophytes pourraient comprendre le modèle, et ça permettrait une meilleure maintenance en cas de départ. Le point négatif c’est que ce sera sûrement barbant pour le créateur du modèle et si ceux qui le modifient ensuite ne reporte pas leur retouche dans l’explication celle-ci deviendra inutile. V!v£ l@ Rosière /Murmurer…/ 24 mars 2013 à 14:30 (UTC)Répondre
Il y a déjà deux endroits où le code est décrit : directement en commentaire dans le code (détails techniques précis), et la page de documentation associée au module, qui décrit les fonctions et leur usage (sans entrer dans les détails techniques internes). Ces deux choses sont indispensables, mais on ne va pas faire plus (ce n'est pas seulement barbant : c'est difficile à maintenir).
Et si on doit désosser un code pour pouvoir le comprendre, c'est qu'il est mal écrit... — Dakdada 25 mars 2013 à 15:14 (UTC)Répondre

Espace insécable automatique devant certains symboles typographiques ? modifier

Bonjour.

Le conseil suivant est-il également valable sur Wiktionnaire ?

« N'utilisez pas l'entité html &nbsp; pour créer des espaces insécables, car elles seront créées automatiquement par le programme lors de l'affichage de la page. »

— (D’après les conventions typographiques de Wikilivres)

D’après un avis, cela est valable au moins sur Wikilivres et Wikipédia.

Merci pour votre aide, Automatik (discussion) 25 mars 2013 à 00:40 (UTC)Répondre

J’ai ouï dire qu’au tout début des wikis il fallait les mettre, mais qu’un patch avait réglé ça il y a fort longtemps. JackPotte ($) 25 mars 2013 à 08:24 (UTC)Répondre
Dans certains cas, comme entre deux mots ordinaires, il faut les mettre à la main si cela est nécessaire et justifié ; en association avec des caractères de ponctuation, le logiciel s’occupe normalement de tout. Mais il y a des cas non-triviaux, comme entre une valeur numérique et une abréviation d’unité.
D’une manière générale, tous les &nbsp; devraient être planqués dans les modèles, on ne devrait jamais en mettre dans les articles. --GaAs 25 mars 2013 à 19:01 (UTC)Répondre
Dans la mesure où les Anglais ne mettent pas d’espace avant les signes typographiques comme le point-virgule, et que le logiciel gère les espaces automatiquement, cela signifie qu’il fonctionne donc différemment selon la langue ? Automatik (discussion) 27 mars 2013 à 20:56 (UTC)Répondre
Non, il se comporte de la même façon partout, s’il trouve un espace propre il le respecte : en:User:JackPotte/test. JackPotte ($) 27 mars 2013 à 21:44 (UTC)Répondre
Le logiciel remplace donc automatiquement les espaces simples par des espaces insécables devant un signe de ponctuation double. Je ne l’avais pas compris comme ça avant, merci beaucoup. Automatik (discussion) 27 mars 2013 à 22:32 (UTC)Répondre

Syntaxe wiki ou HTML : que préférer ? modifier

Salut.

Quelqu’un saurait-il laquelle des deux syntaxes suivantes il faut préférer et pourquoi :

<em>Texte à afficher en italique</em>

ou

''Texte à afficher en italique''

Merci d’avance pour vos réponses, Automatik (discussion) 25 mars 2013 à 01:51 (UTC)Répondre

Question facile. C'est évidemment la deuxième. La raison est simple : nous ne sommes pas un site destiné à être édité par des professionnels du HTML. (à noter d'ailleurs que le résultat n'est pas forcément équivalent entre ces deux notations : la balise em ne génère pas forcément des italiques, ça peut dépendre des navigateurs. Lmaltier (discussion) 25 mars 2013 à 06:49 (UTC)Répondre
Merci. (Du coup les cas où on voit de telles balises em, il faut être prudent avant de les remplacer par des doubles apostrophes, vu que ces deux syntaxes différent dans leur rendu.) Automatik (discussion) 25 mars 2013 à 14:43 (UTC)Répondre
D'un autre côté, si on tombe sur des em dans une page, c'est que la page est probablement mal écrite, et du coup il vaut mieux les remplacer. — Dakdada 25 mars 2013 à 15:07 (UTC)Répondre
Ça marche. Automatik (discussion) 25 mars 2013 à 15:13 (UTC)Répondre

Remplissage automatique de la boîte d'édition modifier

Bonjour. Savez-vous comment cela se fait ? --Automatik (discussion) 25 mars 2013 à 05:18 (UTC)Répondre

Dans AWB, c’est la boite de l’onglet "start". JackPotte ($) 25 mars 2013 à 08:23 (UTC)Répondre
C’est-à-dire qu’il faut faire quoi pour se retrouver dans la même situation - je vois l’onglet Start, mais pas d’indication pour que la boîte d’édition recopie le texte inséré ? Cet utilisateur, en écrivant ce message, aurait utilisé AWB pour que la boîte d’édition se remplisse ainsi ? Automatik (discussion) 25 mars 2013 à 14:38 (UTC)Répondre
Pour obtenir le résumé de ce qui est modifié, il faut laisser cette boite vide, c’est automatique. JackPotte ($) 25 mars 2013 à 15:21 (UTC)Répondre
Si je laisse le champ « Default Sumary » vide j’obtiens Please enter an edit summary (pas l’affichage de la page à droite donc). Mais je doute qu’il ait utilisé AWB pour répondre à un message sur sa pdd ? Automatik (discussion) 25 mars 2013 à 15:45 (UTC)Répondre
Euh, si je pipe bien la question, tu parlais du remplissage auto du champ "résumé" lors de l’édition ? Si c’est bien la question, ça n’a rien à voir avec AWB mais je doute un peu vu la réponse de Jackot, c’est faisable avec qques lignes de javascript, voir par exemple la façon de faire dans Mediawiki:Gadget-CreerFlexionFr.js :
document.getElementById('wpSummary').value = "Création avec Gadget-CreerFlexionFr";
Sauf que qd j’y réfléchis j’ai un doute : comment récupérer dans javascript le texte de ta réponse ? Le plus simple est de faire à la main un copier-coller, ce qui donne exactement ce résultat.
Il est aussi possible que ce soit une fonction de AutoEd (dernière ligne de w:en:User:Magioladitis/vector.js). --GaAs 25 mars 2013 à 18:49 (UTC)Répondre
Merci pour la réponse ; Automatik (discussion) 27 mars 2013 à 22:52 (UTC)Répondre

Lua : mettre les entités html ou le codage utf-8 modifier

Qu’est-ce qui est le plus efficace, à votre avis entre les deux possibilités ci-dessous ?

  • titi = '&thinsp;'
  • titi = '\226\128\137' -- (sauf erreur, mais peu importe, ce n’est pas le sujet)

Ceci bien sûr dans l’objectif de retourner le résultat à Mediawiki, afin de générer du wikicode (lequel devra générer la page html). --GaAs 25 mars 2013 à 19:54 (UTC)Répondre

Tu veux écrire une espace fine sécable ? Dans ce cas, si tu ne veux pas utiliser directement «», tu peut utiliser &#x2009; ou &#8201;. Le code &thinsp; ne marche pas toujours avec de vieux navigateurs, et \226\128\137 est incompréhensible pour nous êtres humains. — TAKASUGI Shinji (d) 26 mars 2013 à 02:56 (UTC)Répondre
J’avais oublié que si on écrit titi = '', à priori le lua à la sauce scribunto créera une chaine de 3 octets contenant \226\128\137 (j’ai pas testé, mais j’ai lu ça qque part). Mais c’est encore pire comme solution, parce que qd tu édites le code tu ne vois rien du tout (tu connais Whitespace ? ).
Écrire &#x2009; est légèrement plus lisible (à peine en fait, seul &thinsp; est vraiment compréhensible par un humain), mais du donnes du boulot supplémentaire au parseur de Mediawiki, alors que le programme lua peut renvoyer directement le résultat gratuitement, d’où ma question. --GaAs 27 mars 2013 à 23:10 (UTC)Répondre
En passant je viens de voir qu’il y a une fonction mw.text.decode, qui ne doit pas fonctionner pour l’instant mais est prévue. --GaAs 28 mars 2013 à 08:37 (UTC)Répondre
Apparemment cette librairie est maintenant dispo [7]. Automatik (discussion) 28 mars 2013 à 15:48 (UTC)Répondre

--Psychoslave (discussion) 3 avril 2013 à 08:00 (UTC)Répondre

Je trouve que vous vous creusez les neurones pour rien ici, il suffit de prendre la solution la plus portable techniquement, et d’ajouter un commentaire lua pour ceux qui voudraient comprendre le code.

  • titi = '&amp;thinsp;' -- caractère & et une espace fine
    
  • titi = '\226\128\137' -- la même chose (non?)
    
  • titi = ' ' -- !!! ceci est une espace insécable !!!
    

Magic word "BASEPAGENAME" modifier

Bonjour,

Je ne comprends pas pourquoi on a des modèles de ce genre : Modèle:BASEPAGENAME. Ne sont-ils pas inclus automatiquement, sans que l’on crée ces modèles ?

Il est marqué notamment que « Le modèle interne {{BASEPAGENAME}} ne fonctionne pas sur ce wiki pour tous les espaces de noms. » alors que Spécial:Version indique bien tout en bas que basepagename est un mot magique valide.

Cela me rend confus ; quelqu’un saurait-il ? Merci d’avance, Automatik (discussion) 27 mars 2013 à 23:18 (UTC)Répondre

Je ne sais pas trop, à part que le modèle utilise rel2abs.
Sinon l’appellation « modèle interne » est très mauvaise, il s’agit évidemment de « mot magique ». --GaAs 27 mars 2013 à 23:33 (UTC)Répondre
Il est possible que le mot magique donne des résultats qui ne conviennent pas à ce qui était voulu lorsqu’utilisé dans le main, où les sous-pages ne sont pas activées et où donc l’usage de BASEPAGENAME (le mot magique) n’a guère de sens. --GaAs 27 mars 2013 à 23:42 (UTC)Répondre
Selon la documentation de w:en:Template:BASEPAGENAME, ce modèle n’a pas de fonction excepté comme explication pour les débutants qui confondent les modèles et les mots magiques. — TAKASUGI Shinji (d) 28 mars 2013 à 06:04 (UTC)Répondre
Le nôtre n’est pas dans ce cas, il fait vraiment qqch de différent du mot magique. --GaAs 28 mars 2013 à 08:43 (UTC)Répondre
Oui, comme tu l’as dit plus tôt, verdy_p affirme dans l’historique que cela sert effectivement à être utilisé dans l’espace de nom principal pour contourner le fait que normalement ça ne marche pas dans des espaces de noms sans sous-pages (i.e. le main). Cela dit, en pratique ce n’est pas utilisé dans ce cas. Automatik (discussion) 28 mars 2013 à 21:51 (UTC)Répondre
Où est l’espace de nom main dont tu parles ? Si tu parles de l’espace de nom principal (sans préfixe), le mot magique {{BASEPAGENAME}} marche toujours bien. En tous cas, il ne faudrait jamais nommer un modèle comme cela si sa fonction est différente. — TAKASUGI Shinji (d) 28 mars 2013 à 23:41 (UTC)Répondre
Oui, je voulais parler de l’espace principal. Je me suis donc trompé vu que comme tu le laisses entendre, il accepte la présence de sous-pages.
Dans l’historique du modèle BASEPAGENAME, Verdy p explique pourquoi il l’a créé. Tu comprendras mieux que moi.
Il y a aussi {{MOIS.NOM}} qui semble désuet depuis la version 1.19 du logiciel Mediawiki qui offre {{CURRENTMONTHNAME}}. Il y a sûrement aussi d’autres cas dans cette liste. Automatik (discussion) 29 mars 2013 à 00:09 (UTC)Répondre
{{CURRENTMONTHNAME}} ne donne que le nom du mois actuel. — TAKASUGI Shinji (d) 29 mars 2013 à 01:15 (UTC)Répondre
Oui, et {{MOIS.NOM}} aussi. En effet. Automatik (discussion) 29 mars 2013 à 10:23 (UTC)Répondre
@TAKASUGI Shinji, il semblerait que le magic word BASEPAGENAME ne se comporte pas correctement (ou pas comme Verdy le voulait) sur un titre de page avec un / (slash) dans un espace de nom sans sous-pages. Et c’est effectivement une très mauvaise idée d’avoir donné au modèle le même nom.
@Automatik, {{MOIS.NOM}} donne le nom du mois passé en paramètre (comme documenté), ce que ne fait pas CURRENTMONTHNAME. C’est utilisé dans les trucs du genre {{NavigQM}}. --GaAs 29 mars 2013 à 15:28 (UTC)Répondre
J’ai confirmé ce que tu as dit par essayer les deux codes dans 24/7. En fait le mot magique {{BASEPAGENAME}} et Modèle:BASEPAGENAME donnent des résultats différents, comme a écrit Verdy p. — TAKASUGI Shinji (d) 3 avril 2013 à 03:19 (UTC)Répondre

Lua : mw.ustring.sub(txt,1,0) ne retourne pas une chaine vide modifier

Pourtant ça devrait, non ? Ça retourne en fait la même chose que mw.ustring.sub(txt,1,1) (le 1er caractère de la chaine), ce qui n’est pas logique. --GaAs 28 mars 2013 à 18:44 (UTC)Répondre

Si car les chaines démarrent à 1. JackPotte ($) 28 mars 2013 à 20:52 (UTC)Répondre
Ça n’a rien à voir avec la question, ou j’ai mal compris ? Si j’écris mw.ustring.sub(txt,5,4), que suis-je censé obtenir ? --GaAs 29 mars 2013 à 07:33 (UTC)Répondre
Mon premier message n’était pourtant pas crypté : MW:Extension:Scribunto/Lua_reference_manual/fr#string.sub indique que ton 4 représente la position de fin, et non pas la longueur de la sous-chaine. JackPotte ($) 29 mars 2013 à 10:58 (UTC)Répondre
Oui, parfaitement : donc sub(txt,5,4) est la chaine qui va du 5e caractère au 4e, et devrait être vide, non ? --GaAs 29 mars 2013 à 15:01 (UTC)Répondre
Je confirme que l’interpréteur en ligne de lua.org renvoie une chaine vide pour string.sub(txt,1,0), alors que la version scribunto mw.ustring.sub(txt,1,0) renvoie le 1er caractère. --GaAs 29 mars 2013 à 15:09 (UTC)Répondre

Lua Edit modifier

Bonjour. Quelqu’un saurait-il comment obtenir le résultat du code tapé avec LuaEdit ? Automatik (discussion) 29 mars 2013 à 11:51 (UTC)Répondre

Il faut invoquer tes fonctions. JackPotte ($) 29 mars 2013 à 12:19 (UTC)Répondre
Par exemple, je mets print(x) après avoir assigné à la variable x la valeur 1. Si j’utilise la touche Entrée, ça passe à la ligne, mais ne renvoie rien. Automatik (discussion) 29 mars 2013 à 12:26 (UTC)Répondre
Remplace ton "print" par "return", et le résultat apparaitra à l’endroit du invoke. JackPotte ($) 29 mars 2013 à 12:52 (UTC)Répondre
En parlant de LuaEdit, je parlais http://luaedit.sourceforge.net/ , pas de Scribunto. Désolé d’avoir été imprécis. Je m’en sers pour tester la syntaxe basique, dès qu’il faudra utiliser des trucs liés à Scribunto j’irai sur https://test.wikipedia.org. Automatik (discussion) 29 mars 2013 à 17:30 (UTC)Répondre

Réglé : WT:Scribunto répondait déjà à mes questions depuis le début, donc je présente mes plus plates excuses pour cette question inutile (disons-le). Automatik (discussion) 4 avril 2013 à 02:04 (UTC)Répondre