Discussion modèle:Langue

Italique

Il faudrait créer un doublon de ce modèle pour les langues n'utilisant pas l'alphabet latin : en effet, il ne faut dans ce cas là pas mettre le texte étrangerophone en italique. R@vən 1 décembre 2006 à 00:16 (CET)

Il ne faut jamais mettre le texte en italique : l'indication de langue prévaut sur cette règle de typographie française. On peut ensuite directement définir des règles CSS pour mettre les textes latin non français en italique, mais je ne pense pas que ce soit vraiment utile. Gentil ♡ 9 décembre 2006 à 22:51 (CET)

Hmm, pourquoi cela prévaut-il ? À mon humble avis, il serait souhaitable qu'il y ait une cohérence entre ce template et la recommandation de Wikipédia:Conventions typographiques#Mots étrangers: « Les noms communs étrangers, c'est-à-dire ceux qui ne sont pas entrés dans le vocabulaire français et sont donc absents des dictionnaires du français usuel, sont toujours en italique lorsqu'ils sont écrits avec l'alphabet usuel (dit alphabet latin moderne) ou ses variantes. ».

Ensuite, que ce soit géré par les CSS par défaut ou par l'ajout de guillemets, peu importe, tant que c'est homogène. Ce`dric 19 janvier 2007 à 19:34 (CET)

Attention, de tels termes ne doivent pas être employés avec {{lang}}, car la phrase qui contient un terme d'origine étrangère reste une phrase en français. Gentil ♡ 20 janvier 2007 à 12:50 (CET)

Ok, donc l'usage de ce modèle concerne uniquement des textes ou expressions complètes, autonomes, et non pas des mots isolés.

Non, j'ai dit que ce modèle ne concerne pas les termes au sein de phrases en français. Les termes isolés, servant eux à une étymologie ou une traduction, doivent être identifiés par le modèle. Gentil ♡ 20 janvier 2007 à 17:35 (CET)

Ma confusion vient du fait qu'on le voit souvent utilisé pour de simples mots, en général pour définir l'orthographe d'un mot dans une autre langue en parallèle de l'orthographe francisée. Ou alors par le biais de {{grec ancien}}, pour donner l'étymologie d'un mot (bien qu'évidemment ici la question de l'italique ne se pose pas).

Par exemple dans Kalevala on trouve « Le Kalevala est composé de cinquante chants (le mot finnois, ''{{lang|fi|runo}}'', est souvent traduit par ''rune'', mais a seulement à faire indirectement avec les signes runiques du vieux germanique). ». L'usage de ce modèle est-il légitime dans ce cas ?

Qu'en est il d'un mot donné entre parenthèses parcequ'il n'existe pas d'équivalent en français, généralement pour des raisons culturelles ? Par exemple « Parfois voit-on aussi des « garçons étoilés » (stjärngossar) lors de la Sainte Lucie ». Ce`dric 20 janvier 2007 à 14:35 (CET)

Oui, pour tout ce qui est étymologie, ce modèle est bien employé. Donc tes exemples méritent l'utilisation du modèle. Je vais grossir un exemple où il ne faut pas l'employer : « Les internautes downloadent souvent des animes sur peer-to-peer. » Ici, les termes d'origine étrangère ne sont pas des explications lexicales, mais des mots étrangers employés abusivement en français. L'italique s'impose, mais pas le modèle. Gentil ♡ 20 janvier 2007 à 17:31 (CET)

Je ne suis pas sûr de bien saisir l'utilité du modèle alors. Il est bien dit qu'il sert à l'accessibilité (donc à des lecteurs vocaux notamment), or si l'on utilise des mots étrangers en plein milieu d'un texte, il m'apparaît pertinent et consistant avec le but de ce modèle que ces mots soient prononcés correctement par le système vocal. Actuellement je wikifie l'article sur Michael Jackson, et j'ajoute un peu partout ce modèle de lang pour assurer la bonne reconnaissance tant des titres de chansons ou d'albums que (mais là j'hésite) des noms propres à sonorité anglophone ou des noms de journaux etc.--Gandalfcobaye (d) 16 juillet 2009 à 18:58 (CEST)

Non, tout va bien : ton utilisation du modèle dans l'article Michael Jackson est tout à fait pertinente. --Lgd (d) 16 juillet 2009 à 19:30 (CEST)

Marche pas

Ce modèle ne marche pas si on ecrit juste {{lang|rtl|ar| 'mot'}} . Il faut absolument ajouter la balise 'code' comme ça <code> {{lang|rtl|ar| 'mot'}} </code> pour qu'il s'active .On m'a dit que la balise code s'utilise pour la programmation, par pour quoté une langue. Où est donc le problème? Mokaaa??? يا أخي إسآل 11 février 2007 à 17:57 (CET)

De quoi parles-tu ? Où ne fonctionne-t-il pas ? Normalement, on n'utilise jamais <code> avec ce modèle. Gentil ♡ 12 février 2007 à 01:24 (CET)

Ok, je vois la différence dont tu parles. Pour moi, voici l'aspect de ta page utilisateur :

arabe avec Microsoft sans serif

Mais pour les visiteurs, l'aspect est celui-ci :

arabe sans Microsoft sans serif

La balise <code> impose simplement une largeur fixe à tout texte qu'elle contient. Si tu désires le même effet pour l'arabe, alors il suffit d'imposer la police de caractères adaptée pour l'arabe. Tu peux le faire dans ton propre Special:MyPage/vector.css, en prenant exemple sur le mien et en employant la classe .lang-ar, ou bien on peut généraliser l'apparence de l'arabe à tous les visiteurs en faisant une demande à un administrateur. Gentil ♡ 12 février 2007 à 01:44 (CET)

Effectivement, ce qui apparait chez moi est le deuxième screenshot que tu as mis. Vous serez d'accord avec moi que la police de la première ligne est plus lisible que celle de la seconde. C'est pour ça que le jour où j'avais ajouté la balise code j'ai aimé le rendu... Bon, là vous dites que cette balise code n'est pas faite pour ça, ok, ce n'est pas grave. Concernant le 1èr screenshot, le fait que ça soit en gras améliore un peu la lisibilité, mais bon ça reste toujours serré, et puis mettre les caractères en gras ne serait pas très judicieux dans les articles. L'interet pour moi est de permettre une bonne lisibilité au lecteur lambda, pas pour moi. Parceque là, je vois pas trop l'interet du modèle? si meme sans l'utiliser, on a le meme rendu!? N'est il pas possible d'espacer ou d'agrandir un peu les caractères? Par exemple, de le rendre un peu comme l'ecriture en Persan sur la première ligne de cet article here. C'est pas très beau mais au moins nettement plus visible. Merci Mokaaa??? يا أخي إسآل 12 février 2007 à 13:27 (CET)

Problème des translittérations, romanisations et autres transcriptions

En effet, comment distinguer les kanji et les kana (hiragana & katakana) du romaji ? Il n'existe que le code ja correspondant à la langue japonaise. Idem pour les hànzì et les pīnyīn ! Le problème se posent pour toutes les langues n'utilisant pas l'alphabet latin et possédant donc une transcription en alphabet latin. En soit ce n'est pas bloquant mais c'est gênant dans le cas où comme moi, je spécifie une taille 200 % pour les sinogrammes et kanji/kana ! Quelqu'un a une solution ? une idée ? VIGNERON * ^discut. 27 mai 2007 à 12:29 (CEST)

Voir le modèle anglais en:Template:Transl, qui est susceptible, à défaut d'apporter des éléments de réponse, de fournir des pistes de réflexion, puisque certaines des translittérations suivent une codification internationale stricte. Pour ma part, avec le modèle français, j'ai déjà utilisé concurremment {{lang|sr|sr-Cyrl}} et {{lang|sr|sr-Latn}} puisque les doubles codes langue+alphabet sont censés être reconnus par les navigateurs oraux, selon la spécification HTML. Ton problème est peut-être toutefois un peu plus compliqué que celui que j'ai eu à résoudre lorsqu'il m'est arrivé de vouloir écrire du serbe selon les deux graphies. Hégésippe | ±Θ± 3 juin 2007 à 21:07 (CEST)

Proposition d'amélioration de modèle

J'étais assez chagriné de voir les modifs de Modèle:MyBot sur le modèle {{persan}}, car le modèle remplacé ne fait pas la même chose et qu'il va falloir se retaper du texte plutôt que de se servir du modèle qui fait tout... En bref, je souhaiterais qu'on puisse réfléchir à un modèle commun qui serve à mettre le texte dans une langue étrangère ainsi qu'une translitération, en paramétrant la langue. Ce modèle pourrait être de la forme {{Translit|fa|زمانی برای مستی اسبها|Zamāni barāye masti-ye asbhā}} qui donnerait (en [[persan]] : {{lang|rtl|fa|زمانی برای مستی اسبها}}, ''Zamāni barāye masti-ye asbhā''}}, soit (en persan : زمانی برای مستی اسبها, Zamāni barāye masti-ye asbhā). On peut alors le paramétrer avec toutes les langues. Je peux avoir des avis ? فاب - so‘hbət - 15 juin 2007 à 10:11 (CEST)

