Discussion modèle:Sigle

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

Âpre débat[modifier le code]

Acronym Finder ne me semble pas si intéressant que ça. Il est en anglais, il est moche et la moitié de la page est occupée par la publicité. Ripounet 1 août 2006 à 13:07 (CEST)[répondre]

+1, le lien est utile seulement pour les sigles anglophones. - phe 10 août 2006 à 21:41 (CEST)[répondre]

Retrait du lien[modifier le code]

Après cet apre débat et une consensualité ubuesque de 100%, j'ai retiré le lien parasite vers Acronym Finder Ripounet 17 mars 2007 à 02:22 (CET)[répondre]

Non. Ce lien est utile pour trouver les autres significations d'un sigle.
Si ça peut vous rassurer, je l'ai remplacé par un lien vers un site plus lisible, où il n'y a pas de pub. Pour l'anglais, je l'ai signalé clairement en ajoutant le modèle {{en}}.
Enfin je ne suis pas d'accord sur le fait qu'il soit utile seulement pour les sigles anglophones. En effet, on trouve sur ces 2 sites de nombreuses significations de sigles en français et dans d'autres langues que l'anglais. /845/17.03.2007/01:50 UTC/

Catégorie:Sigle[modifier le code]

Ce modèle ne devrait-il pas catégorifier automatiquement dans Catégorie:Sigle les pages qui le contiennent ? — Ċ ң т╒ η (♪ Jasons ! ♫) 6 juin 2007 à 22:57 (CEST)[répondre]

Restauration Acronym Finder[modifier le code]

J'ai restauré Acronym Finder pour la raison suivante :

Pour le sigle FOP, Acronym Finder indique le sigle français "Fédération Française des Producteurs d'Oléagineux et de Protéagineux (French)" alors qu'Acronym attic ne l'indique pas. Je suis donc porté à croire qu'acronym attic est mal documenté sur les sigles français.

Teofilo 4 septembre 2007 à 21:42 (CEST)[répondre]

Bonjour,

J'ai l'impression que ces deux familles de modèles — qui servent toutes deux à la navigation entre sigles et abréviations — viennent de deux initiatives indépendantes, la première version semble toutefois beaucoup plus utilisée.

Existe-t-il un consensus sur l'emploi de l'une ou l'autre version ou y aura-t-il une fusion de ces modèles ?

--Bub's [di·co] 26 janvier 2008 à 12:45 (CET)[répondre]

Non, aucun consensus. {{Sigle n lettres}} et {{Sigles n lettres}} sont désormais remplacés par {{Sigle}}. Pour SigleContenant & cie, je ne suis pas qualifié. --Esch. coli 4 mars 2008 à 01:43 (CET)[répondre]
Bonjour,
Sais tu si un bot va être dressé pour remplacer toutes les occurrences de "{{Sigle n lettres}}" et "{{Sigles n lettres}}" sur les centaines de pages où ils employés ou bien cela sera-t-il fait (ou pas) au fil de l'eau ?
Pour information une demande de suppression est en cours sur {{SigleContenu}}.
Cordialement, bonne continuation.
--Bub's [di·co] 4 mars 2008 à 07:29 (CET)[répondre]
J'ai fait une demande là-bas. --Esch. coli 4 mars 2008 à 14:05 (CET)[répondre]

Wikipédia n'ayant pas vocation à lister toutes les significations possibles d'un sigle...[modifier le code]

Pour mémoire, voir le Bistro. --Esch. coli 4 mars 2008 à 01:39 (CET)[répondre]

Bonjour,

L'utilisation de {{Sigle}} sur une page implique que la page concernée est considérée comme une page d'homonymie (car {{Sigle}} est listé dans Mediawiki:Disambiguationspage). Ce comportement est généralement souhaité (car la plupart des sigles sont des homonymies), mais pas dans tous les cas (comme par exemple, SIREN). Pour pouvoir gérer ces cas, j'ai créé {{Sigle sans homonymie}} qui reprend l'ancien code de {{Sigle}}. Pour éviter d'avoir à maintenir 2 versions, {{Sigle}} inclus {{Sigle sans homonymie}}. Le faire dans l'autre sens posait problème car l'inclusion de {{Sigle sans homonymie}} dans une page impliquait l'inclusion implicite de {{Sigle}}, ce qui transformait quand même la page en page d'homonymie. --NicoV (d) 17 août 2010 à 20:52 (CEST)[répondre]

