Repository navigation
Post language metadata is not correctly federated to Hollo #647
Description
Description of a bug
The language information of posts is not correctly preserved when federating:
- from one Hollo instance to another Hollo instance
- from Mastodon to a Hollo instance
The receiving Hollo instance does not correctly interpret the language metadata of federated posts.
Tested versions
- Hollo af7e0bb (unreleased
mainbranch as of 2026/10/03) - Mastodon v4.7.3 (mastodon/mastodon@8ff11c2)
Some context
I noticed that Mastodon uses zh-YUE as the Cantonese language tag, which is rejected by the Intl.Locale constructor:
In that issue, I cited Hollo as an example of an ActivityPub implementation that uses Intl.Locale. I verified locally that language information from Mastodon posts was not being federated correctly to Hollo, and wrote the description based on that finding.
However, I was too hasty and did not verify whether language information was federated correctly from Mastodon to Hollo for languages other than Cantonese. I ran control tests with other languages (e.g., en, ja, and zh-TW) and confirmed that the language metadata is not recognized correctly in any of these cases.
Conversely, I also confirmed that language information successfully federated from Hollo to Mastodon, as long as the language is supported by Mastodon.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Effort
Activity
naskya commentedon Oct 3, 2026
I think the cause is that
persistPost()takes a remote post’s language from the singularcontent/summary, but Mastodon (and Hollo itself) sends data that doesn’t match this after JSON-LD expansion.hollo/src/federation/post.ts
Lines 435 to 440 in af7e0bb
dahlia commentedon Oct 4, 2026
Thanks for the report, and for running the control tests with other languages. That's what made it clear this wasn't only about Cantonese.
There turn out to be two separate problems here.
The first one is in Hollo, and your guess was right. Mastodon and Hollo both send
contentalongsidecontentMap, so after JSON-LD expansion thecontentproperty holds two values: a plain string and a language-tagged one.object.contentreturns the first, which is the plain string, so theinstanceof LanguageStringcheck never passes and the language is always stored asnull. This affects every language, including posts from other Hollo instances. The fix is to look throughobject.contentsandobject.summariesfor aLanguageStringinstead.The second one is specific to
zh-YUEand lives in Fedify.zh-YUEis actually a valid BCP 47 tag (an extended language subtag, which RFC 5646 canonicalizes toyue), butIntl.Localeonly accepts Unicode BCP 47 locale identifiers, which don't allow extlangs. Fedify currently drops such values without any warning. I've filed fedify-dev/fedify#1229 to have Fedify normalize extlang tags before passing them toIntl.Locale, so Cantonese posts from Mastodon will keep their language whether or not mastodon/mastodon#40840 gets resolved.I'll fix that in a Fedify patch release shortly, and then ship both fixes together in a Hollo 0.9.x patch release.
Store the language of remote posts with contentMap
Upgrade Fedify to 2.2.16
dahlia commentedon Oct 5, 2026
Fixed in Hollo 0.9.22.