J'avais utilisé le modèle modèle:persan jusqu'au jour où je l'ai vu qualifier d'obsolète avec pour recommandation d'utiliser le modèle:lang, ça date d'au moins deux ans... MyBot à le réflexe tardif et inversé M.B. 15 juin 2007 à 17:21 (CEST)

Peut-être des paramètres nommés, plutôt que positionnels? {{Translit|lang=fa|text=زمانی برای مستی اسبها|alt=Zamāni barāye masti-ye asbhā}} Ugo14 18 juin 2007 à 09:12 (CEST)

En utilisant {{{text|{{{1}}}}}} pour compatibilité ascendante, pas bête. (Autrement dit, cela autorise d'utiliser soit {{lang|fa|text=زمانی برای مستی اسبها}}, soit {{lang|fa|زمانی برای مستی اسبها}} comme avant.)

Que pensez-vous de Utilisateur:Lachaume/Lang ? Par ailleurs, ne pourrait-on pas automatiser l'ajout de la directionnalité grâce à un modèle {{dir|code langue}} ? — Régis Lachaume ✍ 19 juin 2007 à 18:01 (CEST)

Autres idées :

Ne faudrait-il pas ajouter un espace entre le mot écrit dans la langue et son éventuelle translitération ?

De plus ne serait-il pas judicieux d'ajouter un title= qui affiche le mot "translitération" lorsqu'on passe la souris sur le mot indiqué en paramètre trans= (ou alt= avec le modèle translit s'il existe encore) ?

— MetalGearLiquid ^[m'écrire] 25 décembre 2007 à 03:43 (CET)

Quel code langue ?

Pour le tibétain on prend l'ISO 639-1 bo ou l'ISO 639-2 tib (B) / bod (T) (quelle différence ?) ou bien l'ISO/DIS 639-3 bod ? VIGNERON * ^discut. 17 juin 2007 à 13:49 (CEST)

Je viens de regarder dans la liste IANA et je trouve deux occurrences de Tibetan : bo de type language et Tibt de type script. Je suppose que ce que le code à utiliser est bo mais j'aimerais bien connaître la différence. VIGNERON * ^discut. 25 août 2007 à 10:09 (CEST)

Les codes langues (Type: lang) et codes d'écriture (Type: script) ne sont pas destinés au même usage dans BCP 47. Une bonne lecture de BCP 47 s'impose pour toi, afin comprendre de quoi il s'agit et comprendre la différence, et surtout pour comprendre pourquoi le registre IANA contient aussi les codes langue tib (issu de ISO 639-2:B, à usage uniquement bibliographique et jamais recommandé sur le web, mais défini comme un alias du code recommandé bo issu de ISO 639-1) et bod (issu de ISO 639-2:T, à usage technique, normalement recommandé dans les applications, sauf qu'ici c'est aussi un alias de bo...), et le code d’écriture Tibt (issu de ISO 15924).

Si tu as encore du mal avec l’anglais, au moins consulte l’article BCP 47.

Les codes pour HTML sont seulement ceux issus de BCP 47 (et enregistrés dans la base IANA), mais pas directement les codes ISO 639, ou ISO 15924. Ils ont une syntaxe particulière, et dans BCP 47 on ne parle en fait pas de « code langue », mais d’« étiquette (ou label) de langue », les « codes » inclus dans une étiquette étant des sous-étiquettes (ou sous labels), séparés par des tirets, et placé dans un ordre précis. On ne doit utiliser que les étiquettes recommandées si on veut une compatibilité maximale.

Donc pour coder la langue tibétaine, l'étiquette de langue à utiliser en HTML préférable sera définitivement bo, même si bod ou tib pourrait éventuellement marcher (si le navigateur reconnait les alias), mais en aucun cas Tibt, lequel servirait uniquement sous la forme bo-Tibt s'il était nécessaire de distinguer les différentes écritures de la langue (mais inutile puisque cette écriture tibétaine est également définie implicitement dans la base IANA pour la langue tibétaine, et ce qui en fait un autre alias pour bo), mais peut servir par exemple dans une étiquette comme en-Tibt (langue anglaise écrite dans l'écriture tibétaine). Verdy p (d) 29 août 2010 à 11:02 (CEST)

Italique et arabe

L'arabe en italique devient illisible, et « c'est pas bien » M.B. (d) 29 mars 2008 à 15:05 (CET)

Zut :). Je vais essayer d'améliorer le code pour que les langues à caractères latins soient en italique et les autres dans leur format d'origine. PoppyYou're welcome 29 mars 2008 à 15:23 (CET)

Pb d'affichage également pour le cyrillique. Avant de faire joujou avec les modèles, il serait bon de se préoccuper des conséquences... Je rajoute également que la mise en forme typographique ne doit pas être "codée" dans les modèles mais laissée à l'initiative de l'utilisateur du modèle. H2O (d) 29 mars 2008 à 18:47 (CET)

+1, la mise en italique devrait plutôt être optionnelle (éventuellement avec un argument, sinon avec la mise en forme classique). VIGNERON * ^discut. 17 avril 2008 à 14:54 (CEST)

Italique (bis)

Daniel*D (d · c · b) vient de me donner une idée, le modèle pourrait-il reconnaître les écritures latines pour les mettre en italiques ? VIGNERON * ^discut. 20 juin 2008 à 17:28 (CEST)

Oui, mais ce serait une mauvaise idée. Ce modèle ne peut avoir un double rôle consistant à 1) signaler les changements de langue (appliquer l'attribut lang du HTML) et 2) appliquer des règles typographiques : les deux emplois ne coïncident en effet pas. Il est préférable de poser l'italique au cas par cas, avec '' autour du modèle. --Lgd (d) 20 juin 2008 à 17:53 (CEST)

Justement si, sauf erreur, les langues étrangères utilisant l’alphabet latin coïncide avec l’italique. Me tromperé-je ? VIGNERON * ^discut. 21 juin 2008 à 08:40 (CEST)

Le problème n'est pas là. Le modèle signale un changement de la langue du contenu qui est nécessaire en particulier aux lecteurs d'écran. Par exemple sur des noms propres. Mais ceux-ci, selon les règles typographiques, n'ont pas à être en italique. Et il n'y a pas que les noms propres. regarde par exemple les différentes occurences du modèle {{lang}} dans l'article Accessibilité du Web (notamment dans les notes). --Lgd (d) 21 juin 2008 à 08:57 (CEST)

J’oubliais les noms propres ! Donc, non cela en coïncide pas, dommage (surtout qu’informatiquement il est presque impossible de distinguer un nom commun d’un nom propre). il n'y a pas que les noms propres.^{[réf. nécessaire]} ? Par contre, la plupart des liens de #Références aux documents du W3C devrait être en italique alors que dans #interfaces dynamiques ARIA devrait être en romaine (ou pas). Cdlt, VIGNERON * ^discut. 21 juin 2008 à 09:25 (CEST)

J'avoue froidement que les aspects typographiques n'ont pas été ma priorité lors de mon travail sur cet article, d'autant qu'ils ne sont guère perceptibles dans le lecteur d'écran que j'utilise de préférence à l'interface graphique . Mais si les titres doivent être en italique dans les références, du moment qu'il y a une règle claire et immédiatement exploitable, je serais heureux de faire les corrections.

Sinon, exemples de cas autre que les noms propres: les acronymes comme WAVE ne doivent pas être en italique, sauf erreur de ma part ? Ou, plus inattendu peut-être, des liens comme WAI où l'attribut lang est requis en raison du title=Web Accessibility Initiative --Lgd (d) 21 juin 2008 à 09:50 (CEST)

Un autre exemple amusant, tiens: black-out --Lgd (d) 1 juillet 2008 à 12:08 (CEST)

Espace manquante

Une petite erreur à corriger sur {{Lang}}, il manque une espace entre le texte et la parenthèse de sa translittération (ce qui n'est peut-être pas très visible sur l'exemple japonais, mais le devient beaucoup plus avec du grec ou du russe) :

• Exemple : {{lang|el|texte=ἡμερα|trans=êméra}}
• Donne : ἡμερα (êméra)

Pour la correction, l'espace ne peut être ajouté que s'il y a effectivement une parenthèse (donc il faut un test #if) et il vaut probablement mieux ne pas utiliser une espace insécable (ça risquerait de créer un segment très long dans certains cas, et ça n'est pas anormal qu'une parenthèse soit à la ligne suivante), donc je crois qu'il faudrait :

• Remplacer ce bout : {{{trans|}}}
• Par celui-ci : {{#if:{{{trans|}}}|<!--espace normale--> {{{trans|}}}}}

(Je poste ça ici pour archive, et je lance une Wikipédia:Demande d'intervention sur une page protégée identique.) — Babinski ^(Discutski) 3 avril 2008 à 20:06 (CEST)

L'utilisation d'un commentaire avant l'espace ne marche pas pour empêcher que cette espace soit supprimée du paramètre. En effet, lors que les paramètres de modèles (ou des fonctions du parser comme ici #if) sont évalués, les commentaires HTML sont supprimés directement (en fait ils le sont très tôt, dès la lecture du code wiki n’importe queller page ou modèle à inclure), puis les espaces sont compressés.

La solution c’est d’insérer un <nowiki/> vierge avant cette espace :

{{#if:{{{trans|}}}|<nowiki/> {{{trans|}}}}}

En effet les sections marquées par nowiki sont conservées durant toute l’expansion des modèles, et ces balises de marquage nowiki (balises de début ou de fin de section ou même vides) sont enlevées seulement à la fin, lors de la traduction en HTML du code wiki étendu final...

Durant toute l’évaluation des paramètres et l'expansion des modèles, les balises nowiki sont traitées comme s’il s'agissait de texte normal (et donc les espaces avant ou après sont traités comme ceux séparant des mots: ils peuvent être compressés mais pas totalement supprimés).

L’astuce vaut aussi pour conserver un saut de ligne au début d'un paramètre notamment pour la mise en forme de tbleaux contenant des rangées ou cellules conditionnelles): on met un <nowiki/> juste avant un saut de ligne à conserver en début de paramètre, ou juste après un saut de ligne à conserver en fin de paramètre. Verdy p (d) 14 juin 2008 à 22:35 (CEST)

Note: la solution actuellemet employées utilise pour cette espace une entité XML/HMTL "&#32;" ça marche depuis peu de temps pour éviter que cette espace soit supprimée, mais pas encore sur toutes les versions de MediaWiki, et cela reste instable car c'est génant dans l'évaluation de certaines expressions comme les tests de nullité (avec le premier paramètre de #if), ou tests d’égalité (dans les deux premiers paramètres de #ifeq ou les case d'un #switch avant le signe "=") ou encore dans les expressions, car ces entités sont converties en caractères normaux (et parfois alors compressés à nouveau) avant d’évaluer le test de nullité ou d’égalité ou d’évaluer l’expression (note: dans les expressions numériques avec #expr ou #ifexpr, les blancs ne nécessitent aucun traitement car ils n’y ont jamais aucune valeur, ils peuvent toujours être supprimés et donc il ne faut pas mettre de balises nowiki dedans sinon l’expression ne s’évaluera pas correctement).

C’est une partie assez instable du traitement du code wiki qui varie encore d’une version à l’autre de MediaWiki. La gestion des blancs a toujours été assez compliquée en MediaWiki. Verdy p (d) 14 juin 2008 à 22:54 (CEST)

Syntaxe

Recopié depuis la page "accessibilité, bonnes pratiques". --amicalement, Salix ( converser) 12 juillet 2009 à 16:21 (CEST)

---

Bonjour, quel est l'intérêt d'utiliser la syntaxe ''[[Web accessibility Initiative| {{lang|en|Web accessibility Initiative}}]]'' plutôt que celle-ci : ''{{lang|en|[[Web accessibility Initiative]]}}'' ? Il faudrait le préciser. --amicalement, Salix ( converser) 18 juin 2009 à 09:34 (CEST)

Bonjour,

Dans le premier cas, l'attribut title du lien est renseigné correctement, pas dans le second (où il est vide). Or le title est parfois lu par défaut, selon la configuration de l'outil de consultation... il faut donc, s'il est présent, qu'il soit correctement renseigné. Litlok →m'écrire 18 juin 2009 à 10:14 (CEST)

Pas tout à fait

• Le title du lien est identique dans les deux cas (il est systématiquement renseigné sur tous les liens par mediawiki, sauf dans le cas très particulier de certains liens sur une image avec le paramètre link)
• La première syntaxe est une syntaxe de précaution vis à vis des rédacteurs: s'ils doivent mettre le modèle {{lang}} à l'intérieur du lien, sur l'expression précisément concernée, ils seront moins exposés à mêler différentes langues dans le modèle :
  • première syntaxe, ils sont incités à faire [[Web accessibility Initiative|{{lang|en|Web accessibility Initiative}} sur le site du W3C]]
  • Seconde syntaxe, ils risquent de nous faire des {{lang|en|[[Web accessibility Initiative|Web accessibility Initiative sur le site du W3C]]}}
• Par ailleurs, la restitution est plus fiable dans certains modes de consultation des liens de certaines configurations de Jaws avec cette syntaxe : le span lang autour du lien n'est pas toujours pris en compte quand le lien est lu hors contexte dans la liste des liens, ce qui n'est pas le cas du span lang dans le lien.

--Lgd (d) 18 juin 2009 à 11:08 (CEST)

---

Interwiki

Probablement plus que tout autre modèle, ce modèle-ci devrait exister sur toutes les wikis, éventuellement sous un nom différent s’ils le désirent (mais alors avec redirection pour que {{lang}} reste utilisable partout - question de bon sens), il faut bien entendu ajouter des liens interwiki en particulier lorsque le nom du modèle diffère !

Un bot pourrait éventuellement aider, il me semble (je suis sûr que ce modèle existe déjà sur bien plus de wiki que ne le laisse présumer la liste des interwiki actuellement mentionnés). Edit : afin de faciliter la tâche au bot, j’ai rassemblé ici déjà une série de liens interwiki, à lui de les propager, et éventuellement en collecter d’autres (attention certaines pages sont protégées, il faudra donc un bot avec privilèges).

De plus, il faudrait inciter les autres wikis, lorsque ce n’est pas encore le cas, à apporter un support du paramètre dir= (certes en dehors de l’arabe, l’hébreu et le yiddish, il y a probablement peu de langues qui nécessitent réellement la présence d’une telle option), voire même texte= et trans= (ou leurs équivalents), et bien entendu documenter un minimum ce modèle.

— MetalGearLiquid ^{[m’écrire]} 21 juillet 2009 à 09:52 (CEST)

À noter :

• pl:Szablon:Lang ne semble pas fournir le même résultat que sur les autres wikis, car ce modèle semble se contenter de mettre le code langue entre parenthèses, mais n’affichera pas le texte passé en paramètre (ce qui prête non seulement à confusion, mais a le désagréable effet de dégrader l’article - on doit donc actuellement renoncer sur la wikipédia en polonais d’utiliser un tel modèle, ou trouver celui qui fait ce qu’on attend de lui…).
• ht:Modèl:Lang non plus ne fait pas du tout ce à quoi on est en droit de s’attendre.
• Je n’ai pas trouvé de modèle {{lang}} sur les wikipédias : FI (finnois), GOT (gotique), HE (hébreu), LA (latin), VO (volapük), YI (yiddish), cette liste est loin d’être complète, car je ne me suis borné qu’à tester une trentaine de wikis sur les quelques 250 disponibles !

— MetalGearLiquid ^{[m’écrire]} 21 juillet 2009 à 10:41 (CEST)

Merci pour ces interwikis, en effet très utiles.

Pour le paramètre dir: sa présence n'est plus une obligation depuis le passage de la norme WCAG à sa version 2, les agents utilisateurs (navigateurs, synthèses vocales, etc.) étant censés déduire le sens de la lecture et de l'affichage à partir de la mention de lang. --Lgd (d) 22 juillet 2009 à 08:54 (CEST)

Merci pour l’info relative à dir, mais depuis quand est entrée en vigueur la WCAG 2 (ou plutôt sa mise en application sur le terrain), et quelle est la proportion d’agents ancien encore en service ? (pour un navigateur gratuit pour autant que le vieux PC peut l’utiliser sans ramer, passe encore… mais quid des agents payants telles les synthèses vocales à destination de personnes peu aisées et ne pouvant s’en passer… donc à moins que cette recommandation soit très ancienne et que le pourcentage de personnes n’ayant pas accès à une version conforme WCAG 2, je ne suis pas entièrement convaincu qu’il soit déjà opportun de se passer des dir). — MetalGearLiquid ^{[m’écrire]} 22 juillet 2009 à 09:10 (CEST)

C'est faux ! Le code de langue ne fait QUE mentionner la langue, pas directement l'écriture utilisée pour celle-ci (et il peut y en avoir plusieurs).

Le navigateurs en revanche sont « sensés » reconnaitre le sens de l'écriture, mais l'algorithme bidi ne mentionne pas l'état initial de la direction (rtl ou ltr) qui soit s'appliquer pour les premiers caractères, quand ceux-ci sont de direction non stricte (par exemple les ponctuations). Unicode propose bien des caractères d'encapsulation de la direction, mais en HTML ils ne sont pas recommandés du-tout.

Tant qu'on ne pourra pas infiquer explicitement l'écriture utilisée, mais seulement la langue, on ne pourra pas se passer du paramètre "dir=" qui sert à donner la valeur initiale de l'algorithme standard BiDi. WCAG, même en version 2, ne peut pas s'en passer, sauf si le paramètre de langue mentionne aussi explicitement le code (d’origine ISO 15924, mais enregistré aussi dans le registre IANA) de l'écriture (dans un sous-label après le(s) sous-label(s) de langue d'une étiquette de langue BCP 47 standard) dans laquelle les premiers caractères seront interprétés (sachant aussi que dans Unicode plusieurs écritures différentes sont encodées avec les mêmes caractères unifiés, par exemple Hani/Hans/Hant, ou encore Latf/Latg/Latf et qu'un code qui a été demandé aussi pour la variante API de l'écriture latine).

Pour s'en passer, il faudrait pouvoir s'assurer que le paramètre d'écriture est bien passé dans le paramètre de langue (par exemple ar-Arab et non seulement ar), ce qui est impossible à tester ici (sauf si on ajoute un paramètre supplémentaire).

En principe, l'écriture Arab devrait être déduite par défaut du code langue ar pour la langue arabe, mais il ne l'est pas des codes d'autres langues qui s'écrivent aussi dans cette écriture arabe (et dans d'autres écritures...). Et les navigateurs pour l'instant n'ont pas des données stabilisées pour le faire correctement (le travail de codification est encore en cours dans les groupes de travail CLDR et ISO 639, et le registre IANA est encore incomplet, et largement inutilisé).

Il y a quelques exceptions (voir BCP 47) pour lesquelles des codes langues ont un code écriture associé implicite. Mais ce n'est pas le cas de toutes les langues (il suffit de regarder le registre IANA des sous-labels pour la codification des langues). Globalement cela concerne quelques langues mais pas toutes, et en tout cas JAMAIS les langues pour lesquelles plusieurs écritures sont co-officielles dans un ou plusieurs pays.

Quant au nombre de langues qui nécessitent ce paramètre, elles sont bien plus nombreuses que vous ne le pensez (d'une part parce que ça ne concerne pas seulement 2 écritures, mais aussi parce que de nombreuses autres langues utilisent aussi ces écritures droite-à-gauche).

Bref, oui WCAG 2 améliorera les choses, mais pas tout seul. D'une part le travail de normalisation et de codification reste à achever (la norme ISO 639 n'est pas encore complète, ni BCP 47), et d'autre part tout ça doit être mis en œuvre avec des bases de données à jour dans les navigateurs. Dans l'immédiat (en fait encore pour longtemps), on ne pourra pas se passer de ce paramètre de direction.

Il faut savoir lire correctement les normes... Verdy p (d) 30 juin 2010 à 22:40 (CEST)

Pour info, on discute actuellement d’utiliser ce modèle sur Wikisource. Cdlt, VIGNERON * ^discut. 23 juillet 2009 à 13:59 (CEST)

Je n’ai pas trouvé de source de cette discussion sur s:Modèle:Lang, peux-tu en fournir le lien stp ? Merci d’avance. — MetalGearLiquid ^{[m’écrire]} 24 juillet 2009 à 00:40 (CEST)

Pour faire plus joli

Si j'avais eu le droit d'y toucher, j'aurais simplement remplacé « ambigüe » par « ambiguë » dans le troisième titre. C'est peu de chose, mézenfin. Cordialement. Jymm (flep flep) 10 octobre 2010 à 20:59 (CEST)

variantes locales d'une meme langue.

Si l'information de ce modele est utilisée pour lire en audio, comment peut-on preciser les variantes locales des noms? Par exemple le nom Ranelagh, localité Irlandaise est prononcé localement, en anglais, ranela. Mais les anglais, quand ils parlent du parc de londres Ranelagh Garden, semblent dire ranelai.

Je me demande quoi mettre pour Ranelagh (métro de Paris)...

CQui bla : 8 mars 2011 à 17:52 (CET)

Il est possible d'ajouter au code de langue différents codes complémentaires dont la variante géographique. Cependant, l'idée clé est de s'en abstenir sauf nécessité évidente et de conserver des codes de langues minimaux autant que possible.

Dans ton exemple, on préciserait très éventuellement la prononciation anglaise avec le code ga-GB. En revanche, pour la prononciation française, fr sera suffisant si le contexte n'est pas déjà lui-même en français (c'est donc inutile dans un paragraphe d'article de WP, par exemple). Voir à ce sujet Choosing a Language Tag. Cela dit, il n'est pas requis, du point de vue accessibilité, de préciser la langue des noms propres. Cordialement, --Lgd (d) 8 mars 2011 à 19:01 (CET)

Nom en clair

Je propose de créer une sous-page qui permette d'associer le nom de la langue au code. Ceci permettrait de clairement afficher le nom d'une langue avec un petit signal (après un passage de robot pour les transformer), ce la permettrait aussi d'unifier les modèles lang et étymologie. {{ #switch: langue | allemand =de | alsacien=gsw | anglais =en | arabe =ar | arménien =hy | azéri =az | basque=eu | bengali=bn | breton=br | bulgare=bg | catalan =ca | coréen =ko | corse=co | croate=hr | danois=da | espagnol=es | français=fr | finnois=fi | grec ancien=grc | grec moderne=el | hébreu = he | hindi=hi | indonésien=id | italien=it | japonais=ja | khmer=km | latin =la | laotien=lo | luxembourgeois=lb | macédonien=mk | malgache=mg | néerlandais=nl | occitan=oc | provençal=oc | ourdou=ur | persan=fa | farsi=fa | phénicien=phn | polonais=pl | portugais =pt | portugais brésilien=pt-BR | russe=ru | serbe=sr | suédois=sv | thaï=th | tibétain=bo | turc=tr | vietnamien=vi | inconnu }}

Vincnet G discuss 14 mai 2011 à 15:34 (CEST)

Voir {{langue}}. Cordialement, --Lgd (d) 14 mai 2011 à 15:46 (CEST)

Comportement étrange en syriaque (rtl inside)

Bonjour,

Sur la Wikisource (eg. sur cette page ici et sur les suivantes), le s:modèle:lang (est-ce bien le même d’ailleurs ? il semblerait que oui ce n’est visiblement pas le même mais peut-être un spécialiste pourrait vérifier) a un comportement bizarre : il inverse l’ordre des mots sous Chromium (version 12 sous Ubuntu 10) mais pas sous Firefox ! Exemple de ce qui devrait apparaître : ܓܠܵܝܢܐ ܕܩܕ̈ܝܫܐ. Est-ce normal et y a-t-il quelque chose à faire pour corriger cela ? Edit: en utilisant la même syntaxe, le problème n’apparaît pas sur la Wikipédia. Cdlt, Vigneron * ^discut. 19 juillet 2011 à 16:23 (CEST)

Le code HTML généré est identique entre les modèles de Wikipedia et de Wikisource, l'essentiel du code CSS également. Je ne vois a priori rien qui dépende du site dans ce souci (bug du navigateur, plutôt). Cordialement, --Lgd (d) 19 juillet 2011 à 20:25 (CEST)

Étrange, si cela dépendait uniquement du navigateur le bug devrait survenir sur Wikisource et sur Wikipédia, non ? et pas juste sur Wikisource. Merci en tout cas pour avoir regardé. Cdlt, Vigneron * ^discut. 19 juillet 2011 à 23:17 (CEST)

En fait il manque un attribut CSS dans ce modèle (ou dans la feuille de style générale de Wikipédia, voir plus bas), pour le cas où un attribut HTML dir="rtl" ou dir="ltr" est mentionné (dans le test {{#if:{{{{dir|}}}| dir="{{{dir|}}} ...}}) : on devrait avoir aussi un style="unicode-bidi:embed" pour résoudre le problème (à ajouter même si dir="ltr", ce qui permet d'inclure par exemple une transcription latine au milieu d'un texte arabe par exemple) des inversions de certains mots ou ponctuations au début ou à la fin de la transcriptions, à cause du comportement contextuel par défaut de l'algorithme Bidi d'Unicode.

• L'indication de seulement l'attribut HTML dir ne suffit pas (il sert seulement à préciser la direction à appliquer au début du texte inclus, mais pas la façon dont la direction sera appliquée à la suite de l'élément ainsi marqué, voire même pour les derniers caractères à l'intérieur de l'élément marqué (dont la direction dépend de la direction déterminée non pas au début de l'élément de texte marqué, mais de celle au début du paragraphe).
• L'indication du code langue, ou même d'un code d'écriture, ne suffit pas non plus (une même langue écrite dans une même écriture dispose encore de caractères de direction non absolue mais contextuelle, il suffirait que le texte commence par des espaces, des ponctuations ou des symboles, qui continuent à hériter de la direction des caractères codés juste avant, même si ces carastères d'avant sont hors de l'élément marqué).

Ce comportement contextuel de l’algorithme Bidi standard d'Unicode marche la plupart du temps (c'est un bon compromis adapté aux cas les plus fréquemment rencontrés dans les textes à écritures bidirectionnelles), mais il ne sait pas lever certaines ambiguïtés impossibles à déterminer par le seul codage, telles que celles qui surviennent quand on a une liste de termes dans différentes langues, séparés par des ponctuations accolées qui bougent en même temps que le texte, et qui provoque aussi des inversions d'éléments dans la liste qui normalement se lit encore dans un seul sens

Le style "unicode-bidi:embed" permet d'indiquer ce que l'algorithme doit faire (dans le cas des caractères dont la direction est contextuelle, comme les espaces, symboles, ponctuations et chiffres) et que tout ce qui est inclus dans l'élément doit être traité en un seul et même niveau, séparé du reste du texte situé à l'extérieur qui retrouve alors la même direction après cet élément marqué que celle qui était avant l'élément marqué (par défaut le texte situé après continue d'hériter la direction qui était dans l'élément encapsulé, sauf les ponctuations finales à l'intérieur d'un élément non marqué inséré en fin de paragraphe, car alors ces pontuations se retrouvent alors déplacées à la fin du paragraphe comme si elles n'étaient pas marquées du tout).

Notes :

• La feuille de style CSS par défaut de Wikisource (et aussi de Wikipédia) mentionne déjà ce style "unicode-bidi: embed;", mais uniquement pour le sélecteur CSS "span[dir=rtl] { ... }".
• En fait il devrait l'appliquer à tous les éléments HTML (pas seulement span), et quelle que soit la direction indiquée par l'attribut HTML dir (donc avec les deux sélecteurs CSS "[dir=rtl], [dir=rtl] { ... }" basés uniquement sur le test de valeurs de l'attribut HTML et non du type d'élément HTML).
• Il est excessivement rare qu'on ne désire pas de ce style quand on indique l'attribut HTML dir (et de vouloir alors le comportement contextuel par défaut d'Unicode, comparable au style "unicode-bidi: inherit;" qui est le style par défaut de tous les éléments HTML) ; alors qu'il suffit de justement ne pas mentionner cet attribut dir (et donc de ne pas indiquer ou de laisser vide le paramètre dir de ce Modèle:Lang)... Verdy p (d) 8 mars 2012 à 18:34 (CET)

Sinon je confirme que ce ne peut être qu'un bogue de l'implémentation de l'algorithme Bidi standard dans la version du navigateur utilisée, si les mots sont inversés autour de l'espace (dont la direction est bien contextuelle et doit être celle résolue pour le caractère précédent, ce qui ne provoque aucun changement de direction des mots et espaces internes à une même phrase syriaque ou arabe. Il est probable que la version du navigateur ne sache pas encore déterminer que les lettres syriaques sont de type RTL fort (obligatoirement de droite à gauche), et qu'alors le navigateur se plante sur l'espace en le résolvant à tord selon la direction du paragraphe au lieu de la direction du caractère précédent (cette direction contextuelle de l'espace ne se résout en celle résolue pour le début du paragraphe que s'il n'y a pas de caractère précédent dans le même paragraphe).

Si tu utilises Chromium, tu est donc probablement sous Linux, et sous Linux l'algo Bidi fait partie d'une librairie partagée (vérifie les versions de tes librairies, notamment Pango qui est semble-t-il le moteur de rendu de texte utilisé par Chromium sous Linux).

Sinon, ton message étant déjà ancien (mais posant une question qui peut en intéresser d'autres...), il est probablement corrigé maintenant (et le moteur de rendu de texte a subit de profonds changements depuis, aussi bien dans Chromium que Chrome, mais aussi Firefox, car c'est une pièce de code relativement complexe prenant en compte des difficultés liées à la complexité de recherche résolution des polices utilisables pour un texte donné, et leur prise en compte ou non de certains mappings internes pour TrueType/OpenType, ou les vieilles polices bitmap sans TrueType encore utilisées largement sous Linux et d'origine X11). Verdy p (d) 8 mars 2012 à 18:51 (CET)

Police Pinyin

Bonjour,

Actuellement les transcriptions en pinyin sont désagréables à lire. Le mieux serait d'utiliser un police normale, tout en conservant l'italique il me semble. Voir la discussion ici. Merci de m'approuver (ou de proposer mieux encore), que l'on puisse procéder à une modification :) Zandr4^[Kupopo ?] 9 mars 2013 à 14:31 (CET)

Toi qui me lis, approuve-moi ! Zandr4^[Kupopo ?] 11 mars 2013 à 17:31 (CET)

J'approuve. Cela m'irrite depuis longtemps, mais pas tout le temps. Aujourd'hui j'ai tenté d'en savoir plus, après m'être aperçu que ce n'était pas limité au pinyin. Le résultat dépend du média utilisé (d'où l'intermittance de mon irritation) : écran ou papier, quel navigateur (et sa configuration ?). Lorsqu'un script latin est spécifié dans le code de langue (zh-Latn-pinyin ou akk-Latn p.e.), on se retrouve avec un attribut script="font-family= sans-serif;" dans la balise span et je suppose que c'est de là que vient le problème (qui n'est visible que lorsque le rendu par le média du texte normal est différent de celui du texte balisé "sans-serif"). Ce même problème se pose pour le texte en langue latine, comme p.e. dans le modèle {{etc.}} où l'on se retrouve avec ", etc." sans empattement au sein d'un texte éventuellement avec empattement, ce qui fait bizarre. Malheureusement, je ne parvient pas à mettre la main sur la cause profonde du phénomène et ne sais donc même pas où signaler le problème. Si quelqu'un a une idée… Klipe (discuter) 29 septembre 2013 à 16:37 (CEST)

Le modèle lang se contente d'ajouter <span class="lang-xx" lang="xx">

Mediawiki ajoute xml:lang="xx" style="font-family: sans-serif;"

Les css peuvent s'appliquer, mais je n'ai rien vu concernant le chinois (pinyin ou non) dans le css de wiki.

Les navigateurs ont aussi une gestion de l'affichage des langues qui peut éventuellement changer la police. Cela dépend bien sur du navigateur mais peut-être aussi des polices installées sur l'ordinateur.

Il peut aussi y avoir le modèle {{Chinois}} dans la partie. Pour le pinyin, il utilise le code langue zh-latn-pinyin et met en italique en encadrant le modèle lang par un code><span style="font-style:italic;">.

Il est possible de forcer l'affichage dans une police donnée (ici arial) en ajoutant à spécial:ma page/common.css :

:lang(zh-latn) { font-family: arial, sans-serif !important; }

Zebulon84 (discuter) 29 septembre 2013 à 20:00 (CEST)

En effet, correction : il y a 2 problèmes.

• "sans-serif" explicite, alors que le reste du texte est "sans-serif" seulement pour @media screen ==> À l'impression, tous les textes balisés par le modèle {{lang}} sont p.e. en Arial alors que le reste peut être en Times. Je l'ai vu aussi hier pour des titres en anglais via modèles Ouvrage ou Article. Et lorsque je regarde la source maintenant, je ne le vois plus !? Quelque chose (de plus) m'échappe…
• Le pinyin (+ Wade-Gile etc.) sous FireFox : lorsqu'on spécifie le script Latn pour la langue zh, on utilise quand même la police de caractère configurée pour les sinogrammes (p.e. SimSun, plutôt qu'Arial). Or pour d'autres langues ça fonctionne correctement (p.e. akk-Latn mentionné plus haut s'affiche bien avec une autre police que akk). Je constate que sous IE, c'est Arial qui semble utilisé dès qu'on spécifie un script latin pour la langue chinoise (mais par contre on n'a pas droit à du cunéiforme avec la langue akk dans son script d'origine). Serait-ce donc un problème FireFox ?

J'y perds mon lang-la Klipe (discuter) 30 septembre 2013 à 14:18 (CEST)

Oui c’était bien un problème sur Firefox qui changeait la police même quand le subtag -Latn* était spécifié, ça concernait aussi d’autres langues comme le japonais ou le coréen. C’est maintenant corrigé sur Firefox 36 [1]. Cordialement, — Thibaut ^{「にゃんぱすー」} 12 mars 2015 à 09:16 (CET)

Correction

Bonjour. Le terme « syntaxte » (syntaxe) trouvé en début d'article est à corriger.--Cjp24 (discuter) 1 septembre 2013 à 13:50 (CEST)

Mais cette erreur étant sur la page de documentation (non protégée) vous auriez pu corriger directement. — Zebulon84 (discuter) 1 septembre 2013 à 16:41 (CEST)

J'ai tout simplement suivi la procédure suivante indiquée : [2]. --Cjp24 (discuter) 1 septembre 2013 à 16:52 (CEST)

Pour la majorité des modèles, la documentation est dans un « sous page » : une page dont le nom commence par le nom du modèle auquel est ajouté « /Documentation ».

Pour modifier cette page il est possible de cliquer sur « [modifier le code] » qui est à coté de de « Documentation », en haut du cadre vert. Un lien vers la page de documentation et plus d'information à ce sujet est disponible tout en bas du cadre vert.

Zebulon84 (discuter) 1 septembre 2013 à 19:09 (CEST)

Possibilité de retirer le lien du modèle sous la forme {{Lang-fr|}}

Bonjour,

J'utilise le modèle d'une façon « détournée », c'est-à-dire en mettant un tiret après Lang ( {{Lang-fr|Texte}} ) afin d'obtenir, par exemple :

(en français : Texte)

Mais dans un article où j'utilise plusieurs fois ce modèle de cette façon, avoir le lien français à chaque fois est un inconvénient. Y a-t-il une manière de l'annuler, de la même façon qu'on annule le lien dans le modèle {{s|XX|e}} / {{s-|XX|e}}.

Cordialement, --Daehan (discuter) 4 décembre 2013 à 11:56 (CET)

Le modèle {{lang-fr}} n'est pas ce modèle avec un tiret, est un autre modèle.

Le plus simple pour ne pas avoir de lien est d'écrire le texte :

(en anglais : {{lang|en|text}})

donne : (en anglais : text).

N'est-ce pas plus simple que de créer encore tout une suite de modèle uniquement pour ça ?

Zebulon84 (discuter) 4 décembre 2013 à 23:23 (CET)

Bien sûr, pas question de créer un autre modèle. Je me demandais juste s'il y avait une subtilité comme celle évoquée.

Merci pour la réponse. Cordialement, --Daehan (discuter) 5 décembre 2013 à 00:39 (CET)

Acronyme

Doit on utiliser ce modèle pour des acronyme étrangers ? Ni des mots des des expressions, mais des acronymes ? Christophe Cagé - M'écrire * Mes articles

trans

Hello,

{{lang|ja|texte=先生|trans=sensei}} = 先生 (sensei)

Est-ce possible de faire en sorte que le texte dans le paramètre "trans" soit automatiquement mis en italique ? Merci. — Thibaut ^{「にゃんぱすー」} 12 mars 2015 à 09:14 (CET)

 Thibaut120094 :  Fait. – Zebulon84 (discuter) 9 avril 2015 à 15:50 (CEST)

 Zebulon84 : Merci ! — Thibaut ^{「にゃんぱすー」} 9 avril 2015 à 17:22 (CEST)

Quelque chose a-t-il changé récemment concernant le paramètre "trans". Il me semblait qu'avant {{lang|grc|Ἐξαγωγή|trans=''Exagogé''}} donnait Ἐξαγωγή (Exagogé). Aujourd'hui, cela donne plutôt ἘξαγωγήExagogé, ce qui est assez laid. --Chamberí (discuter) 11 juin 2015 à 20:17 (CEST)

J'ai effectivement modifier la méthode de génération du code, et j'ai oublié de changer le nom d'une variable...

corrigé. — Zebulon84 (discuter) 11 juin 2015 à 21:01 (CEST)

Ça a l’air résolu, merci à vous deux . — Thibaut ^{「にゃんぱすー」} 11 juin 2015 à 21:02 (CEST)

 Zebulon84 et Chamberi : Bonjour, La transcription en italique est effectivement une bonne idée mais il faudrait que les parenthèses qui entourent la transcription soit elles en romain. GabrieL (discuter) 18 octobre 2016 à 15:39 (CEST)

C'est bien ainsi que je l'avais programmé.  Ltrlg a étendu l'italique aux parenthèses le 11 septembre dernier. — Zebulon84 (discuter) 19 octobre 2016 à 08:25 (CEST)

D'accord, merci.  Ltrlg : Bonjour, cela me parait fautif de mettre les parenthèses en italique, seule la transcription en alphabet latin fait appel à la langue étrangère, pas les parenthèses qui doivent au contraire rester en romain pour montrer qu'elle ne font pas partie de la transcription. GabrieL (discuter) 19 octobre 2016 à 09:46 (CEST)

 Zebulon84 : bonjour, depuis une semaine et malgré une notification et un message sur sa PdD personnelle, Ltrlg qui s'est connecté trois fois (si j’en crois ses contributions) ne m'a pas répondu. Est-ce que tu peux revenir à ta version précédente (italique pour la transcription mais romain pour les parenthèses ? GabrieL (discuter) 25 octobre 2016 à 10:30 (CEST)

Dans une parenthèse, virugle ou parenthèses ?

Lorsque l'écriture alternative est donnée entre parenthèses, faut-il écrire

1. « République arabe d'Égypte (en arabe جمهوريّة مصر العربيّة, Gumhuriyya Miṣr al-Arabiyya) », avec une virgule, ou
2. « République arabe d'Égypte (en arabe جمهوريّة مصر العربيّة (Gumhuriyya Miṣr al-Arabiyya)) », avec deux jeux de parenthèses ?

Les deux formes sont présentes un peu partout.

—Tinm, le 18 septembre 2015 à 23:36 (CEST)

Résolu.

Voir Discussion Wikipédia:Conventions_typographiques#Transcription des langues étrangères : dans une parenthèse, virugle ou parenthèses ?. —Tinm, le 2 février 2016 à 00:27 (CET)

Signe égal : le mal aimé ?

Bonsoir,

Dans le titre de l'épisode 51 de la série Chica Vampiro, celui-ci contient deux fois le signe plus et une fois le signe égal. Après vérification, ce n'est pas les signes plus qui gênent mais le égal, si je laisse celui-ci ça ne fait tout simplement pas apparaître le titre de l'épisode, juste les parenthèses, j'ai donc du retirer le signe. Mais est-ce normal que ce signe gêne ? --Anakindu72 (discuter) - Le Mans, le 2 octobre 2015 à 18:27 (CEST)

Si le texte contient le signe égal, il faut faire comme ceci : {{lang|es|texte=0 + 0 = la tête à Toto}}. Cordialement, — Thibaut ^{「にゃんぱすー」} 2 octobre 2015 à 19:00 (CEST)

Ça a effectivement résolu le problème, merci. --Anakindu72 (discuter) - Le Mans, le 2 octobre 2015 à 19:47 (CEST)

Code inexistant

Bonjour !

Je suis en train de rédiger la page du volapük. Si cette langue construite du xix^e siècle possède bien un code IETF (vo), comme l'espéranto (eo), l'interlingua (ia) ou le kotava (avk) qu'il m'arrive de citer pour comparer, ce n'est pas le cas d'autres comme l'idiom neutral ou le latin sans flexion. Je ne viens pas m'en plaindre, je suis déjà surpris que le kotava en ait un, mais je suis du coup ennuyé : que faire ? J'ai essayé d'utiliser le code « mis », mais il n'est pas non plus pris en compte. Dois-je me résigner, en contradiction avec les recommandations pour l'accessibilité, à ne pas utiliser {{lang}} ? Ou y a t-il un moyen comme en HTML pour citer une langue sans code (<span lang="x-idiom neutral" />) ? Dois-je utiliser ce code HTML directement ?

Sinon, je proposerais bien d'ajouter le code « mis », pour marquer le changement de langue sans la préciser, pour ce genre de cas particuliers.

Fleniko (amicalement),
Ἐμμανουήλ ^{[@] -- [✉]} 4 novembre 2015 à 11:30 (CET)

tokelau

Bonjour, apparemment le code langue pour le tokelau, à savoir "tkl", n'est pas pris en charge (voir l'article créé ce jour : inati). Serait-il possible de l'ajouter ? D'avance merci. Cordialement, choumix (discuter) 29 février 2016 à 10:42 (CET).

 ChoumX : c’est fait [3]. --Moyogo/ ^(discuter) 29 février 2016 à 10:56 (CET)

 Moyogo : : Merci, Moyogo ; toujours à la pointe concernant la linguistique ! Cordialement, choumix (discuter) 29 février 2016 à 11:07 (CET).

Prise en charge automatique du sens d'écriture

Bonjour

Une modification récente d'Oliv0 (d · c · b) m'a fait me rendre compte que le modèle ne prend pas automatiquement en compte le sens d'écriture, alors que le module Langue à justement une fonction directionLangue(frame).

Le problème est que si le texte (par exemple en araméen) est aligné droite avec style="text-align:right;", les points de fin de phrase se retrouvent à droite, c'est à dire en début de phrase.

N'y a t'il pas un moyen de régler ça directement sans avoir à ajouter un paramètre dir= (direction) au modèle ? Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 4 mars 2016 à 11:51 (CET)

 SyntaxTerror : la direction droite à gauche de la langue est prise en compte si elle est indiquée dans Module:Langue/Data, ce qui n'est actuellement pas le cas pour l'araméen. Si cette langue est toujours écrite de droite à gauche, il faut ajouter , rtl = true après le nom de la langue, sur la ligne data["arc"] = {code = "arc", nom = "araméen"}.

Exemple :

השפה הכתובה מימין לשמאל.

שתי שורות.

Attention, l'éditeur de texte lui ne gère pas la direction de la langue, donc les points sont du mauvais coté : j'ai fait ici un copié-collé depuis Google traduction, point inclus. Ils sont au bon endroit sur Google, arrive au mauvais endroit dans l'éditeur de texte, sont au bon endroit lors de l'affichage.

— Zebulon84 (discuter) 4 mars 2016 à 12:48 (CET)

Autre possibilité pour prendre en compte une direction de droite à gauche : préciser le type d'écriture. Par exemple le turc est considéré comme gauche à droite car il est aujourd'hui écrit en alphabet latin, mais si un texte utilise l'alphabet arabe il sera considéré de droite à gauche à condition d'utiliser le code de langue « tr-arab ». — Zebulon84 (discuter) 4 mars 2016 à 13:00 (CET)

 Zebulon84 : merci pour cette réponse rapide et ces précisions. Je viens d'ajouter , rtl = true à l'araméen sur Module:Langue/Data. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 4 mars 2016 à 13:24 (CET)

Réduction du nombre d'invocations Lua

J'ai effectué cette modification, qui court-circuite le Lua pour le code de langue en, après avoir constaté que le modèle affecte déjà les performances à partir de quelques centaines d'utilisations.

L'idée est d'améliorer les performances au niveau global, en réduisant le nombre de recours au module Lua, tout en limitant l'overhead pour les inclusions faisant encore appel au Lua.

Quelques notes :

• je me suis décidé pour seulement en et pas un switch avec en, de, es… car en est vraiment le plus utilisé, dix fois plus que ceux qui suivent (de, es…)
• support du paramètre dir, à ce jour jamais utilisé avec le code en, mais pourrait éventuellement servir pour inclusion d'un passage "ltr" à l'intérieur d'un texte "rtl"
• en revanche pas de support du paramètre trans, en l'occurrence inutile, et plus complexe à implémenter (notamment les italiques)

od†n ↗^blah 26 janvier 2017 à 19:11 (CET)

 od†n : je propose de simplifier tout en supportant tous les paramètres avec le code :

{{#ifeq: {{{1}}}{{{dir|}}}{{{trans|}}} | en
  | <span class="lang-en" lang="en">{{{texte|{{{2}}}}}}</span>
  | {{#invoke:Langue|langue}}
}}

— Zebulon84 (discuter) 16 avril 2017 à 09:15 (CEST)

Comme je n'avais pas compris sur le coup, j'explique le code que tu proposes : court-circuitage ssi 1=en && dir vide && trans vide.

Les performances restent les mêmes, et je ne suis pas certain que cela soit plus simple… donc vote "mmm… non." pour ma part. od†n ↗^blah 16 avril 2017 à 15:30 (CEST)

Langue navajo

Apparemment le code nv (langue navajo) n'est pas pris en charge. Pourrait-on corriger cela. Merci. — Berdea (discuter) 4 novembre 2017 à 10:20 (CET)

Bonjour Berdea, le code nv pour la langue navajo est bien dans la liste donc il est pris en charge dans le modèle {{Langue}}.

Pour utiliser {{lang-nv}}, il faut le créer (vous pouvez en faire la demande sur Projet:Modèles).

Cordialement. — Thibaut (discuter) 4 novembre 2017 à 11:57 (CET)

Merci. Du coup j'ai créé le modèle {{lang-nv}}. — Berdea (discuter) 5 novembre 2017 à 11:10 (CET)

incompatible avec la prévisualisation

Bonjour,

Quand ce modèle est utilisé en haut d'un RI, il disparait de la prévisualisation. Existe-t-il un moyen de lui proposer un affichage alternatif comme pour les images ? car dans le cas d'un synonyme faisant partie d'un jargon non francisé mais d'usage très répandu, le fait qu'il soit occulté devient un réel problème. -- Camion (discuter) 2 février 2018 à 10:44 (CET)

Bon, discussion ici. -- Camion (discuter) 2 février 2018 à 15:19 (CET)

Présence d'un zéro à la fin de la translittération

Quelle est l'utilité du zéro à la fin de la translittération ? Est-ce une erreur ? Exemple : αβγδ (abcd). — Orgyn (talk) 27 avril 2018 à 20:49 (CEST)

 Orgyn : aucune. C'est un bug (introduit par moi il y a deux semaines ) que je viens de corriger. — Zebulon84 (discuter) 27 avril 2018 à 22:41 (CEST)

Détection des erreurs

Bonjour,

Sur le modèle équivalent sur Wikisource s:Modèle:lang, il y a une catégorisation automatique quand il y a une erreur de syntaxe, c'est fort pratique. Serait-il possible d'avoir la même chose ici ?

@Zebulon84 et @Thibaut120094

Cdlt, Vigneron * ^discut. 14 juillet 2018 à 14:45 (CEST)

Bonne idée, je vais ajouté ça. — Zebulon84 (discuter) 14 juillet 2018 à 19:24 (CEST)

 Fait.  VIGNERON : les erreurs sur la langue étaient catégorisées depuis longtemps dans Catégorie:Page avec code de langue invalide. Les pages sans texte (ou paramètre 2) sont désormais dans Catégorie:Page utilisant un modèle avec une syntaxe erronée à la lettre « L ». Dans tout les cas, un message d'erreur est affiché pour repèrer facilement le modèle qui pose problème. — Zebulon84 (discuter) 15 juillet 2018 à 08:01 (CEST)

Problème avec le moldave (mo)

Bonjour

Je viens de corriger sur WikiData un nom de langue indique comme en moldave (IETF = mo) à cause d'un problème de code non valide sur Leova.

Le code affiché avant le nom (dans l'infobox liée à WikiData) était bien (ro), mais le modèle lang reconnaissait seulement « mo », alors que ce code est noté comme invalide dans Module:Langue/Data.

Je ne sais pas comment régler ce problème qui peut très bien survenir encore, pour une autre langue ou si WikiData ne retire pas ce code (j'en ai parlé sur leur bistro, mais je ne sais pas ce que ça va donner), et de toute façon, je ne peux pas toucher aux codes, les pages étant protégées.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 1 mars 2019 à 16:11 (CET)

"cop" pour le copte

Bonjour. Serait-il possible de rajouter le code de langue "cop" pour le copte…? qui est utile pour transcrire certains extraits des ouvrages de Champollion !--Lorlam (discuter) 18 avril 2021 à 23:53 (CEST)

Langue : irlandais

Bonjour, suite à l'article du jour Montagnes de Wicklow, dans le RI, on peut y lire « ...et en ga : Sléibhte Chill Mhantáin ».. Le modèle {{en irlandais}} renvoie vers la page d'homonymie ga Gabon, Galice, Gambie, Géorgie, etc. et non pas Irlandais. Un essai de remplacement par le modèle {{lang-ga}} affiche aussi le même résultat. Il y aurait peut-être un petit réglage à faire (chose que je n'ai su faire). Merci ! => Sg7438 discuter, c'est ici ! 14 décembre 2021 à 05:33 (CET)

Code de langue et translittération

Bonjour, je m'interroge sur cette utilisation du modèle. Rémih y écrit ''{{lang|ru|Memorial}}'' sur la translittération de Мемориал (association russe). Outre l'italique qui n'a pas lieu d'être, le modèle est-il ici censé... faire rouler le r aux synthétiseurs vocaux ?

Salutations — Vega (discuter) 13 janvier 2022 à 01:21 (CET)

Peut-être {{lang|ru-Latn|Memorial}}, Memorial, est plus adéquat, du moins dans l’introduction à côté de la graphie cyrillique ? Par la suite et dans les autres sections, c’est un peu pédant. L’usage est clairement « Memorial » et « Mémorial » en français, pas besoin de mettre le code langue ru à chaque fois. Le logo anglais utilise lui-même « Memorial » ; on n’utilise pas le modèle lang pour tout les noms d’organisation en anglais. Pourquoi le faire ici ? --Moyogo/ ^(discuter) 13 janvier 2022 à 11:06 (CET)

Noms de marques ou de produits

Bonjour,

Est-il nécessaire d'utiliser un format spécial pour des noms de marque d'origine étrangère (par exemple Triumph, Honda, Rolls-Royce, etc.) ou peut-on se contenter de les écrire directement et littéralement ?

De même, quelles sont les règles pour le nom de certains produits de ces marques comme Daytona, Thunderbird, Street Triple, Chief et autres ? Olinone (discuter) 21 février 2023 à 07:26 (CET)

Bonjour Olinone et merci de la question. On pourrait arguer qu'en tant que noms propres, les marques ne doivent pas forcément se voir affubler du modèle {{langue}}, mais il ne faut pas oublier que l'une des raisons d'être de ce modèle est de s'assurer que les mots soient prononcés correctement par les lecteurs d'écran (notamment utilisés par les personnes non ou malvoyantes pour parcourir l'encyclopédie). C'est pourquoi j'aurais tendance à dire que si le nom en question est censé se prononcer différemment de ce que dictent les règles de l'orthographe française, il est effectivement bon de recourir au modèle {{langue}}.

Ainsi, dans les exemples que vous citez, je n'utiliserais personnellement pas le modèle pour Honda, habituellement prononcé à la française « onde-a » (et non « honn-da »), mais je n'hésiterais pas à y recourir pour tous les autres noms — par exemple Triumph, à prononcer « traï-eummf » et non « tri-unfe ». -- Cosmophilus (discuter) 25 février 2023 à 23:25 (CET)

Merci Cosmophilus de votre réponse. J'en comprends le sens, même si, pour le contributeur que je suis s'intéressant parfois à des entreprises et produits étrangers, la conséquence est un alourdissement non négligeable du temps passé à la mise en forme. Je vais essayer de m'y conformer au mieux.

PS: dans le cas de Triumph, il se trouve que l'usage courant de ce nom de marque en français est de le prononcer "à la française" c'est à dire comme "triomphe" (avec un "e" muet à la fin). Mais je ne vais pas soulever de polémique inutile sur ce type d'exemple. Olinone (discuter) 26 février 2023 à 08:19 (CET)

Combiner {{langue}} avec des wikiliens redirigés

À noter : Les conseils pour les liens internes dans le modèle de langue anglaise {{lang}} sont incompatibles (et opposés) avec les conseils dans ce modèle {{langue}}. Plus précisément, en:Template:Lang#Links déclare que

[[Livre des heures|{{lang|de|Stundenbuch}}]] → Stundenbuch ne fonctionne pas dans l'espace article, mais fonctionne sur talk et certains autres types de pages

mais Modèle:Langue#Liens_internes déclare

Dans le cas d'un lien redirigé, la syntaxe à privilégier est celle-ci : ''[[Deep Impact (film)|{{Langue|en|Deep Impact}}]]''

quoi faire ? Je ne sais pas. Scarabocchio (discuter) 2 mars 2023 à 12:16 (CET)

@Scarabocchio Eh bien, vérifions. Dans cette discussion et sur un article,

• ''[[The New York Times|{{Langue|en|New York Times}}]]'' → New York Times : indication de langue ok
• ''{{Langue|en|[[New York Times]]}}'' → New York Times : indication de langue ok

Cela dit, je n'ai pas lu les arguments de la discussion évoquée, Discussion Wikipédia:Atelier accessibilité/Archives accessibilité 2010#Modèle:Lang et liens internes. Salutations — Vega (discuter) 2 mars 2023 à 23:08 (CET)

@Vega merci!

Je viens de créer Utilisateur:Scarabocchio/common.css pour teinter les textes avec lang=en en rose.

Ces deux semblent fonctionner (mettre le fond en rose) tous les deux...

::''[[Nightfall (album)|{{lang|en|Nightfall}}]]'' ::

::''{{lang|en|[[Nightfall (album)|Nightfall]]}}'' ::

Mystérieux.

Scarabocchio (discuter) 3 mars 2023 à 10:47 (CET)

 Scarabocchio, fortiche ! Vous pouvez proposer cette petite manipulation à WP:Atelier accessibilité et Projet:Scripts et gadgets, elle serait pratique pour les béotiens de l'html comme moi. À première vue, il manque juste la détection des noms entiers de paramètres "langue".

Et surtout, je vous propose de demander au même atelier la modification de la documentation de Modèle:Langue, en visant notre démonstration ci-dessus. — Vega (discuter) 23 mars 2023 à 16:59 (CET)

@Scarabocchio : j'ai aussi ce genre de code dans mon commons.css (mon code fait pour toutes les langues), mais il ne marche pas à tous les coups, notamment pour les modèles bibliographiques où le texte pourtant mis dans des balises <lang> ne change pas de couleur.

Il me semble que le seul outil qui permettent de vraiment voir les passages dans d'autres langues soir le gadget accessibilité (voir Wikipédia:Atelier accessibilité/Aide gadget#Vérifier l'accessibilité des changements de langue). Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 17 novembre 2023 à 00:32 (CET)

@SyntaxTerror : je t'ai ajouté la détection dans les balises <cite> (voir 209704874), ça devrait repérer bien davantage de cas maintenant. od†n ↗^blah 17 novembre 2023 à 05:03 (CET)

Merci beaucoup Od1n.

Puisque j'ai un admin d'interface sous la main, pourrais-tu faire en sorte que mon bouton « date » écrive date={{subst:aujourd'hui}} (avec le résultat en français) dans mon Utilisateur:SyntaxTerror/common.js, c'est celui ligne 15. Ça ne marche pas de mettre des codes ISO ou des balises nowiki (voir Wikipédia:Le Bistro/16 novembre 2023#Bouton Monobook perso dans mon commons.js)

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 17 novembre 2023 à 09:58 (CET) (je regrette vraiment d'être trop faignant pour apprendre le CSS (et le JS, HTML, C, Python, etc. )

Hop, c'est réparé : 209712479. od†n ↗^blah 17 novembre 2023 à 13:12 (CET)

Préfixes, suffixes, radicaux et compagnie

Je viens de traduire l'article sur le verbe en basque depuis l'anglais et je travaille la mise en forme. J'utilise évidemment le modèle Langue pour des mots entiers, des phrases, etc. Mais qu'en est-il pour les radicaux et les affixes ? Autant, mettre le mot entier "etorri" dans une balise de langue me semble être évident, autant pour son radical "-tor-", leurs dérivés "-ator-" et "-etor-", ainsi que les nombreux affixes du style "e-", "-i", "-tu" et compagnie, je ne sais pas trop quoi faire. Ça me paraitrait logique de les mettre aussi dans le code de langue, pour éviter une lecture "à la française" par les lecteurs d'écran, mais je me demande aussi si ça peut pas poser d'autres problèmes, surtout avec les tirets qui indiquent qu'on peut rajouter des trucs avant ou après.

Sachant que dans l'article en anglais, quelques rares occurrences de radicaux et d'affixes étaient mises dans le modèle équivalent à Langue dans le Wikipédia anglais, mais c'était vraiment très rare. L'Arpetani (discuter) 26 juillet 2023 à 14:04 (CEST)

Bonjour L'Arpetani Wikipédia:Atelier accessibilité/Bonnes pratiques#Changements de langue est clair sur ce point : dans la mesure où la prononciation en basque est différente de celle en français, le modèle Langue est nécessaire pour les lecteurs d'écran. Les suffixes, préfixes et radicaux font aussi partie de la langue, donc ils sont soumis aux mêmes principes que les mots complets. Bien à vous, -- Cosmophilus (discuter) 26 juillet 2023 à 22:16 (CEST)

Merci beaucoup :) L'Arpetani (discuter) 27 juillet 2023 à 10:38 (CEST)

Mise à jour et simplification de la documentation

Bonjour

La requête Projet:Modèle/Demandes/2023#luo m'a fait me rendre compte que la doc de ce modèle est trop détaillée et pas forcément à jour.

J'ai remplacé {{#invoke:Langue|listeAliasCode}} par {{#invoke:Langue|tableauLangues}} dans la section Modèle:Langue/Documentation#Tous les codes, mais il y a sans doute plus à faire pour rendre cette doc plus utile pour le contributeur moyen (ou moyen +, car peu de gens lisent la doc des modèles ).

Des avis ?

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 17 novembre 2023 à 00:23 (CET)

Pour info, j'ai entretemps effectué ceci sur la dizaine de pages qui appelaient {{#invoke:Langue|tableauLangues}} (avec ta modif, Modèle:Langue/Documentation#Tous les codes a donc été dans le lot), parce que le tableau généré est énorme et ralentissait considérablement le chargement de ces pages (notamment au niveau du navigateur qui souffre avec autant de HTML). od†n ↗^blah 30 novembre 2023 à 01:04 (CET)

@Od1n : c'est aussi une solution, je ne pensais pas que ce tableau était si lourd. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 30 novembre 2023 à 01:16 (CET)

Mon navigateur principal est encore Pale Moon, mais il n'a pas les optimisations de performances des navigateurs modernes, et avec la quantité de markup de ce tableau il a énormément de mal. Avec Chrome c'est acceptable, mais on voit quand même que le rendu est coûteux (l'alternance des lignes change plusieurs fois, le temps d'appliquer les multiples CSS qui s'overrident). Et on peut très bien avoir des utilisateurs avec des machines particulièrement peu puissantes (je pense aux netbooks). od†n ↗^blah 30 novembre 2023 à 05:30 (CET)

@od†n : je critique pas du tout ta modif, je pense qu'il faut que tout soit le plus accessible à tout le monde si possible. Ça n'est pas si gênant que ça d'aller sur une autre page consulter une liste, qui ne sert en plus pas très souvent. Şÿℵדαχ₮ɘɼɾ๏ʁ 30 novembre 2023 à 05:46 (CET)

Translittération

Il serait préférable que les translittérations soient entre crochets [] plutôt qu'entre parenthèses (). C'est la convention la plus répandue dans le cas des bibliographies, en tout cas. Qui est d'accord avec moi ? Urhixidur (discuter) 20 novembre 2023 à 21:22 (CET)

@Urhixidur je proposerai un texte flottant encadré lorsque l'on pointe avec la souris. Et l'idée d'être entre crochets est bonne. Je travaille sur un module de transcription sur Wikisource en vue de faciliter au débutant la lecture du grec. Sicarov (discuter) 1 avril 2024 à 00:51 (CEST)