Je ne pense pas que c'était la bonne solution. L'intégralité des articles en question possède le modèle {{Homonymie}} ou un de ces dérivés qui sont tous listés dans Mediawiki:Disambiguationspage. J'aurais plutôt délisté {{Sigle}} et {{Sigles}} de Mediawiki:Disambiguationspage). Cordialement - Drongou (d) 7 décembre 2010 à 23:03 (CET)[répondre]
Outcha, c'est ya longtemps... je passais par là et mon avis c'est que multiplier les concepts dans les noms de modèle n'aide pas vraiment à comprendre le merdier du wiki. Bref c'est très facile de poser deux bandeaux sigle et homonymie, mais pour ce rappeler du modèle magique qui fait qu'il y en a qu'un ou que l'autre ou pas l'autre mais l'un, c'est vraiment pas gagné. Après ça on rajoute un troisième concept transversal...
Simplement deux bandeaux, c'est vraiment bien. bayo 31 mai 2013 à 15:46 (CEST)[répondre]
Je suis d'accord, il aurait mieux valu séparer les concepts. A l'époque je ne savais pas si les nombreuses pages incluant {{Sigle}} incluaient aussi un bandeau d'homonymie, et j'ai pris la solution de simplicité pour corriger le problème. --NicoV (d) 31 mai 2013 à 19:57 (CEST)[répondre]
Pour info, voici la discussion avec Phe qui m'avait amené à créer ce modèle, et pourquoi il considérait que {{Sigle}} devait être listé dans Mediawiki:Disambiguationspage. --NicoV (d) 3 juin 2013 à 17:21 (CEST)[répondre]

lettres -> caractères[modifier le code]

Bonjour,

A mon avis ce serait bien de penser à modifier le modèle pour qu'il affiche « Sigle contenant 2 caractères » plutôt que « Sigle contenant 2 lettres ». Ya pas mal de sigles avec des chiffres et ça fait vraiment curieux sur leurs pages. Les catégories porte d'ailleurs bien leurs nom.

C'était juste comme ça en passant, a+ bayo 31 mai 2013 à 15:40 (CEST)[répondre]

Je me suis fait la même réflexion et j'ai renommé les listes concernées, mais il faudrait aussi changer le modèle...
Cymbella (discuter chez moi) - 13 juin 2015 à 22:41 (CEST)[répondre]

Évolution du modèle pour mettre en exception des espaces de nom[modifier le code]

Trop long ? lire seulement le gras
Salut LD. Je poursuis ici la discussion relative à ce modèle.

Préliminaire, dans ce qui suit, le nocat fait référence à l'actuel 2=nocat. Idée connexe : peut-être qu'on pourrait passer au paramètre optionnel nocat=oui qui semble plus courant dans l'encyclopédie. En réalité, ça importe peu puisqu'un hypothétique appel avec paramètre vide {{sigle||nocat}} devrait plutôt être remplacé par {{sigle}} que par {{sigle|nocat=oui}}, le second paramètre n'étant pas utilisé par le modèle dans ce cas. De plus, ce paramètre est très peu répandu/sollicité pour ce modèle : 30 fois à la valeur valide « nocat ».

Je te rejoins sur le fait qu'il n'y a pas de raison d'appliquer des "paramètres" nocat dans les brouillons. Pour décatégoriser ces pages, ce ne serait pas logique et on risquerait d'oublier de les retirer lors de la publication.

Pour la suite, tout dépend de ce ce que l'on veut catégoriser et ce que l'on appelle « appel incorrect ». D'ailleurs, la « catégorie:Modèle sigle utilisé incorrectement » pourrait être renommée en « catégorie:Page (ou Article) contenant un modèle sigle utilisé avec un (premier) paramètre incorrect » selon les choix que nous ferons (ci-dessous). Par exemple, il serait possible d'y catégoriser aussi les appels avec paramètre 2 ayant une valeur différente de « nocat ». Pour le titre, voir aussi ce qui se fait pour les catégories semblables.

