Goffi a écrit 1537 commentaires

Je ne vois pas en quoi vendre de l'hébergement ça serait contraire à vos valeurs. Au contraire ça permet de développer vos valeurs : faire en sorte que le grand public puisse réellement utiliser XMPP.

ce n'est pas ce que j'ai dit, j'ai dit qu'on souhaitait en vivre en gardant nos valeurs, un hébergement n'est pas du tout contraire à ça bien entendu. Je sous entendais plutôt continuer à faire du libre, pas de publicité, pas de vente de donnée personnelles, etc.

Le grand public n'utilisera pas votre logiciel client s'il n'y a pas des offres d'hébergement grand public. La base quoi.

oui bien sûr. Mais j’espère plutôt voir des hébergements locaux/associatifs.

Tu pourras en discuter avec Daniel Gultsch qui visiblement a prévu d'assister à ta conférence : https://twitter.com/xmpp_berlin/status/912083945440899072

c'était mercredi dernier ;). Et Daniel n'était pas là, il est en Allemagne mais pas à Berlin il me semble.

Sincèrement Goffi je ne comprends pas pourquoi depuis le temps que tu promeus et travailles sur XMPP et étant donné ta maîtrise technique tu n'as pas développé un service de qualité comme Daniel Gultsch ou Nicolas Lœuillet avec Wallabag.it. Dans le même genre il y a aussi Antoine Nguyen qui développe Modoboa.

Je ne suis pas certain que l'administration d'un serveur XMPP puisse aider beaucoup à nous financer, et ça prend du temps (qu'on n'a pas).

Par contre vivre de XMPP en gardant nos valeurs c'est ce qu'on cherche à faire, notamment en faisant du service autour du développement et de notre projet. La sortie de la première version stable/grand public approchant, la question va bientôt pouvoir se poser sérieusement.

Tu oublie l'entête XML, la balise stream et tout ses namespaces. Et je ne parle pas du protocole de transport si on communique pas directement sur les ports XMPP (HTTP entre autre…)

Non je n'ai pas oublié la négociation de base, c'est juste que ça n'est pas pertinent ici. C'est une fois au début ça, ça n'est pas ce qui est envoyé à chaque message, et c'est présent dans n'importe quel protocole.

XMPP est indépendant du protocole de transport, tu peux l'utiliser sur TCP (ce qui est le cas courant décrit dans les RFC), ou HTTP, ou autre. Si tu choisis d'utiliser autre chose que TCP, tu as probablement des bonnes raisons (utilisation dans un navigateur, vouloir passer un NAT, ou que sais-je), et dans ce cas tu as les avantages/inconvénients du transport en dessous, mais ça n'a rien à voir avec XMPP lui même, donc je ne vois pas trop le rapport.

Et donc non, ce n'est pas léger. Le XML n'est pas léger. Si c'était le cas, il n'y aurait pas eu d'autres formats créés pour les échanges de données, comme YAML ou JSON.

J'ai pas non plus dit que XMPP était le format de sérialisation le plus léger du monde, j'ai dit que XMPP était relativement léger et certainement pas lourd comme tu l'indiques. Tu t'avances un peu sur les raisons de créations d'autre formats de sérialisation, JSON a l'avantage (pour le web) d'être un sous ensemble du Javascript, YAML est pratique pour la lecture, je ne suis pas sûr que la raison principal de leur création est la supposée lourdeur de XML. Si c'était l'objectif principal, on se tournerait vers des formats binaires.

IRC n'est peut être pas le bon exemple pour comparer. Alors prenons ICQ par exemple. Pour envoyer ton message d'exemple, avec un ICQ ça prend 32 octets + longueur du message (6) soit 38 octets. Avec XMPP, il faut 54 octets rien que pour ta balise message, sans compter l'en tête XML, la balise stream, les éventuels caractères blanc entre les balises etc.

Mais j'ai l'impression que tu penses que l'en-tête XML et la balise de stream sont envoyés à chaque message, ça n'est absolument pas le cas ! Et accessoirement le flux peut être compressé, donc ce qui passe effectivement dans les câbles est nettement plus petit que le message XML que le développeur peut voir/générer.

