Discussion module:traduction

Page de tests : Discussion module:traduction/test. — Dakdada 14 juillet 2013 à 22:10 (UTC)Répondre

Bonjour,

Actuellement, une paire de parenthèses vide à l’intérieur s’affiche dans les traductions quand R est présent et vide (voir Dieu). Est-ce voulu ? Automatik (discussion) 8 juillet 2013 à 15:58 (UTC)Répondre

Bien vu : voilà la correction . Le comportement par défaut est de ne pas les afficher si le paramètre est donné mais vide. — Dakdada 8 juillet 2013 à 16:38 (UTC)Répondre

Super, merci Automatik (discussion) 8 juillet 2013 à 16:54 (UTC)Répondre

Les ancres dans les liens internes correspondent parfois aux codes interwikis, alors qu’ils devraient être convertis selon l’inverse de {{code interwiki}}.

Par exemple, dans États-Unis d’Amérique, il apparait Vereinigte Staata fa Amerika#als (comme dans w:als:) au lieu de Vereinigte Staata fa Amerika#gsw (comme sur http://www-01.sil.org/iso639-3/documentation.asp?id=gsw).

Je propose donc de remplacer {{code interwiki}} par un tableau Lua, qui puisse convertir dans les deux sens, afin que quoi que l’utilisateur remplisse, le code interwiki sera au format interwiki, et le lien interne au format interne.

Bien sûr il n’est pas question de remplacer {{als}} quand il parle de l’albanais tosk (d’où le besoin de connaitre le code de {{T}}, donc une occasion de plus de les fusionner). JackPotte ($♠) 14 juillet 2013 à 14:21 (UTC)Répondre

Dans États-Unis d’Amérique, {{trad}} est écrit avec als au lieu du correct gsw. Le code als est déjà pris par une autre langue, donc faire fonctionner la conversion dans l'autre sens n'a pas de sens. Fusionner {{T}} avec le contenu (souvent bien variable) de la ligne qui suit n'a pas non plus de sens. Ce n'est quand même pas compliqué d'écrire le même code langue (et pas dur à repérer). — Dakdada 14 juillet 2013 à 18:07 (UTC)Répondre

Donc tu demandes aux contributeurs d’écrire au moins deux fois le même code (dans T et trad), alors même que nous pourrions aisément leur n’en faire écrire qu’un seul comme sur les autres Wiktionnaires, tout en éradiquant le problème d’initié que je mentionne aujourd’hui (choisir entre les liens internes et externes) et qui persistera en répétant le même code ? Pourtant, je viens de démontrer que ce qui n’est quand même pas compliqué brise les liens ! JackPotte ($♠) 14 juillet 2013 à 18:37 (UTC)Répondre

Je dis juste que ce n'est pas un argument suffisant pour fusionner : les traductions sont plus compliquées qu'un simple T + trad. Si tu veux qu'on adhère à cette idée, commence par proposer une manière de faire en prenant en compte tous les cas possibles (multiples traductions, traductions sans équivalent, etc.). — Dakdada 14 juillet 2013 à 18:46 (UTC)Répondre

Maintenant tu me dis que je n’ai rien proposé et pas tout prévu par rapport à toi alors même que ça fait des années que j’essuie des fins de non recevoir pour une solution plus simple.

Et ne me redis pas que tout ceci aucun sens dans l’absolu et donc que ce serait une perte de temps stp, car j’ai tu temps j’en ai perdu à me faire des ampoules aux doigts à cause de cette syntaxe arbitraire. JackPotte ($♠) 14 juillet 2013 à 19:17 (UTC)Répondre

PS : honnêtement elle m’a même dissuadé plusieurs fois d’ajouter des traductions à mes créations. JackPotte ($♠) 14 juillet 2013 à 19:30 (UTC)Répondre

Bon ben puisqu'on est là-dessus : note que j'ai aussi fait un pas dans cette direction récemment avec ceci. Je n'avais jamais vu ta proposition (en 2011 je n'étais pas très actif), mais on a le même avis. C'est juste que maintenant, si on veut voir ça utilisé, il faudra rajouter les cas plus compliqués que j'ai mentionnés plus hauts : traductions multiples, sans équivalent, avec ou sans liens, avec transcription, commentaires, etc. — Dakdada 14 juillet 2013 à 19:34 (UTC)Répondre