Comportements possibles vis à vis des catégorisations

A. nocat et espace de nom prioritaires. Si on ne veut jamais catégoriser les pages hors de l'espace principal, même si elles ont un paramètre 1 erroné. Il suffit de rajouter le test sur l'espace de nom au même niveau que le nocat, en début de code. On peut faire d'une pierre deux coups avec l'astuce suivante dans laquelle le mot « Exception » est remplaçable par n'importe quel autre mot ou caractère non vide, même « 0 » si l'on veut.

{{#if:{{#ifeq: {{{2|}}} | nocat | Exception }}{{NAMESPACE}}
  |<!-- à faire si on a un nocat ou si on est hors de l'espace des articles -->
  |<!-- à faire si on est dans un article sans 2=nocat -->
}}

Dans notre cas

{{#if: {{{1|}}}
  | {{#if:{{#ifeq: {{{2|}}} | nocat | Exception }}{{NAMESPACE}}
      | <!--pas de catégorisation-->
      | {{#switch: {{#ifexpr: {{{1}}} > 9 | 9 | {{{1}}} }}
          |2|3|4|5|6|7|8=[[Catégorie:Sigle de {{{1}}} caractères]]
          |9={{#ifexpr: ceil({{{1}}})={{{1}}}|[[Catégorie:Sigle de 9 caractères ou plus]]|[[Catégorie:Modèle sigle utilisé incorrectement]]}}
          |#default=[[Catégorie:Modèle sigle utilisé incorrectement]]<!--tous les autres cas-->
        }}
    }}
}}

Par rapport au code existant, j'ai juste simplifié un peu (regroupé) les cas principaux et ajouté un test de validité du paramètre pour le cas des nombres supérieurs à 9 mais non-entiers.

Notons qu'avec ce choix, l'usage du nocat en dehors des articles serait superflu.

B. nocat prioritaire puis erreur de premier paramètre prioritaire sur le type d'espace. Si on veut que le nocat empêche toute catégorisation mais qu'en son absence les erreurs de paramètre 1 soient détectées quel que soit l'espace de nom : on garde le | {{#ifeq: {{{2|}}} | nocat au début et on met des tests sur l'espace de nom pour chacune des catégorisations.

Par exemple :

{{#if: {{{1|}}}
  | {{#ifeq: {{{2|}}} | nocat
      | <!--pas de catégorisation-->
      | {{#switch: {{#ifexpr: {{{1}}} > 9 | 9 | {{{1}}} }}
          |2|3|4|5|6|7|8={{#if:{{NAMESPACE}}||[[Catégorie:Sigle de {{{1}}} caractères]]}}
          |9={{#ifexpr: ceil({{{1}}})={{{1}}}|{{#if:{{NAMESPACE}}||[[Catégorie:Sigle de 9 caractères ou plus]]}}|[[Catégorie:Modèle sigle utilisé incorrectement]]}}
          |#default=[[Catégorie:Modèle sigle utilisé incorrectement]]<!--tous les autres cas-->
        }}
    }}
}}

C. Erreur de paramètre 1 prioritaire sur le nocat et sur l'espace de nom. Si on veut que toute erreur sur le paramètre 1 soit détectée même en présence d'un nocat, on optera pour quelque chose du genre :

{{#if: {{{1|}}}
	| {{#switch: {{#ifexpr: {{{1}}} > 9 | 9 | {{{1}}} }}
		|2|3|4|5|6|7|8=
			{{#if:{{#ifeq: {{{2|}}} | nocat| Exception }}{{NAMESPACE}}<!-- Cette valeur dans le #if est vide si on est à la fois dans l'espace principal et sans 2=nocat -->
				|<!--pas de catégorisation. hors de l'espace principal ou nocat.-->
				|[[Catégorie:Sigle de {{{1}}} caractères]]
			}}
		|9=
			{{#ifexpr: ceil({{{1}}})={{{1}}}<!--on teste si le paramètre 1 est un entier ou non. A priori jamais de message d'erreur car on sait déjà d'après le premier switch qu'on a un nombre. -->
				|{{#if:{{#ifeq: {{{2|}}} | nocat| Exception }}{{NAMESPACE}}!-- idem cas précédent -->
					| <!--pas de catégorisation. entier valide mais page hors de l'espace principal ou nocat..-->
					|[[Catégorie:Sigle de 9 caractères ou plus]]}}
				|[[Catégorie:Modèle sigle utilisé incorrectement]]<!--pas entier -->
			}}
      |#default=[[Catégorie:Modèle sigle utilisé incorrectement]]<!--tous les autres cas-->
    }}
}}

La question est donc : quel comportement choisissons-nous ? Notification FDo64, Od1n, Milyon et Herr Satz.

pour moi, B, sans conviction. — Ideawipik (discuter) 27 septembre 2022 à 22:40 (CEST)[répondre]

Pistes pour améliorer les performances[modifier le code]

1. Pour éviter au programme d'effectuer un appel de #ifexpr (fonction plus coûteuse qu'un #if) à chaque fois y compris quand le paramètre est un simple entier inclus dans l'intervalle [2, 8], on peut essayer de repousser le traitement des cas particuliers quitte à ce que l'exécution soit légèrement plus complexe dans ce cas extrêmement rares. Avec le choix C décrit plus haut, le code pourrait être ceci :

{{#switch: {{{1|}}}
	|=<!--paramètre vide rien à faire-->
	|2|3|4|5|6|7|8=
		{{#if:{{#ifeq: {{{2|}}} | nocat | Exception }}{{NAMESPACE}}
			|<!--hors de l'espace principal : pas de catégorisation-->
			|[[Catégorie:Sigle de {{{1}}} caractères]]
		}}
	|9=[[Catégorie:Sigle de 9 caractères ou plus]]
		{{#if:{{#ifeq: {{{2|}}} | nocat | Exception }}{{NAMESPACE}}
			|<!--hors de l'espace principal : pas de catégorisation-->
			|[[Catégorie:Sigle de 9 caractères ou plus]]
		}}
	|#default=
		{{#switch: {{#ifexpr: ceil({{{1}}})={{{1}}}|vrai|faux}}
			|vrai=
				{{#ifexpr: {{{1}}} > 9
					| {{#if:{{#ifeq: {{{2|}}} | nocat | Exception }}{{NAMESPACE}}
						|<!--hors de l'espace principal : pas de catégorisation-->
						|[[Catégorie:Sigle de 9 caractères ou plus]]
					  }}
					|[[Catégorie:Modèle sigle utilisé incorrectement]]
				}}
			|#default=[[Catégorie:Modèle sigle utilisé incorrectement]]<!--tous les autres cas-->
		}}
}}

Remarque mineure, on pourrait même regrouper les cas 2 à 9 avec un [[Catégorie:Sigle de {{{1}}} caractère{{#ifeq:{{{1}}}|9|s ou plus|s}}]] mais je ne pense pas que cela en vaille le coup.

2. Méthode basique : considérer qu'il n'y a pas de sigle de plus de quinze caractères (pour l'instant, on a au maximum onze caractères et pour seulement un cas dans l'encyclopédie).

À la présence de tests nocat près, on écrit

{{#switch: {{{1|}}}
	|=<!--paramètre vide rien à faire-->
	|2|3|4|5|6|7|8=[[Catégorie:Sigle de {{{1}}} caractères]]
	|9|10|11|12|13|14|15=[[Catégorie:Sigle de 9 caractères ou plus]]
	|#default=[[Catégorie:Modèle sigle utilisé incorrectement]]
}}

Et si par hasard on avait un jour un article catégorisé pour une valeur entière N supérieure, il suffirait de rajouter cette valeur particulière dans le switch du modèle.

3. Sur la partie génération du tableau, on pourrait économiser des switch répétés sept fois à l'identique en dupliquant une seule fois le code du tableau dans un seul switch à deux cas. À voir…

4. Bénéfice d'un passage en Lua ? — Ideawipik (discuter) 27 septembre 2022 à 22:40 (CEST)[répondre]

Bonsoir Ideawipik Émoticône.
Désolé, je n'ai pas tout lu et je ne comprends donc pas bien l'objectif recherché.
Néanmoins j'ai corrigé tous les cas d'erreurs : paramètres 1 & 2 vides ou incorrects.
De ce que je comprends, on devrait pouvoir se passer du switch et se contenter de mettre :
{{#if: {{{1|}}}|{{#ifexpr: {{{1}}} > 8|[[Catégorie:Sigle de 9 caractères ou plus]]|[[Catégorie:Sigle de {{{1}}} caractères]]}}}}
Et pour le nocat, je préfère un paramètre nommé, comme cela se fait d'habitude.
--FDo64 (discuter) 28 septembre 2022 à 00:18 (CEST)[répondre]
TL;DR. Il y a assez peu d'utilisations erronées (possibles, et effectives) de ce modèle, mieux vaut clairement (àmha) privilégier la simplicité de code que des codes de vérifications complexes et qui n'ajoutent finalement pas grande utilité. Du moment que l'outil wstat.fr permet de faire le ménage pour ceux qui le souhaitent. Il y a bien d'autres modèles largement plus "contaminés" par des utilisations erronées (et là encore, où l'outil wstat.fr devrait permettre de faire un coup de ménage avant de réfléchir à des catégorisations etc dans le modèle même). od†n ↗blah 28 septembre 2022 à 07:54 (CEST)[répondre]
Bonjour FDo64. L'objectif était de combiner deux exigences de catégorisation, la première étant déjà intégrée au modèle, bien qu'améliorable.
Raison 1 : détection des erreurs de paramètre qui entraîneraient un résultat inopportun, comme des catégorisations automatiques incohérentes ou incorrectes. En pratique, si on était sûr qu'aucun contributeur ne mettra autre chose qu'une valeur valide ta proposition suffirait. Mais tu connais la fréquence des erreurs en tout genre.
Avec ton code,
  • tout nombre supérieur à 8, par exemple 12.84, donnerait « Catégorie:Sigle de 9 caractères ou plus ». Pas très naturel mais pourquoi pas ? C'est déjà le cas maintenant.
  • tout nombre inférieur à 8 mais différent de 2, 3…, 7 ou 8 alimenterait une catégorie inexistante (exemple : Sigle de 1 caractères, Sigle de -7.64 caractères) soit un lien rouge en bas d'article. En admettant que quelqu'un s'aperçoive de l'erreur, il ne détecterait pas facilement son origine sauf s'il connaît le modèle dont on parle, alors qu'une catégorie de maintenance indiquant une erreur dans l'utilisation de tel ou tel modèle dirige vers la page de documentation dudit modèle facilitant la correction de l'erreur.
  • toute chaîne qui ne serait pas un nombre générerait dans la page un message d'erreur peu compréhensible pour le premier venu. Quoique… « Erreur d’expression : « mot » non reconnu. », ça va encore.
Raison 2 : les catégorisations automatiques par le modèle ne sont pas souhaitées partout. À cela s'ajoute la question relative à la distinction entre espace principal et autres espaces de nom pour les catégorisations, question initiée par LD qui a relevé la présence indue de quelques pages utilisateur parmi des catégories de l'espace encyclopédique. Par exemple, la page Utilisateur:Wizar44/Brouillon est ajoutée par le modèle dans « Catégorie:Sigle de 4 caractères ». Or l'usage d'un nocat, idéal pour mettre en exception un appel en page d'aide ou dans une documentation de modèle et occasionnellement dans un article, ne nous semble pas la meilleure option pour mettre en exception des pages de type de brouillon susceptibles d'être publiées en tant qu'articles. Il ne serait pas non plus correct de catégoriser la page de brouillon dans Catégorie:Modèle sigle utilisé incorrectement au simple motif que le modèle y est présent, ni d'interdire l'usage du modèle sur de telles pages.
Bilan. La prise en compte des catégorisations automatiques a été déclinée pour ce modèle en trois propositions (A, B, C) supra, selon le comportement souhaité, i.e. selon les critères que l'on veut rendre prépondérants entre la présence d'un nocat, l'espace de nom et une erreur sur la valeur du paramètre. À nous de choisir. — Ideawipik (discuter) 29 septembre 2022 à 23:34 (CEST)[répondre]