Aller au contenu

Discussion modèle:Table des caractères Unicode/LigneDébut

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Ceci est une version archivée de cette page, en date du 5 mai 2020 à 22:53 et modifiée en dernier par Orlodrim (discuter | contributions). Elle peut contenir des erreurs, des inexactitudes ou des contenus vandalisés non présents dans la version actuelle.

Dernier commentaire : il y a 5 ans par Orlodrim dans le sujet Question de syntaxe et paramètre « styles »
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

Question de syntaxe et paramètre « styles »

Bonjour Verdy p. À quoi correspond le paramètre styles de ce modèle ?

  • Il est actuellement inutilisé dans l'encyclopédie. Cf statistiques. Il y aurait d'ailleurs une utilisation du paramètre inexistant polices à corriger.
  • Je ne suis pas sûr du bon fonctionnement des balises <noinclude> dans les balises <includeonly>. Il me semble que {{{styles|<noinclude>1</noinclude>}}} est, dans ce cas équivalent, à {{{styles|}}}.

Cordialement. --Ideawipik (discuter) 5 mai 2020 à 16:43 (CEST)Répondre

Pas du tout. Ce n'est équivalent QUE lors de l'inclusion dans une autre page, mais ici c'est un code qui sert à la page du modèle lui-même, et très utile pour la prévisualisation de toute modification (les balises "includeonly" sont maintenant mal vues car on ne teste pas directement ce qu'on modifie): l'affichage devrait être présent dans la page du modèle elle-même pour fournir une prévisualisation correcte. Mais ici il sert en plus à contrôler si on doit inclure la feuille de styles et quand on doit le faire (pas à chaque caractère, sinon on explose la taille d'expansion). Le but ayant été de réduire considérablement la taille du code à parser en éliminant le plus possible d'attributs, afin que la page complète de tout un plan s'affiche correctement (y compris lorsqu'on détaille les tables avec plus d'infos comme les noms de caractères).
D'autre part le paramètre "polices" est bel et bien utilisé ! (il sert pour certaines écritures quand les polices par défaut des navigateurs sont trop défectives afin d'ajouter des polices plus complètes aux polices par défaut et les utiliser si possible ; on en a des exemples dans plusieurs boites). Si quelqu'un a viré ce paramètre il a eu tord et n'a rien compris, ni rien demandé !
Même chose pour le paramètre styles qu'il FAUT garder (on sent que quelq'une trop zélé n'a rien cherché et rien regardé). Verdy p (discuter) 5 mai 2020 à 18:54 (CEST)Répondre
L'outil que tu utilises en plus se plante: le paramètre "polices" est bien détecté comme utilisé dans une page (il 'était dans bien plus avant), mais PAS dans l'appel de "/LigneDébut" mais dans celui de "/Début" en tête de table uniquement. Cet outil se trompe entre les modèles utilisés ! Verdy p (discuter) 5 mai 2020 à 19:04 (CEST)Répondre
Fais très attention à des modifs: ces modèles ont des besoins très stricts et économisent au maximum le code. Tout ajout ou suppression malencontruese peut à nouveau faire exploser les pages qui les incluent (notamment ça se voit tout de suite sur la page du plan multilingue de base qui affiche sur la même page wiki les tables pour les 65536 positions de ce plan, qui est le plus complexe et le plus lourd). Verdy p (discuter) 5 mai 2020 à 19:22 (CEST)Répondre
Ces modèles ont déjà été cassés à plusieurs reprises, dans d'autres cas j'ai fait de la maintenance quand j'ai constaté que des pages débordaient avec des ajouts plus récents. La dernière gosse maintenance a été justement d'optimiser les styles avec le paramètre que tu ne comprend pas, en utilisant la fonctionnalité des feuilles de style par modèle ajouté à MediaWiki qui a été décisive et réduit considérablement la taille du code généré, mais avec des test compliqués pour savoir quand inclure ou pas la feuille de style: elle n'a besoin d'être incluse qu'une seule fois dans toute la page; on peut l'inclure plusieurs fois, mais c'est coûteux lors de l'expansion, puis seulement Mediawiki peut éliminer les doublons; malheureusement MediaWiki n'élimine pas ces doublons lors de l'expansion en raison de la façon dont fonctionne les caches d'expansion des modèles: il duplique chaque expansion telle quelle, le nettoyage des doublons de styles se faisant seulement à la fin). Pour éviter ce problème, le paramètre "styles" indique là où peut se faire l'inclusion de la feuille (en principe en tête de table avec une valeur par défaut à 1, mais dans une page incluant une table avec d'autres, on peut vider ce paramètre pour ne le garder à 1 que dans une seule des tables affichées: la feuille de styles est la même pour toutes les tables). Verdy p (discuter) 5 mai 2020 à 19:48 (CEST)Répondre
Ce paramètre polices sert surtout pour les blocs Unicode contenant plusieurs écritures très différentes mais pourtant à affiche dans une seule table (la division des écritures dans ces blocs se fait au niveau des "colonnes Unicode" de 16 caractères et non du bloc de codes alloué). Il est très peu utilisé (car la plupart des blocs Unicode sont homogènes sauf quelques uns dans le plan 0 qui a hérité d'anciennes pratiques issues de la fusion des travaux initiaux d'Unicode et de l'ISO dans la version 1.1 qui a rendu les versions antérieures incompatibles entre elles et avec la version unifiée), ce qui ne veut pas dire qu'il ne sert à rien. Depuis la version 1.1, Unicode et l'ISO dispose d'une "roadmap" pour éviter de tels cas et de mélanger les blocs entre eux, et de règles plus précises pour les allocations (ce qui facilite aussi le travail des typographes pour les polices, et celui des développeurs pour les tables de données d'internationalisation des logiciels avec un traitement plus efficace car pouvant être optimisé). Mais les blocs alloués le sont définitivement avec leurs limites et doivent conserver leur homogénéité (même si on les complète ensuite en bouchant des trous avec des caractères de même écriture, et en respectant certains trous conservés pour des raisons historiques ou parce que ce sont des positions pour des caractères toujours en discussion et pas forcément unifiés définitivement avec d'autres alloués ailleurs). Verdy p (discuter) 5 mai 2020 à 19:36 (CEST)Répondre
Re-Bonjour Verdy p. J'ai l'impression que la première réponse était un peu précipitée. Mais je te remercie pour le développement et l'explication du contexte.
  1. Nous n'avons pas la même interprétation des balises noinclude, includeonly et onlyinclude, mais je peux me tromper et ne demande qu'à apprendre. C'est pour cela que je ne comprends pas à quoi servent, dans le présent modèle, les balises <noinclude> (Quelle est la valeur par défaut passée au paramètre styles ?). Mais, j'ai bien compris le fonctionnement technique du paramètre styles quand ce dernier est non vide et faisais juste remarquer qu'il n'était pas utilisé dans les articles ou modèles au , sans mettre en cause son utilité générale potentielle.
  2. Il n'a jamais été dit que les paramètres « styles » ou « polices » étaient inutiles ou inexistants partout. Le paramètre polices existe bien dans le code de {{Table des caractères Unicode/Début}} mais n'existait pas dans celui de {{Table des caractères Unicode/LigneDébut}} avant ton ajout en réaction à ce message ; c'était donc bien un paramètre inexistant et sans effet dans ce (sous-)modèle précis, avant cette modification.
  3. Si cela te rassure, je ne me serais pas permis de modifier des éléments que je ne comprends pas.
Si un contributeur, toi ou quelqu'un d'autre, a la patience de m'expliquer la question des balises imbriquées, j'apprécierai beaucoup. Orlodrim ou FDo64, peut-être ? Merci d'avance. --Ideawipik (discuter) 5 mai 2020 à 21:10 (CEST)Répondre
Tout ce que tu mets dans les balises "noinclude" n'a aucune influence sur ce qui sera utilisé comme valeur par défaut quand le modèle sera inclus dans une autre page; cela ne concerne QUE le rendu de la page du modèle lui-même (et uniquement cette page). Et là on on en met, cela sert justement à préciser une valeur qui, par défaut, ne serait même pas précisée (alors que l'utilisation normale du modèle impose de mettre une valeur appropriée): c'est donc un outil de test instantané. On peut librement mettre les valeurs qu'on veut (et le changer n'importe quand pour tester autre chose sans que cela change quoi que ce soit au comportement du modèle là où il est inclus).
Et tout bon modèle devrait être immédiatement testable avec un exemple de rendu correct immédiat pour ce qu'on veut tester (cela n'empêche pas de développer d'autres tests avec des valeurs différentes ou aucune valeur, soit dans la sous-page de doc, soit dans une autre page dédiée liée depuis la page de doc).
C'est pour ça que je trouve que les balises "includeonly" ou leur variante "onlyinclude" (qui masquent le rendu immédiat du modèle) sont inutiles, voire nuisibles dans les modèles à transclure (elles ne sont utiles que pour la catégorisation des modèles et qu'on place dans leur sous-page de doc): on peut toujours d'en passer, afin que le rendu soit correct lors de la prévisualisation de chaque modification, sans passer par un cycle de modification-tests-erreurs-correction...
Autant que possible ce qu'on va mettre dans les "noinclude" devrait permettre de tester immédiatement ce qu'on est en train de modifier: on peut le changer plusieurs fois dans une suite de prévisualisation pour tester différentes parties ou conditions, sans avoir à enregistrer ces tests instantanés. On ne gardera dans les "noinclude" (qui peut n'être que des chaines de remplissage ou des valeurs numériques qui conviennent à l'évaluation des #expr ou des #ifexpr) que les tests les plus significatifs qui affichent la plus grande partie des cas traités.
De même pour le cas où un modèle autocatégorise la page qui l'inclut (y compris les catégories de suivi d'erreurs), on n'est pas obligé du tout de mettre ces catégorisations dans une section "includeonly", il suffit souvent de laisser la catégorisation s'afficher comme si c'était du texte, par exemple en insérant un "&lrm;" (dans une balise "noinclude" entre les deux crochets ouvrants) et en remplaçant la barre "|" par un {{!}} avant la clé de tri (pour éviter que cette barre casse l'analyse des paramètres d'un appel englobant de modèle ou de fonction, ou l'analyse de la syntaxe des cellules de tableau).
Verdy p (discuter) 5 mai 2020 à 22:08 (CEST)Répondre
Merci. Je comprends toutes tes remarques générales concernant l'affichage, qui peut effectivement être utile, du rendu du modèle dans la page du modèle. Quant à l'intérêt de l'usage des includeonly, je pense que tout dépend des cas, les modèles s'y prêtant plus ou moins. Mais dans le cas présent :
  • Le paramètre par défaut n'est pas utilisé dans les articles (à cause du noinclude) et pas non plus dans la page du modèle (à cause du includeonly) Euh ? ;
  • Indépendamment de cela, le test d'affichage pourrait-être fait via la Documentation, incluse dans la page du modèle ;
  • Les tests de rendu lors de modifications peuvent être fait en utilisant la fonctionnalité de prévisualisation : « Aperçu de la page avec ce modèle ».
