Wiktionnaire:Questions techniques/avril 2013

---

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

---

Spécial:Page au hasard et Spécial:Randomrootpage

Bonjour. Quelqu’un connaît-il la différence entre ces deux pages ? Automatik (discussion) 4 avril 2013 à 19:08 (UTC)

Le second ne pas prend pas en compte les sous-pages, ce qui n'est utile que sur les sites comme Wikilivres. — Dakdada 4 avril 2013 à 19:35 (UTC)

C’était marqué en anglais ici : MW:Extension:Randomrootpage. JackPotte ($♠) 4 avril 2013 à 19:36 (UTC)

Merci Dak et merci JackPotte, je ne savais pas qu’on pouvait trouver si facilement des aides sur des pages spéciales sur mw, je saurai désormais. Automatik (discussion) 4 avril 2013 à 21:52 (UTC)

Je t'ai donné un poisson et Jackpotte un manuel de pêche. — Dakdada 4 avril 2013 à 22:05 (UTC)

J’aime l’un comme l’autre Automatik (discussion) 4 avril 2013 à 22:11 (UTC)

Messages systèmes Scribunto

Bonjour. Dans la documentation de Lua, on peut voir que les messages système consacrés à Scribunto sont de la forme Mediawiki:scribunto-doc-subpage-xxxx. Cependant, les messages système semblent être définis dans Mediawiki:scribunto-doc-page-xxxx. Par exemple pour MediaWiki:Scribunto-doc-subpage-name qui a son équivalent ici : MediaWiki:Scribunto-doc-page-name. Lequel "compte" ? Sur la Wikipédia française, le premier n’a même pas été changé, il vaut /doc, alors que dans le second il est bien inscrit que le nom de la doc est en /Documentation, et c’est le cas en pratique. Du coup, quelle est la différence entre ces deux messages systèmes ?

Cordialement, Automatik (discussion) 5 avril 2013 à 01:44 (UTC)

Je m'étais trompé. Le second ne semble pas servir. — Dakdada 5 avril 2013 à 09:05 (UTC)

Tag ponctuel nowiki

Bonjour,

Quelqu’un sait à quoi sert un <nowiki /> ? Automatik (discussion) 7 avril 2013 à 02:32 (UTC)

A rien. JackPotte ($♠) 7 avril 2013 à 07:29 (UTC)

Merci. On peut le trouver dans le modèle fr-verbe-flexion, dans cette situation par exemple :

