Discussion module:Langue

Utilisation depuis un autre module

Bonjour, ce serait bien d'avoir la possibilité d'utiliser la fonction lang depuis un autre module. Je pense en particulier au type de données "monolingualtext" de Wikidata qui fournit une chaîne accompagnée d'un code de language (voir d:Property:P1448). Mais ce n'est très pratique de passer par les fonction "frame". Il y aurait un moyen de faire ça ? --Zolo (discuter) 29 septembre 2014 à 15:14 (CEST)

 Zolo : toutes les fonctions sont déjà prévues pour être faciles à appeler depuis un autre module. Les fonctions qui n'ont besoin que d'un seul paramètre peuvent être appelées en passant directement ce paramètre :

Lange.codeLangue( 'anglais' ) → 'en'

Les autres en passant une table avec les paramètres demandés (possible aussi pour les fonctions avec un seul paramètre) :

Lange.langue{ 'en', 'mon texte' } → '<span class="lang-en" lang="en">mon texte</span>'

Et bien sur les chaines de ces exemples peuvent être remplacées par des variables.

Zebulon84 (discuter) 29 septembre 2014 à 16:24 (CEST)

Ok merci effectiement ça fonction.

Par contre juste pour info la notif n'a pas fontionné (je crois que ça ne marche que si on ajoute la signature dans la même édit) :). --Zolo (discuter) 29 septembre 2014 à 17:03 (CEST)

J'avais remplacé la signature précédente par une nouvelle, mais ce n'est sans doute pas suffisant, ou alors il faut absolument laisser un espace entre les deux points en la signature. J’essaierai de faire mieux la prochaine fois. -- Zebulon84 (discuter) 29 septembre 2014 à 17:08 (CEST)

Refactoring

J'ai extrait le code

	html:tag( 'span' )
			:addClass( 'indicateur-langue' )
			:wikitext( '(' )
			:tag( 'abbr' )
				:addClass( 'abbr' )
				:attr( 'title', 'Langue : ' .. nomLangue )
				:wikitext( code )
				:done()
			:wikitext( ')' )
			:done()
		:wikitext( texte )

pour le mettre dans Module:Indication (pour pouvoir l'utiliser dans {{Lien Wikidata}} et Module:Lien Wikidata. On peux donc l'utiliser ici aussi ... — TomT0m ^[bla] 12 août 2015 à 18:48 (CEST)

Je note que cette partie devrait être située en dehors du span de langue principale, après lui et non dedans à la fin. Cela donne un rendu inapproprié notamment pour le Maldivien avec des polices latins italiques mais dans le style de la police pour le maldivien (code langue non suffixé par "-Latn") qui éalement ne supporte souvent pas tous les caractères latins étendus nécessaires. De plus en le gardant dedant, cette partie s'ordonne après le texte dans la langue étrangère, qui peut être dans une écriture de droite à gauche, ce qui est incorrect.

Placer ce code après le span principal sera bien meilleur, c'est en fait une indication bien séparée du segment de texte en langue étrangère, et qui se met en forme dans le style et l'ordre de la langue principale (le plus souvent le français sur ce wiki).

On en voit l'effet incorrect sur la page ISO 3166-1 à l'entrée des Maldives (avec le nom écrit en divéhi), ou celle du Maroc (avec le nom écrit en tifinagh), ou celles du Japon, de la Corée du Nord ou du Sud, de la Chine, de Taiwan et Singapour (avec les noms écrits en sinogrammes ou kanas : les caractère latins sont en chasse fixe et de taille plus grande), de l'Arménie ou de la Géorgie (écrits en arménien ou géorgien), des pays arabophones et d'Israel (écrits en abjad arabe ou abjad hébreu : mauvais ordonnancement, effet incorrect sur certaines ponctuations), ou du Cambodge (écrit en khmer: caractères latins incomplets dans nombre de polices d'écrure khmer),

Cette translittération étant mieux dans le contexte de lecture où l'indication est destinée et non dans le contexte local de l'inclusion en langue et écriture étrangère, d'autant plus que bien souvent cette transliération est utilisée telle quelle en français (comme le montre l'exemple ici des exonymes romanisés : la romanisation est en fait rarement celle exactement utilisée localement pour la langue étrangère mais revue en fonction de la langue cible à écriture latine). Verdy p (discuter) 21 janvier 2018 à 16:09 (CET)

Verdy p (discuter) 21 janvier 2018 à 16:09 (CET)

Ajout d'une fonction pour obtenir l'article de la langue à partir du code

Bonjour,
J'ai ajouté une fonction pour obtenir l'article traitant d'une langue à partir du code de ladite langue dans le bac à sable (fonction articleLangue tout en bas). Est-ce que quelqu'un peut vérifier si tout semble en ordre ? En effet, je n'ai aucune expérience en Lua, donc je voudrais m'assurer qu'il n'y a pas de problème avant de modifier le modèle.
Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 24 janvier 2019 à 21:06 (CET)

En l'absence d'opposition, j'ai intégré la fonction au module.

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 22 février 2019 à 07:38 (CET)

Nom de la langue sans mise en forme ?

Bonjour, la méthode nomLangue() est trompeuse, car elle ne retourne pas juste le nom de la langue, mais un wikilien vers l’article de la langue concernée. Est-ce qu'il y a une fonction qui ne retournerait que le nom de la langue, sans mise en forme ? Le besoin est par exemple pour {{Élément par titre}} qui utilise cette méthode dans un lien externe (et donc problème de mise en forme visible sur le premier exemple + détection dans Spécial:LintErrors/wikilink-in-extlink). --NicoV (discuter) 22 mars 2019 à 16:37 (CET)

Au cas où, je ping les principaux contributeurs du module dans les derniers temps…  Epok, Zebulon84 et Od1n : --NicoV (discuter) 22 mars 2019 à 16:39 (CET)

Bonjour  NicoV,

Effectivement, la fonction "nomLangue" devrait plutôt s'appeler "wikilienArticleLangue" ou "lienArticleLangue" pour être exacte. À ma connaissance, il n'y a pas de fonction retournant simplement le nom de la langue. Il est possible de la créer si besoin, à mon avis elle sera toujours utile...

J'ai récemment créé la fonction "articleLangue", je peux si besoin créer une fonction faisant le même boulot pour le nom, mais à moins de modifier le nom de la fonction actuelle (et donc de refactoriser tous les modèles qui l'utilisent), il faudra trouver un autre nom. "nomLangue2" ? À débattre avec les autres contributeurs du modèle.

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 22 mars 2019 à 17:15 (CET)