NB : je maintiens ce que j'ai dit pour l'inverse de code interwiki : gsw et als ne sont pas interchangeables. — Dakdada 14 juillet 2013 à 19:37 (UTC)Répondre

Mais je n’ai pas dit le contraire, et si Lua les gère comme ça deviendrait mieux. Pour les fonctions elles sont déjà toutes prises en compte dans ma solution (y compris les commentaires, présents notamment dans les expressions métaphoriques avec traductions littérales, ex : quand les poules auront des dents). JackPotte ($♠) 14 juillet 2013 à 19:45 (UTC)Répondre

Je ne crois pas avoir tout vu alors. Il faudrait faire une page de tests pour tous les cas de figure pour être clair. Tiens, il y a aussi le cas des langues à plusieurs scripts qu'il faudrait prendre en compte. — Dakdada 14 juillet 2013 à 21:45 (UTC)Répondre

C’est toujours urgent et je ne sens toujours pas de consensus. Je crains qu’un quatrième message sur la Wikidémie de ma part ne soit encore qu’un vain effort. JackPotte ($♠) 29 juillet 2013 à 21:55 (UTC)Répondre

Il faut deux choses : un modèle complet près à être utilisé (ou au moins dont toutes les spécificités sont définies : paramètres et sorties surtout) et une page de démonstration. Pour convaincre les contributeurs qu'on ne les embarque pas vers un truc qui ne marchera pas. — Dakdada 10 août 2013 à 13:26 (UTC)Répondre

Il suffirait juste de faire de {{T}} une redirection vers {{L}}. JackPotte ($♠) 15 août 2013 à 14:02 (UTC)Répondre

Le problème n'est-il pas T + trad ? — Dakdada 15 août 2013 à 15:00 (UTC)Répondre

La solution de supprimer {{T}} que je m’évertue à proposer depuis des années ne tenait pas compte de ton nouveau projet qui supprimerait aussi {{trad}} : Wiktionnaire:Gestion_des_modèles/Propositions#Liste_par_langue, et sur lequel je n’ai pas encore de recul même si elle ressemble à celle des hispanophones. JackPotte ($♠) 15 août 2013 à 15:29 (UTC)Répondre

Bonjour,

Actuellement, quand on ajoute une traduction dans une langue manquante sans Wiktionnaire, il faut soit :

• savoir qu’il n’y a pas de Wiktionnaire dans cette langue et utiliser {{trad--}} ;
• soit utiliser {{trad}} et laisser le robot (merci JackBot) passer pour changer le {{trad}} en {{trad--}}.

Que pensez-vous de spécifier dans module:langues/data l’existence ou non du Wiktionnaire en question dans la langue donnée, afin que les liens pour les Wiktionnaires existants soient gérés automatiquement par {{trad}} ? Au niveau maintenance, ce ne serait pas très dur, des nouveaux Wiktionnaires n’apparaissent pas tous les jours ; ce serait juste la mise en place qui demande davantage d’efforts. Mais cela n’est pas un problème en soi, puisque rien ne presse.

Globalement, que pensez-vous de l’idée ? Il y a peut-être des éléments que j’aurais dû prendre en compte et que j’oublie…

Merci d’avance pour vos réactions, Automatik (discussion) 14 juillet 2013 à 21:49 (UTC)Répondre

Oui, c'est une bonne idée. Il suffit de rajouter un paramètre aux langues avec un Wiktionnaire existant (par exemple wikt=true) et de triturer un peu le code pour qu'il prenne ce paramètre en compte (très simple). — Dakdada 14 juillet 2013 à 22:04 (UTC)Répondre

Il serait juste dommage de brider les liens vers un wiki parce qu’on a pas mis à jour la liste de Wiktionnaires. D’autant qu’un javascript pourrait le déterminer on load (mais en augmentant le temps de chargement). JackPotte ($♠) 14 juillet 2013 à 22:14 (UTC)Répondre

