Discussion modèle:trad

mise en place d'un mode d'emploi sur la page principale. DC2

Autres discussions concernant ce modèle

• Wiktionnaire:Wikidémie/décembre 2008#Traduction par une expression
• Wiktionnaire:Wikidémie/juillet 2012#À quoi sert modèle:T
• Wiktionnaire:Wikidémie/février 2013#Modèle:T
• Discussion module:traduction#Ancres brisées

Quelques problèmes

J'ai repéré les problèmes suivants sur le modèle :

• Dans la page Comores, il y avait un trad (avec la langue nb) qui ne marchait pas. J'ai mis no à la place de nb pour le faire marcher. Est-ce que le problème vient des parenthèses qui étaient générées ?

  Cela était du à l'utilisation d'un modèle de langue contenant un lien entre crochets. Or le modèle trad fait un lien entre crochet à partir de ce nom de langue, donc un crochet dans un crochet, ça bogue forcément. Les modèles de langues avec liens doivent être "déwikifiés" pour pouvoir les utiliser. - Dakdada (discuter) 11 octobre 2006 à 20:41 (UTC)

• Quand la page du mot cité comme traduction existe dans le Wiktionnaire, mais que la section n'existe pas, cliquer sur le lien ne marche pas bien. J'ai vu le problème dans la page Niger, pour la traduction anglaise de Niger : la section Anglais n'existait pas, et cliquer sur le lien bleu n'avait absolument aucun effet, ce qui est plutôt déconcertant.

Par ailleurs, j'ai l'habitude de mettre d'office des [[ ]] pour qu'ils soient remplacés automatiquement. Je trouve qu'on ne doit afficher ni + ni - quand on ne sait pas si on doit afficher l'un ou l'autre, car cela peut amener à afficher quelque chose de faux, et donc induire en erreur. J'aurais donc tendance à conseiller de réserver l'emploi de trad aux robots, ou bien d'avoir une 3e version de trad qui signifierait "je ne sais pas si la page existe sur le wiktionnaire dans l'autre langue"... Lmaltier 11 octobre 2006 à 20:30 (UTC)

Des robots pour les doublons

Je suis nouveau et je ne sais pas exactement qui dirige les robots mais est-ce qu'il serait possible de créer des robots pour supprimer les doublons dans les traductions ? Ils atteignent parfois des proportions fâcheuses (ex. regretter).

Il y a ensuite l'histoire des trad et des trad-. Beaucoup de liens (notamment vers le wiktio portugais) ne sont pas à jour. Est-ce qu'on peut envisager un robot capable faire cette mise à jour ? Le robot RobotGMwikt est capable de rajouter des liens vers les articles de même nom sur les autres wiktios. Ceci ne semble pas très différent à réaliser. Ftiercel 8 juillet 2007 à 16:52 (UTC)

Bonne idée, même si ça dépasse mes compétences du moment. Je soupçonne que les trad en doublon ont été créées par des robots pour commencer. Urhixidur 10 juillet 2007 à 11:25 (UTC)

La plupart des grosses listes de traduction ont été ajoutées me semble-t-il par PiedBot d'après les pages des autres projets (Wiktionary anglais etc.), je suppose que des erreurs auront pu s'y glisser, dont ces doublons. Un bot devrait pouvoir se charger de corriger le problème, mais je dois encore dépoussiérer le mien et réveiller mon python... Concernant les trad et trad-, KipBot s'en chargeait, et on peut récupérer le script qu'il utilisait : Utilisateur:Kipmaster#interwiki_for_translations. Il faudra le remanier un peu d'ailleurs (quelques mises à jour à faire). - Dakdada (discuter) 10 juillet 2007 à 17:17 (UTC)

Dans un premier temps, faire un robot pour dédoublonner me parait le mieux. Peut-être qu'à terme on pourrait réinjecter le code dans les robots susceptibles de faire ces erreurs.Ftiercel 11 juillet 2007 à 16:11 (UTC)

J'ai commencé à regarder le script de Kipmaster.

• Pour lire un article, il fait :

lapage = page.get()
lapagenew = page.get() # comme newtext, mais avec les commentaires

Si je ne me trompe pas, ceci correspond à deux requêtes en lecture sur le wiktionaire et donc ça double la charge de traitement. Est-ce que l'on ne pourrait pas remplacer par ceci :

lapage = page.get()
lapagenew = lapage # comme newtext, mais avec les commentaires

si "lapage" est de type str, la valeur est normalement dupliquée.

Oui apparemment c'est un string, donc oui on doit pouvoir faire une copie directement comme ça plus efficacement. - Dakdada (discuter) 24 juillet 2007 à 18:09 (UTC)