Elle définit que le schema XML du protocol, donc que celui-ci repose sur XML et pas sur autre chose à priori (à moins qu'il y ait une autre XEP qui propose une alternative à XML ?)

non, elle définit le fonctionnement du processus de standardisation, ce sont les RFCs qui indiquent que ça utilise du XML, et ça peut effectivement être changé par des XEPs comme celle que j'ai indiqué dans mon précédent message.

Alors on passe sur meet.jit.si, on perd la vidéo aussi régulièrement, mais pas le son

Essayez avec un autre serveur, cf. mon message par ailleurs. Le mieux serait d'avoir le votre pour être sûr d'avoir une bande passante dédiée, et de bien configurer pour avoir tout ce qu'il faut pour passer les NAT.

un message minimal c'est

<message to='toto@example.net'>
    <body>
        salut!
    </body>
</message>

C'est pas franchement terrible. Et si vraiment ça pose un problème (mémoire limitée en embarqué par exemple), tu as des méthodes de compression (Efficient XML Interchange (EXI) Format par exemple).

Ce qui prend vraiment de la bande passante à l'usage par contre, c'est les informations de présence (surtout de nos jours avec les appareils mobiles qui se connectent/déconnectent en permanence), et ça va être optionnel avec MIX (ça l'est déjà dans certaines implémentations, et le problème est réduit avec la gestion de flux (Stream Management) qui limite les déconnexions).

Et tu as le choix en fonction de ta configuration de limiter les infos que tu utilises, d'avoir une synchronisation ou pas, etc.

En pratique tu constateras que Prosody ou Conversations sont très peu gourmands en ressources là où d'autres ont des soucis. Oui XMPP est relativement léger.

Alors bien sûr si tu compares un XMPP avec plein de fonctionnalités activées (présence, accusés de réception, états de conversation etc.) à un IRC qui ne fait que du message simple, tu auras une bande passante nettement plus importante (y'a beaucoup plus d'infos qui passent). Mais si tu fais à fonctionnalités égales, je ne suis pas sûr que ça soit beaucoup plus gros, et si tu optimises comme expliqué plus haut, c'est probablement même moins demandant en bande passante.

mise à jour: je n'ai pas compris le rapport avec la XEP-0001 par contre

Pourquoi donc ? XMPP est parfaitement compatible avec WebRTC (https://xmpp.org/uses/webrtc.html), c'est même une très bonne chose. La vidéo conférence était quelque chose d'extrêmement compliqué à développer auparavant (codecs, annulation d'écho, etc) et c'est ce qui explique pourquoi ça a mis tant de temps à se développer (jingle ne s'occupe que la négociation de la session P2P et du « signal », ce qui n'est qu'une partie du problème).

WebRTC et ses implémentations offrent une résolution standard de ces problèmes, ce qui rend maintenant la visioconférence très accessible, et c'est pour ça qu'on la voit désormais presque partout, au moins dans les applications web.

edit: ah ben edhelas a répondu la même chose :)

Je n'apprécie pas les inscription via SMS pour une raison similaire (pas envie de filer mon numéro, pas envie que mon opérateur me spy).

Je n'aime pas filer mon numéro également, mais grâce à mes contacts qui utilisent Whats App (que je n'ai jamais utilisé) ou similaire, ils l'ont, et ils connaissent certaines de mes relations. Ça ne pose visiblement pas de problèmes à beaucoup de monde ici, mais moi ça m'en pose un, et un gros.

On connait d'autres cas d'usage d'XMPP hors messagerie instantanée ?

https://linuxfr.org/users/jnanar--2/journaux/mon-ami-se-fait-des-amis
https://linuxfr.org/news/authentifiez-vous-sans-mot-de-passe-grace-a-xmpp
https://linuxfr.org/tags/parlons_xmpp/public
https://salut-a-toi.org (que je développe)
https://movim.eu
http://projectmaxs.org
https://habahaba.im/
https://meet.jit.si/

pour les premiers qui me viennent à l'esprit. Souvent ça fait aussi messagerie (parce que bon, tant qu'à utiliser XMPP).

Dans l'embarqué (enfin pardon « l'internet des objets » ou IoT ça fait mieux), c'est de plus en plus utilisé aussi.

Jusqu'ici j'avais testé sans succès Jitsi: ça marchotait mais l'image bloquait assez vite ou autre problème. J'utilisais toujours https://meet.jit.si/ et hier j'ai testé avec https://framatalk.org suite à une discussion à Berlin sur le sujet qui m'a fait comprendre un truc tout bête : leur serveur est probablement surchargé, et du coup ça bloque. Pour le coup ça a marché vraiment super bien, et c'est un lien à envoyer c'est tout.

