🪨 (@Varpie)

La gestion du langage avec la fédération est... intéressante...

Une lecture de l'outbox d'un utilisateur sur #Mastodon montre que les notes n'ont pas d'attribut de langue, contrairement au status récupéré directement depuis l'API de Mastodon, mais il y a un attribut contentMap qui ne fait pas partie de la spécification des notes, qui comprend un mapping du texte en fonction des langages (par exemple, une note avec "content:" "Hello, world!" va avoir "contentMap": { "en": "Hello, world!" }), ce qui en théorie veut dire qu'un contenu peut être fait multilingue.

Vu que ce n'est pas un attribut normalisé, #Firefish ne l'utilise pas, mais il contient un attribut source (également non normalisé) avec le markdown Misskey des notes.

Enfin bon, ça montre un peu les limites d'#ActivityStreams : même si les bases sont correctes, il manque des éléments comme la gestion des langues qui rendent les choses plus complexes, parce que maintenant tout le monde va vouloir y faire à sa sauce et bonjour le bazar. Ce serait bien que ce soit normalisé aussi...

@Varpie y a tellement de choses qui manque au spec au point qu'au final, souvent c'est l'implémentation de mastodon qui sert de ref. C'est un peu domage. Je sais pas si le groupe de travail ActictityPub est encore actif.

@julien Evan Prodromou, un co-auteur d'ActivityStreams, a fait quelques modifications dans l'editor's draft il y a quelques mois, mais ça n'a pas l'air super actif non plus. Pour ActivityPub, pas de changements depuis que c'est devenu une recommendation, en gros.

@julien Après, en l'occurrence dans ce cas Mastodon suit juste la norme d'ActivityStreams, qui prend le nom de la propriété, rajoute Map et permet d'avoir la valeur avec plusieurs langues. Donc pour le coup c'est bien, et normal que les autres suivent.

Tout ça pour voir que je ne vais pas pouvoir faire un plugin pour ajouter les langues sur Firefish, parce que le backend ne le supporte pas (et comme Firefish ne supporte pas ActivityPub en client-to-server, pas moyen de le forcer).