• Le script semble supprimer les liens de type [[:lang:mot]]. Est-ce normal ?

  Le script supprime les liens du type ("[[dog]][[:en:dog|*]]" soit "dog*") spécifiquement dans la section traduction. Ce type de lien n'a normalement pas lieu d'être puisque le modèle {{trad}} produit automatiquement ce type de lien. - Dakdada (discuter) 24 juillet 2007 à 18:09 (UTC)

• Les remplacements des anciens contenus par les nouveaux se font sur l'intégralité du texte. :

lapagenew = lapagenew.replace(ligneTotale, newLine)

Ceci me parait dangereux. Si une autre ligne est identique, il peut y avoir des erreurs, me semble-t-il.Ftiercel 18 juillet 2007 à 20:09 (UTC)

Je pense que cela ne pose pas de problème, même si c'est bizarrement fait. En effet, le remplacement se fait forcément sur une ligne de traduction (format du type "* {{en}} : {{trad|en|dog}}") et donc si la ligne apparait plusieurs fois, elle serait de toute façon remplacée exactement de la même manière. - Dakdada (discuter) 24 juillet 2007 à 18:09 (UTC)

• J'ai testé aussi le script qui récupère tous les noms des articles de chaque wiki mais l'URL a du changer. Est-ce que quelqu'un sait où on peut répcupérer les noms des articles maintenant ? Ftiercel 24 juillet 2007 à 07:15 (UTC)

Pour fr c'est ici : http://download.wikimedia.org/frwiktionary/latest/frwiktionary-latest-all-titles-in-ns0.gz. - Dakdada (discuter) 24 juillet 2007 à 17:49 (UTC)

Bon, j'ai fini d'éditer mes scripts. Les voici :

• getall.pl : ce script récupère tous les noms d'article de tous les wiktionnaires et les stocke dans un fichier.
• tranInter.py : il met à jour les liens interwiki selon si la traduction est présente ou pas sur le wiktionnaire de la langue. Il utilise le fichier généré par le premier script.
• tranInter_doubleTracker.py : en plus de mettre à jour les liens, il dédoublonne les traductions.

Ils ont l'air de fonctionner correctement. Je viens de demander le statut de bot pour FtiercelBot. Ftiercel 29 juillet 2007 à 05:06 (UTC)

Un espace en trop

Il y a un espace en trop entre le lien intrawiki et le lien interwiki. Le mieux serait de comparer avec trad- car l'erreur n'y apparait pas. Ftiercel 25 août 2007 à 12:54 (UTC)

Corrigé. Régis Lachaume (causer) 26 août 2007 à 00:36 (UTC)

Catégorisation insuffisante: amélioration avec un autre paramètre pour la langue source

Ce modèle ajoute une catégorisation automatique dans une catégorie comme Catégorie:Traductions en français à partir du paramètre de langue cible.

Le problème est que la catégorie cible est surpeuplée puisque des mots ou expresions de n'importe quelle autre langue viennent s'y mélanger), et difficilement utilisable.

