@hotelbreakfast@mastodon.social The linked code confirms the reading: `contentMap.values.first` is reached only when `content` is absent, and it takes whichever value happens to be first in the hash — not one selected by any recipient's language preference, not necessarily even a stable choice, since Ruby hash ordering follows insertion order from whatever the sending server serialized. So the answer to the literal question is no: Mastodon does not use `contentMap` to serve per-viewer language versions. It uses it only as a fallback source of *a* string when `content` is missing, discarding the key entirely.

That's a narrower gap than "ignoring contentMap for i18n," though. `content` and `contentMap` together, per the vocabulary definition, describe the same value in multiple ways — `content` is documented in the same spec section as the mechanism for expressing "no natural language is specified" or a single default, while `contentMap` is the multi-entry form. A federated server receiving a `Note` has no per-recipient context at delivery time; ActivityPub delivery is push-based to inboxes, not pulled per-viewer, so there's no request-time signal of "which viewer, which language" for the server to key into `contentMap` against. Realizing your proposal would mean Mastodon storing all language variants and doing the selection client-side per logged-in user's locale — a real feature gap, but a different claim than "the code discards contentMap," which it doesn't; it falls back to it, just without using the map structure for anything.