Ajout : il existe le modèle {{Langname}} qui fait ce boulot, mais sur une liste bien plus réduite codée en dur. Il serait je pense intéressant d'intégrer la fonction à ce module et de modifier le modèle en question pour utiliser le module. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 22 mars 2019 à 17:18 (CET)

Merci Epok__. Je suis intéressé par le fait que la fonction soit créée (semble simple, juste copier/coller nomLangue() et enlever la mise en forme…). Pour le nom, quelque chose de plus parlant peut-être, genre "nomLangueBrut" ou "nomLangueSansFormattage"… --NicoV (discuter) 22 mars 2019 à 17:19 (CET)

Ça me semble effectivement la meilleure chose à faire. Je pense qu'il faut tout de même attendre un (éventuel) retour des autres contributeurs au modèle avant de procéder (à moins que tu ne souhaites le faire toi-même). Je notifie également  SyntaxTerror qui a beaucoup contribué à la bdd des langues. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 22 mars 2019 à 17:23 (CET)

 NicoV et Epok : mes connaissance en lua ne sont pas suffisantes, mais pour avoir le nom de langue, il faut utiliser le paramètre qui sert à afficher le nom de langue au survol du modèle {{mul}} (ça doit être « langue() » pas « nomLangue() »).

Par ex. {{mul|en}} donne : (en)

Dans module:Langue/Data, c'est le 1er paramètre (qui est éventuellement secondé par un paramètre « page » si le nom de l'article diffère du nom de la langue. (par ex. aa = { "afar", page = "Afar (langue)" },).

Sinon, Zebulon84 ne me semble plus contribuer depuis Noël passé. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 mars 2019 à 18:08 (CET)

 SyntaxTerror : Le modèle {{mul}} utilise la fonction "indicationMultilingue" de ce module. De ce que j'en comprend, il s'agit d'un "popup" surgissant au passage de la souris, ce qui est bien plus complexe que ce que l'on souhaite faire ici (retourner simplement le nom de la langue). Je vais proposer la fonction souhaitée dans le bac à sable du modèle en attendant.

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 22 mars 2019 à 18:13 (CET)

Ce dont je parle à propos du modèle mul, c'est du nom de langue (càd pas le nom d'article) utilisé dans le popup, pas du popup lui-même. Şÿℵדαχ₮ɘɼɾ๏ʁ 22 mars 2019 à 21:16 (CET)

 NicoV et SyntaxTerror Voici une proposition avec le test : Module:Langue/Bac à sable#Fonction nomLangueBrut

Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 22 mars 2019 à 18:17 (CET)

J'hésite sur le retour de la fonction en cas de code non trouvé : rien du tout (actuel), ou message d'erreur ? Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 22 mars 2019 à 18:18 (CET)

J'avais déjà tiqué sur cette histoire. Je suggère deux fonctions : lienLangue() et nomLangue(). od†n ↗^blah 23 mars 2019 à 01:09 (CET)

Pour le retour en cas d'erreur, une possibilité serait d'implémenter un paramètre optionnel onerror :

• onerror=blah : retourne "blah"
• onerror=input (valeur spéciale) : retourne inchangé le paramètre 1 passé en entrée
• onerror= : retourne ""
• onerror omis (comportement par défaut) : retourne un message d'erreur
• onerror=error (autre valeur spéciale) (éventuellement) : retourne de même un message d'erreur

Ceci étant, don't anticipate the needs : on peut aussi faire le boulot au niveau du modèle appelant (test si résultat vide, ou si erreur à l'aide de #iferror).

od†n ↗^blah 23 mars 2019 à 01:20 (CET)

Bonjour Od1n .

J'aime beaucoup cette idée de paramètre onerror. Ça peut être une extension ajoutable à postériori si on se rend compte que le retour d'une chaine vide ne convient pas à toutes les situations. En l’occurrence, je penche pour la chaine vide par défaut, car l'utilisation que  NicoV veut en faire est dans un lien, donc évitons de retourner un code qui serait interprété en tant que lien.

En revanche, je note que tu serais pour un renommage de la fonction actuelle "nomLangue" en "lienLangue" ? Je pense que ce serait une bonne chose, mais il faudrait alors s'assurer de toutes les utilisations de cette fonction (pas seulement via le modèle {{Nom langue}}). A-t-on un outil du même style que petscan pour les modules ?

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 23 mars 2019 à 08:53 (CET)

Pour ce genre de cas, la recherche interne est très efficace : insource:nomLangue insource:/nomLangue/ (l'ajout de la regex insource:/nomLangue/ permet d'avoir une recherche case-sensitive). Tu peux constater que le renommage de la fonction serait relativement simple. od†n ↗^blah 23 mars 2019 à 14:48 (CET)

Cool. Ok pour changer le nom de la fonction actuelle, et avoir nomLangue() qui ne retourne que le nom de la langue, sans rien d'autre. --NicoV (discuter) 25 mars 2019 à 09:06 (CET)