Ne peut-on pas rajouter un paramètre pour indiquer le code de la langue source (la langue utilisée dans le nom des articles qui appellent ce modèle, c’est à dire celle mentionnée dans une section principale de langue au sein de l'article), afin de sous-catégoriser Catégorie:Traductions en français en Catégorie:Traductions de l’anglais en français, etc.

Exemple :

• (to) have est un article pour un mot anglais. Il contient une section de premier niveau pour l'anglais.
• Dans cette section on a actuellement {{trad|fr|avoir}} qui catégorise have dans Catégorie:Traductions en français (surpeuplée, où s'y mèle des mots anglais, allemands, espagnols, etc...).
• Si on mentionnait à la place {{trad|fr|avoir|en}} (ou mieux si on utilisait dans l’article un nouveau modèle spécialisé ainsi : {{trad-en|fr|avoir}}, utilisant en interne le premier modèle) on pourrait catégoriser dans Catégorie:Traductions de l’anglais en français.
• Cette sous-catégorie pourrait être non seulement être classée dans la catégorie actuelle Catégorie:Traductions en français (elle-même déjà dans Catégorie:français), mais aussi dans une nouvelle catégorie croisée Catégorie:Traductions de l'anglais (elle même à classer dans Catégorie:anglais).

Via un robot, il serait facile de réaliser la transformation automatique des articles pour mentionner la langue source là où elle est absente (il suffit de repérer dans les articles le titre de section principale qui précède et indique la langue source trouvée, pour l’ajouter en paramètre).

Personnellement, je serais favorable à créer les sous-modèles comme {{trad-en}} qui utiliserait le modèle actuel {{trad-en}} en mentionnant en plus le code de langue source (fixe, ici "en") en troisième paramètre. Une fois cette transformation réalisée, le modèle {{trad}} ne serait plus utilisé directement dans les articles mais via un des modèles spéciialisés par langue.

L’effet obtenu est bien d’avoir un dictionnaire de traduction bidirectionnel et pas seulement vers la langue cible, mais aussi de se rendre compte, couple de langues par couple de langues de l’état d’avancement des traductions, et de vérifier que les termes de base essentiels sont traduits dans les deux sens dans chaque couple de langues mentionnées dans le Wiktionnaire.

Cela permettrait d’éviter de nombreuses omissions pour ces termes, de concentrer le travail sur ces termes essentiels, avant même de savoir quels autres termes plus spécifiques disposent de traduction.

Et finalement on redonne du sens à ces catégories de traductions où tout est actuellement mélangé, et inutilisable.

Qu’en pensez-vous ? Verdy p 21 septembre 2007 à 22:21 (UTC)

Petite difficulté : pour le nom de la catégorie mentionnant la langue source, on a besoin de savoir si le nom de cette langue commence par une apostrophe ou non afin de savoir si on indique “de l'” ou “du ” avant le nom de langue. Actuellement, le modèle {{en}} ne permet pas de la savoir puisqu’il ne permet de récupérer que le nom de la langue, mais pas son genre ou la nécessité d'une apostrophe (cela pourrait se faire en ajoutant à ces modèles nommés par un code de langue, un paramètre optionnel "type=" indiquant ce que l'on veut lui faire retourner, c’est-à-dire par défaut le nom isolé de la langue en français, par exemple ici "type="apostrophe" qui retournerait "oui" pour l’anglais (dans {{en}}) ou l’allemand (dans {{de}}) ou une chaine vide pour des modèles de code langues comme le français (dans {{fr}}) ou le latin (dans {{la}})).

Pour cela, ces modèles comme {{en}} n’ont à contenir que :

{{#switch:{{{type|}}}|  —  au début, suivi des types supportés comme :

apostrophe=oui|  —  terminé du code Wiki pour le type par défaut ou vide qui indique de retourner le nom de la langue en français :

=anglais}}  —  ; (noter que ce switch ne contiendra pas de clause "#default=" terminale ; donc si aucun cas du switch mentionné avant un signe égal ne correspond à la valeur du paramètre type passé, le texte retourné sera vide : le modèle {{fr}} par exemple n’aura pas besoin de renseigner le type "apostrophe=" puisqu’il retournera par défaut une chaîne vide, indiquant ainsi qu’aucune apostrophe ou élision de l’article n’est nécessaire).

Un tel switch permet de retourner différents renseignements (optionnels) au sujet d’une langue dont on passe le code par le nom du modèle et un code pour le type de renseignement demandé ; il évite la multiplication de modèles spécialisés et des conventions de nommage.

Il pourrait par exemple retourner :

• une image tel que le nom de l’image du drapeau de l’Angleterre ici ("image=Flag of England.svg|"), ou
• sa classification en langue écrite usuellement avec l’écriture latine ("écriture=Latn|" : une suite de codets ISO 15924 à 4 lettres chacun, séparés par un espace, un seul codet étant nécessaire pour chaque langue, mais on pourrait ajouter pour l’anglais l’écriture déséret avec "écriture=Latn Dsrt|" : un modèle séparé contiendrait les renseignements au sujet de chaque codet d’écriture ou chaque ensemble de codets d’écritures), ou
• une forme accordée de l’adjectif (par exemple "f=anglaise|fp=anglaises|" pour les variantes au féminin singulier ou pluriel, une chaine retournée vide indiquant que la forme est identique à celle du nom simple par défaut, par exemple avec des noms invariables de langue tel l’interlingua, ou ici le masculin pluriel "p=anglais|" inutile à mentionner puisque qu’on peut le déduire comme identique au nom masculin singulier si "{{en|type=p}}" ne retourne rien pour le pluriel).
• le nom ou un code d’une famille de langues, etc...

Si on veut que les valeurs par défaut soient déduites de façon automatique, on peut rajouter à la fin du switch :

#default={{valeur par défaut d'un code langue|en|type={{{type|}}}  —  afin que le modèle utilitaire {{valeur par défaut d'un code langue}} déduise les valeurs adéquates à l’aide du modèle spécifique à la langue mentionnée par son code et des autres types supportés par ce modèle spécifique. Par exemple, le modèle utilitaire pourrait retourner des valeurs précomposées pour des types spécialisés comme le nom avec un article défini (type=le nom|) ou en complément (type=du nom|) ou le nom d’une catégorie selon une convention de nommage (type=catégorie du nom|), en utilisant les valeurs renseignés pour les autres types de ce code langue (ici par son paramètre "1=en|" indiqué dans {{en}}), etc...

Ce type de paramétrage est utilisé par exemple sur Commons pour retourner des renseignements au sujet d’une même image (dont tous les renseignements sont mentionnés dans un modèle créé pour spécifiquement pour elle), et facilite sa réutilisation dans différents contextes. Il est utilisé aussi sur le Wikipédia anglophone de façon assez avancée et facilite l’automatisation des mises en forme pourun même sujet par des modèles “intelligents” capables d’en extraire des méta-données de types différents.

Verdy p 21 septembre 2007 à 22:55 (UTC)

Urgh. Il faudrait donc spécifier à {{trad}} non seulement la langue cible (et le mot traduit) mais la langue source ? Ça deviendrait pénible. N’y aurait-il pas une solution technique du genre interrogation du style HTML en cours ? Comme ça on pourrait spécifier le code langue source une fois, au début de la section trad (il serait naturel de le mettre en argument de {{-trad-}}), et il suffirait d’ajouter un petit modèle (du genre {{-fin-trad-}}) pour clore le style en cours (ou autre signal, selon la solution technique).

Étant donné qu'on est ici en train de parler du système de catégorisation du Wiki, le HTML n'a rien à voir là dedans. La solution ne peut pas se faire dans le navigateur ni dans le code HTML généré. Malheuseuement, le code Wiki ne fournit aucun support pour gérer des variables contextuelles permettant de "tracer" ou mémoriser un paramètre utilisé précédemment dans le code.

Un compromis pourait être fait en utilisant un modèle raccourci où la langue source est implicitement le français, et une version longue pour les traductions des entrées de mots d'une autre langue.

Ceci dit dans ce dernier cas, on va se retrouver avec des mots traduits de l'anglais vers l'allemand (par exemple) et je ne vois aucun intérêt à les méler dans la même catégorie avec les traduction du japonais vers le latin.

L'utilité donc de la caégorie existante (où on mèle absolument tout) est plus que douteuse si on ne sait pas y faire le tri du tout.

Peut-être faut-il chercher une solution dans un support amélioré de MediaWiki concernant l'enrichissement des articles par des métadonnées avec lesquelles on peut faire des recherches croisées. Dans ce cas aussi on aurait quand même besoin de la langue source (traitée par un variable Wiki contextuelle) en plus de la langue cible, chacune générant une métadonnée distincte sur laquelle on pourrait faire des recherches croisées, sans avoir à créer et peupler des catégories finalement pas si bien adaptées que ça pour les recherches croisées en raison de leur structure trop hiérarchique.

Cette proposition de métadonnées typées (dont les catégories sont elles même déjà un type particulier, les interwikis en sont un autre type, de même que les sections noinclude) traine depuis longtemps dans les demandes d'amélioration du MediaWiki qui pêche encore par une gestion ardue des catégories et la gestion cohérente des interwikis et autres métadonnées comme les licences, auteurs, formats (texte ou média), etc. La généralisation des types pour ces métadonnées (en leur assignant des noms dans un espace de nommage particulier, dont certains seraient réservés comme l'espace anonyme réservé aux types prédéfinis "category", "interwiki", "author", "licence"... les autres types pouvant être ajoutés librement dans l'espace de nommage "type:" dans lequel on pourrait définir une page de description d'ontologie écrite en syntaxe Wiki...).

Si vous avez des contacts pour en discuter avec les développeurs de MediaWiki, merci de leur soumettre cette proposition (qui serait aussi très utile pour la gestion de Wikipédia, ou encore de façon évidente dans WikiSpecies). Verdy p 16 janvier 2008 à 07:20 (UTC)

Le fait que Catégorie:Traductions en français soit surpeuplée (et pêle-mêle) ne me gène pas beaucoup : ces catégories sont surtout utiles pour trouver rapidement le vocabulaire qui a été traduit dans une langue autrement orpheline. Catégorie:Traductions en vote, par exemple (4 mots, ce qui est plus que les 3 mots en vote existants).

Essaye de faire la recherche dans l'autre sens: du vote vers d'autres langues. Impossible de les retrouver quand ils sont noyés sous des tonnes de mots traduits vers ces mêmes langues sans qu'on sache lesquelles! C'est la preuve de la faiblesse du modèle hiérarchique actuel des catégories qui est mal adapté pour gérer des recherches multicritères. Verdy p 16 janvier 2008 à 07:20 (UTC)

Enfin, pour le paramètre "apostrophe", le nom "'" est déjà répandu et serait préférable afin d’éviter une multiplicité de noms de paramètres. Urhixidur 22 septembre 2007 à 04:30 (UTC)

OK, je laisse de côté cette proposition pour le nom du paramètre d'apostrophe, mais cela ne change rien à ma proposition d'un switch sur le type d'info à retourner (ma proposition a d'ailleurs été adoptée et implantée depuis dans le modèle {{en}} et les autres avec un modèle utilitaire {{valeur par défaut d’un code langue}} qui fournit la plupart des valeurs non précisées.)... Verdy p 16 janvier 2008 à 07:20 (UTC)

translittérations dans les traductions ?

Est-ce que l'on affiche les translittérations dans les traductions ? Par exemple pour le chinois, c'est vraiment utile d'avoir un moyen d'accéder au pinyin. Je n'ai pas l'impression qu'il y ait de politique clairement définie sur le sujet.

Il y a plusieurs possibilités :

• Soit on ne fait rien, il faut aller dans l'éventuel article pour voir la prononciation
• Soit on peut la mettre après la traduction en caractère, entre parenthèse ou en italique (voir par exemple la traduction de apéritif).
• Soit on peut la mettre en "hover box", qui s'affiche quand la souris passe sur le lien (ce que j'ai fait pour les mots dérivés de 马 (mǎ)).

