洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

I've been wrestling with implementing content support in Hackers' Pub, our -powered platform for software engineers.

While ActivityPub theoretically supports multilingual content through the contentMap property, the reality is that most server implementations (Mastodon, Misskey, etc.) don't properly handle this content as of April 2025. This creates a significant challenge for us.

We want our users to share their knowledge in multiple languages, but we need to ensure compatibility with existing ActivityPub servers. I'm considering several approaches:

  1. Creating separate posts for each language with clear language indicators, linking them through inReplyTo relationships (so translations appear as replies to the original post)
  2. Using the primary language in content while storing translations in contentMap
  3. Adding "View in other languages" links at the bottom of each post
  4. Implementing inline language dividers that degrade gracefully on non-supporting servers, for example:
    <div lang="en">
  <h3>English</h3>
  <p>This is the English content…</p>
</div>
<hr>
<div lang="ko">
  <h3>한국어</h3>
  <p>한국어 내용입니다…</p>
</div>

I'm leaning toward a hybrid approach—showing content in the user's preferred language when possible while providing easy access to other language versions.

Has anyone tackled this problem effectively? I'd love to hear about your experiences or ideas for making multilingual content work well in the fediverse, especially when dealing with server implementations that don't fully support ActivityPub's multilingual features.

Hackers' Pub

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

hackers.pub

10
0
0

If you have a fediverse account, you can reply to this note from your own instance. Search https://hackers.pub/ap/notes/019641cd-bde9-7f41-a31a-7b187b088127 on your instance and reply to it.

Chee Aun 🤔 @cheeaun@mastodon.social
Public

@hongminhee洪 民憙 (Hong Minhee) (4) seems good. It'll be no different than having mixed-language content. E.g. the ruby tags can be extended as such:

```
<ruby lang="ja">日本語<rp>(</rp><rt lang="ko">일본어</rt><rp>)</rp></ruby>
```

But, I think some folks might want to separate them with (1), so that people can subscribe to one account but filter by language ("Change subscribed language" in individual profile pages on Mastodon).

1
1
0
partizan @partizan@twiukraine.com
Public

@hongminhee洪 民憙 (Hong Minhee) maybe it's better to rely on contentMap, and temporarily be the one fedi platform that supports it, and when you are sure it works good enough, you can share knowledge and maybe even help others build it the right way.

1
0
0
silverpill @silverpill@mitra.social
Public

@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).

Pitch As described in the issue title: Mastodon could consider removing the sanitzation rule that strips <hr> elements from incoming statuses received via the federation API. Motivation Horizontal ...

Allow horizontal rule / `<hr>` elements in incoming statuses through the sanitizer · Issue #28593 · mastodon/mastodon

Pitch As described in the issue title: Mastodon could consider removing the sanitzation rule that strips <hr> elements from incoming statuses received via the federation API. Motivation Horizontal ...

github.com · GitHub

0
2
0