Le plus simple : dès qu'un nouveau wiki apparaît, il est ajouté à la liste des langues à modifier (à la main ou par bot). Vu la fréquence d'apparition des wikis, utiliser javascript est inapproprié. — Dakdada 14 juillet 2013 à 22:35 (UTC)Répondre

Moi ce que j’ai compris pour javascript, c’est que la coloration des liens (et la reconnaissance des Wiktionnaires manquants) pourrait être géré automatiquement par javascript, afin de se cantonner à {{trad}} dans le code source. J’ai peut-être mal compris, mais l’idée est alléchante (sa mise en place, je ne sais pas). Par contre un problème commencera probablement à se poser pour les pages avec de longues listes de traductions. Automatik (discussion) 14 juillet 2013 à 22:47 (UTC)Répondre

@Dak, je voulais t’épargner cinq minutes chaque semaine pour vérifier cette fréquence. JackPotte ($♠) 14 juillet 2013 à 23:00 (UTC)Répondre

J'explique : javascript s'exécute côté client. À chaque page chargée, le client ferait une requête vers et parserait la liste (soit 1 requête en plus de la page). Or on a des centaines de milliers de connexions par jour. Même si on met ça en cache avec un cookie ou un truc du genre, c'est à comparer à la fréquence d'ajout d'un wiktionnaire, qui est plutôt de l'ordre d'une fois par mois (cf meta:Requests for new languages), donc une vérification par semaine suffit. Javascript est donc particulièrement inadapté dans ce cas.

Quitte à faire un truc automatique, autant que ce soit une simple alerte sur la page d'ajout des langues. — Dakdada 15 juillet 2013 à 06:43 (UTC)Répondre

Si j’ai bien compris, l’ajout d’un paramètre dans Module:langues/data permettrait « seulement » de pouvoir se passer de {{trad--}}. En ce qui concerne {{trad+}} et {{trad-}}, c’est là qu’intervient le javascript. C’est bien ça ? Si oui alors je suis assez réticent comme Dakdada à la solution javascript ou cela ralentirait énormément les grosses pages de traductions du style Utilisateur:Pamputt/eau mais ça n’empêche pas de faire des tests pour me prouver le contraire . Pamputt 29 juillet 2013 à 22:18 (UTC)Répondre

C’est ce que j’avais compris au début, mais je crois qu’en fait le javascript dont voulait parler JackPotte sert à repérer simplement si le Wiktionnaire existe ou non, donc à remplacer la solution que tu évoques pour éviter trad--, mais en javascript. Automatik (discussion) 31 juillet 2013 à 20:37 (UTC)Répondre

Ah bah dans ce cas , je rejoins entièrement Dakdada. Le javascript ne peut servir qu’à ralentir le chargement de la page dans ce cas alors qu’on peut s’en passer. Pamputt 31 juillet 2013 à 20:39 (UTC)Répondre

J’ai adapté dans des sous-pages persos le modèle:trad pour qu’il fasse le travail de trad-- quand il n’y a pas de wiktionnaire dans la langue. Voici le résultat des tests :

(Changements apportés aux modules) Les changements n’ont pas été appliqués aux modules officiels, bien entendu

• Module:langues
• Module:langues/data (langues reclassées par ordre alphabétique en même temps)
• Module:traduction

Voilà pour les tests, reste à savoir s’il y a des objections, des remarques… le code est peut-être mal écrit aussi. Automatik (discussion) 7 août 2013 à 23:31 (UTC)Répondre

Bonjour,

Le genre ayant été ajouté au module, on pourrait peut-être ajouter quelque chose pour l’afficher en entier (comme le feraient les modèles de genre largement présents dans les sections de traduction), en ajoutant un morceau de code qui ressemblerait à celui-ci :

 if genre ~= nil and genre ~= '' then
     local g = {'m' = 'masculin', 'f' = 'féminin', 'n' = 'neutre', 'c' = 'commun'}
     if (g) then
         genre =  genre = " ''" .. g .. "''"
     else
         genre =  " ''" .. genre .. "''"

— Automatik (discussion) 1 septembre 2013 à 18:34 (UTC)Répondre