De toute les solutions libres (XMPP ou pas) que j'ai essayé jusqu'ici, Jitsi meet et celle qui a de loin marché le mieux (en audio pur il y a Mumble qui marche très bien, mais c'est beaucoup plus compliqué d'inviter quelqu'un, il y a un logiciel à installer et à configurer).

Par contre je ne sais pas si ça marche dans Android (ça doit marcher au moins dans le navigateur).

Pour le reste de la question (le journal), je trouve de plus en plus stérile les discussions sur le sujet ou sur ce qu'il faut ou pas faire. On sait parfaitement ce qu'il faut faire, mais on manque tout simplement de ressources pour que ça aille plus vite. Un logiciel comme Conversations qui a un certain succès est plus léché notamment parce qu'il a un développeur un plein temps dessus, tout simplement.

je pensais indépendamment d'un navigateur (ou alors avec quelque chose headless), et oui pour avoir du temps réel.

Si, par exemple, on est dans une application de chat proprio, qu'il n'y a pas d'API ni rien, pouvoir utiliser weboob pour faire une passerelle serait un bon moyen pour avoir une solution rapide le temps de faire un reverse engineering sur le protocole. Oui avec les Websocket ça serait bien aussi.

Je me doute que ça n'est pas possible à l'heure actuelle (vous n'en avez pas l'utilité a priori), mais je me demandais si c'était envisageable avec l'archi de Weboob, et apparemment oui donc :)

Salut,

bravo pour cette version.

Je me demandais si Weboob était capable de surveiller une page et réagir à des événements, notamment un nouvel élément DOM qui apparaît.

Un exemple serait une page web gérant une messagerie : est-ce qu'un nouveau message qui apparaît pourrait déclencher une callback par exemple ?

Je sais que ça n'est pas du tout l'objectif de base, et que ça complique énormément (notamment parce qu'il faut interpréter du Javascript, mais j'ai cru comprendre que Weboob commençait à le faire dans certains cas), je me demande juste si c'est possible/envisageable.

Encore une chose, en survolant la doc de l'API je ne vois rien qui permet de recevoir les messages/notifications en temps réel. Est-ce qu'un système type webhook, long polling ou autre est envisagé ? Merci

super, merci pour les infos c'est ce qu'il me fallait.

Déjà bravo pour cette version et le travail qui va avec.

Est-ce qu'il y a un endroit où on peut suivre l'évolution de l'API ? Je fais parti de ceux intéressés.

D'autre part en Python je vois principalement 2 modules : diaspy et federation. Si je comprends bien le premier utilise l'API (il y en a une provisoire donc ?) et le second est une implémentation du protocole, c'est bien ça ? Est-ce que l'évolution de l'API risque de casser diaspy ?

Bonne continuation.

toi tu vas te faire engueuler ! ;)

Sinon merci pour le partage, même si ça ne me sera pas utile à titre personnel.

C'est pas vim, c'est ton terminal ça , appuie sur Ctrl+Q pour débloquer.

stty -ixoff -ixon avant de lancer Vim et ça va rouler.

C'est un projet très intéressant, et un que je n'ai pas encore testé moi même bien que j'en entende parler depuis plusieurs années. Je viens de regarder la démo vite fait, c'est complet.

Au sujet de l'identité nomade, je me pose plusieurs questions :

• comment contacte-t-on quelqu'un qui peut être sur n'importe quel serveur ? Il y a un hash ou quelque chose compliqué, ou une astuce ?
• je suppose que oui mais je demande par acquis de conscience : les données sont chiffrées en cas de duplication ? Si je mets une identité sur plusieurs serveurs, ça ne veut pas dire que tous les admins de ces serveurs ont accès à mon nom, ma liste de contacts, mes messages, etc ?
• du coup si les admins n'ont pas accès (ce que je suppose), est-il possible de dire qu'on ne veut pas de quelqu'un ?
• quid de la place aussi, est-ce que dupliquer une identité ça prend beaucoup de place ? Si j'ai des albums photos, des vidéos, etc., est-ce qu'ils me suivent ?

D'autre part, est-ce qu'on a une idée du nombre d'utilisateurs ? Est-ce qu'il y a un modèle économique ? Comment c'est développé (prise de décisions) et par qui ?

Bon courage, il faudra que je prenne le temps de regarder ça de plus près un jour.

