@hongminhee洪 民憙 (Hong Minhee)

>most server implementations (Mastodon, Misskey, etc.) don't properly handle this content as of April 2025

How multilingual content should be handled, in your opinion? Specification doesn't provide any guidance on that matter.

>I'm considering several approaches:

I'd use (2) as primary representation and (3) as fallback.

(1) is fine too (FEP-e232 links could be used instead of inReplyTo, if top-level posts are preferable).

(4) should be avoided, because such content will be rendered as a long post with no clear boundaries between translations. I don't think <hr> is a good solution, and it's not widely supported (m).

@silverpill

How multilingual content should be handled, in your opinion? Specification doesn't provide any guidance on that matter.

It would be great if the existing implementations have language tabs for multilingual posts!

FEP-e232 links could be used instead of inReplyTo, if top-level posts are preferable

FEP-e232 sounds a good idea! I'm considering that approach too.

(4) should be avoided, because such content will be rendered as a long post with no clear boundaries between translations. I don't think <hr> is a good solution, and it's not widely supported (m).

I'm also considering using <details> as well. I'm not sure how many existing implementations support it though. 🤔

2

If you have a fediverse account, you can reply to this note from your own instance. Search https://hackers.pub/ap/notes/0196432c-ada3-70c3-be27-a3f640a42eaf on your instance and reply to it.

FEP-e232 object links are microsyntaxes, but what would the `tag`s annotate? Maybe combine with (3) and make the "View in other languages" links the microsyntaxes, like `{ "name": "<a href="…/ja">日本語</a>", "rel": "alternate", "hreflang": "ja", … }`?

In that case, I'd abandon (2) altogether, since they would be pure overhead (embedding the `contentMap` representation for each language in every `alternate` object would be a headache, especially for long-form articles)

1