Tu négliges un peu le principal intérêt de tout ça : fournir des ressources linguistiques dans des langues qui en manquent. De ce côté là, tu peux mutualiser la production de contenu, avec une concentration de l’effort sur les traducteurs pour les parties ou ça se différencie.
Certes, mais je suppose aussi que les langues les plus couvertes vont être celles avec la plus grande communauté, et le reste, pas vraiment. Bien sur, pouvoir écrire une encyclopédie avec moins de ressources est un plus. Mais on va pas nier que Wikipedia, ç'est le point de vue du plus grand groupe qui prime.
Fr.wp a un biais vers la France, en.wp sans doute vers les USA.
Sur le côté multilingue des fonctions ou descripteurs, ce sera le même esprit que Wikidata et c’est un peu la raison d’être de Wikifonctions, tout sera traduisible dans toute les langues. Le multilinguisme est la raison d’être de tout ça et c’est une piste et un parti pris exploré à fond : le but c’est d’avoir des gens de toutes cultures qui participent et de voir ce que ça donne, sans leur imposer une langue ou même un langage de programmation.
Wikidata contourne le souci via des identifiants abstraits, et le seul endroit ou tu vois du texte, c'est dans les labels. Il est d'ailleurs intéressant de voir que même si ça n'est pas destiné à écrire du texte et à être lu à la base, il y a quand même eu des gens qui ont voulu traiter ça comme du texte à part entière, avec tout les soucis que ça entraîne d'un point de vue linguistique.
Ici, les fonctions (dans ton exemple) vont avoir des noms dans une langue (sans doute l'anglais, on va pas se mentir). C'est ça le souci pour moi.
Avoir du contenu personnalisé sur tous les sujets dans toutes les langues, ce que tu suggérerait pour avoir de la décentralisation totale, c’est juste la situation actuelle, avec un paquet de Wikipédias avec peu de contenu. Et les wikipédias majoritaires qui ont peu de contenu sur les sujets des cultures moins hégémoniques.
Oulah non, au contraire, je trouve la structure des wikipedias actuelles beaucoup trop centralisés, je suis beaucoup plus radical à ce niveau.
Mon argument, c'est celui de la fin de ce commentaire sur l'espace pour le désaccord, à savoir qu'il n'y pas vraiment moyen de facilement faire une encyclopédie dérivée de Wikipedia, sauf sur des axes mineurs (comme l'inclusion ou non de certaines pages), ou via un processus peu pratiques (importer des dumps réguliers, qui requiert des compétences poussés et entraine des soucis à la synchro).
Pour reprendre un sujet qui déchire la communauté en ce moment, le fait d'avoir des images ou pas sur les articles pourrait être un exemple de choix possible si WP n'était pas si centralisé.
Avoir des fonctions pour faire son propre "abstract wikipedia", serait un bon pas, car en théorie, quelqu'un pourrait surcharger les fonctions pour changer des choses (tout comme on le fait pour spécialiser une classe en prog objet, ou du monkeypatching, etc).
Pour reprendre mon exemple, avec un système de surcharge pas trop mal foutu, rien n’empêcherais d'avoir le choix du type d'infobox, avec ou sans les images dessinées, etc. Les gens qui ne veulent pas les voir les retirent, les gens qui pensent que c'est un plus les affichent. Et tout le monde serait libre de proposer son encyclopédie, tout comme tout le monde, en théorie, peut faire des choses avec wikidata sans avoir à se mettre d'accord sur tout un tas de détails.
Maintenant, si une éventuelle surcharge est aussi pratique que "surcharger" une page de WP, alors ça ne va pas être vraiment décentralisé au sens ou je l'entends, plutôt le contraire.
Les infoboxes tirés de wikidata sont acceptées car elles sont surchargeables sur wikipedia au cas par cas. Un monde ou ça ne serait pas le cas tournerait à la guerre civile, car ça entraînerais une centralisation sur wikidata pour décider ce qui s'affiche sur X instances de WP, et c'est la centralisation en question qui est (selon moi) une des principale source de conflit.
Sans ce mécanisme de surcharge (qui est peut être prévu, j'ai pas suivi du tout le projet), ça va être au mieux autant source de friction que WP classique, au pire, ça va être pire parce qu'il n'y a pas la soupape de "les anglophones font ce qu'ils veulent, les francophones font autre chose".
[^] # Re: Natural Language Generation
Posté par Misc (site web personnel) . En réponse au journal Wikifunctions est le nouveau projet de le fondation Wikimedia, un wiki de fonctions éditables par. Évalué à 5.
Certes, mais je suppose aussi que les langues les plus couvertes vont être celles avec la plus grande communauté, et le reste, pas vraiment. Bien sur, pouvoir écrire une encyclopédie avec moins de ressources est un plus. Mais on va pas nier que Wikipedia, ç'est le point de vue du plus grand groupe qui prime.
Fr.wp a un biais vers la France, en.wp sans doute vers les USA.
Wikidata contourne le souci via des identifiants abstraits, et le seul endroit ou tu vois du texte, c'est dans les labels. Il est d'ailleurs intéressant de voir que même si ça n'est pas destiné à écrire du texte et à être lu à la base, il y a quand même eu des gens qui ont voulu traiter ça comme du texte à part entière, avec tout les soucis que ça entraîne d'un point de vue linguistique.
Ici, les fonctions (dans ton exemple) vont avoir des noms dans une langue (sans doute l'anglais, on va pas se mentir). C'est ça le souci pour moi.
Oulah non, au contraire, je trouve la structure des wikipedias actuelles beaucoup trop centralisés, je suis beaucoup plus radical à ce niveau.
Mon argument, c'est celui de la fin de ce commentaire sur l'espace pour le désaccord, à savoir qu'il n'y pas vraiment moyen de facilement faire une encyclopédie dérivée de Wikipedia, sauf sur des axes mineurs (comme l'inclusion ou non de certaines pages), ou via un processus peu pratiques (importer des dumps réguliers, qui requiert des compétences poussés et entraine des soucis à la synchro).
Pour reprendre un sujet qui déchire la communauté en ce moment, le fait d'avoir des images ou pas sur les articles pourrait être un exemple de choix possible si WP n'était pas si centralisé.
Avoir des fonctions pour faire son propre "abstract wikipedia", serait un bon pas, car en théorie, quelqu'un pourrait surcharger les fonctions pour changer des choses (tout comme on le fait pour spécialiser une classe en prog objet, ou du monkeypatching, etc).
Pour reprendre mon exemple, avec un système de surcharge pas trop mal foutu, rien n’empêcherais d'avoir le choix du type d'infobox, avec ou sans les images dessinées, etc. Les gens qui ne veulent pas les voir les retirent, les gens qui pensent que c'est un plus les affichent. Et tout le monde serait libre de proposer son encyclopédie, tout comme tout le monde, en théorie, peut faire des choses avec wikidata sans avoir à se mettre d'accord sur tout un tas de détails.
Maintenant, si une éventuelle surcharge est aussi pratique que "surcharger" une page de WP, alors ça ne va pas être vraiment décentralisé au sens ou je l'entends, plutôt le contraire.
Les infoboxes tirés de wikidata sont acceptées car elles sont surchargeables sur wikipedia au cas par cas. Un monde ou ça ne serait pas le cas tournerait à la guerre civile, car ça entraînerais une centralisation sur wikidata pour décider ce qui s'affiche sur X instances de WP, et c'est la centralisation en question qui est (selon moi) une des principale source de conflit.
Sans ce mécanisme de surcharge (qui est peut être prévu, j'ai pas suivi du tout le projet), ça va être au mieux autant source de friction que WP classique, au pire, ça va être pire parce qu'il n'y a pas la soupape de "les anglophones font ce qu'ils veulent, les francophones font autre chose".