• test1 = modèle de base
• test2 = squelette de sous-modèle (remplacer les constantes/variables du wikisanakirja là où il y a X)
• test3 = sous-modèle käsi (basé sur fi-subs-käsi)
• test4 = affichage de käsi

À inclure plus tard à la fin des modèles:

<noinclude> {{Documentation}} ]</noinclude>

• Demander l'avis d'autres contributeurs. Ajuster en fonction des retombées.
  • L'appel est lancé, je commence et on verra si j'ai d'autres réponses.
• Me renseigner sur le fonctionnement des modèles. Idem, ajuster.
  • J'ai assez de renseigments pour m'orienter de manière initiale. La page Aide:Modèle était très aidante. Je peux poser des questions sur la page Wiktionnaire:Gestion des modèles.
• Créer des modèles à tester dans mon réseau de pages utilisatrice.
  • Créer une nouvelle page pour un modèle de base.
  • Créer un squelette qui sert à la création de sous-modèles.
  • Créer un premier sous-modèle.
  • Demander un avis en ce qui concerne la prochaine étape.
  • Poursuivre la création de modèles en fonction de la décision prise.
• (...)
• Créer des sous-modèles supplémentaires, toujours en commençant par les tester sur mon terrain.
• Faire archiver les vieux modèles. Les modifier pour inclure la phrase "ne pas utiliser" et créer une sous-catégorie Modèles vieillis pour désengorger la catégorie Modèles de déclinaison du finnois.
• Utiliser les nouveaux modèles!

La manière dont je vise des classes ciblées a un impact direct sur: la facilité des usagers à remplir le modèle (est-ce qu'ils peuvent juste se fier à KOTUS?), le temps que ça prend (champs techniquement superflus ou non?), la probabilité de publier quelque chose de fautif (lié à l'aspect facilité, mais pas juste; champs superflus = plus de chances d'erreurs).

Si j'opte pour le modèle de KOTUS, c'est facile à référencer. Mais il va y avoir des classes de mots où on trouve énormément de mots et il y a souvent un champs superflu (à moins de trouver comment définir des ensembles). Il y a 10k+ de mots de type valo sur le Wikx anglais, avec gradation possible, et ce n'est pas la seule classe concernée. Je peux créer deux modèles par classe KOTUS avec gradation pour éviter un champ superflu, ça va pas doubler la quantité de modèles, mais ça va en faire quand même beaucoup. On parle de dizaineS de classe à la base, plus de 50 pour des paradigmes distincts et les constantes bien isolées. Si je m'en tiens au système KOTUS, je peux nommer les modèles en fonction des numéros KOTUS. C'est court et c'est facile à référencer: tu écris fi-décl-1, tu as le modèle de la classe 1 de KOTUS. C'est plus facile de se souvenir lequel utiliser sans consulter quoi que ce soit quand on a un nom comme fi-décl-valo mais c'est plus long, et c'est juste possible d'utiliser le modèle sans la moindre consultation avec un degré de connaissance du finnois au moins intermédiaire. Il risque d'y avoir plus de gens non-avancés qui souhaitent contribuer au finnois que de gens avancés. De toute façon niveau utilisation sans consultation, ça devrait pas être quelque chose que je (et d'autres) fais de manière entièrement manuelle pour chaque entrée. C'est probablement simple de faire en sorte qu'un bot se charge au moins en partie de ça...?

Si j'arrive à faire usage de la fonction ensemble, ça réduit le souci niveau champs superflus, au moins au niveau de l'harmonie, peut-être aussi au niveau de la gradation. La forme nominative ne prédit pas la racine mais la racine prédit la forme nominative (la vaste majorité du temps); ça peut être utilisé pour optimiser. Encore faut-il que je trouve comment; il y a EU des modèles qui utilisaient des ensembles codés avec la syntaxe wiki par le passé, mais je n'arrive pas à les trouver pour le moment. Peut-être qu'ils ont été supprimés une fois le passage à un module parent en Lua fait. (Màj: Cette observation semble toujours correcte, mais elle devient moins pertinente.)

Il ne faut pas se fier exclusivement au Wikx finnois car malgré la qualité du travail fait au niveau de l'isolement de constantes/variables et de nombre de formes casuelles possibles dans le paradigme de chaque classe de mots, certaines formes peuvent manquer. Le modèle fi-subs-hame n'a qu'une forme plurielle (hameisiin) mais deux sont possibles tel que relevé par KOTUS (hameisiin; hameihin). Donc: se baser sur le Wikx finnois ET vérifier s'il concorde avec KOTUS, ajouter les formes manquantes au besoin. Ce n'est pas le fait de se fier à KOTUS qui va assurer une exhaustivité complète assurée par le modèle, mais ça va s'en rapprocher.