Il y a le bot officiel de SàT, Sabot, qui affiche les commits. En fait c'est juste un script sh qui est appelé par un hook Mercurial. J'avais expliqué le fonctionnement dans un épisode de parlons XMPP, avec un autre bot fait avec SleekXMPP.

Il va probablement bientôt afficher les tickets également.

Je soupçonne que beaucoup de monde ici a au moins fait un bot IRC, c'est un classique chez les développeurs.

Mon message n'était absolument pas dirigé contre toi, je trouve ta dépêche très bien, et la comparaison est un sujet compliqué, parce qu'il faut bien connaître les 2 environnements (d'ailleurs je ne connais pas suffisamment bien Matrix pour faire une comparaison technique poussée, j'espère avoir le temps un jour de regarder de plus près). Et c'est un projet qui fait parler de lui, c'est une très bonne chose de faire des dépêches travaillées sur le sujet, donc merci :)

Cependant même après ton message, il me semble que la différence fondamentale est bien que Matrix intègre (kitchen sink…) à la base beaucoup plus que XMPP ? Et du coup est clairement moins flexible au niveau des extensions ?
Cela me rappelle un peu le débat micro-noyau et noyau monolithique.

Je pense que le débat micro-noyau/monolithique est plutôt applicable au débat décentralisé client/server contre 100% P2P, parce qu'au niveau des fonctionnalités XMPP est justement proche du fonctionnement de Linux, avec un noyau dur (les RFCs), et des modules dynamiques (les extensions).

Au niveau des différence fondamentales, il n'y en a pas tant que ça, le système de réplication est parfaitement adaptable à XMPP. XMPP utilise XML ce qui est critiqué par certains (à tort à mon avis) sur TCP (ou autre), Matrix utilise HTTP qui a sa lourdeur.
XMPP a des recommandations par années (les « compliance suite »), qui permet d'avoir une base commune pour les clients « modernes ».

