Discussion utilisateur:Ygonaar

Ceci est ma page de discussion. N'hésitez surtout pas à me laisser un message au besoin. Même si vous êtes débutant en syntaxe wiki, vous ne pourrez faire AUCUN dommage irréparable. Pour éditer un nouveau message, cliquez sur l'onglet "+". Pour intervenir sur un message déjà existant, cliquez sur l'onglet "modifier" correspondant au titre du message sélectionné.

Les anciens messages ont toutes les chances de se trouver aux archives. N'hésitez cependant pas à y intervenir si vous le jugez pertinent.

Voir les archives de cette page

Les crédits

Je ne sais pas si tu l'a remarqué, mais les crédits mentionnent que les chroniques d'Ygoonar sont une exclusivité de l'Oniropædia, ce qui n'est manifestement pas le cas au vu du premier des deux liens fournis. --Narcian le Grand Rêvant 2 janvier 2007 à 12:06 (CET)

Les crédits mentionnent Licence d'Oniropædia par défaut, soit la licence Attribution-NonCommercial-ShareAlike 2.5, ce qui permet à quiconque de reprendre ce texte à partir du moment où il respecte les termes de la licence. Le fait que ces textes ont déjà été publiés sur d'autres sites sans licence précisée par défaut, c'est à dire sous copyright, ne doit normalement pas poser de problème. En revanche, le modèle crédit me semble encore à améliorer.

Amitiés. --Ygonaar 3 janvier 2007 à 14:19 (CET)

Je ne parlait pas de la licence mais de la ligne qui mentionne exclusivité. A priori il faut renseigner le champ publication avec l'un des deux liens mentionnés pour que cette mention abusive disparaisse. --Narcian le Grand Rêvant 4 janvier 2007 à 10:34 (CET)

Merci, je n'avais pas fait attention. Il faudrait vraiment que j'édite à tête plus reposé... et que je me penche sérieusement sur ce modèle crédit et sa saleté d'insertion automatique de date dans le champs publication...

Amitiés. --Ygonaar 4 janvier 2007 à 20:31 (CET)

Bon, je prends quelques congés et voilà qu'à mon retour je découvre ces tonnes de modifications.

Alors avant tout Oui le modèle Crédits est encore à améliorer. Le système d'insertion de date automatique est là uniquement du fait que j'avais originellement destinée le modèle pour les écrits issus de Fanzines (et de Magazines), or ceux ci n'ayant pas toujours d'issn la date est généralement nécessaire pour identifier le numéro exact.

Maintenant, il y a aussi la redondance existant entre le modèle Voir aussi dans un certain nombre de cas. Il faudrait donc que l'on se penche sérieusement sur ce que l'on veut dans les Crédits, dans Voir Aussi et que l'on définissent les contextes d'usage. Je ne peux pas le faire tout seul (sinon cela serait trop dirigiste).

Quand cela sera bien définit, nous pourrons finaliser un modèle pérenne.--Just an Illusion 5 janvier 2007 à 00:02 (CET)

Ne boude pas JaI, c'est contre le modèle que je râlai, pas contre son concepteur qui a pris le temps d'élaborer un code source complexe et élaboré.
Peut-être trop complexe et élaboré d'ailleurs. La suite a été déplacée sur Discussion Modèle:Crédits#Ce modèle est très complexe et élaboré.
Amitiés.--Ygonaar 18 février 2007 à 19:57 (CET)

Création/Catégorisation des Catégories

J'ai remarqué que tu n'avais pas catégorisé la nouvelle catégorie "Règle maison" dans la catégorie principale "Catégorie". A l'avenir, essaie d'y penser lorsque tu crée une nouvelle catégorie.

Tu ne semble pas non plus habitué à utiliser la syntaxe [[Catégorie:nom de la catégorie|{{PAGENAME}}]]

--Narcian le Grand Rêvant 4 janvier 2007 à 10:41 (CET)

catégorie:Règle maison était catégorisée dans sa catégorie mère catégorie:Règle qui sera elle-même catégorisée dans catégorie:Catégorie racine lorsqu'elle sera éditée. Mais c'est vrai que j'avais oublié catégorie:Catégorie, ce qui est d'autant moins excusable que c'est moi qui l'avait créée.

Quant aux modifications de la classification dans les catégories avec le [[nom de la catégorie|{{PAGENAME}}]], c'est un usage que je connais (je crois d'ailleurs être le premier à en user sur Oniropædia), mais dont l'utilisation systématique me parais pas forcement judiscieuse. Elle simplifie considérablement la lecture et la recherche dans certains cas, mais le fait de connaitre le nom de l'espace dans d'autre cas, et donc savoir que l'on va ouvrir un article, une catégorie ou un portail me paraissait pertinent.

Amitiés. --Ygonaar 4 janvier 2007 à 19:32 (CET)