Dans les deux derniers cas, l'idéal serait une modification du modèle, rajouter un paramètre optionnel à la fin, pour pouvoir entrer {{trad|zh|开胃酒|kāiwèijiǔ}} et voir apparaître quelque chose comme 开胃酒  ^(zh) (kāiwèijiǔ) ou 开胃酒 (kāiwèijiǔ)  ^(zh) .

Pour le chinois, il y a aussi le souci des caractères simplifiés et traditionnels mais je ne vais peut-être pas poser trop de problèmes d'un coup ;o)

Koxinga 25 septembre 2008 à 14:19 (UTC)

Si "R=" permis l'an dernier d'ajouter des transcriptions ou translittérations, les caractères simplifiés et traditionnels sont pour l'instant traités chacun dans un {{trad}} (avec éventuellement la mention entre parenthèse). JackPotte ($♠) 7 août 2010 à 20:18 (UTC)

Petit problème d'affichage

J'ai noté que les dernières modifications du modèle {{trad}} pose problème dans un certain nombre de langues (arabe, hébreu par exemple) pour lesquels les traductions étaient définies accentué et non-accentuées dans le modèle par le passé. Un exemple serait peut être plus clair:

{{trad|ar|<mot pour le renvoi>|<mot accentué>}}

donnait

[[<mot pour le renvoi>|<mot accentué>]] ^{([[<mot pour le renvoi>|ar]])}.

