Discussion module:traduction

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

Paramètre "R"

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)

Bien vu : voilà la correction [1]. 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)

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

Ancres brisées

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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

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)

Traductions dans une langue sans Wiktionnaire

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)

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)

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)

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)

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)

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

J'explique : javascript s'exécute côté client. À chaque page chargée, le client ferait une requête vers [2] 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)

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 ^[Discuter] 29 juillet 2013 à 22:18 (UTC)

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)

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 ^[Discuter] 31 juillet 2013 à 20:39 (UTC)

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 :

Comparaison trad actuel/trad proposé

{{trad}} actuel	{{trad}} remodelé	Différences
aujourd’hui	aujourd’hui	Voyez les traductions en tsolyáni (gérées par {{trad}})
majeur	majeur	Voir la dernière traduction en espagnol de l’avant-dernière boite de traductions
{{trad|dog|azdklbez}} : azdklbez (*)	{{trad|dog|azdklbez}} : Utilisateur:Automatik/bac à sable/Modèle:trad	Le modèle trad nouvelle version reconnaît bien que cette langue n’a pas de Wiktionnaire et affiche le texte approprié
{{trad|it|pizza}} : pizza (it)	{{trad|it|pizza}} : Utilisateur:Automatik/bac à sable/Modèle:trad	Pour un code existant, le nouveau trad marche comme avant
{{trad|erregr|pizza}} : pizza (*)	{{trad|erregr|pizza}} : Utilisateur:Automatik/bac à sable/Modèle:trad	Pour un code inexistant, le nouveau trad indique que la langue n’a pas de Wiktionnaire(*), tandis que le trad actuel crée un lien du type code Langue inexistant:pizza qui sera interprété comme un lien normal (et mis en exposant donc). Les deux trad mettent l’entrée dans une catégorie de maintenance quoi qu’il en soit.
(*) : mais il est aussi possible de générer un texte signalant à l’utilisateur qu’il a entré un mauvais code langue.

(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)

Gestion du genre par le module

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[genre]) then
         genre =  genre = " ''" .. g[genre] .. "''"
     else
         genre =  " ''" .. genre .. "''"

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

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)

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)

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)

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

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

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)

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

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

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

Erreur de script

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 ^[Discuter] 11 septembre 2013 à 16:08 (UTC)

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)

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 ^[Discuter] 11 septembre 2013 à 16:18 (UTC)

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)

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)

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)

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)

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)

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)

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(...)[0] is undefined) mais il tourne toujours sur l'anglophone. JackPotte ($♠) 18 septembre 2013 à 18:03 (UTC)

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)

Codes en exposant

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)

Je viens de le changer [3]. — Dakdada 21 octobre 2013 à 16:53 (UTC)

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

Liens internes

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)

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)

Pourtant ils sont présents dans nombre de pages ; des humains en rajoutent [4], JackBot aussi [5] — 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)

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 [6] qui fait des liens corrects (newton#nan + lien externe MW) alors que [7] fait un lien erroné (newton~zh-min-nam + lien externe WM). — Dakdada 8 janvier 2014 à 13:39 (UTC)

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)

Liens en exposant et codes wikimédia

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 (tir) ({{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)

Code de langue dans _fait_ecrit_traditionnel

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)

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

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="/wiki/%E9%BB%84%E6%B2%B3#zh" title="黄河"><span lang="zh" xml:lang="zh">黄河</span></a> <span class="trad-exposant"><a href="//zh.wiktionary.org/wiki/%E9%BB%84%E6%B2%B3" class="extiw" title="zh:黄河"><span class="trad-existe">(zh)</span></a></span> (<a href="/wiki/%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="/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.org/wiki/%ED%99%A9%ED%95%98" class="extiw" title="ko:황하"><span class="trad-absent">(ko)</span></a></span> (<a href="/wiki/%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)

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)

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

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

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

Apostrophe

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)

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

@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)

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

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

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)

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 ([9]). — Automatik (discussion) 18 septembre 2016 à 17:38 (UTC)

@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)

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)

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)

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)

En effet, la catégorie:breton ne classe pas uniformément les mots contenant le trigramme c'h [10]. 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)