Ce serait effectivement dans la continuité de ce qui était utilisé dans {{trad}}, mais pour des raisons de lisibilité, j'ai voulu faire court comme sur en:Template:t. JackPotte ($♠) 1 septembre 2013 à 19:38 (UTC)Répondre

Je comprends, dans ce cas-là il faudrait peut-être ajouter une infobulle comme sur en. D’ailleurs du coup ce n’est plus homogène avec les modèles de genre utilisés directement après une traduction (et en fait il est plus courant de trouver un modèle tel {{m}} que le genre m comme troisième paramètre de {{trad}}, donc on obtiendra certaines fois (m), et d’autres fois masculin). — Automatik (discussion) 1 septembre 2013 à 19:46 (UTC)Répondre

C'est vrai mais quand je remets des accolades cela n'affiche pas le modèle mais sa syntaxe : voir le gaélique écossais dans octobre#Traductions. JackPotte ($♠) 4 septembre 2013 à 12:59 (UTC)Répondre

Je réparerai cela plus tard. JackPotte ($♠) 4 septembre 2013 à 13:02 (UTC)Répondre

L'imprévu a été traité. JackPotte ($♠) 4 septembre 2013 à 13:10 (UTC)Répondre

Pour éviter les problèmes, pensez à utiliser la page de test : Discussion module:traduction/test. Il faudrait la mettre à jour pour les genres. — Dakdada 4 septembre 2013 à 13:20 (UTC)Répondre

Tu fais bien de le préciser, ceci devrait suffire. JackPotte ($♠) 4 septembre 2013 à 14:25 (UTC)Répondre

Merci. Automatik (discussion) 4 septembre 2013 à 14:36 (UTC)Répondre

Le code modifié avait une grosse erreur : il dépendait de l'existence d'un modèle, et il supposait que ce modèle était un modèle de genre. Résultat : quand le paramètre était mal rempli, il affichait une grosse erreur. J'ai remplacé par une simple liste de genres qui ne repose plus sur des modèles. Pour les cas où le modèle est mal rempli, j'ai créé la catégorie Catégorie:Wiktionnaire:Traductions avec genre inexistant.

Pour la prochaine fois : avant de faire des modifications, il faut d'abord faire une listes des différents cas possibles dans Discussion module:traduction/test, y compris en écrivant des utilisations erronées (paramètres vides, différents de ceux attendus...). Comme ça on sait ce qu'on fait et on évite les bugs.

NB : j'ai constaté cette erreur via la catégorie Catégorie:Pages avec des erreurs de script qu'il convient de surveiller régulièrement. — Dakdada 5 septembre 2013 à 13:01 (UTC)Répondre

PS : du coup il faudra corriger toutes les pages de Catégorie:Wiktionnaire:Traductions avec genre inexistant quand elles auront été mises à jour. — Dakdada 5 septembre 2013 à 13:08 (UTC)Répondre

Je propose de catégoriser les modèles avec un argument 4 de la même façon. JackPotte ($♠) 6 septembre 2013 à 07:36 (UTC)Répondre

L'argument 4 n'est pas utilisé : c'est moins dommageable. — Dakdada 6 septembre 2013 à 09:11 (UTC)Répondre

J'en déduis que tu n'es pas contre traquer ce genre d'erreur, donc je le ferai. JackPotte ($♠) 6 septembre 2013 à 12:03 (UTC)Répondre

En effet. Pense à bien catégoriser tout ça (il faudrait ranger un peu Catégorie:Maintenance du Wiktionnaire). — Dakdada 6 septembre 2013 à 13:51 (UTC)Répondre

J'ai regroupé les appels de modèles incorrects ensemble, et nous y avons 26 Catégorie:Wiktionnaire:Traductions avec paramètre en trop. JackPotte ($♠) 8 septembre 2013 à 14:26 (UTC)Répondre

Il y a une erreur : le genre 'n' est présent deux fois dans le code du module et le genre 'c' aucune. Automatik (discussion) 7 septembre 2013 à 20:58 (UTC)Répondre