Si j'ai bien compris ton propos, quand on sait que l'on va ouvrir un portail, il vaut mieux que tout soit indexé à la lettre "P" pour Portail. Dans ce cas, à quoi servent les catégories "Portail" et "Catégorie" ? --Narcian le Grand Rêvant 5 janvier 2007 à 09:53 (CET)

Ce n'est pas vraiment ce que j'ai essayé de dire. Prenons deux exemples:

• Dans la catégorie portail, nous trouvons x liens qui seraient tous indexés à portail:... avec une catégorisation classique. Le classement alphabétique automatique devient alors abscons et une catégorisation systématique avec [[nom de la catégorie|{{PAGENAME}}]] très très utile.
• En revanche, dans la catégorie règle maison, on trouvera des articles traitant de règle. La répartition alphabétique de leurs titres devrait être homogène, même si l'on peut craindre que beaucoup d'auteur feront commencer leurs titre de page par "Règle de...". En tout cas, il n'y aura certainement qu'un portail référencé, celui traitant des règles maisons. Un lecteur novice dans Oniropædia aura certainement du mal à trouver le portail à partir de la catégorie, noyé qu'il sera parmi tous les articles commençant par "règle". Dans ce cas, il me semble que l'information de l'espace particulier (portail) est pertinente et n'apporte nulle nuisance, au contraire. Donc je serai partisan de ne pas le catégoriser avec sont seul nom de page. Mais si une majorité préfère une utilisation systématique de PAGENAME par soucis de simplicité, je n'en ferai pas une maladie...

Amitiés. --Ygonaar 6 janvier 2007 à 23:58 (CET)

Il ne s'agit pas d'un soucis de simplicité, mais :

• De méthodologie : Il vaut mieux prendre une seule et même bonne habitude
• D'uniformisation : Avant mon intervention nous avions Archives (modèle) à la lètre "A" et Archive (modèle) à la lettre "M". Si à l'intérieur même d'une catégorie, il n'y a pas uniformisation de l'indexation, les "surfeurs" vont rapidement être perdus. Et cela sera pire si le mode d'indexation change d'une catégorie à l'autre. Une telle géométrie variable est (pour moi) nuisible au succès et à la pérénité de l'Oniropædia
• Sur le point de l'indexation, il reste toutefois un soucis : le classement des lettres spéciales comme "É" et "Œ" qui apparaissent en fin de classement que ce soit avec le classement automatique ou bien avec l'utilisation de [[nom de la catégorie|{{PAGENAME}}]]. Pour ma part je préconise exeptionnellement un classement manuel dans ce dernier cas de figure (par exemple [[Catégorie:Portail|Eléments de portail]] pour la catégorie "Éléments de portail")

--Narcian le Grand Rêvant 8 janvier 2007 à 08:45 (CET)

Je suis d'accords avec toi pour l'indexation des lettres spéciales et tes arguments d'uniformisation et de simplicité se tiennent. Oniropædia n'est pas encore très grosse et nous avons encore le choix, mais c'est vrai que cela risque de devenir problématique de modifier notre stratégie ultérieurement sans bot. Donc il va faloir que l'on décide officielement entre:

• L'indexation systématique avec le nom de la page seulement. Simple et homogène mais perte d'information pertinente de temps en temps.
• L'indexation raisonnée, où le contributeur choisi au cas-par-cas la méthode qui lui semble la plus pertinente. Moins homogène, sujet au débat contradictoire et plus sensible aux erreurs, mais fournissant par définition l'information la plus réfléchie et, je l'espère, le plus souvent la plus pertinente.

Je vais mettre un lien sur le Tambour afin qu'un maximum de gens donnent leur avis.

Amitiés. --Ygonaar 8 janvier 2007 à 15:28 (CET)

Cela fait un bout de temps que je n'ai pas contribué donc voici mon opinion sur le sujet.

Si l'on veut catégoriser de manière systématique, tout en évitant le problème des caractères, on doit pouvoir mettre au point un modèle qui retirera les cas problématiques. On arrivera alors à une indexation du type [[nom de la catégorie|{{{Indexation|{{PAGENAME}}}}}]]

De même il devrait être possible de mettre au point un modèle mettrais la catégorie et le nom d'indexation tel que {{{Indexation|Portail}}} qui nous donnerait [[Catégorie:Portail|Eléments de portail]] dans le cas de {{PAGENAME}}=Éléments de portail.

Le principale avantage de l'utilisation d'un modèle pour l'indexation est le fait de pouvoir modifier toute l'indexation sans avoir peur d'oublier une des pages déjà indexé lors des mises à jour. Cela permettra aussi de mettre au point un bot simple dont le rôle pourrait justement être de vérifier la présence de cette indexation. Je crois d'ailleurs que c'est l'une des fonctions d'une des pages spéciales.