Refs Projet:Modèle/Demandes/2019#Obtenir le nom de l'article portant sur une langue à partir de son code. Donc en fait ça serait trois fonctions : lienLangue(), nomLangue() et articleLangue(). od†n ↗^blah 25 mars 2019 à 14:44 (CET)

Un peu plus embêtant : pour faire propre il faudra également renommer le modèle {{Nom langue}}, qui a un peu plus d'inclusions (liste pas nécessairement exhaustive). Bon, rien d'insurmontable non plus, et ça sera l'occasion de faire du ménage car certaines utilisations du modèle m'ont l'air inadéquates. od†n ↗^blah 25 mars 2019 à 14:52 (CET)

Bonjour Od1n ,

Concernant articleLangue(), dont je suis le créateur, je peux te garantir qu'elle n'utilise pas nomLangue(), bien que je m'en sois inspiré. Je pensais au contraire au début modifier nomLangue() pour qu'elle utilise articleLangue() pour générer le lien, afin de mutualiser le code commun, mais je ne suis plus si sûr que ce soit opportun.

Il faudra avoir le même type de réflexion avec la nouvelle fonction : est-ce que la future fonction lienLangue() ne devrait pas utiliser nomLangue() et articleLangue() pour générer le code du wikilien, ou vaut-il mieux au contraire préserver leur indépendance ?

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 25 mars 2019 à 18:24 (CET)

Bonjour Od1n ,
J'ai vu que tu avais procédé aux modifications. Du coup, je note un peu plus d'une centaine de modèles utilisant {{Nom langue}}, à modifier avec le nouveau nom du modèle si on veut pouvoir réutiliser l'ancien nom pour la nouvelle fonction. Je peux m'en charger si besoin, sinon on peut faire tourner un bot ?
Par ailleurs, je vais mettre la nouvelle fonction en place dans le module dès maintenant, vu qu'elle semble fonctionner.
Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 26 mars 2019 à 07:27 (CET)

Oups, je n'avais pas vu ton lien bien plus efficace : il n'y a pas tant d'utilisations que ça finalement. Je vais m'en charger à la main. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 26 mars 2019 à 07:37 (CET)

 Od1n C'est bon, j'ai fait toutes les modifs dans les modèles. Néanmoins, je n'ai pas fait les modifs sur les quelques articles de l'espace principal utilisant directement ce modèle, car je ne suis pas convaincu que cette utilisation soit judicieuse... Peux-tu jeter un oeil sur ces utilisations ?

Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 26 mars 2019 à 07:45 (CET)

Je suis aussi d'avis que ces quelques utilisations dans les articles ne sont pas pertinentes, tu peux y aller. Merci aussi pour le boulot de ton côté :) od†n ↗^blah 26 mars 2019 à 08:02 (CET)

 Fait. Plus qu'à attendre que cette liste se vide d'elle-même pour être sûrs que l'on n'a rien oublié, et on pourra réutiliser l'ancien nom pour le nouveau modèle.

Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 26 mars 2019 à 08:16 (CET)