Merci, j'avais vérifié pourtant mais relister les noms des modèles et leurs contenus fût trop long pour mon attention. Pour les humains nous pourrions peut-être nous contenter d'un filtre par tableau à quatre lettres même si appeler les modèles ralentirait le script. JackPotte ($♠) 7 septembre 2013 à 21:05 (UTC)Répondre

On peut trouver dans l'article christadelphe les valeurs suivantes pour le paramètre 3 :

• mf (1ere boite, pour l’espéranto - eo)
• p (1ere boite, pour l’arménien - hy)

Apparemment, pas seuls les genres ne sont indiqués. Automatik (discussion) 8 septembre 2013 à 16:08 (UTC)Répondre

OK pour ajouter "mf" puisqu'il était géré avant, par contre "p" pourrait induire en erreur (la traduction est-elle forcément au pluriel ?). JackPotte ($♠) 8 septembre 2013 à 16:21 (UTC)Répondre

C'est pas pour rien que d'aucuns préféreraient n'avoir pas d'infos supplémentaires comme le genre. Si on précise le genre, pourquoi ne pas aussi préciser le nombre ? Ou le type de déclinaison ? Ou si le mot est régulier ou pas ? Avant d'en rajouter, ce serait bien de décider une bonne fois pour toute si c'est vraiment pertinent de mettre le genre ou tout autre info de ce type. — Dakdada 8 septembre 2013 à 16:45 (UTC)Répondre

J'ai vu deux types d'utilisation de 'p' dans les traductions : avant un pluriel clairement indiqué dans ce cas-là on comprend qu'il sert à introduire le pluriel ; après la traduction (par exemple avec {{p}}) pour indiquer que le mot dans la langue est forcément pluriel (voir Moyen Âge, traduction anglaise) : vu le peu d'utilisation de 'p' en tant que paramètre de {{trad}}, j’ai déplacé quelques-uns que j’ai vus, de même pour {{s}}, directement dans un modèle en clair, pas en paramètre du modèle trad. Automatik (discussion) 8 septembre 2013 à 16:54 (UTC)Répondre

Bonjour, sur la page gigantesque de traductions, il y a des « Erreur de script » qui apparaissent en bas de la page. Quelqu’un sait d’où ça vient et comment le corriger ? Pamputt 11 septembre 2013 à 16:08 (UTC)Répondre

En cliquant sur l'erreur on a la réponse : « Le temps alloué pour l’exécution des scripts a expiré. » Même en Lua, le fait d'utiliser des milliers de trad et T reste trop long pour créer la page. La seule solution viable sera de se convertir à une version des tableaux de traduction en un seul modèle (en discussion, mais on est encore loin d'être prêt). — Dakdada 11 septembre 2013 à 16:14 (UTC)Répondre

Ok, je comprends. Parfait donc si vous êtes en train de travailler sur une amélioration de la prise en charge des traductions. Courage Pamputt 11 septembre 2013 à 16:18 (UTC)Répondre

On peut déjà supprimer {{T}} en écrivant les langues en toutes lettres dans un premier temps, ce serait moins radical et semblable à l'anglophone. JackPotte ($♠) 11 septembre 2013 à 17:59 (UTC)Répondre

Mieux vaudrait passer directement à un modèle englobant que passer par une étape temporaire. Le modèle anglophone est tout aussi limité que le nôtre. — Dakdada 11 septembre 2013 à 18:27 (UTC)Répondre

Pas si sûr, comment éviter que ceux qui ne mettent pas le signe égal flinguent toutes les traductions, et imposent une recherche dans une longue liste, surtout avec Visual Editor. Et quid des images de la LSF ? Je garde la démo du gadget filtrant les trad pour la PDD. JackPotte ($♠) 12 septembre 2013 à 05:32 (UTC)Répondre

Mettre le signe égal est enfantin par rapport à ce qu'on doit faire actuellement : modèle T, modèle trad, paramètres divers... Avec Lua on peut faire tout un tas de vérification pour détecter les erreurs, chose très compliquée actuellement. La recherche dans la liste est inévitable dès lors qu'on met toutes les traductions au même endroit, quelle que soit la méthode utilisée. Le Visual Editor sera autant inutile maintenant que plus tard pour les listes de traduction, puisqu'on utilise des modèles de partout (et qu'ils sont indispensables). Pour les images de la LSF : ben on les laisse ? Sinon, merci de mettre un lien vers la démo dont tu parles, même si j'ai du mal à voir ce que ça à a voir avec le modèle. — Dakdada 17 septembre 2013 à 14:04 (UTC)Répondre