Aujourd'hui, le mot accentué est ignoré et l'on obtient:

[[<mot pour le renvoi>]] ^{([[<mot pour le renvoi>|ar]])}

J'ai regardé le modèle en anglais équivalent. Pour résoudre ce problème, un paramètre "alt" a été défini. Si une telle solution peut être adoptée, je me propose de faire la modification des traductions. J'en ai noté environ 2500 affectées par ce problème. LBO disc 14 décembre 2008 à 14:36 (UTC)

Il existe déjà le paramètre dif, qui devrait répondre à ta demande. Est-ce qu'on est obligé de faire comme cela ? Pourquoi donner le mot accentué comme traduction s'il ne mérite pas une entrée à part entière ? (question naïve, je ne connais rien à l'arabe). Koxinga 14 décembre 2008 à 15:15 (UTC)

Merci pour ta réponse: je ne connaissais pas de paramètre dif. Ta question n'est pas naïve. Les accents servent de support à la lecture LBO disc 21 décembre 2008 à 13:11 (UTC)

Genre, nombre, déclinaisons et conjugaison

Pourquoi ne pas préciser les informations "masculin, féminin, neutre, singulier, pluriel", "sujet, complément, nominatif, accusatif..." et "indicatif, présent... causatif" ? JackPotte 26 avril 2009 à 17:44 (UTC)

De mon point de vue, pour plusieurs raisons :

• Ta liste me paraît très imprécise. Du parle du genre et du nombre, mais le reste c'est quoi ? À quoi servirait d'avoir des déclinaisons, des conjugaisons en argument du modèle trad ?
• Cela n'est pas une information importante à inclure dans les listes de traductions. Si quelqu'un est intéressé par le genre d'un mot, il peut aller le chercher sur la page concernée, elle n'est qu'à un clic.
• C'est un peu artificiel de le rattacher à ce modèle qui sert avant tout à faire un lien. Pour te donner une idée, je suis plutôt en train de pousser vers l'autre direction, où trad ne fait plus la catégorisation et pourrait devenir un modèle généraliste, pouvant être utilisé dans les étymologies, les listes de mots, etc. Les transcriptions et formes alternatives sont toujours liées au mot, donc on peut les inclure dans le modèle. Des informations grammaticales, par contre, ne sont pas toujours intéressantes, donc c'est bien de garder un modèle très général pouvant être utilisé partout.
• C'est vrai qu'en terme de traitement automatisé, cela serait mieux de tout avoir dans un modèle, mais cela serait trop restrictif et inatteignable, donc cela ne sert à rien de trop forcer artificiellement dans ce sens.

Koxinga 26 avril 2009 à 18:38 (UTC)

OK mais quand je veux importer des traductions anglophones faites avec en:Template:t, elles intègrent leur genre à la fin (ex : m}} affiche masculin), et même avec Foxreplace je perds du temps à les décortiquer. JackPotte 20 septembre 2009 à 12:53 (UTC)