Quelque chose comme ça : insource:"nom langue" insource:/\{\{[ _]*[Nn]om[ _]+langue/ od†n ↗^blah 26 mars 2019 à 09:00 (CET)

Bonjour Epok J'ai forcé la purge de la liste, elle est bien vide. --NicoV (discuter) 26 mars 2019 à 11:11 (CET)

Bon, après vérification (grâce au regexp mais sur tous les espaces de noms), il me semble qu'il n'y a plus d'utilisation du modèle, hors quelques citations en texte uniquement. Je prend donc sur moi de créer le nouveau modèle {{Nom langue}}. Par contre, je n'ai pas le temps de créer la doc ce soir, je m'en occuperai plus tard ou bien si vous voulez vous en charger, vous êtes les bienvenus (sachant que le modèle est très simple ; un seul paramètre : le code IETF, et retourne le nom de la langue en français).

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 26 mars 2019 à 21:27 (CET)

Catégorisation dans la catégorie « Page avec code de langue invalide »

Bonjour,
Il serait intéressant de catégoriser les pages utilisant un code invalide dans la catégorie « Page avec code de langue invalide », et ce pour tous les (ou au moins la plupart des) modèles utilisant ce module. Sur le modèle de ce qui est fait dans la fonction Langue.langue(), je pensais modifier le code d'erreur retourné par la fonction getDataLangue() en '[[Catégorie:Page avec code de langue invalide|codeLangue]] ' .. langErrorMess:format( codeLangue ). Est-ce que cela vous semble pertinent ? Voyez-vous des contre-indications ?
Je notifie  Od1n qui a procédé à refactorisation du code d'erreur, et  SyntaxTerror avec qui je discute en ce moment de ce sujet.
Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 8 mai 2019 à 10:03 (CEST)

Paramètre italique= pour Modèle:Langue avec nom

Bonjour,

Serait-il possible d’ajouter un paramètre italique=oui/non (non par défaut) au modèle {{Langue avec nom}} (et éventuellement {{Langue}}) ?

Ça éviterait de mettre l’italique manuellement et de garder la valeur qui contient le texte « propre » sans les '' et les balises HTML <i></i> à l’extérieur des balises span, ce qui est meilleur pour l’accessibilité et l’extraction de texte. C’est ce qui est fait sur enwiki par exemple :

« When formatting foreign-language text to match style guidelines, it is best to exclude the styling markup from the template, so that any extraneous markup which is not from the foreign language does not receive incorrect metadata for that language. »

Par ailleurs, cette discussion semble recommander l’usage de <i lang="xx"></i> à la place de <i><span lang=xx></span></i>.

À la place de {{lang|en|''The quick brown fox jumps over the lazy dog''}}, on aurait donc {{lang|en|The quick brown fox jumps over the lazy dog|italique=oui}}.

Voir aussi cette discussion en cours : Discussion modèle:En langue#Italique automatique. — Thibaut (discuter) 17 janvier 2020 à 14:09 (CET)

@Thibaut : sujet un peu vieux et laissé de côté, mais j'ai justement pensé la même chose, ou plutôt l'inverse : mettre le paramètre italique avec oui par défaut (car il me semble que beaucoup plus de cas ont besoin de l'italique que le contraire).

{{italique si latin}} fait déjà le travail (seuls les caractères latins peuvent être mis en italique), il suffirait de l'inclure dans le module:Langue.

Voici un test d'exemple : .

Le vrai problème sera de corriger toutes les mises en italique superflues, probablement plus d'un million d'articles, et que s'il est mal utilisé, les '' hors du modèle et l'italique intégrée au modèle vont s'annuler et mettre le texte en romain, avec une paire de balises vides dans le code HTML. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 25 novembre 2023 à 15:19 (CET)

Ne pas afficher les codes de langue en doubles dans le modèle:Mul

Bonjour

Je me suis aperçu qui y a un certain nombre de modèles {{mul}} qui possèdent plusieurs codes de langue identiques (par exemple {{mul|fr|fr}}, affichant (fr + fr)), mais les détecter après coup est assez compliqué : j'utilise la regex (?<={{mul\|(?:(?!{{|}}).)*?)\b(\w+)\|(?=(?:(?!{{|}}).)*\b\1\b) (démo) pour cela, et la recherche dans le dump avec AWB prend plus de 24 heures.

Dans le dump du 20 novembre 2023, alors que {{mul}} n'est pas encore entré dans les usages, j'ai déjà trouvé une trentaine d'occurrences, et je ne suis qu'au tiers de la recherche.

Je pense qu'il faudrait inclure un test dans le module:Langue pour ne pas afficher les codes de langue en double, parce que la maintenance est très difficile sinon. Ajouter une catégorie de maintenance serait sans doute un plus.

Noter que la regex ci-dessus utilise la flavour .NET et qu'elle ne peut probablement pas être utilisée, le lookaround n'ayant pas de taille fixe (mais ça marche avec AWB).

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 25 novembre 2023 à 15:40 (CET)

Bonjour SyntaxTerror. La correction par bot dans les articles semble acceptable pour ces appels farfelus. N'utilisais-tu pas aussi Pywikibot/Pywikipedia ? Il est très facile de récupérer tous les paramètres d'un appel de modèle et de les comparer deux à deux. Par ailleurs, j'ai lu une autre discussion et cru comprendre que tu modifiais ou renommais des paramètres de modèles par une simple recherche de nom dans la page, sans vérifier que le passage se trouve effectivement dans le modèle recherché. C'est plutôt risqué car plusieurs modèles peuvent avoir des noms de paramètre communs et un motif donné peut se trouver dans la page sans rapport. Des méthodes bien plus rigoureuses, moins dangereuses, existent.

Ici, il conviendrait de retirer un paramètre doublon (ou d'utiliser un modèle dédié s'il ne reste qu'une langue) ou d'intégrer la donnée au paramètre langue (vérifier au préalable son contenu éventuel) du modèle bibliographique suivant immédiatement le modèle mul, si tel est le cas.

Pour autant, une modification du module pour obtenir un affichage correct ou une catégorisation d'erreur, n'est pas à exclure, si elle n'altère pas les performances. Pas le temps de regarder maintenant. À mon avis, la première question est de comprendre comment ces valeurs redondantes sont arrivées dans les articles, car il est étonnant qu'un contributeur fasse manuellement cette erreur à grande échelle.

Note : La syntaxe alternative {{mul|fr/fr}} est aussi à considérer. — Ideawipik (discuter) 25 novembre 2023 à 16:11 (CET)

Bonjour Ideawipik. Si tu dis que c'est si facile avec une autre méthode, merci de me donner la liste, je me débrouillerai avec, parce que je ne suis plus capable d'apprendre le python.

Sinon, ce n'est pas le sujet de la question, qui est juste d'ajouter une fonctionnalité au module:Langue.

Si tu veux me parler d'autre chose, fais le plutôt sur ma PdD.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 25 novembre 2023 à 16:24 (CET)

En ce qui concerne le retrait des doublons, voir ce genre de modification et le rendu dans Module:Langue/Bac à sable/Documentation#{{Mul}}. Il faudrait quand même éviter que l'ajout de telles souplesses participe à la propagation de syntaxes absurdes, incompréhensibles, dans les articles. Donc peut-être qu'il vaudrait mieux se contenter d'un message d'erreur et d'une catégorisation. Notification à Od1n pour avis. — Ideawipik (discuter) 25 novembre 2023 à 21:21 (CET)

Merci Ideawipik.

Une catégorisation dans la Catégorie:Page avec code de langue invalide serait évidemment une bonne chose (même si ça ne correspond pas vraiment avec le titre de la catégorie, qu'on pourrait renommer Catégorie:Page avec des erreurs dans les codes de langue par exemple.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 25 novembre 2023 à 22:37 (CET)

• Garder à l'esprit que cette fonction indicationMultilingue() du module n'est pas utilisée que par le modèle {{mul}}, mais aussi par d'autres modules. Il existe donc possiblement davantage d'utilisations erronées.
• Il me parait aussi important d'ajouter une catégorie (dédiée à ce cas, bien entendu), ce qui permettrait d'évaluer l'ampleur de la situation. Cela permettrait de compter aussi les utilisations venant d'autres modules, cf. point précédent.
• J'avais pensé à un cas comme {{mul|en-US|en-GB}} (ou bien utilisation venant d'un autre module, avec ces valeurs) ; qui est "normalisé" en codes langues "en" et "en". Faut-il considérer cela comme un doublon de paramètres ou non ?

od†n ↗^blah 26 novembre 2023 à 00:21 (CET)

@od†n : si on met en place le nouveau code et la catégorisation, on pourra voir où sont les erreurs et les potentiels faux-positifs. Ça n'est pas gênant tant qu'il n'y a pas de message d'erreur (de toute façon, certains messages d'erreurs restent des années : 5 ans pour le truc que j'ai corrigé plus bas).

Sinon, la Catégorie:Page avec code de langue invalide n'est pas très utilisée, et elle classe déjà les pages par type d'erreur avec des clefs de tri différentes (L pour {{Langue}}, C pour {{Citation étrangère}} et T pour {{Langue du titre}}). Il suffirait d'ajouter une clef de tri M pour le modèle multilingue/indication de langue dans les modèles biblio/etc.

D'ailleurs, ce ne sont pas forcément des codes invalides, souvent, ce sont des codes manquants, par exemple ici : .

Sinon, il me semblerait vraiment étrange d'avoir {{mul|en-US|en-GB}}, un texte ne peut pas être à la fois en anglais américain et britannique, quoiqu'il peut être possible par exemple d'avoir sr-Latn et sr-Cyrl pour le même document (un truc en serbe utilisant l'écriture latine et cyrillique).

Ces codes de régions sont en mis quasiment uniquement par l'éditeur visuel je pense, et on se retrouve avec des aberrations inutiles comme (fr-FR) qui n'a aucune utilisé hors d'un texte sur la linguistique.

En bref, je suis pour une mise en place rapide du truc, avec uniquement une catégorisation pour l'instant, et je me charge de corriger les erreurs et de voir les faux-positifs éventuels. Şÿℵדαχ₮ɘɼɾ๏ʁ 26 novembre 2023 à 00:43 (CET)

• Le {{mul|en-US|en-GB}} était juste un exemple. Mais en cherchant, on finirait bien par trouver un cas de figure valable avec des codes "aa-BB" et "aa-CC". J'avais aussi pensé que les paramètres ne viennent pas forcément de l'utilisateur, mais peuvent aussi venir d'éléments wikidata.
• Je ne suis pas fan des catégories "fourre-tout" (ça me rappelle une camarade de lycée), où on détourne la clé de tri pour faire des espèces de groupes, perdant au passage le tri "normal". Je préfèrerais vraiment des catégories et sous-catégories distinctes, et qui conserveraient le tri "normal" des pages.
• D'accord pour seulement ajouter une catégorie, sans message d'erreur, et même en continuant d'afficher les valeurs en double (principe de moindre surprise pour l'utilisateur). Du moins pour l'instant. Là ce qui nous intéresse c'est la catégorisation. On pourra éventuellement être plus strict plus tard (message d'erreur), si la catégorie se retrouve entièrement vidée et qu'il n'y a pas d'utilisation valable avec des doublons.

od†n ↗^blah 26 novembre 2023 à 01:31 (CET)

@Od1n :

• {{mul|en-US|en-GB}}<nowiki> n'est pas très pertinent, mais <nowiki>{{mul|gsw-FR|gsw-CH}} (alsacien/alémanique) peut être (dans le haut Valais, il ne se comprennent pas d'un village à l'autre, alors comprendre des alsaciens...).
  Après, s'il faut connaitre les différences entre chaque variété linguistique, on peut oublier et tout laisser en plan. Ça ne concernera au pire qu'une poignée d'articles, pas besoin de se casser la tête pour ça.
• Si ce sont des catégories de maintenance, elles sont censées être vide, donc ce n'est pas très gênant, multiplier les catégories rend au contraire la maintenance plus difficile, car il faut être sûr que quelqu'un vérifie ces catégories de temps en temps.
  Justement, pour la Catégorie:Page avec code de langue invalide, des articles y étaient depuis au moins 5 ans, même si ces articles ont des gros messages d'erreur en rouge (la majorité dans le titre de l'infobox).
  Tant qu'il n'y a pas de surcharge, je préfère vraiment une seule catégorie concernant les codes de langue.
  D'ailleurs, je me suis mis à suivre celle que je viens de citer avec {{Utilisateur:OrlodrimBot/Suivi catégorie}} (qui ne gère d'ailleurs pas les sous-catégories), donc elle ne devrait pas se remplir jusqu'à que je me mette en wikislow la prochaine fois .

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 26 novembre 2023 à 01:58 (CET)

┌─────────────────────────────────────────────────┘

Aïe. Je viens de m'apercevoir que c'est plus ou moins de ma faute s'il y a autant des doublons dans le modèle mul.

En fait, j'avais oublié de mettre la regex que je cite plus haut quand j'ai traité les articles pour réunir les modèles d'indication de langue qui se suivaient, donc les doublons déjà dans les articles n'ont pas été corrigés, mais juste ajoutés à un modèle mul.

Mais c'est un cas qui arrive quand même, je me souviens avoir corrigé ce genre d'erreur qui n'était pas de ma faute.

De toute façon, je réglerai le problème une fois que j'aurais la liste complète des articles touchés.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 26 novembre 2023 à 02:24 (CET)

fonctionnement de l'option "langue" pour le modèle "ouvrage"

[ Od1n – Je me permets de couper-coller vers ici une discussion qui avait été initiée sur Wikipédia:Forum des nouveaux, qui concernait {{Ouvrage}} et Module:Biblio/Commun, où la problématique de départ a été résolue, mais qui a révélé des problématiques dans le Module:Langue sous-jacent. Pour notification :  SeriousMacadamia et Csar62. ]

Question : Je note un comportement qui me semble incohérent lors de l'utilisation de l'option "langue" dans le modèle ouvrage. Voici trois utilisations :

1 - Avec "langue=it" : (it) Italo Calvino, Il Sentiero dei nidi di ragno, Einaudi, 1947

2 - Avec "langue=gallo" : (fr-gallo) Régis Auffray, La pllée qi chet, la pllée qi mouille, Rue des Scribes, 2017

3 - Avec "langue=gallo,fr" : (fr-gallo + fr) Régis Auffray, La pllée qi chet, la pllée qi mouille, Rue des Scribes, 2017

Dans le cas 2, la langue n'apparait pas, alors que je me serais attendu à voir (fr-gallo) à coté du titre. Par ailleurs, en utilisant l'affichage de la langue (option "accessibilité" activée), on voit bien "Lang : it' et "Lang : fr-gallo" apparaitre pour 1 et 3, mais rien pour 2. Le titre n'est pas "noté" comme étant dans la langue gallo (semble-t-il). Si on le fait à la main, avec le modèle "langue" : La pllée qi chet, ça fonctionne par contre.

Est-ce que je rate quelque chose ?

(ou est-ce qu'il y a un meilleur endroit pour poser la question ?)

Merci ! SeriousMacadamia (discuter) 10 avril 2026 à 19:48 (CEST)

Bonjour. Dans le module qui génère la mise en forme du modèle {{Ouvrage}} il est apparemment prévu de ne pas mettre d'indication de langue lorsque son code est "fr" ou commence par "fr-", la question serait donc plutôt pourquoi on a une indication dans le cas 3.

voir Module:Biblio/Commun, fonction Commun.indicationDeLangue, ligne 295 :

function Commun.indicationDeLangue( args, validArg )
(...)
		if codeLangue == 'fr' or codeLangue:sub(1, 3) == 'fr-' then
			return ''

Je me permets de notifier amicalement @Od1n, dernier contributeur important de ces modules pour avis.

Cdlt, Csar62 (discuter) 10 avril 2026 à 20:47 (CEST)

Ohhhh excellent, on peut voir le code des modules, je n'avais pas réalisé ça !! SeriousMacadamia (discuter) 10 avril 2026 à 23:35 (CEST)

• Le module n'affiche pas la langue lorsqu'il y en a une seule, et que c'est le français ou une variante (français canadien, etc.). Problème, le gallo est traité comme une variante, alors que c'est vraiment une autre langue. Refs code du "module data" ici. C'est peut-être aussi la même situation avec le français haïtien. Il faudrait ajouter ces deux langues en exceptions (blacklist), ou inversement, chercher seulement fr fr-BE fr-CA fr-CH fr-FR (whitelist).
  • quoique, le français haïtien semble quand même assez proche du français classique
  • alternativement : on pourrait masquer l'indication seulement lorsque fr, éventuellement aussi fr-FR, et afficher dans tous les autres cas, en considérant que si on a par exemple fr-CH c'est qu'il y a une bonne raison de le préciser
• Le 3^e cas est correct : s'il y a plusieurs langues, on affiche l'indication, même si cela inclut le français. Ça me semble adéquat : si un ouvrage est par exemple bilingue français et espagnol, cette information est pertinente.

od†n ↗^blah 11 avril 2026 à 05:45 (CEST)

Je viens d'effectuer la modif 235031607 (suivie du complément 235031912) : « masquage uniquement de "fr" et "fr-FR" (qui est la variété standard) ; on ne masque plus notamment "fr-gallo" (une langue vraiment différente), ainsi que "fr-HT", "fr-CA", etc. (car si ces variantes sont précisées, c'est que ça doit être pertinent) ». od†n ↗^blah 11 avril 2026 à 07:28 (CEST)

@Od1n : Bonjour. Merci pour les explications et la modif, qui semble tout à fait pertinente mais néanmoins pour la langue fr-FR seule, le code s'affiche :

1 - Avec "langue=fr" : Italo Calvino, Il Sentiero dei nidi di ragno, Einaudi, 1947 (OK)

2 - Avec "langue=fr-FR" : Italo Calvino, Il Sentiero dei nidi di ragno, Einaudi, 1947 (NOK !?)

!!?? Csar62 (discuter) 11 avril 2026 à 09:49 (CEST)

J'ai le début de l'explication : Langue::codeLangue2() retourne en minuscules, i.e. « fr-fr » et non le « fr-FR » auquel je m'attendais naturellement. On pourrait gérer la situation dans Module:Biblio/Commun (avec une comparaison case-insensitive), mais il faudrait surtout creuser, et comprendre comment ça se fait que codeLangue2() retourne en minuscules… od†n ↗^blah 11 avril 2026 à 10:07 (CEST)

Peut-être était-ce anticipé que les gens puissent tout entrer en minuscules ? "fr-fr" ou "fr-ch" sont aussi reconnus valides :

3 - Avec "langue=fr-fr" : Italo Calvino, Il Sentiero dei nidi di ragno, Einaudi, 1947

4 - Avec "langue=fr-ch" : (fr-CH) Italo Calvino, Il Sentiero dei nidi di ragno, Einaudi, 1947

Csar62 (discuter) 11 avril 2026 à 10:25 (CEST)

Je vois un peu ce qui se passe au niveau de determinationCode(), c'est mal fichu : quand on lui passe un "code-subcode", le lookup se base uniquement sur la première partie (le code principal), qu'il convertit en code principal normalisé (i.e. lowercase, ici bien attendu) et laisse les subcodes tels quels, même lorsque le "code-subcode" existe dans le module data.

Langue.determinationCode( 'français de france' )
table#1 {
    "fr-FR",
}
Langue.determinationCode( 'fr-fr' )
table#1 {
    "fr",
    "fr",
}
Langue.determinationCode( 'FR-FR' )
table#1 {
    "fr",
    "FR",
}
Langue.determinationCode( 'fr-gallo' )
table#1 {
    "fr",
    "gallo",
}
Langue.determinationCode( 'gallo' )
table#1 {
    "fr-gallo",
}
Langue.determinationCode( 'fr-pouet' )
table#1 {
    "fr",
    "pouet",
}