L'autre avantage c'est que l'on peut faire le modèle de tel manière pour que les deux propositions d'Ygonaar soient possibles (et cela en fonction des paramètres définis lors de l'appel)

Par exemple :

• {{{Indexation|Portail}}} donnerait [[Catégorie:Portail|Eléments de portail]] dans le cas de {{PAGENAME}}=Éléments de portail.
• {{{Indexation|Scénario|toto}}} qui donnerait [[Catégorie:Scénario|toto]] dans le cas de {{PAGENAME}}=Le tort tue.

Pour illustrer mon propos, j'ai directement créé le modèle proposé. Je n'ai pas mis d'exemple, mais le modèle lui-même utilise la version la plus simple de ce modèle. Une autre version en exemple est utilisé pour indexer la page de discussion.--Just an Illusion 9 janvier 2007 à 23:27 (CET)

Honnêtement, je ne vois pas trop à quoi sert ce modèle sinon d'inclure automatiquement le PAGENAME si le champs 2 est vide. Je ne suis pas certain que ce soit plus rapide que la syntaxe de catégorisation par défaut et on risque certainement de perdre les autres contributeurs habitués à Wikipédia. Mais peut-être que quelque chose m'a échappé? Toujours est-il que cela ne répond pas à la question initiale: doit-on instaurer une nomenclature à instaurer systématiquement ou laisse-t-on chaque contributeur choisir ce qu'il estime la plus adaptée au cas-par-cas?

Amitiés. --Ygonaar 12 janvier 2007 à 10:40 (CET)

Le modèle ne sert à rien en lui-même, sauf à anticiper de futures évolutions sur l'indexation des pages. En effet dans ce modèle j'ai isolé uniquement le fond (le nom de la page, et la manière de l'indexée) de l'aspect technique du codage, qui elle ira toujours en évoluant.

Tu me dis que l'on risque de perdre les "habitués à Wikipédia" (tu veux certainement dire de la syntaxe wiki, qui traite la forme). Je te dirais qu'elle n'est nullement intuitive. De plus je ne suis pas sur que tous les utilisateurs courants (et futurs), soient de grands contributeurs en syntaxe wiki. Je pense que la plus part préféreront un système plus style wysiwyg.

Pour répondre a ta question : pour une raison d'uniformité (et de maintenabilité), il ne faut un système systèmatique.

C'est moins contraignant qu'on le croit, et l'indexation n'est pas le problème de l'auteur mais celle du site d'usage. --Just an Illusion 18 janvier 2007 à 00:08 (CET)

Il est vrai qu'actuellement ce modèle n'apporte rien, mais il répond au soucis de méthodologie. En le complexifiant un poil, on peut régler le problème d'indexation des accents et autres caractères spéciaux (Æ,Œ), que l'on index sur PAGENAME, FULLPAGENAME, ou bien encore un LIBELLÉ SPÉCIFIQUE.

Après réflexion j'observe, que pour Ygonaar, il y a deux types de catégories :

1. Les catégories catalogant les pages d'espaces de nom (par exemple Modèle pour les modèles, Portail pour les portails, Aide pour les pages d'Aide, Catégorie pour les catégories, etc).
2. Les catégories catalogant les pages de l'espace principal des articles.

toujours pour Ygonaar, la règle d'indexation devrait-être la suivante :

1. Les catégories catalogant les pages d'espaces de nom (ie catégories d'espace de nom) doivent être systématiquement indexées sur PAGENAME.
2. Les catégories catalogant les pages de l'espace principal des articles doivent être systématiquement indexées sur FULLPAGENAME.

Désolé mais je n'avais pas noté le cas FULLPAGENAME, donc ce n'est pas dans mon modèle.--Just an Illusion 18 janvier 2007 à 00:08 (CET)

faire une syntaxe [[Catégorie:nom de catégorie]] est équivalente à faire une syntaxe [[Catégorie:nom de catégorie|{{FULLPAGENAME}}]]. L'avantage de la seconde c'est qu'elle simplifie la codification des modèles. --Narcian le Grand Rêvant 18 janvier 2007 à 09:47 (CET)

Avec un modèle on peut automatiser et systématiser le catalogage et l'indexation des pages d'un espaces de nom. Sur le modèle de l'espace des portails, on peut catégoriser les pages principales dans la catégorie "Espace de nom", et les sous-pages dans la catégorie "Élément de espace de nom".
Attention, il y a des cas particuliers : les pages de discussion des modèles ne sont pas cataloguées dans "Discussion modèle" mais dans "Syntaxe des modèles", les pages des utilisateurs ne sont pas cataloguées dans "Utilisateur" mais dans "Éditeur".

D'où mon deuxième champ pour préciser un nom spécifique.--Just an Illusion 18 janvier 2007 à 00:08 (CET)

Il existe également la catégorie spéciale "Archive" qui catalogue toutes les pages dont le nom se termine par "/Archives". On devrait même faire en sorte que les pages d'archive ne soient pas cataloguées dans "Élément de espace de nom" comme c'est actuellement le cas pour les sous-pages d'archive de l'espace des portails.