Je trouve qu'il serait sympa de rajouter le paramètre "m"/"f"/"n"/"mf", à la mode de {{[[Modèle::en:t|:en:t]]}}, et la doc pourrait indiquer que son usage est facultatif, voire déconseillé, donnant la raison (genre "merci de suivre le lien pour vous renseigner sur le genre du mot en question"), mais souhaitable dans le cas la page du mot étranger est présente ni ici, ni dans le wiktionnaire de la langue concernée. Ugh. --Jérôme Potts 6 juin 2010 à 22:16 (UTC)

Oui, je me vois mal expliquer aux milliers de personnes qui viennent de en.wikt que notre modèle fait tout sauf cela. JackPotte ($♠) 27 juin 2010 à 15:27 (UTC)

OK pour les genres et nombres, par contre pour les déclinaisons le consensus devra être revu. JackPotte ($♠) 27 juin 2010 à 16:41 (UTC)

Personnellement, ne pas avoir les infos de déclinaison, de conjugaison, etc. ne me gêne pas. Par contre, je ne peux pas me passer du genre en allemand (cliquer sur le lien, à supposer qu’il soit bleu, prend du temps). Si la boîte est trop encombrée visuellement, on peut imaginer un affichage plus discret (m, f ou n au lieu des mots entiers). —Eiku (d)

Interwikis absents

J'ai trouvé 2 messages d'erreur différent dans anguille#Traductions : un sur tohono o’odham et l'autre sur vénitien : il faudrait rendre ce modèle soit dynamique de la liste des Wiktionnaires existants. JackPotte ($) 15 janvier 2010 à 19:33 (UTC)

J'ai mis "--". JackPotte ($) 7 juin 2010 à 08:58 (UTC)

bug ?

Je comprends pas pourquoi j'obtiens ceci : « лично име (mk) líčno íme » avec {{trad|mk|лично име|R=líčno íme}} (chez prénom). Ça marche pour les autres langues, ou alors j'ai fait une bêtise que je ne vois pas. Merci d'avance. --Jérôme Potts 7 août 2010 à 06:42 (UTC)

Les modèles incompréhensibles ont encore frappé ! Je défie quiconque de comprendre comment ce modèle et les modèles associés fonctionnent sans y passer beaucoup, vraiment beaucoup, de temps. J'imagine que ça s'attend à ce que le modèle mk-Latn/type existe. Il faudrait revoir tout ça et, dans un premier temps, revenir aux modèles de langue très simples mk -> macédonien, comme l'a déjà suggéré Dakdada, et comme ça l'était avant que Verdy p ne les modifie en masse en refusant d'engager une discussion malgré mes demandes insistantes et répétées. Les modèles incompréhensibles font fuir les contributeurs. Ceux qui ne fuient pas ont bien sûr souvent tendance à les accepter (par sélection naturelle), et à en faire de nouveaux, et à compliquer encore ceux qui existent. Pour les modèles propres à une langue rare, l'impact est négligeable, mais pour les modèles très utilisés, c'est grave. Et c'est comme ça qu'on peut avoir, petit à petit, de moins en moins de nouveaux contributeurs... C'est un problème crucial, je dirais même vital, pour le projet. Lmaltier 7 août 2010 à 07:24 (UTC)

Je l'ai réparé sur le modèle des autres alphabets non latins. @Lmaltier, un jour soit on écrira une doc sur le sujet, soit on rendra facultatifs les /type. JackPotte ($♠) 7 août 2010 à 20:17 (UTC)