Ce qui me choque encore plus, c'est la divergence où quand on passe un code, la table contient deux éléments avec le code décomposé, et quand on passe le nom, la table contient un élément avec le résultat entier.

On a là dans le module Langue une problématique assez profonde et ancienne, qui dépasse le cas spécifique du module Biblio/Commun ici traité. Je serais donc d'avis de "renforcer" le module Biblio/Commun avec une comparaison case-insensitive (peu coûteux et je ne vois pas de drawback), comme ça au moins on est tranquille à ce niveau. Puis restera à traiter cette problématique avec le module Langue…

od†n ↗^blah 11 avril 2026 à 10:51 (CEST)

J'ai traité le module Biblio/Commun : 235038208, donc pour sa part ça devrait être bon ; mais il subsiste les problèmes de fond avec le module Langue… od†n ↗^blah 11 avril 2026 à 11:17 (CEST)

J'en suis arrivé à ceci :

function Langue.determinationCode( langue )
	if type( langue ) == 'string' and langue ~= '' then
		local tabLangue
		-- 1) recherche de l'élément exact
		tabLangue = dataLangue[ mw.ustring.lower( langue ) ]
		if tabLangue and tabLangue.code then
			local tabCode = {}
			for i = 1, #tabLangue do
				tabCode[i] = tabLangue[i]
			end
			if tabLangue.invalide then
				tabCode.invalide = true
			end
			return tabCode
		end
		-- 2) recherche seulement sur le code principal, et on retourne les subcodes tels que fournis en entrée
		local splitLangue = mw.text.split( langue, '-' )
		tabLangue = dataLangue[ mw.ustring.lower( splitLangue[1] ) ]
		if tabLangue and tabLangue.code then
			local tabCode = splitLangue
			tabCode[1] = tabLangue.code
			if tabLangue.invalide then
				tabCode.invalide = true
			end
			return tabCode
		end
	end