Tu n'es vraiment jamais tombé sur ces pages Catégorie:Traductions en langue des signes française qui contiennent des liens externes voire des images ou des vidéos 20px au milieu des traductions ? Si ce site peut être géré comme Wikispecies pour "conv", pour ne pas perdre la souplesse du multimédia actuelle le module Lua devra filtrer toutes les extensions .png, .jpg... pour les interpréter.

Concernant la démo que tu me redemandes, il y en a déjà plein le site des {{trad}} sans {{T}}. JackPotte ($♠) 17 septembre 2013 à 14:59 (UTC)Répondre

S'il s'agit d'images, je ne vois pas ce que le modèle aura à interpréter ou à filtrer ? Pour la démo, désolé, je ne comprend pas où je peux trouver ça (et je ne vois pas le rapport avec yb gadget) : est-ce possible d'avoir un lien précis ? — Dakdada 18 septembre 2013 à 08:12 (UTC)Répondre

Justement le problème est bien qu'on ne voit pas ce que le modèle liste par langue, dont tu prétends qu'il est la solution à ces erreurs imprévues, aura à filtrer (commentaires, images, références...).

Sinon le gadget concerne toutes les langues : Mes traductions fût saboté cette année (TypeError: button.parentNode.nextSibling.getElementsByTagName(...) is undefined) mais il tourne toujours sur l'anglophone. JackPotte ($♠) 18 septembre 2013 à 18:03 (UTC)Répondre

en:Template:t-simple/documentation : « This template is for use on water where several thousand invocations of {{t}} and friends cause noticable slowness. It should not be widely used, as there is no benefit unless it is used several hundred times. » Une autre idée possible — Automatik (discussion) 23 octobre 2013 à 21:39 (UTC)Répondre

Bonjour,

Actuellement, les codes en exposant sont toujours ceux du Wiktionnaire ; par exemple, pour une traduction en mandarin, on aura :

• Mandarin : 痣 (cmn) (zhi)

Ne serait-ce pas mieux de mettre en exposant (zh), puisque le le lien créé vise bien zh.wiktionary.org ? Ça permet notamment de s’y retrouver plus facilement entre les projets. — Automatik (discussion) 21 octobre 2013 à 15:40 (UTC)Répondre

Je viens de le changer . — Dakdada 21 octobre 2013 à 16:53 (UTC)Répondre

Merci — Automatik (discussion) 21 octobre 2013 à 17:33 (UTC)Répondre

Bonjour,

Actuellement, {{trad}} utilise toujours le code langue reçu en paramètre pour créer l’ancre du lien interne vers la traduction. Mais cela donne des ancres fausses quand c’est le code Wikimédia qui est indiqué en paramètre.

Par exemple, dans la page eau, la traduction en alémanique contient un lien vers wasser#als au lieu de wasser#gsw. Comme on peut le voir, l’ancre #als n’existe pas dans la page wasser, puisque nous avons défini le code "gsw" pour l’alémanique dans module:langues/data, qui est donc utilisé pour l’ancre de la section de langue alémanique.

Un administrateur veut-il bien y remédier ? Merci d’avance. — Automatik (discussion) 26 décembre 2013 à 03:12 (UTC)Répondre

C’est une erreur du code langue donné et pas du modèle : als correspondant à albanais tosk. Les codes langues Wikimédia ne doivent tout simplement pas être donnés en paramètre. — Dakdada 8 janvier 2014 à 12:07 (UTC)Répondre

Pourtant ils sont présents dans nombre de pages ; des humains en rajoutent , JackBot aussi — j’en ai d’ailleurs déjà parlé à JackPotte, mais ça n’est pas simple à faire selon ce que j’ai compris. — Automatik (discussion) 8 janvier 2014 à 12:28 (UTC)Répondre