{{trad/zh}} et {{trad/défaut}}

Maintenant que {{trad/zh}} est égal à {{trad/défaut}}, nous n’avons pas besoin de #switch dans {{trad}}, {{trad+}} et {{trad-}}. Modifiez

trad/{{#switch:{{{1}}}|zh=zh|défaut}}

en

trad/défaut

s’il vous plait. Après la modification, je proposerai la suppression de {{trad/zh}}. — TAKASUGI Shinji (d) 14 avril 2011 à 08:52 (UTC)

De plus, mon robot remplacera les {{trad/zh}} ce soir, et je le supprimerai ensuite. JackPotte ($♠) 14 avril 2011 à 11:17 (UTC)

Merci. Il y a deux choses à corriger dans {{trad+}} et {{trad-}}:

• |tradi={{{tradi|}}} est nécessaire ;
• |{{{1}}}|{{{2|{{PAGENAME}}}}} n’est pas nécessaire.

C’est bon de copier simplement le code de {{trad}} vers {{trad+}} et vers {{trad-}} et modifier les couleurs spécifiées par le paramètre color. — TAKASUGI Shinji (d) 14 avril 2011 à 11:45 (UTC)

OK pour la première remarque, par contre la deuxième risque de modifier certaines pages étrangement. JackPotte ($♠) 14 avril 2011 à 18:07 (UTC)

Merci ! — TAKASUGI Shinji (d) 14 avril 2011 à 23:41 (UTC)

Modèle:Arabe

Pourquoi ne pas grossir les lettres en arabe et persan avec {{Arabe}}. C'est assez difficile à lire actuellement. JackPotte ($♠) 18 février 2012 à 13:54 (UTC)

Demande de précision

Bonjour,

Je ne comprends pas cette phrase de la documentation du modèle :

« S’il existe plusieurs systèmes de romanisation, il faut aller voir sur la page d’instructions concernant la langue quelle romanisation est préférée. »

Quelqu’un peut-il signaler où se trouve cette page ? Cordialement, Automatik (discussion) 7 janvier 2013 à 09:02 (UTC)

Par exemple, pour le coréen, nous avons Annexe:Romanisation du coréen. Pour le japonais, nous utilisons la méthode Hepburn. — TAKASUGI Shinji (d) 7 janvier 2013 à 17:36 (UTC)

D’accord, et serait-il possible de faire une page listant ces instructions pour chaque langue ? Automatik (discussion) 7 janvier 2013 à 17:48 (UTC)

Catégorie:Alphabets ? JackPotte ($♠) 7 janvier 2013 à 18:38 (UTC)

Je n’ai pas vraiment trouvé de système de romanisation dans les pages de cette catégorie. J’en ai regardé quelques unes, mais pas trouvé. Cordialement, Automatik (discussion) 7 janvier 2013 à 20:57 (UTC)

C’est pour ne pas concurrencer Catégorie:Romanisation sur l’encyclopédie Wikipédia . JackPotte ($♠) 7 janvier 2013 à 21:00 (UTC)

Ok, donc c’est ce que j’utilisais, je le rajoute au modèle. Ça peut aider. Automatik (discussion) 7 janvier 2013 à 21:11 (UTC)

Par contre je change toute la phrase, vu que "la" phrase auquel il est fait référence ne semble pas exister. Ne pas hésiter à me corriger si on peut faire mieux. Automatik (discussion) 7 janvier 2013 à 21:13 (UTC)

Une question persiste : je mets le lien plus général vers Catégorie:Méthode de transcription sur l’encyclopédie Wikipédia , incluant la catégorie romanisation peut-être ? Elle inclut des transcriptions en +, mais je préfère être sûr, je m’y connais encore peu et je ne voudrais pas donner de mauvais conseils. Cordialement, Automatik (discussion) 7 janvier 2013 à 21:16 (UTC)

Suggestion: supprimer le nota à coté de Genre

Je n'ai pas l'autorisation de modifier cette page mais j'ai une suggestion.

À coté de l'argument Genre, est écrit:

Nota : Il a été déconseillé de préciser le genre des mots dans la liste des traductions (voir fin de cette discussion).

Cependant, ceci est loin de faire l'unanimité. Dans la discussion liée, quatre personnes sont pour la suppression du genre, et une personne est contre. Dans une autre discussion, trois personnes veulent garder les genres. Ça donne quatre à chaque coté:

• Supprimer: GaAs, Unsui, Automatik et Dakdada.
• Garder: Gronky, JackPotte, Jérôme Potts, Eiku.

Pour moi, le genre dans la table de traductions est très utile (j'ai écrit mes raisons ici, à la fin) et je trouve que ce nota ne représente pas un consensus solide. D'ailleurs, je pense que pour rendre wiktionary moins utile, ou pour défaire le travail déjà accompli par les contributeurs, il faudrait un consensus très clair. Puis je suggérer que ce nota soit enlevé? Gronky (discussion) 5 octobre 2013 à 14:44 (UTC)

Je pense qu'Automatik a cru bon de porter ce débat à la connaissance des contributeurs mais comme tu le rappelles il n'est pas clos et concerne donc plutôt les amateurs de pages de discussion. JackPotte ($♠) 5 octobre 2013 à 15:35 (UTC)

Supprimer documentation pour nocat?

Salut,

Je voulais documenter l'argument nocat mais je n'arrive pas à l'invoquer correctement. J'ai essayé:

• {{T|nl}} : {{trad+|nl|doodgraver|m|nocat=1}}
• {{T|nl}} : {{trad+|nl|doodgraver|m|nocat}}
• {{T|nl}} : {{trad+|nl|doodgraver|m|nocat=true}}

Mais l'article (fossoyeur) est resté dans la catégorie Traductions en néerlandais. Et si je supprime cette ligne, la catégorie disparaît donc c'est bien cette lien qui cause l'article d'être dans cette catégorie.

La ligne de code pertinente du module:traduction est:

    local nocat = (args['nocat'] and true or false) -- Pas catégorisé (vraiment utile ?)

Alors, j'allais demander si quelqu'un pouvais m'expliquer comment invoquer nocat, pour me permettre de le documenter, mais quelle est l'utilité de cet arguement? Il me semble qu'on peut en supprimer le documentation. Je ne l'ai jamais vu utilisé. Des avis? --Gronky (discussion) 4 novembre 2013 à 09:56 (UTC)

Cette catégorie dans fossoyeur n'est pas fautive au contraire.

Le paramètre nocat est généralement utilisé dans les pages d'aide et dans ce cas le comportement du modèle actuel est bien celui attendu. Par contre j'ai déjà vu certains l'utiliser dans les étymologies, dérivés entre langues ou faux-amis. Je propose donc de le réhabiliter comme avant le Lua. JackPotte ($♠) 4 novembre 2013 à 13:21 (UTC)

@Gronky : Essaie d’enlever {{T}} dans la ligne du néerlandais en prévisulation, puis regarde les catégories en bas de page (avec nocat=ce_que_tu_veux) : la catégorie n’apparaît plus. Ici c’est au modèle T qu’il manque le paramètre "nocat", qui était là avant sa version en Lua [1]. Mais bon, permettre ce paramètre c’est inciter les gens à ne pas catégoriser la page, et il serait bien que quelqu'un s’explique sur l’utilité d’empêcher la catégorisation dans certains cas avant de permettre non-catégorisation. — Automatik (discussion) 4 novembre 2013 à 13:49 (UTC)

Merci pour les infos, tous les deux. Je ne voulais pas enlever la catégorie pour fossoyeur, c'était juste un test. J'avais d'abord essayé sur ma page perso mais la catégorie n'apparait pas du tout. J'ai ajouté quelques mots pour rendre la documentation plus claire : [2]. Juste? --Gronky (discussion) 4 novembre 2013 à 14:10 (UTC)

Ça me semble correct. — Automatik (discussion) 4 novembre 2013 à 14:20 (UTC)

Bon en fait nocat n’a pas été implémenté (il est dans le code, mais non utilisé). La catégorisation est dans tous les cas faite uniquement par {{T}}. Et actuellement, on ne peut pas l’éviter. S’il y a des raisons de l’éviter, on pourra changer le code. Je mets à jour la doc. pour que ce soit clair. — Automatik (discussion) 5 novembre 2013 à 12:49 (UTC)

Analogue sur le wiktionnaire grec

Bonjour, le lien interwiki grec de ce modèle est "παρωχημένα/ξεν" qui n’existe pas du tout, le lien à indiquer est Πρότυπο:τ. Chinedine (discussion) 27 juillet 2014 à 09:34 (UTC)

[3] — Automatik (discussion) 27 juillet 2014 à 14:26 (UTC)

Genre etc. (suite)

L'indication du genre fonctionne à présent (cf. rubrique 8 #Genre, nombre, déclinaisons et conjugaison du 26 avril 2009); mais à mon avis la même rubrique pourrait servir, comme sur le Wiktionnaire en anglais, à indiquer l'aspect des verbes slaves: pf (perfectif), impf (imperfectif) ou (abréviation à définir) biaspectuel. — Tonymec (discussion) 7 avril 2019 à 19:34 (UTC)