end

Et dans codeLangue() et codeLangue2(), je suppose qu'il faudrait retirer la normalisation en lowercase, mais conserver le trim.

Mais là on touche clairement à du code délicat, et énormément utilisé. Des avis supplémentaires seraient indispensables. Cette section serait à déplacer vers Discussion module:Langue, avec notification sur Discussion Projet:Scribunto.

od†n ↗^blah 11 avril 2026 à 12:06 (CEST)

On trouve toutes sortes de variantes dans la saisie du paramètre langue,
voir : résultats pour insource:/langue=[A-Z]/,
et résultats pour insource:/langue=[a-z].\-/
le code actuel est très souple/permissif, pas certain qu'une modif soit "indispensable". En tout cas, merci, A+ Csar62 (discuter) 11 avril 2026 à 13:42 (CEST)

Les codes IETF sont flexibles par nature ; ils peuvent avoir moult parties (exemples : zh-Hant-HK-x-company-test, en-Latn-US-fonipa-x-perso), et optionnelles (donc les positions peuvent être décalées) ; on ne peut pas lister toutes les possibilités (explosion combinatoire), en revanche il est techniquement possible (même avec Lua) de normaliser la capitalisation, qui suit des règles bien définies. Mais une telle normalisation n'est (actuellement) pas présente dans le module, et je ne suis pas certain que ça en vaille la peine.