Par contre sur le plan politique (c'est pour ça que j'ai dis que j'attendais de voir), XMPP a beaucoup d'entreprises/associations et de particuliers impliqués (certains avec un but lucratif d'autre non), un système (par parfait certes) d'élection, de « council » (conseil), et des règles écrites (par exemple, il ne peut pas y avoir plus d'un certain pourcentage de membres de la même entreprise, je n'ai pas le chiffre exact en tête).

Matrix souhaite un chemin similaire d'après ce que j'ai compris, mais est développé par des membres issus d'une même entreprise, avec un financement privé, une influence et une prise de décision très concentrée, et un but probablement lucratif.

Pour moi la différence se situe plutôt là que sur le plan technique.

En tout cas j'ai jeté un oeil vite fait, et rien ne semble avoir bougé sur leur FAQ au niveau de XMPP depuis un moment. Un point que je ne comprends pas très bien, c'est pourquoi tu te refuses à proposer un changement (pull request) pour leur FAQ ?

À l'époque je n'avais pas (et ne voulais pas) de compte Github. Entre temps j'ai dû en faire un pour mon travail salarié, et je me suis résigné à en faire un autre pour contribuer à titre personnel à des projets dessus (que j'ai appelé goffi_contrib pour bien spécifier que c'était uniquement pour la contribution).

Je pense aussi que je suis trop biaisé pour modifier ça moi même, et que c'est à eux de le faire de toute façon. De la même façon je ne touche pas à la page Wikipédia de SàT parce que Wikipédia demande aux gens impliqués de ne pas le faire, et pourtant je regrette que cette page est quasiment vide et n'est pas à jour.

Et aussi (surtout), je n'ai pas le temps pour ce genre de choses annexe, même si au final écrire des commentaires comme ici est aussi long, mais j'ai vraiment un rythme de fou.

C'est je trouve assez constructif de leur part, d'essayer d'expliquer les différences avec XMPP. Et c'est risqué car du coup ils s'exposent aux critiques si ce n'est pas parfait (seuls ceux qui ne font rien ne font jamais d'erreurs).

Ah mais ça n'est pas ça le mal, c'est tout à fait légitime de faire ça, même de critiquer.

Ce que je reproche c'est la manière dont ça a été fait, et dans la FAQ les réponses sont mises, mais toujours avec une formulation qui fait douter.

Plutôt que de supprimer l'affirmation fausse que XMPP n'est pas « web-friendly », ils mettent une remarque entre parenthèses, dire que la synchronisation d'historique ou les passerelles sont des « second class citizen feature » (fonctionnalités de seconde zone) est un mensonge, c'est plein de « apparently », « questionable », il y a des guillemets autour de « fine » quand la communauté répond que ça marche avec un satellite à très faible débit.

Sans oublier la phrase « The whole subject of XMPP vs Matrix seems to bring out the worst in people » (« le sujet de XMPP contre Matrix semble faire sortir le pire côté des gens ») qui laisse entendre que c'est la communauté XMPP qui a agit avec agressivité (il y a eu en effet quelques réponses sèches à la longue).

Salut,

bon malgré mes vacances je reste un peu en ligne :). Merci pour cette dépêche détaillée.

Je vais donner mon point de vue d'un dév très impliqué dans XMPP, comme les lecteurs réguliers de ce site le savent peut-être.

Côté technique, je pense que le projet est intéressant, mais pas exceptionnel. La réplication des données risque de poser un problème de mise à l'échelle (ce qui semble se confirmer en lisant cette dépêche et par des échos que j'ai eu de gens ayant des difficultés à joindre des gros salons sur des petites machines type Raspberry Pi), et je ne vois rien qui ne pourrait être implémenté avec XMPP.

Mais côté forme, c'est un des rares, et je pense même le seul projet contre lequel j'ai une dent, et je pousse pourtant à la coopération entre les projets libres. La raison est simple, pour se faire connaître, et dès le début (j'ai connu Matrix à leur présentation lors de leur premier FOSDEM) ils ont cherché à taper sur XMPP et sa communauté. Attention, je n'ai rien contre les critiques techniques (j'en fais moi-même, XMPP a ses défauts comme tout), mais là on a vraiment eu le sentiment qu'il fallait essayer d'appuyer sur la tête du voisin pour nager à la surface, et c'est le seul projet qui m'a donné ce sentiment malgré les tonnes de projets existants, ce qui a eu des effets jusqu'ici même. Et avec leur budget marketing qui semble très important, cela a provoqué une ambiance délétère dont on se serait bien passé.

Maintenant que ce projet commence à être connu, la situation s'est nettement améliorée, mais ce n'est pas tout à fait fini pour autant, leur FAQ en particulier, qui a pourtant déjà été complétée suite à une réponse de la communauté, reste un cas d'école de mauvaise foi. Je l'ai déjà fait remarquer, on m'a promis de le corriger, mais force est de constater que c'est toujours là.

Sur le plan politique (qu'on oublie un peu trop souvent), j'attends de voir ce que ça va donner.

Enfin pour la comparaison avec XMPP, il est absolument ridicule de comparer les fonctionnalités avec la base RFC de XMPP. les RFCs sont volontairement très réduites et minimales, et toutes les extensions (et non la plupart) sont optionnelles. C'est une force et certainement pas une faiblesse. XMPP a bien plus de fonctionnalités que Matrix.

XMPP est capable de négocier les fonctionnalités disponibles et de s'adapter. Il est évident qu'un client XMPP qui se concentre sur, disons, le partage de fichier, n'a pas forcément besoin des fonctionnalités de blogage.

Aujourd'hui le nombre de serveurs et de clients est réduit pour Matrix, ou du moins se base sur un nombre réduit d'implémentations (je n'ai pas vérifié, mais je ne serais pas étonné que les clients bureau/téléphone soient des ports de la version web à coups d'Electron ou similaire). On en reparlera si le succès est là et que les implémentations se multiplient, il y aura inévitablement des problèmes de compatibilité et de fonctionnalités non implémentées ou implémentées un peu différemment.

Bref, encore une fois je n'ai rien contre la technologie elle-même, et je souhaite qu'on puisse communiquer entre les différents protocoles, mais diplomatiquement ils ont très mal commencé et ça a l'air de se tasser (même si on attend toujours pour la FAQ). À mon sens (forcément biaisé), ça n'apporte strictement rien par rapport à XMPP, c'est un énorme désavantage de ne pas avoir le système d'extensions, et cela semble lourd à l'usage (à voir ce que ça va donner avec Dentrite). Par contre leur logiciel a l'air léché ce qui est une bonne chose et sans doute la raison du succès (avec la com). Ceci dit, une dizaine de dév à plein temps (jusqu'ici) c'est énorme, et ça explique le résultat rapide.

En comparaison, un projet comme Movim, certes plus ancien, a été fait par principalement une seule personne sur son temps libre, et je n'ai pas l'impression qu'il a beaucoup à envier.

s/donc 4 amis/dont 4 amis/
s/voir que XMPP et actif/voir que XMPP est actif/
s/mais ça cruellement de bras/mais ça manque cruellement de bras/

Et sûrement d'autres que j'ai laissé passé :(

Non, et je vois très rarement des réactions « directes » (à part des vagues d'inscriptions suite à des versions majeures et des publications ici, ou celles qu'il y a eu sur Framablog ou Reflets, mais qui s’essoufflent vite).

C'est pareil dans les événements : il y a toujours un enthousiasme certain quand t'es sur place, t'as des tas de gens qui te disent qu'ils vont t'aider, contribuer, ou faire ci ou ça, et au final ça n'arrive jamais ou presque.

Mais par contre je vois clairement les évolutions avec le temps : à force d'en parler, le projet est connu dans la communauté francophone. À ma première conf aux JDLL il y a 6 ans il y avait 4 ou 5 personnes. À mes dernières confs aux RMLL il y a 2 ans, il y avait salle comble, et les gens disent presque tout le temps avoir entendu parler du projet désormais dans le monde francophone. Par contre j'ai fait une conférence en République Tchèque l'année dernière, il y avait… 4 ou 5 personnes (donc 4 amis :) ).

Les articles sur XMPP ont été utiles également, il y a notamment eu un regain d'intérêt pour l’authentification XMPP (et le composant de Chteufleur< a été écrit suite à ça), et ça a incité du monde à utiliser XMPP pour des projets (au moins jnanar< qui a fait une interface ad-hoc pour son robot). Et surtout ça permet de voir que XMPP et actif, et à ceux qui s'y intéressent de comprendre un peu mieux comment ça marche, ce qui était le but.

En ce qui concerne cette émission en particulier, je ne crois pas que l'audience de Radio Prague soit faramineuse, mais elle est très accessible et je m'en servirai comme référence pour expliquer le projet à ceux qui le souhaitent.

SàT reste encore confidentiel, et à la limite c'est pas plus mal de rester sous les radars tant que la version grand public n'est pas sortie (mais ça cruellement de bras, je suis le seul à développer à l'heure actuelle), par contre une fois celle-ci en place, j'espère et je pense que ça va décoller assez rapidement.

J'utilise Linphone avec mon opérateur mobile qui me permet de passer les appels ou SMS en SIP, c'est très pratique, la version Android marche vraiment bien, et elle est plus intuitive que la version bureau (je suis en 3.11.1, la version Arch n'a pas encore l'air à jour). De ceux que j'ai essayé, c'est de loin celui qui marche le mieux avec SIP.
Bref, merci pour cet outil bien utile.

Salut,

déjà bravo pour ce super boulot, j'utilise Grammalecte de temps en temps (par exemple en relecture de longues dépêches, notamment avec le greffon Vim), et c'est un super outil.
La dépêche a beau parler de grammaire, elle m'a paru très intéressante (et a dû te prendre un temps fou à écrire).

J'ai quelques questions/remarques:

1. Sur un plan pratique, tu maintiens désormais 2 moteurs (Python et Javascript) si j'ai bien compris, même 3 vu que Firefox et Thunderbird ont un moteur différent. C'est gérable sur le long terme ? Il n'y a pas un risque d'abandon de la version Python ?
2. Comment est-il possible d'utiliser Grammalecte depuis un logiciel tiers, au hasard en Python ? Comme une bibliothèque ? La dernière campagne parlait d'un mode serveur si mes souvenirs sont bons, est-ce la façon de faire ? Peut-on trouver de la documentation sur le sujet ?
3. Question liée à la précédence : il y a-t-il moyen d'utiliser des fonctions internes, je pense en particulier à la possibilité de retrouver la forme canonique d'un mot ? Ça pourrait m'être très utile.
4. Pour ma part je préférerais avoir un mode strict qui refuse les néologismes et autres bizarreries sur le web justement (pour choisir moi même ce que je souhaite garder ou non), est-ce qu'il serait possible de faire un mode plus ou moins laxiste (une sorte de liste déroulante avec un niveau de ce qui est accepté) ?

Encore bravo et merci pour ce projet.

En effet, j'ai cru que c'était un des dévs qui parlait (et il n'y a pas que le dernier « nous », les 2 sont trompeurs). Je ne vois nulle part une mention que c'est une traduction, du coup ça serait bien de la mettre.

Merci pour l'article en tout cas.