Le recours a une table de correspondance "Espace de nom" <-> "Catégorie", "Élément de catégorie" permet de traiter automatiquement tous les espaces de nom.

C'est une autre idée. Par contre je vois mal sa mise en place en syntaxe wiki. Surtout si l'on veut être exhaustif.--Just an Illusion 18 janvier 2007 à 00:08 (CET)

Il est à noter que lorsqu'une page d'un espace de nom porte le même nom qu'une catégorie, la page en question est systématiquement cataloguée dans la catégorie en question ainsi que dans la catégorie parente. Attention : une catégorie ne doit pas se retrouver cataloguée dans elle-même, et les pages qui ne sont pas des catégories ne doivent pas se retrouver cataloguée dans la catégorie racine.

En ayant recours à une table de correspondance "Catégorie" <-> "Catégorie parente", on peut également automatiser le catalogage "connexe" des pages d'espace de nom et la hiérarchisation des pages de catégorie. Attention : certaines catégories ont plusieurs catégories parentes.

Pour finir, si l'on veut encore plus de souplesse, on peut recourir à une table de correspondance qui code en dur le mode d'indexation comme suit :

• Catégorie <-> PAGENAME pour les catégories devant obligatoirement être indexées sur PAGENAME
• Catégorie <-> FULLPAGENAME pour les catégories devant obligatoirement être indexées sur FULLPAGENAME
• Catégorie <-> {{{LIBELLÉ SPÉCIFIQUE|####}}} pour les catégories relevant d'un mode d'indexation manuel.

Dans le cas des articles de l'espace principal, on peut faire en sorte qu'en l'absence de paramétrage du modèle d'indexation les pages soient cataloguées dans la catégorie "Pages à catégoriser". De cette façon on peut concevoir une méthodologie simple qui consiste d'abord à inclure le modèle d'indexation sans paramètre (ce qui peut être fait automatiquement par un bot). Ensuite, si cela est nécessaire, on rajoute la bonne catégorie (celle qui correspond à la spécification la plus fine), pour finir, si la page se retouve indexée sous le caractère #, on rajoute le LIBELLÉ SPÉCIFIQUE d'indexation.

Cette façon de faire, permet de changer de politique de catégorisation sans avoir à repasser sur chaque page. Il y a alors juste à retoucher les tableaux de correspondance et les pages de catégorie.

Nota : initialement j'avais rédigé un discours un peu plus structuré/didactique, malheureusement, lorsque j'ai cliqué sur prévisualisation, j'ai tout perdu suite à une déconnection intempestive

Et oui, personnellement je fais parfois un ctrl+a, ctrl+c avant une prévisualisation, sinon j'ai un bon cache.--Just an Illusion 18 janvier 2007 à 00:08 (CET)

--Narcian le Grand Rêvant 12 janvier 2007 à 13:27 (CET)

---

J'ai mis en place les tables de correspondances suivantes :

• {{Catégorisation/Catégorie espace de nom}}
• {{Catégorisation/Catégorisation/Module de base/Catégories parentes}}
• {{Catégorisation/Catégorisation/Module de base/Indexation dans catégorie/Configuration}}

ainsi que le modèle de conversion de caractère {{Désaccentuation}} qui doit permettre de régler le problème des accents et autres caractères spéciaux.

Un certain nombre d'explications se trouvent sur les pages de discussions associées.

Actuellement aucun de ces modèles n'est encore en exploitation. Je vais maintenant m'atteler à modifier le modèle {{Indexation}} afin qu'il exploite les modèles {{Catégorisation/Catégorisation/Module de base/Indexation dans catégorie/Configuration}} et {{Désaccentuation}}.

--Narcian le Grand Rêvant 10 avril 2007 à 13:14 (CEST)

Je viens de faire quelques essais avec la nouvelle version du modèle {{Indexation}}. Si personne ne pousse de cris d'orfraies d'ici lundi prochain, je généraliserai l'utilisation de ce dernier sur toutes les pages.

--Narcian le Grand Rêvant 10 avril 2007 à 16:11 (CEST)

La généralisation du modèle {{Indexation}} est terminée

--Narcian le Grand Rêvant 9 mai 2007 à 17:25 (CEST)

Félicitation pour ce travail de fourmi! En fait, ça ce typographie comment, un cri d'orfraie? Amitiés. --Ygonaar 9 mai 2007 à 18:21 (CEST)

Félicitation pour ce travail de fourmi! En fait, ça ce typographie comment, un cri d'orfraie? Amitiés. --Ygonaar 9 mai 2007 à 18:11 (CEST)

?!? Deux fois la même question ?!? 8:)

Tout ce que j'ai réussi à trouver en faisant une courte recherche sur le net, c'est que l'orfraie hurle. Pas moyen de trouver un extrait sonore. Par conséquent j'ignore comment se typographie un cri d'orfraie. :-)

--Narcian le Grand Rêvant 9 mai 2007 à 18:53 (CEST)

Blanchiment

Tu as blanchi la page Portail:Botanique/Appel à contribution/archive dont j'avais demandé la suppression est qui était une page de redirection. Cette page fait actuellement doublon avec la page Portail:Botanique/Appel à contribution/Archives. Peux-tu donner la raison de ton action ?

--Narcian le Grand Rêvant 25 janvier 2007 à 18:51 (CET)

En fait, je voulais seulement enlever la catégorisation en "page à supprimer" (car sinon, curieusement, elle reste visible dans cette catégorie même après suppression, et cela devient donc vite le foutoir). Mais un blanchiment complet est parfois plus rapide, et comme la page devait être supprimée...

Amitiés. --Ygonaar 25 janvier 2007 à 19:20 (CET)

Et tu compte la supprimer quand cette fameuse page ? --Narcian le Grand Rêvant 26 janvier 2007 à 09:38 (CET)

Mais c'est déjà fait voyons!!!-) Bon, faudrait peut-être que je dorme plus, moi...

Amitiés. --Ygonaar 26 janvier 2007 à 10:45 (CET)

Politique d'austérité ?

Répondou. --Xiloynaha, qui court se cacher.

Substitution retardée

A postériori la substitution ne s'applique pas directement aux paramètres passés aux modèles. Désolé de t'avoir aiguillé sur un mauvais exemple de code.

Cdlt, --Narcian le Grand Rêvant 28 février 2007 à 18:52 (CET)

Mince, un conflit d'édition! Je recopie: Ce n'est pas grave, l'idée générale n'est pas mauvaise quand même. Je vais faire quelques pâtés pour voir si je m'en sorts. J'ai déjà résolu ma principale inquiétude, c'est à dire pouvoir renseigner les champs des modèles de deuxième ordre. On devrait donc pouvoir s'en sortir!

Amitiés. --Ygonaar 28 février 2007 à 19:10 (CET)

exemple de code qui marche

il est utilisé dans le modèle {{Bienvenue}} pour faire une catégorisation conditionnelle.

<includeonly><!-- début section catégorisation -->
{{subst:</includeonly><includeonly>#ifeq:{{subst:</includeonly><includeonly>NAMESPACE}}|{{subst:</includeonly><includeonly>ns:User}}|[[{{subst:</includeonly><includeonly>ns:Category}}:Éditeur|{{PAGENAME}}]]}}
<!-- fin section catégorisation --></includeonly>

j'espère que tu réussira à t'en inspirer malgrés sa complexité.

--Narcian le Grand Rêvant 28 février 2007 à 19:06 (CET)

Merci, je vais essayer de creuser la question (sous un pâté de sable, c'est peut-être inconscient non?). Amitiés bis. --Ygonaar 28 février 2007 à 19:10 (CET)

exploitation de la valeur par défaut d'un paramètre

Bon, je crois avoir trouvé une bonne piste. Un premier niveau de modèle appelé obligatoirement avec un subst (non retardé) créant la structure des section et appelant des seconds niveaux de modèle créant le corps des sections. J'arrive même à avoir une section secondaire (le Voir aussi de Annexes) complètement conditionnelle. Mon seul problème de fond, pour l'instant, est de comprendre pourquoi le champ niveau de titre n'accepte pas de valeur par défaut avec la procédure classique {{{appel de la valeur de champ|valeur par défaut}}}. Si tu as une explication? Sinon je forcerai la valeur par défaut avec une parser function.

Amitiés. --Ygonaar 1 mars 2007 à 02:14 (CET)

---

Quand tu utilise le code :

{{subst:Utilisateur:Ygonaar/Bac à sable/squelette
|section=1
|niveau de titre=
|scénario=
|article=bibi fricotin
|lien=
|bibliographie=toute la BD des origines à aujourd'hui
|auteur=
|illustrateur=
|éditeur=
|publication=
|numéro=
|année=
|isbn=
|issn=
|lien=
|licence=
}}

Tu défini un niveau de titre égale à une chaîne de caratère de longueur nulle. Du coup, le paramètre étant "défini", il n'est pas remplacé par sa valeur par défaut. Pour obtenir la valeur par défaut, il faut exclure "|niveau de titre=" du code utilisé voir Discussion Modèle:Section portail pour un exemple de modèle qui ne s'appelle pas toujours avec l'intégralité de ses paramètres (Attention: la page est longue à se calculer).

{{subst:Utilisateur:Ygonaar/Bac à sable/squelette
|section=1
|scénario=
|article=bibi fricotin
|lien=
|bibliographie=toute la BD des origines à aujourd'hui
|auteur=
|illustrateur=
|éditeur=
|publication=
|numéro=
|année=
|isbn=
|issn=
|lien=
|licence=
}}

--Narcian le Grand Rêvant 1 mars 2007 à 10:50 (CET)

Donc, pour résumer, si on veut obtenir une valeur par défaut avec le processus "classique", il ne faut pas que le champ soit présent dans le code d'appel du modèle? --Ygonaar 1 mars 2007 à 15:36 (CET)

Tu as tout compris. (désolé pour la réponse tardive) --Narcian le Grand Rêvant 1 mars 2007 à 19:31 (CET)

Avantages et Inconvénients des structures multi-étages et/ou à substitution (telle quelle ou bien retardée)

Après une petite nuit de sommeil (faites des gosses qu'ils disaient, faites des gosses...), il me semble bien plus problématique d'utiliser une substitution directe. Si on touche ensuite le modèle de premier ordre, il faudra modifier à la main tous les articles! Remarques, ce serait peut-être tout de même le cas avec une substitution retardée. Du coups, j'hésite furieusement. Qu'en pense le peuple?

Ou alors, il nous faudrait un bot capable de repérer le code du modèle dans chaque page, récupérer la valeur des champs et refaire le subst:modèle de premier ordre... Il y a-t-il des dresseurs dans la salle?

Amitiés. --Ygonaar 1 mars 2007 à 10:28 (CET)

Je peux sans problème me charger de transformer le code du modèle en substitution retardée (je me suis déjà fait la main sur le modèle {{Bienvenue}}).

Tu (on) doit faire le choix entre des articles long et galère à retoucher car pas de lien d'édition de section, et une structure en dure appelant des modèles qui n'implémentent que le corps des sections comme s'était plus ou moins initialement le cas avec les premières versions de modèles. Dans le cas initial, il est à la charge de l'utilisateur/éditeur d'implémenter lui-même manuellement la structure des sections des articles qu'il rédige. La structure avec susbtitution (d'un modèle pur ou d'un modèle avec substitution retardée) n'est qu'un outil offert en plus à l'utilisateur/éditeur lui permettant d'alléger sa charge de travail manuelle et rien de plus (sans oublier qu'elle offre une pseudo-normalisation).

--Narcian le Grand Rêvant 1 mars 2007 à 10:50 (CET)

Certes, mais ce principe de modèle à deux étages pourrait être généralisé à tous les modèles générant plusieurs sections (plante, humanoïde, recette alchimique, ...). Or il arrivera fatalement un jour que l'on retouche au modèle primaire (ou squelette) d'un de ces modèles complexes. Ces modifications, qu'elles touchent du code en substitution directe ou retardée d'ailleurs (ce qui relativise il me semble l'intérêt de faire une substitution retardée), n'affecteront pas tous les articles déjà créés. On pourrait se dire que tant pis, ça aurait été à fortiori le cas avec des créations manuelles d'articles, mais puisqu'on en est à nos débuts, autant partir des meilleures bases possibles. Je pense donc que posséder au moins un bot capable (un bot par modèle?) de réactualiser automatiquement tous les appels de ces modèles serait un luxe précieux. Et un argument fort pour se lancer à fond dans ce type de stratégie. Mon pauvre modèle {{Modifier}} a en fin de compte du soucis à se faire...

Je vais essayer de me renseigner un peu sur les bots et battre le rappel pour voir si on a pas un dresseur diplômé planqué dans un coin. Amitiés. --Ygonaar 1 mars 2007 à 15:36 (CET)

---

• La substitution retardée "intégrale" a pour intérêt principal de rendre le modèle inexploitable s'il n'est pas substitué (on appel cela de la substitution forcée) et est recommandée pour les modèles à usages temporaires tels que {{Supprimer}} et {{Bienvenue}} (note: seul {{Bienvenue}} utilise la substitution forcée).
• La substitution retardée a également pour intérêt de pourvoir cascader récursivement les modèles si ceux-ci utilise la technique de la substitution retardée paramétrée (il n'y a pas d'exemple de ce genre sur l'Oniropædia)
• La substitution retardée partielle peut être utilisée pour faire de l'inclusion substituée conditionnelle (cf {{Bienvenue}}). Avec cette dernière technique il est possible de conditionner le traitement d'un bout de code au cas du modèle substitué ou au cas du modèle non substitué, tout en faisant en sorte que la page modèle se comporte comme si le modèle était substitué.

Dans le cas qui nous préoccupe (hors contexte de bot), si l'on veut que le modèle {{Modifier}} ne soit appelé que s'il y a substitution, il faut une substitution retardée partielle. De même si l'on veut que le chapîtrage ne soit effectif qu'en mode "substitution effective".

Je ne saisi pas trop le problème avec {{Modifier}}. J'avais juste sous-entendu que ce modèle n'aurait peut-être pas trop d'utilité si l'on généralise les modèles complexes, car il n'y a plus guère de raison d'utiliser alors __NOEDITSECTION__. --Ygonaar 1 mars 2007 à 17:24 (CET)

Dans l'optique où toute la structure de section est implémentée par le modèle squelette, il n'y a en effet plus aucune raison de recourrir au modèle {{Modifier}}. Dans mon optique initiale seule la section "Annexes" était implémenté dans le modèle squelette, le corp du modèle squelette apellant tour à tour les modèles "Voir aussi" et "Crédits", chacun de ses modèles codant sa propre section. Comme tu le souligne, cela souleve la problématique de la maintenance de l'appel du modèle {{Modifier}} en cas de modification de la structure principale des articles. --Narcian le Grand Rêvant 1 mars 2007 à 18:16 (CET)

Ensuite, si les titres des sous-sections qui comportent des images sont implémentés via des modèles, il deviendra inutile de repasser sur chaque article si l'on change les images.

Ça limiterait probablement en effet fortement le nombre de situations problématiques. --Ygonaar 1 mars 2007 à 17:24 (CET)

En ce qui concerne le cas très spécifique du rajout d'une sous-section, si l'on crée un modèle squelette spécifique au rajout de la sous section concernée, on s'allège considérablement le travaille de mise à jour des articles existant : pas de nécessité de réinsérer par substitution le modèle squelette principal tout en ayant le soucis de conserver les valeurs paramétrées.

Cas de figure non idyllique, mais limitant encore une fois le problème. De toutes manières, nous devront bien renseigner individuellement pour chaque article les nouveaux paramètres créés. --Ygonaar 1 mars 2007 à 17:24 (CET)

Reste :

1. le cas des sections à affichage conditionnel qu'on veut rendre à affichage permanent ou bien des sections à affichage permanent qu'on veut rendre à affichage conditionnel : là, il s'avère indispensable d'avoir un bot
2. le cas des sections que l'on supprime : ici un bot fera perdre (de façon probablement non souhaitée) de l'information. Question : le bot sera-t-il suffisamment intelligent vis-à-vis de ce dernier cas de figure ?

Je pense que l'on peut paramétrer un bot pour qu'il créé dans les articles analysés une nouvelle section de type "données à traitées", où il placerait tout les champs qu'il doit supprimer dans l'appel du nouveau modèle. A la charge bien sur aux éditeurs d'analyser ensuite tout cela. --Ygonaar 1 mars 2007 à 17:24 (CET)

--Narcian le Grand Rêvant 1 mars 2007 à 16:15 (CET)

Brillante et didactique analyse, cher Narcian. J'en conclu que:

• Même sans bot, nous serions capable de limiter fortement les problèmes.
• Les problèmes résiduels seront de toute manière sans commune mesure avec une tentative d'homogénisation d'articles créés sans modèle guide.
• je ne vois pas de raison que cela exclu l'utilisation future d'un bot, et pour l'instant, le nombre d'article à traiter reste... très humainement faisable.
• Beaucoup d'article, notamment les nouvelles et scénarios, deviendront très rébarbatif à utiliser sans liens d'édition de section. Or le modèle {{modifier}} reste très contraignant et sensible à tout changement antérieur du chapîtrage. Il y aura donc certainement nombre de problème dans Oniropædia si ce modèle doit être utiliser trop fréquemment.
• Il est par conséquent primordial d'éviter que le modèle Crédits (associé ou non à Voir aussi ou autre), LE modèle obligatoire, utilise __NOEDITSECTION__.

Deux règles impératives :

1. Modèles à substitution forcée (cette dernière règle pose le problème de la complexité des modèles à deux étages dont la mise en place ne sera pas à la portée du premier profane venu)

   --Narcian le Grand Rêvant 1 mars 2007 à 18:16 (CET)

2. Pas de section à affichage conditionnelle : les liens "modifier" qui sont après une section masquée ne fonctionnent plus correctement (cf Démo Annexes)

Une règle fortement recommandée

1. Pas de recours à un modèle de type {{Modifier}}

->Attention, il vaut mieux laisser des {{Modifier}} conditionnels, tout problématique qu'ils puissent être, car d'autre __NOEDITSECTION__ pourraient avoir été appelé d'une manière ou d'une autre sur la page d'article. Même si cette situation est à éviter le plus possible.--Ygonaar 1 mars 2007 à 21:50 (CET).

Ca va être coton de laisser une structure conditionnelle activable/désactivable après coup, surtout qu'à ma connaissance il n'y a pas moyen de détecter la présence d'un __NOEDITSECTION__ sur la page finale. Dans l'immédiat je vais faire un code qui utilise systématiquement le modèle {{Modifier}}. On vera après coup comment faire pour rendre l'appel conditionnel et facilement switchable après-coup.

--Narcian le Grand Rêvant 2 mars 2007 à 10:53 (CET)

• Si les modèles à deux niveaux avec substitution seront assez complexe pour l'éditeur profane, leur utilisation se limitera toujours à renseigner une liste de champs. Ça doit être largement utilisable si l'on est pas trop feignant sur les notices.

Le modèle crédits actuel n'est ni à deux niveaux, ni à substitution, pourtant il est extrêment difficile à prendre en main. Donc avec l'exemple de code à copier-coller qui va bien, il n'y a plus de soucis de prise en main par un profane, quelque soit la technique de codage utilisée (cette dernière pouvant restée inconnue du profane) --Narcian le Grand Rêvant 1 mars 2007 à 18:16 (CET)

• La principale difficulté reste l'éventuelle substitution retardée, dont la structure pourra certainement être recopiée d'un précédent modèle. La deuxième difficulté sera peut être que la procédure de test d'une section conditionnelle reste à jour, mais le cas devrait être rarissime.

La deuxième difficulté que tu souligne est due au fait que du désaccouple l'affichage du titre d'une section de l'affichage de sont corps, mais je pense qu'en testant si le corps renvoie des caractères ({{#if:{{corps-sous-modèle}}|affichage titre sous section| }}) on doit pouvoir s'extraire de cette difficulté (je viens juste d'avoir cette fulgurance :-)) --Narcian le Grand Rêvant 1 mars 2007 à 18:16 (CET)

Il est a noter que si l'on veux n'avoir qu'un seul appel au sous-modèle, il faut installer l'extension suivante : http://meta.wikimedia.org/wiki/VariablesExtension qui permet de stockée le résultat d'une expression (et je l'espère de l'appel à un modèle) dans une véritable variable locale à la page. Encore du boulot pour Xyloinaha

--Narcian le Grand Rêvant 2 mars 2007 à 10:53 (CET)

Donc je te suggère de nous faire une proposition de code, à ta charge de décider (et de nous convaincre par la suite) quel type de substitution tu préfères, qui servira probablement de référence pour les autres modèles. Tu peux user à ta guise de mon bac à sable si tu veux. Préviens juste moi quand je pourrai à nouveau y mettre mon nez sans casser tes travaux (ou pour me dire que je pousse un peu trop mémé dans les orties).

Amitiés. --Ygonaar 1 mars 2007 à 17:24 (CET)

Voici mon planning :

1. D'ici la fin de semaine je fait du hacking du code de ton bac-à-sable et je rappatrie le tout sur ma clé USB.

   Code hacké. Tu peux continuer à faire des essais sur ton bac-à-sable. --Narcian le Grand Rêvant 1 mars 2007 à 19:03 (CET)

   Pas de problème avec ma Glace Noire? C'est qu'il est précieux, mon bac à sable... --Ygonaar 1 mars 2007 à 21:50 (CET)

2. Ce WE je prépare les différents modèles de démonstration.

   modèles constituants + première ébauche du modèle "Annexes" faits. --Narcian le Grand Rêvant 5 mars 2007 à 15:37 (CET)

3. Lundi prochain je test et j'implémente les différents éléments.

   Tests terminés : Première ébauche non satisfaisante voir modification (plus haut dans cette section) de la partie "Règles impératives" --Narcian le Grand Rêvant 5 mars 2007 à 15:37 (CET)

4. Dès que j'obtiens satisfaction je te le signal.

   Tu dispose d'une première ébauche ici : {{Test}}. Elle est à ta disposition pour encore 2 à 3 jours (selon les termes d'usages en vigueur de ce modèle). J'attends tout retour constructif au sujet de cette ébauche.

   Cordialement --Narcian le Grand Rêvant 5 mars 2007 à 15:37 (CET)

--Narcian le Grand Rêvant 1 mars 2007 à 18:16 (CET)

Répondu

Discussion_Utilisateur:Xiloynaha#Phase_de_vote_pour_le_logo

Logo et manipulations depuis un format non vectoriel

A propos de tes problèmes de conversion des logos depuis ppt vers un format d'image vectoriel (par exemple svg), voici quelques pistes pour résoudre ton problème.

Depuis un fichier powerpoint, tu peux essayer de le lire avec le logiciel Open Office. Il devrait être possible de générer ainsi un fichier svg.

Pour les autres formats d'image (tif, jpg, gif, png,...) non vectoriels, il est possible de les transformer en eps. Cela ne sera pas du vrai vectoriel, mais il existe des convertisseurs eps vers svg.

Sinon il faudrait reprendre le dessin sous un outil comme Illustrator, j'ai cru comprendre que l'équivalent en libre était Inkscape (du moins pour les fonctions nécessaire à ce projet). On doit pouvoir importer l'image originelle comme un calque, afin de pouvoir reprendre plus facilement le dessin.

--Just an Illusion 17 mars 2007 à 16:41 (CET)

Il y a plusieurs logiciels libres pour convertir une image bitmap en vectoriel. L'un d'eux est utilisé par Inkscape, et donne d'assez bons résultats, mais plus l'image est complexe (couleurs et formes), plus il y a de boulot pour la reprendre derrière. A part ça oui, Inkscape sait intégrer une image bitmap dans un SVG. --Xiloynaha 18 mars 2007 à 21:43 (CET)

Réponses externes

Répondu à Discussion Oniropædia:Le tambour/Logo#Mise au point sur le premier tour --Narcian le Grand Rêvant 18 avril 2007 à 09:39 (CEST)