--Ideawipik (discuter) 5 mai 2020 à 22:39 (CEST)Répondre
Bonsoir, les échanges qui précèdent me semblent bien mystérieux :
  • Notification Verdy p : Tu es le seul à intervenir sur ce modèle (à part 3 corrections mineures) donc si un paramètre a disparu, c'est de ton fait.
  • Notification Ideawipik : Il me semble également que les balises <noinclude> dans des balises <includeonly> sont sans effet.
--FDo64 (discuter) 5 mai 2020 à 22:48 (CEST)Répondre
Ce que Verdy p semble vouloir dire, c'est qu'il enlève les balises includeonly quand il édite le modèle. Mais je ne suis pas sûr d'avoir bien compris, ou si c'est bien ça, je ne vois pas l'intérêt pour ce modèle précis : en effet, ce modèle utilisé seul n'affiche rien d'utile. À l'inverse, les inclusions présentes dans la page de documentation permettent de tester les changements en prévisualisation même sans enlever les balises includeonly.
Je serais également intéressé de savoir dans quelle page le paramètre styles est utilisé. Mon site n'en montre pas, mais il peut effectivement être incomplet, dans la mesure où il repose sur une analyse statique. Des constructions complexes (module ou appel d'un modèle dont le nom dépend d'une variable par exemple) peuvent donc le mettre en défaut. Ou des bugs, tout simplement.
Orlodrim (discuter) 5 mai 2020 à 22:53 (CEST)Répondre