Le Lua est recommandé plutôt que de bidouiller avec des fonctions auxquelles la syntaxe wiki n'est pas très bonne (j'imagine?) mais jongler avec du Lua, ça devient compliqué. Je n'y connais rien. Mais ça reste faisable. À considérer: je prends le modèle de base (anglais ou finnois) et je le traduis. Je repère les mots qui renvoient à des réalités linguistiques et qui doivent être en français (nombre, cas, etc.) ainsi que les commentaires du code, je les traduis, voilà. Pourquoi est-ce que ça marcherait pas? Le code peut être maintenu par un francophone qui sait coder le Lua, par la suite, au besoin. Survol de quoi traduire ou pas, probablement à rerevoir:

• À traduire: noir (toujours ou pas...? ça varie entre finnois & abréviations anglaises? possible que les abréviations anglaises soient conventionnalisées peu importe la langue du codeur? ou est-ce que c'est plus analogue au vert? mystère), bleu, bleu-vert (= commentaires; en ajouter des nouveaux?), rouge.
• À ne pas traduire: vert, mauve (= not/and/or), gris.

Les modules Lua ont des fonctionalités plus poussées que la syntaxe wiki, ce qui pourrait permettre entre autres de décliner automatiquement les mots. Un module Lua très complexe est utilisé sur le Wikx anglais en tant que parent aux modèles et aussi pour automatiser beaucoup de choses. Les modèles avec la syntaxe wiki pourraient faire des trucs sophistiqués avec ifexist mais c'est une ParserFunction qui bouffe beaucoup d'énergie, alors c'est déconseillé. Je ne sais pas exactement pourquoi on me dit "Lua est conseillé" mais ça a l'air d'être une raison au moins. Ça serait utile de connaître les autres raisons s'il y en a. Je penche vers la traduction du Lua plutôt que la seule utilisation de la syntaxe wiki, mais il est quand même question de traduire du code que je ne comprends pas bien, ça doit être bien justifié. Si c'est justifié, ça vaut la peine de vraiment prendre le temps de le comprendre et de l'adapter.

• Module Lua sur le Wikx anglais
• Module Lua sur le Wikx finnois (le plus récent)
• Module Lua sur le Wikx finnois (un ancêtre, semi?-hors d'usage)

Traduire le module Lua du Wikx finnois le plus récent semble être la meilleure idée à ce stade; il est plus modeste que le module du Wikx anglais parce qu'il ne cherche pas à automatiser grand chose, ce qui réduit sa fonctionalité MAIS ça rend l'idée de le traduire pour le rendre compréhensible à un programmeur francophone beaucoup plus réaliste. J'aurais de la difficulté à bien traduire le module du Wikx anglais. C'est dommage parce qu'automatiser autant, ça permet par exemple de faciliter l'emploi de modèles de déclinaison pour les apprenants de la langue, mais bon. Il faut que je comprenne mieux quelles parties sont quoi et font quoi. En ce moment, si on regarde une partie du code de modèle finnois...:

| sanaluokka = substantiivi

| yks = {{#switch:{{{yks|}}}|=|-=-}}

| mon = {{#switch:{{{mon|}}}|=|-=-}}

| tarkenne = {{{tarkenne|}}}

| vokaalisointu = {{{5|a}}}

Yks et mon sont des paramètres. Vokaalisointu est moins sophistiqué que je pensais; c'est juste pour définir une harmonie par défaut, et puis après on peut déclarer l'autre harmonie quand c'est applicable. Mais il n'y a pas de mécanisme où cette ligne en rapport à l'harmonie permettrait d'éviter d'écrire ö|ä, il y a juste une manipulation de tronçons de variables/constantes, je pense. C'est moins automatique et il n'y pas de classes comme je pensais, contrairement au Wikx anglais. Il y a peut-être des observations à corriger/nuancer avec davantage d'étude des modules ET des modèles, en fait surtout le module récent du Wikx et ses modèles pour des classes de mots. Il faut regarder ça de plus près et demander un nouvel avis.

Si je décide de traduire le module de base Moduuli:fi-nom-taiv du Wikx finnois, il faut aussi traduire les modules qu'il utilise... (Ou en tous cas, si je transfère le module en question, il faut transférer les autres modules utilisés. Traduire est-il vraiment une priorité? C'est nécessaire pour une maintenance éventuelle mais c'est pas comme si on se bousculait pour coder quoi que ce soit pour le finnois sur le Wikx français... Aussi, ce n'est pas parce que le module est mentionné dans le code qu'il est vraiment utilisé, ou qu'il serait utilisé sur le Wikx français; il y a des atavismes. Les modules dont le nom est mis en gras semblent essentiels.)

1. Moduuli:Mallinetyokalut (Fonctions variées. Aide à l'organisation des formes casuelles et de leurs propriétés, voir la section m.taivutusmuodot = apu.numeroidut_parametrit (...) et la façon dont c'est ensuite réutilisé pour l'aspect sg/pl tantum.)
2. Moduuli:Kielilinkki (Sert à la mise en lien et l'ajout de #codelang, mais ne semble pas créer les même problèmes de mise en lien au niveau modèle de base qu'on voyait du côté Wikx français.)
   • Moduuli:kielikoodit (Interprète les codes de langue; nécessaire et à priori fait usage du même code de langue ISO pour le finnois peu importe où on est dans le réseau Wiki.)
   • Moduuli:Kirjoitusjärjestelmät (Récupère des fonctionalités liées à des systèmes d'écriture autres que l'alphabet latin...? Ça ne casse rien si tout ça n'est utilisé que pour le finnois, j'imagine? Il faudrait juste enlever les sections avec "kjdata".)
   • Moduuli:Automaattilinkki (Vieille manière de faire de la mise en lien; le module contient le bandeau "ne pas utiliser". Si je comprends bien, il est inclus dans le code de Mooduli:kielikoodit afin de vérifier s'il y a déjà une mise en lien vieillotte effectuée et éviter d'en ajouter une deuxième. Donc à priori je peux ignorer le transfert de ce module et effacer la section autolink?)
   • Moduuli:Mallinetyokalut: Idem qu'en haut, au moins ça fait pas un module supplémentaire à traiter.
3. Moduuli:Taivutustaulukkotyökalut (Passe de /descriptions métalinguistiques → formes/ à /formes → descriptions métalinguistiques/.)

Ça fait un peu effet boule de neige mais la chaîne s'arrête assez vite; je pense avoir fait le tour et par exemple Moduuli:kielikoodit n'utilise pas de modules supplémentaires à son tour.

Je repère toujours pas où est réellement la partie tableau statique dans l'ensemble de modules/modèles du Wikx finnois??? Les bouts de code suivants (dans Moduuli:fi-nom-taiv) y renvoient, je pense???:

function m.Taivutustaulukko(frame)

m.args = frame.args

(...)

local cur = frame

if cur.args.frame == "+parent" then

Peut-être que c'est pas ça les bouts pertinents mais reste qu'il y a forcément une mise en forme du tableau quelque part. La manière dont le tableau a des sous-sections "kieliopilliset sijamuodot", "sisäpaikallissijat", "ulkopaikallissijat" et "muut sijamuodot", ça sort pas de nulle part. C'est où? C'est pas dans Moduuli:Taivutustaulukkotyökalut et c'est pas dans Moduuli:Mallinetyokalut??? C'est pas dans les modèles non plus (logique). Il me manque forcément quelque chose d'important qu'il faudrait absolument transférer ET traduire, mais je vois pas où autre ça pourrait être.

À considérer en général:

• Nombre de formes casuelles défini au niveau des sous-modèles.
• Mise en lien qui n'interfère pas avec la variation du nombre de formes casuelles pour une cellule du tableau.
• Définition de l'harmonie, avec une harmonie par défaut. A est de loin plus commun que ä.
• Distinction entre toutes les cellules de formes singulières et celles de formes plurielles. Ça sert à rendre tous les modèles utilisables pour les tantum.
• Définir un ensemble pour la gradation...? C'est peut-être trop compliqué pour une simple manipulation de tronçons plutôt qu'une déclinaison automatique vraiment poussée comme du côté anglais.
• Catégoriser les modèles comme modèles, les pages avec modèles juste comme mots de type 1,2,3...
• Lien (dans l'en-tête) vers un annexe qui décrit la classe de mots, comme sur le Wikx anglais. Se baser sur KOTUS pour le contenu.
• (En-tête auquel on peut ajouter une précision, comme pour le Wikx finnois; on s'en passe facilement..? En faisant une section Nom commun 2 qui a un deuxième tableau sans précision, par exemple. Je sais pas c'est quoi l'usage concret de ces tarkenteet. Quel genre de précisions?)
• (Notes dynamiques; je pense qu'on s'en passe et que c'est peut-être même pire.)

Ce qui a été intégré dans ma fusion des modèles français et finnois (#1?):

• Nombre de formes casuelles défini au niveau des sous-modèles.
• Mise en lien qui n'interfère pas avec la variation du nombre de formes casuelles pour une cellule du tableau: géré en faisant la mise en lien au niveau des sous-modèles, pas au niveau du modèle de base.