{{#if:{{{'|}}}|’|e <nowiki />}}

Ou encore dans la situation suivante :

{{#if:{{{1|}}}|<nowiki />
!colspan="3"{{!}}

Si c’est inutile dans ce cas-là, je propose de les supprimer. (Si personne ne veut modifier le modèle pour ça, je proposerai que ça soit fait avec une autre modif’ de ce modèle, si elle est acceptée.) Automatik (discussion) 8 avril 2013 à 00:07 (UTC)

Bien sûr que c’est utile, les modèles ne fonctionnent pas sans ça ! (Je suis surpris que JackPotte ne le sache pas)

En gros, c’est un des hacks mais pas le seul que les développeurs de modèles en wikicode ont trouvé pour que le parseur ne sucre pas un retour à la ligne, voire un espace.

Une bonne raison de plus de convertir tout ça en lua. --GaAs 8 avril 2013 à 18:14 (UTC)

Merci. Automatik (discussion) 8 avril 2013 à 18:28 (UTC)

NB : En ce qui concerne les espaces, il y a longtemps que je convertis les {{…|… <nowiki />}} en {{…|… }} (sémantiquement plus compréhensibles), mais pour les sauts de lignes je ne connais pas de remplacement utile. --GaAs 8 avril 2013 à 18:34 (UTC)

On peut l’utiliser aussi pour empêcher certains codes wiki d’être évalués. Les deux codes suivants produisent le même résultat :

• {{<nowiki />cf}} → {{cf}}
• <nowiki>{{cf}}</nowiki> → {{cf}}

Il est à noter que nowiki ajoute certains caractères invisibles :

• {{str len|a}} → 1
• {{str len|a<nowiki />}} → 35
• {{str len|<nowiki>a</nowiki>}} → 34

— TAKASUGI Shinji (d) 15 avril 2013 à 03:24 (UTC)

Lua et #ifexist

Comment faire l’équivalent de {{#ifexist:}} en lua ? Je voudrais porter {{pron}} en lua, car de nombreux modèles l’utilisent. --GaAs 8 avril 2013 à 18:05 (UTC)

Comme ça :

local article = mw.title.new("zinzin") -- On crée un objet "mw.title" avec le titre de la page dont on cherche à vérifier l'existence

if article.exists then
    -- Faire quelque chose
end

Si nécessaire on pourrait créer une fonction ifexist() dans le Module:bases. — Dakdada 8 avril 2013 à 18:20 (UTC)

Super merci.

Pour la création de la fonction, je pense que ce serait utile (même si on ne l’importe pas pour des questions de performances, on aurait le code sous la main).

--GaAs 8 avril 2013 à 18:39 (UTC)

Un seul module annexe ou plusieurs pour améliorer les performances ?

Bonjour,

J’ai vu que chez les Anglophones, le module de translittération était éclaté en multiples sous-modules, chacun translittérant une langue ([1]). Est-ce mieux pour les performances de faire ainsi que de tout mettre dans un même module en /data ? Merci d’avance, Automatik (discussion) 9 avril 2013 à 05:11 (UTC)

Je me vois mal maintenir autant de modules que de langues publiées, soit plusieurs milliers. D’autant plus que certains seront identiques. JackPotte ($♠) 9 avril 2013 à 11:01 (UTC)

Ce n'est pas particulièrement mieux pour les performances (j'aurais tendance à dire le contraire). D'ailleurs, n'est-il pas possible de mettre les translittérations sous la forme d'une simple table de pairs de remplacement (en utilisant des regex quand nécessaire) ? Il suffirait alors de charger le tableau général de toutes les translittérations une fois pour toute quand on charge une page. Parce que sinon j'ai l'impression que tout est écrit en dur dans chaque langue, donc il faut charger chaque module à chaque fois qu'il y a une translittération à faire, ce qui n'est pas optimal. — Dakdada 9 avril 2013 à 12:04 (UTC)

Je me posais la même question pour les conjugaisons : mettre tous les fr-conj-n-xxx dans le même module ou pas ? --GaAs 11 avril 2013 à 14:43 (UTC)

Les fonctions de création de tableau ne seront probablement pas appelées plus de deux ou trois fois dans une page, donc la séparation et la taille des pages doit plutôt se faire en terme d'organisation et de maintenance. On peut faire un module pour le squelette et un module pour le remplissage, ou plutôt trois pour les trois groupes. NB : penser à donner un nom lisible, donc écrire « conjugaison » en toutes lettres. — Dakdada 11 avril 2013 à 14:59 (UTC)

pagefromfile.py

Bonjour, quelqu’un a-t-il déjà utilisé ce module python sous windows sans problème d’encodage ? Lyokoï et moi avons suivi semble-t-il les recommandations mais nous avons le même problème : les caractères é, è, à, etc. se retrouvent mal codés. — Unsui Discuter 9 avril 2013 à 20:10 (UTC)

Lyokoï88 (d · c · b) n’a pas donné suite à la première solution que je lui avais communiqué. JackPotte ($♠) 9 avril 2013 à 20:14 (UTC)

Je l’ai donnée à Unsui qui m’a montré son résultat. Du coup, je suis pas super convaincu. --Lyokoï (discussion) 9 avril 2013 à 20:25 (UTC)

Quelle idée aussi de vouloir faire ça sous Windows :P Plus sérieusement, il faut d'abord vérifier que le fichier contenant la liste des articles est bien encodé en utf-8 (et pas en iso-8859-1, latin1, ANSI ou je ne sais quoi). Il faut voir avec quel éditeur texte tu fais ça (ce n'est pas une bonne idée d'utiliser le bloc-note de base). — Dakdada 9 avril 2013 à 20:44 (UTC)

C’est fait, sur Notepad++ pour moi. --Lyokoï (discussion) 9 avril 2013 à 20:45 (UTC)

Hmm... sinon, as-tu essayé de vérifier l'encodage de la ligne de commande (genre chcp, sachant que l'utf-8 doit être quelque chose comme 65001) ? — Dakdada 9 avril 2013 à 20:50 (UTC)

Moi aussi (sauvegardé encodé utf-8 sans BOM comme il est conseillé mais en utf-8 tout court ça fait pareille). L’astuce de JackPotte fonctionne mais alors quelle sale tête ! (voir öinen). Y-a-pas mieux ? Sinon Dak, il faut taper chcp 65001 avant de passer la commande ? — Unsui Discuter 9 avril 2013 à 20:58 (UTC)

Arg oui le truc de JackPotte ne marche pas :-(

Pour chcp : oui, mais j'imagine que ça ne changera l'encodage que du terminal... — Dakdada 9 avril 2013 à 21:13 (UTC)

Pour chcp : pas mieux qu’avant. Pour le truc de JackPotte, si il fonctionne mais après il faut passer un coup d’AWB pour tout reconvertir utf-8 (remarque, c’est faisable si lors de la création on place ces pages dans une catégorie de travail du style : Mots comprenant des caractères codés en HTLM, ce qui optimisera singulièrement le post-traitement AWB qui ne lirait que cette catégorie. Bon ça fait quand même usine à gaz. Sinon la solution la meilleure c’est quoi ? (j’ai plus de 100 000 pages à créer comme ça). — Unsui Discuter 9 avril 2013 à 21:22 (UTC)

Le plus rapide serait de passer ta liste à un dresseur de bot qui n'a pas de problème d'encodage... — Dakdada 9 avril 2013 à 21:28 (UTC)

Mediawiki

Bonjour,

J’ai cherché à retrouver dans doc.wikimedia.org les lignes suivantes ajoutées au logiciel suite à cette requête à Bugzilla.

+    'frwiktionary' => array(
+        'WT' => NS_PROJECT,
+    ),

Quelqu’un sait pourquoi je ne les trouve pas ? Automatik (discussion) 11 avril 2013 à 14:11 (UTC)

Ces lignes sont ajoutées au fichier de configuration LocalSettings.php de notre wiki fr.wiktionary.org, pas dans le code du logiciel Mediawiki. Seuls des administrateurs (des vrais) peuvent voir et modifier ce fichier. — Dakdada 11 avril 2013 à 14:19 (UTC)

Merci ; Automatik (discussion) 11 avril 2013 à 16:29 (UTC)

Liens dans le Modèle:source

Bonjour,

Quelqu’un saurait-il expliquer pourquoi, lorsqu'on met un lien dans le modèle {{source}}, le lien est en mode "plainlinks" et non un lien comme ça ? Exemple : mettre sur la glace. Je n’ai pas trouvé de réponse dans Mediawiki:Common.css, dans lequel je ne lis que :

.sources {
 font-size: 0.85em;
}

Sauriez-vous me guider ? Automatik (discussion) 12 avril 2013 à 11:28 (UTC)

C'est en fait défini sur les lignes d'exemples :

/* Liens discrets dans les exemples */
.ns-0 #bodyContent ol li ul a,
.ns-0 #bodyContent ol li li ul a,
.ns-0 #bodyContent ol li ul ul a { 
    color:#000090;
    background:none !important;
    padding-right:0;
}

Si je ne m'abuse, le "background:none !important;" empêche l'affichage de toute icône sur la ligne d'exemple (je ne comprends pas pourquoi on a mis !important par contre). — Dakdada 12 avril 2013 à 13:38 (UTC)

Merci ; pour le !important, tu l’avais mis toi-même par contre : [2]. Automatik (discussion) 12 avril 2013 à 13:54 (UTC)

En effet, mais je ne sais pas exactement pourquoi. — Dakdada 12 avril 2013 à 14:42 (UTC)

Propriété id de la balise HTML span

Bonjour,

Les modèles issus de {{term}} contiennent (en général du moins) la propriété id dans la balise span ; exemple : {{germanisme}}. À quoi sert cette id ?

Merci d’avance, Automatik (discussion) 14 avril 2013 à 14:38 (UTC)

Ce point a déjà été abordé sur la Wikidémie, il s’agit de désambiguïser les polysèmes lors des hyperliens internes, comme : sens#mathématiques.

De plus, cela permet à chacun via son common.css de changer pour un thème donné, la couleur, taille de la police… JackPotte ($♠) 14 avril 2013 à 16:46 (UTC)

Merci, j’ai peut-être loupé la discussion ou ai une mauvaise mémoire. Automatik (discussion) 14 avril 2013 à 17:33 (UTC)

Remarquez, les id sont censés être uniques. Ça ne marche donc pas s'il y a plus d'un "mathématiques" ou autre dans une page.

En outre, faites gaffe : le modèle "term" veut dire terminologie. L'utiliser pour "germanisme" ou "figuré" est une erreur. — Dakdada 14 avril 2013 à 22:25 (UTC)

{{emploi}} pour {{germanisme}} est-il correct ? Automatik (discussion) 14 avril 2013 à 22:32 (UTC)

Plutôt {{registre}} je pense. --GaAs 15 avril 2013 à 13:52 (UTC)

Merci, c’est aussi ce que propose Wiktionnaire:Liste de tous les modèles#Registres d’emploi, donc je change. Automatik (discussion) 15 avril 2013 à 14:01 (UTC) Je suis complètement à côté de la place ces temps-ci, ce modèle utilisait déjà registre depuis le début et j’ai soutenu le contraire. Désolé J’ai appris cependant comment ça marche dans l’ensemble, notamment avec ce lien. Automatik (discussion) 15 avril 2013 à 14:07 (UTC)

Te bile pas, j’en fais des bien pires. --GaAs 15 avril 2013 à 18:54 (UTC)

Un modèle pour que toutes les pages de doc des modules lua se ressemblent

J’espérais que les devs avaient prévu le nécessaire pour qu’on puisse traiter les pages comme Module:prononciation/Documentation juste par du CSS. Ben non, sauf erreur de ma part ce n’est pas possible.

Donc je vais créer {{documentation module}}. La question grave de chez grave, c’est « faut-il l’écrire en lua ? » --GaAs 14 avril 2013 à 17:19 (UTC)

NB : même pas un lien vers la page de doc quand on lit le module, ça c’est vraiment une horreur. --GaAs 14 avril 2013 à 17:21 (UTC)

N’hésite pas à t’inspirer de WP qui l’a déjà écrite (en lua) : w:Module:Documentation module. Automatik (discussion) 14 avril 2013 à 17:35 (UTC)

Pas exactement en fait, ça sert juste à présenter la doc. transcluse. Automatik (discussion) 14 avril 2013 à 18:02 (UTC)

Au-delà de l'aspect pratique d'un modèle de documentation, il faudrait qu'on adopte une mise en page type pour la présentation du contenu des modules, pour avoir une documentation homogène. — Dakdada 14 avril 2013 à 22:20 (UTC)

 Pour. Libre aux plus expérimentés de définir cela. Automatik (discussion) 14 avril 2013 à 22:23 (UTC)

J’ai mis {{documentation module}} sur toutes les pages de doc des modules existant(s). Mais il me semble qu’il faudrait ouvrir un bug, parce qu’être obligé de faire ça juste pour rendre le fond vert n’est pas normal. --GaAs 15 avril 2013 à 18:51 (UTC)

Pagename et clé de tri de catégorie

Bonjour,

Je vois de plus en plus souvent, même dans des pages protégées (de WP en particulier), la syntaxe suivante :

[[Catégorie:Nom de la catégorie|{{PAGENAME}}]]

Y a-t-il un cas où le {{PAGENAME}} peut servir à quelque chose ? Cela a-t-il servir dans le passé ? Automatik (discussion) 15 avril 2013 à 13:40 (UTC)

Je ne pense pas que ça serve ou ait servi. Peut-être un outil/bot en est-il à l’origine ? Je pense à une valeur par défaut… --GaAs 15 avril 2013 à 13:50 (UTC)

C’est utile pour les modèles, dont le clé de tri par défaut est le nom de page avec le préfixe de l’espace de noms. — TAKASUGI Shinji (d) 15 avril 2013 à 15:02 (UTC)

Ce bricolage ne sert plus, les pages sont correctement catégorisées à présent, sans l'espace de noms. — Dakdada 15 avril 2013 à 15:59 (UTC)

C’est donc ce que je disais, une facilité pour un programme informatique, je fais parfois ça quand je suis fatigué, mais ça reste malgré tout une *très* mauvaise façon de faire même qd je suis fatigué. --GaAs 15 avril 2013 à 18:47 (UTC)

Lua : require croisés

Bonjour. Y a-t-il un problème à mettre require("Module:B") dans Module:A et require("Module:A") dans Module:B ? Vous allez me dire, pourquoi ne pas tout mettre dans le même module, mais ça casse un peu la symétrie de l’architecture que j’envisage (où il y a une bonne douzaine de modules en plus de A et B).

NB : normalement il ne devrait pas y avoir d’appels récursifs indirects. --GaAs 17 avril 2013 à 15:02 (UTC)

J'imagine que c'est pas ça qui fera planter Lua. J'aimerais bien savoir pourquoi tu as besoin de modules qui s'appellent l'un l'autre par contre... — Dakdada 17 avril 2013 à 15:16 (UTC)

Regarde Module:fr-conj-3-tir en imaginant le même pour le verbe avoir (Module:fr-conj-3-avoir). Tu as une fonction (purement lua) pour générer une variable-tableau de ttes les formes conjuguées, et une pour générer la page d’annexe de conj complète. Cette dernière appelle la première, puis une grosse fonction commune à ttes les conj qui se trouve dans Module:fr-conj pour créer la mise en forme.

Or, pour les temps composés, la fonction dans Module:fr-conj a besoin de la conjugaison du verbe avoir (et être). Le truc efficace, c’est donc qu’elle appelle la première fonction dans Module:fr-conj-3-avoir pour obtenir toutes ses formes, plutôt que doublonner l’info (comme c’est le cas avec les modèles actuels).

Je ne sais pas si j’ai été clair. --GaAs 17 avril 2013 à 15:38 (UTC)

Les fonctions d'affichage ne devraient pas être dans les mêmes modules que les fonctions qui créent le contenu (surtout s'il s'agit de les copier-coller de module en module). Donc la fonction p.complete(frame) n'a pas sa place dans Module:fr-conj-3-tir, qui doit se contenter de créer le contenu et le renvoyer à Module:fr-conj quand celui-ci le demande (avec un require conditionnel genre if conj=="fr-conj-3-tir" then formes = require("Module:fr-conj-3-tir") end). Pour les auxiliaires, il faudrait simplement une fonction dans ces modules qui renvoie les informations de l'auxiliaire (pas la conjugaison complète), voire (plus simple) qui renvoie la conjugaison composée d'un verbe donné dont on fournit le participe passé et la prononciation (mais ce serait alors mieux dans un module spécial qui inclurait les fonctions des deux auxiliaires).

Du moment que toutes les manipulations et invocations se passent dans le module fr-conj, il n'y a pas de problème de require croisés (qui devraient être évitées).

En passant, question nomenclature : ce serait bien d'utiliser les sous-pages et des noms plus longs, comme : Module:fr-conjugaison/3e_groupe/-tir. — Dakdada 17 avril 2013 à 16:36 (UTC)

Mais p.complete() *est* dans Module:fr-conj (à la fin), celle qui est dans Module:fr-conj-3-tir ne fait que lui passer les paramètres spécifiques aux verbes en -tir.

Pour les ss-pages, OK, je veux bien, mais ici le module principal n’est pas Module:fr-conj, celui-ci n’est qu’une librairie utilisée par tous les autres. --GaAs 17 avril 2013 à 16:54 (UTC)

Ce serait bien de les nommer différemment :/ N'est-ce pas la fonction p.complete() de Module:fr-conj-3-tir qui renvoie du texte brut ? Alors qu'elle ne devrait renvoyer que les données ? La fonction d'affichage et d'appel du modèle ne devrait être que dans Module:fr-conj. — Dakdada 17 avril 2013 à 17:32 (UTC)

J’ai l’impression que tu prends le truc dans le sens inverse de moi. Il y a une cinquantaine de modèles fr-conj-n-xxx sur Catégorie:Modèles de conjugaison en français, plus ceux en espagnol, etc., qui n’ont pas tous toujours les mêmes paramètres. En conséquence je suis parti sur le principe 1 modèle = 1 module, par exemple :

• {{fr-conj-3-tir}} = {{#invoke:fr-conj-3-tir|complete}}
• module:fr-conj-3-tir comporte une fonction (en principe privée) qui génère les formes du verbe, et une fonction complete(frame) qui décode frame, appelle la fonction précédente, et passe le bébé à une fonction (que je devrais renommer) dans module:fr-conj
• module:fr-conj contient la totalité du code générant la page d’annexe.
  • Ce module n’aura aucune fonction appelable avec #invoke, c’est juste une librairie.
  • Ce module est destiné à perdre sont fr- et à être commun à toutes les langues romanes.

En faisant comme tu dis, « la fonction d'appel du modèle ne devrait être que dans Module:fr-conj », c’est en fait 50 ou 100 fonctions d’appel qu’il faudrait y mettre, à moins de faire une usine à gaz au niveau du passage de paramètres par #invoke. J’ai donc choisi le contraire : zéro fonction d’appel dans Module:fr-conj. --GaAs 17 avril 2013 à 19:27 (UTC)

Le problème des paramètres différents n'est pourtant pas compliqué : il suffit de réserver 2 ou 3 paramètres (langue=, type=) et de renvoyer le reste des paramètres à la fonction spécialisée. Un exemple d'appel (c'est ça que tu appelles une usine à gaz j'imagine ?) :

{{#invoke:conjugaison|afficher_conjugaison
|langue=fr
|type=3e groupe/-tir
|verbe=avertir
|auxiliaire=avoir
|prononciation=a.vɛʁ.tiʁ
}}

Cette fonction récupérerait les conjugaisons de Module:fr-conjugaison/3e groupe/-tir et les mettrait en forme, avec les fonctions du module de conjugaison général.

Comme tu l'as dit, ma suggestion est bien l'inverse de ce que tu proposes.

NB : pour la question de départ, le mieux pour les auxiliaires serait, comme je l'ai dit, de faire un module dédié, plutôt que de mélanger avec la conjugaison des verbes avoir et être (qui utilisent eux-mêmes les auxiliaires). — Dakdada 17 avril 2013 à 20:19 (UTC)

Le problème, c’est que c’est incompatible avec l’existant, sans apporter aucun avantage àma.

Comment tu traites avec ça {{fr-conj-1-e*er}} (qui a 4 paramètres pour décrire le verbe), {{fr-conj-3-tir}} (qui en a 2), {{fr-conj-3-naître}} (qui a une option pour des temps défectifs), {{fr-conj-3-clure}} (qui une option pour l’ortho du ppa), sans parler de {{es-conj-2}} (jusqu’à 10 paramètres pour décrire le verbe, mais ça devrait réduire), etc. ? Tu prévois tous les paramètres possibles et imaginables ?

Non, honnêtement, la fonction qui fait tout grâce à une tripotée de paramètres, ça me parait une mauvaise façon de faire. Et je ne comprends pas du tout pourquoi ce que je propose te déplait à ce point (1 modèle = 1 module, sans aucune redondance de code grâce à une librairie commune, c’est la limpidité).

Note tout de même que ce que j’ai codé actuellement est à peine une esquisse. --GaAs 17 avril 2013 à 21:14 (UTC)

Que ce soit en paramètre ou dans le nom du modèle, il faut bien qu'on écrive ces informations quelque part. Dans ce que je suggère, les paramètres sont transmis à la fonction du module spécialisé (transmission directe du frame), ce qui revient strictement au même, puisqu'il n'y a pas besoin de les prévoir dans la fonction de base (qui se contente d'afficher le contenu généré).

J'ai dit ça parce que ça permet d'éviter les require croisés, cf titre de la discussion . — Dakdada 19 avril 2013 à 15:28 (UTC)

La seule solution raisonnable, c’est que j’arrête de m’occuper de ça, et c’est ce que je vais faire. --GaAs 22 avril 2013 à 17:24 (UTC)

XHTML

Bonjour,

Écrire <br clear="all"> est-il utile dans ce cas-là :

…
|}

<br clear="all">
=== Exemples ===

? Je vois souvent ça dans les doc, comme dans Modèle:DocumentationM. Merci d’avance, Automatik (discussion) 19 avril 2013 à 12:15 (UTC)

Il vaut mieux utiliser {{Clr}}. — TAKASUGI Shinji (d) 19 avril 2013 à 15:05 (UTC)

Idem. D'ailleurs ce serait plutôt <br clear="all" />. — Dakdada 19 avril 2013 à 15:10 (UTC)

Je ne vois pas la différence dans le rendu avec ou sans <br clear="all"> en fait. Si j’enlève cette balise, le rendu est le même (dans la doc. comme dans le modèle). Automatik (discussion) 19 avril 2013 à 15:37 (UTC)

Tant que le tableau ne flotte pas (comme les illustrations en vignette ou les tableaux d'accord des articles), il n'y a pas besoin de mettre ça. — Dakdada 19 avril 2013 à 16:32 (UTC)

Merci ; Automatik (discussion) 19 avril 2013 à 16:33 (UTC)

Le mot-clé repeat en Lua

Bonjour,

Dans la doc. de Lua, on peut lire que « L'instruction repeat répète le bloc tant que exp est vraie. » (avec repeat block until exp).

Vu que until veut dire « jusqu’à », l’instruction repeat ne fonctionne-t-elle pas plutôt jusqu’à que exp est vraie ? Ou alors, c’est bien tant que exp est vrai, donc jusqu’à ce que exp soit faux ?

Merci d’avance, Automatik (discussion) 21 avril 2013 à 14:01 (UTC)

C’est bien jusqu’à ce que exp soit vraie (= tant qu’elle est fausse) (doc officielle). --GaAs 23 avril 2013 à 09:25 (UTC)

Merci beaucoup Automatik (discussion) 3 mai 2013 à 15:38 (UTC)

La propriété class-lang dans un span

Bonjour,

Où peut-on trouver la déclaration des propriétés comme class-lang utilisées dans des modèles comme {{Lang}} ? Qu’ajoute-t-elle à la propriété lang ?

Cordialement, Automatik (discussion) 21 avril 2013 à 14:01 (UTC)

Classe abbr en CSS

Bonjour,

Le modèle {{abréviation discrète}} donne actuellement des abréviations non discrètes en pointillé ; ex : Abr..

Le but de ce modèle étant d'utiliser des abréviations discrètes donc sans pointillés, faut-il appliquer les styles CSS ad hoc directement dans le modèle, ou alors le mettre dans Mediawiki:Common.css ? Wikipédia a opté pour la seconde solution :

/**
 * ABBR ET BALISE ABBR discrète
 */
 
abbr {
  color: inherit;
}
 
abbr.abbr {
  border-bottom: 0;
}
 
a abbr {
  cursor: inherit;
}

Merci d'avance pour votre aide ; Automatik (discussion) 21 avril 2013 à 14:41 (UTC)

Le problème de Modèle:abréviation discrète sur l’encyclopédie Wikipédia est qu’il faut passer la souris sur le texte pour comprendre qu’il y a une abréviation d’expliquée. JackPotte ($♠) 21 avril 2013 à 19:01 (UTC)

Ça ne me semble pas gênant vu le nom du modèle. Mais qu’on garde la forme actuelle si elle plaît ne me gêne pas non plus, étant donné que je me sentais redevable d’avoir échoué de le faire (mais après coup je n’ai pas empiré le modèle donc pas de sushi). J’enlève class="abbr" du coup ? Automatik (discussion) 22 avril 2013 à 17:11 (UTC)