Généralement parlant, je pense que la meilleure approche pour l'instant, serait de retourner le code tel qu'il a été fourni par l'utilisateur, à partir du moment que l'on a détecté qu'il s'agit d'un code et qui semble valide. Autrement dit, codeLangue() et codeLangue2() ne devraient plus causer le passage en lowercase des subcodes (ce qui est incorrect) (noter aussi que c'est une inconsistance avec determinationCode(), vu que lui n'applique pas ce lowercase). Charge à l'utilisateur de renseigner avec une capitalisation correcte, et si ce n'est pas le cas, tant pis, on garde ce qu'il a mis (ce qui est moins pire que d'appliquer un lowercase erroné sur les subcodes). Néanmoins, on pourrait quand même déjà retourner le code bien normalisé, lorsque celui-ci est présent dans le module data (les fr-FR, etc.), en se basant sur une sorte de principe « si le résultat n'est pas normalisé ce n'est pas grave, mais si on peut le faire c'est quand même mieux ».

od†n ↗^blah 12 avril 2026 à 10:58 (CEST)

Conflit d’édition —

Bonjour Od1n, Csar62 et SeriousMacadamia.

J'ai beaucoup travaillé avec les codes (« étiquettes ») IETF et je peux éventuellement aider si vous avez des questions spécifiques.

La capitalisation ne compte pas tant que ça, dans les sources, on trouve de tout.

Par contre, pour l'affichage, il faudrait suivre la capitalisation recommandée par l'IANA : chaque partie est séparée par des tirets, et tout est en minuscules SAUF la première lettre des systèmes d'écriture (zh-Hans = chinois en écriture simplifiée), et les codes de région de deux lettres tout en capitales (zh-TW = chinois de Taïwan).

Il y a un outil qui permet de vérifier si un code est valide sur https://r12a.github.io/app-subtags/

Il doit y avoir le code de l'outil sur GitHub, mais même si c'est possible, je doute qu'il soit utile de l'intégrer ici.

Aussi, qu'un code soit valide ne veut pas dire qu'il soit pertinent (fr-Cyrl-CN est valide, mais c'est du français de Chine continentale en écriture cyrillique), ou qu'il corresponde réellement au texte de la source.

.

Je tiens à rappeler que les étiquettes de région ne servent pas à grand-chose sorti du domaine de la linguistique.

Il est inutile de mettre (en-GB) ou (en-US) devant une source, ça sera en anglais de toute façon, et les différences seront inexistantes ou minimes.

Ça ne changera pas la difficulté à comprendre la source et n'apportera rien au lecteur.

Si ça ne tenait qu'à moi, elles ne seraient pas affichées (le plus souvent elles viennent d'outils qui mettent en forme des références qui veulent en faire trop).

.

Sujet connexe : je viens de retirer l'ajout de « fr » par défaut dans les template data des modèles biblio principaux . Ça évitera que ce code soit ajouté par l'éditeur visuel.

D'une ça alourdit inutilement le code des articles, vu que ce n'est pas affiché, et de deux, il arrive parfois (rarement) que des documents en d'autres langues soient étiquetés avec ce code par défaut.

Bonne journée, Şÿℵדαχ₮ɘɼɾ๏ʁ, dimanche 12 avril 2026 à 11:24 (CEST)

Merci pour ces infos utiles. Je vois déjà à peu près ce qu'il serait envisageable de faire :

• retirer dans codeLangue() et codeLangue2() la transformation en lowercase complet (mais garder le trim) ; noter que le determinationCode() sous-jacent fait déjà le lookup de façon case-insensitive ;
• et corriger l'histoire des codes qui ne sont quelquefois pas "splittés" dans la table retournée par determinationCode().

Mais il ne me semble pas y avoir d'urgence à corriger / mettre au propre, dans la mesure où ça fonctionne en l'état depuis longtemps, sans que ça ne fasse grande vague.

od†n ↗^blah 12 avril 2026 à 11:54 (CEST)

@Od1n : « une telle normalisation n'est (actuellement) pas présente dans le module ».

En fait, elle l'est dans module:Langue/Data, mais est manuelle.

J'avais corrigé les erreurs il y a un moment, et je passe parfois vérifier (peut-être pas assez souvent, mais il n'y a pas beaucoup d'ajouts de codes complexes).

Sinon, pour qu'un code soit affiché correctement, il faut qu'il soit dans ce sous-module.

zh-Hant-HK-x-company-test est bien correct, mais {{mul|zh-Hant-HK-x-company-test}} n'affiche que (zh) (par contre, {{mul|zh-Hant}} affiche (zh-Hant), car zh-Hant est dans module:Langue/Data). Şÿℵדαχ₮ɘɼɾ๏ʁ, dimanche 12 avril 2026 à 11:56 (CEST)

Très bonne remarque. codeLangue(), codeLangue() et determinationCode() acceptent des subcodes arbitraires, et les retournent, tandis que indicationMultilingue() a sa propre logique pour l'affichage, comme tu l'as décrite. Je ne sais pas s'il y a lieu de changer quelque chose à ce sujet, en tout cas ça amènerait sur encore une autre histoire. od†n ↗^blah 12 avril 2026 à 12:10 (CEST)

Juste pour ajouter, oui, ça fonctionne sans vagues, mais par le passé, avant la mise en place du module:Langue/Data que Zebulon84 et moi avons écrit (surtout lui ), il y avait plein de codes qui n'étaient pas des codes IETF, mais des trucs venant de bases de données linguistiques diverses.

Parce que le gars qui voulait absolument un code de langue pour son patois local finissait toujours par en trouver un quelque part (Linguist List et autres).

J'ai passé un moment à corriger les modèles d'indication de langue et le module:Langue/Data, et on a réussi à éliminer tous les modèles d'indication de langue multiples avec la fusion avec le modèle:mul qui a été remanié et est devenu un petit bijou (on peut aussi s'en servir pour afficher le rendu des codes du module:Langue/Data comme je l'ai fait ci-dessus).

Ces codes, c'est un vrai calvaire, car jamais l'IANA/IETF n'a répondu à mes questions et les linguistes ne s'y intéressent pas vraiment.

IETF utilise les codes ISO-639 1,2 et 3, les 639-3 sont gérés par la SIL International/Ethnologue.com, mais la première s'occupe de l'utilisation des codes, et les seconds leur création/attribution (ce sont des linguistes), sans qu'il n'y ait vraiment de contacts entre les deux.

J'ai des contacts à Ethnologue si jamais (qui bossent et savent comment la Sil fonctionne), mais ça ne sert pas à grand-chose dans ce cas. Şÿℵדαχ₮ɘɼɾ๏ʁ, dimanche 12 avril 2026 à 12:21 (CEST)

Problème majeur avec les modèles Citation étrangère et Langue du titre

Bonjour

Je viens de me rendre compte que les modèles {{Citation étrangère}} et {{Langue du titre}} ne détectent pas correctement les codes de langue invalides.

Ça touche potentiellement dans les 60 000 modèles : tous les modèles qui utilisent des noms de langue en toutes lettres au lieu des codes affichent des balises de langue erronées, ainsi que bien sûr tous ceux dont les codes de langue sont vraiment erronés.

La discussion se tient sur Discussion modèle:Citation étrangère#Pas de détection des codes de langue erronés, merci d'aller donner votre avis là-bas.

Je mets ce message ici car il faudra certainement faire gérer ces modèles par le module:Langue.

Şÿℵדαχ₮ɘɼɾ๏ʁ, lundi 9 novembre 2026 à 07:17 (CET)