C’est clairement une erreur. Les liens et les ancres ne marchent que si on met le code langue normal, pas celui Wikimédia. Compare qui fait des liens corrects (newton#nan + lien externe MW) alors que fait un lien erroné (newton~zh-min-nam + lien externe WM). — Dakdada 8 janvier 2014 à 13:39 (UTC)Répondre

Je suis d’accord et comprends tout à fait. J’ai fait cette demande justement parce qu’il était vain que je modifie par bot ces codes erronés comme ici, mais maintenant il est probable que JackBot ne fera plus la modif. en sens inverse, et il ne restera plus qu’à modifier les codes Wikimédia en codes internes dans les modèles de traduction pour corriger ces liens. — Automatik (discussion) 9 janvier 2014 à 23:38 (UTC)Répondre

Bonjour,

Je croyais le problème réglé mais il y a encore un cas spécial de code langue mal géré : si j’utilise dans {{trad}} un code langue redirigé, genre "tir" pour "ti", alors le code en exposant sera "tir" et non "ti" (wiki existant), donc le lien interwiki sera mauvais ex : test (*) ({{trad|tir|test}}) → passer la souris sur le lien interwiki permet de voir que c’est un lien rouge donc une page à créer. Le module devrait repérer que c’est du tigrigna code "ti". Du coup peut-être faire comme suggéré par JackPotte dans Wiktionnaire:Questions_techniques/juin_2014#Module:code de langue, c’est-à-dire signaler les alias en dur dans la liste des langues. Je ne vois pas d’autres solution pour l’instant, à part ne pas utiliser de code langue redirigé (ce qui reviendrait à ne plus les permettre pour que les choses fonctionnent donc à les rayer de la liste) ou encore avoir un bot qui remplace les codes langue redirigés régulièrement.

Je signale ce problème en espérant qu’une solution soit trouvée. — Automatik (discussion) 24 juillet 2014 à 06:00 (UTC)Répondre

Pourquoi la fonction _fait_ecrit_traditionnel ne génère pas de balise span avec le code de langue donné ? J’ai trouvé aujourd’hui que les traductions chinoise et coréenne d’écriture traditionnelle de fleuve Jaune ne se montrent pas correctement. — TAKASUGI Shinji (d) 8 avril 2015 à 02:48 (UTC)Répondre

Moi je vois bien <span xml:lang="zh" lang="zh">黄河</span> dans les traductions de fleuve jaune. JackPotte ($♠) 8 avril 2015 à 10:34 (UTC)Répondre

Je parle de l’écriture traditionnelle dans des parenthèses donnée par le paramètre tradi.

<li><span class="trad-zh">Chinois</span> : <a href="https://dictious.com/fr/%E9%BB%84%E6%B2%B3#zh" title="黄河"><span lang="zh" xml:lang="zh">黄河</span></a> <span class="trad-exposant"><a href="//zh.wiktionary.orghttps://dictious.com/fr/%E9%BB%84%E6%B2%B3" class="extiw" title="zh:黄河"><span class="trad-existe">(zh)</span></a></span> (<a href="https://dictious.com/fr/%E9%BB%83%E6%B2%B3#zh" title="黃河">黃河</a>) (<span lang="zh-Latn" xml:lang="zh-Latn">Huáng Hé</span>)</li>
<li><span class="trad-ko">Coréen</span> : <a href="https://fr.wiktionary.org/w/index.php?title=%ED%99%A9%ED%95%98&action=edit&redlink=1" class="new" title="황하 (page inexistante)"><span lang="ko" xml:lang="ko">황하</span></a> <span class="trad-exposant"><a href="//ko.wiktionary.orghttps://dictious.com/fr/%ED%99%A9%ED%95%98" class="extiw" title="ko:황하"><span class="trad-absent">(ko)</span></a></span> (<a href="https://dictious.com/fr/%E9%BB%83%E6%B2%B3#ko" title="黃河">黃河</a>) (<span lang="ko-Latn" xml:lang="ko-Latn">Hwangha</span>)</li>

— TAKASUGI Shinji (d) 8 avril 2015 à 10:53 (UTC)Répondre

Oui, il était précisé dans le code qu’il manque ce balisage : Manque un <span lang="">, à faire par une fonction de base, ça devrait être corrigé. — Automatik (discussion) 8 avril 2015 à 12:24 (UTC)Répondre

Merci. Mais justement comme {{trad/défaut}}, il faudrait ajouter -Hant après zh. — TAKASUGI Shinji (d) 8 avril 2015 à 14:14 (UTC)Répondre

Je m’en occupe. — Automatik (discussion) 8 avril 2015 à 14:33 (UTC)Répondre

(voir les tests). — Automatik (discussion) 8 avril 2015 à 14:45 (UTC)Répondre

Je propose d’ajouter le code suivant dans la fonction _fait_asterisque :

mot = mw.ustring.gsub(mot, "’", "'")

Maintenant, le code suivant crée un lien vers en:o’clock avec un apostrophe typographique :

* {{T|en}} : {{trad+|en|o’clock}}

En général, le Wiktionnaire anglais a une redirection vers la page correspondante avec un apostrophe dactylographique (en:o'clock) et il n’y aura pas de problème, mais ce n’est pas toujours le cas. Il est plus simple de remplacer un apostrophe typographique par un apostrophe dactylographique dans un lien externe que de créer une redirection dans un autre projet, comme le font déjà les modèles {{WP}} et {{w}}. — TAKASUGI Shinji (d) 13 septembre 2016 à 13:53 (UTC)Répondre

OK. JackPotte ($♠) 13 septembre 2016 à 13:57 (UTC)Répondre

@JackPotte : Dans ce cas, JackBot aussi devrait changer son comportement quand il remplace {{trad}} par {{trad+}} ou {{trad-}} avec un mot comprenant un apostrophe. Et qui peut modifier le code Javascript de traductions ? Automatik ? — TAKASUGI Shinji (d) 14 septembre 2016 à 00:56 (UTC)Répondre

Je verrai ça ce week-end, à l’occasion. — Automatik (discussion) 15 septembre 2016 à 21:56 (UTC)Répondre

Merci. J’ai modifié le module : . — TAKASUGI Shinji (d) 16 septembre 2016 à 01:22 (UTC)Répondre

JackBot recherche maintenant la traduction, puis si elle est introuvable et qu'elle contient un apostrophe dactylographique alors il la cherche avec l'apostrophe typographique, ou vice-versa. JackPotte ($♠) 16 septembre 2016 à 22:00 (UTC)Répondre

De même pour l’assistant d’ajout de traductions, c’est fait : il remplace maintenant l’apostrophe courbe par la droite avant de vérifier l’existence de la traduction dans les autres wiktionnaires (). — Automatik (discussion) 18 septembre 2016 à 17:38 (UTC)Répondre

@JackPotte : J’ai ajouté aussi l’apostrophe modificative comme dans Cʼhwevrer en breton : Spécial:Diff/26033383. — TAKASUGI Shinji (d) 23 janvier 2019 à 09:30 (UTC)Répondre

Il ne s'agit pas d'une apostrophe mais du trigramme constituant la lettre cʼh en breton !--Prieladkozh (discussion) 23 janvier 2019 à 09:36 (UTC)Répondre

Oui, nous le savons. Cette discussion concerne la compatibilité technique (cf. br:C'hwevrer, br:Cʼhwevrer). — TAKASUGI Shinji (d) 23 janvier 2019 à 09:41 (UTC)Répondre

Le problème est que votre intervention a décalé le mot concerné dans l'ordre alphabétique des mots bretons...--Prieladkozh (discussion) 23 janvier 2019 à 09:43 (UTC)Répondre

En effet, la catégorie:breton ne classe pas uniformément les mots contenant le trigramme c'h . Et à ce propos, Wikipédia indique que le digramme ch et le trigramme c'h se classent avant la lettre c dans l’alphabet breton : Orthographe du breton#Ordre alphabétique sur l’encyclopédie Wikipédia Il faudrait donc peut-être revoir le tri par défaut des mots contenant c'h en breton ? Actuellement, Module:clé de tri — utilisé par {{clé de tri}} — fait apparaitre c’h systématiquement après c. — Automatik (discussion) 23 janvier 2019 à 12:49 (UTC)Répondre