-
-
Notifications
You must be signed in to change notification settings - Fork 7.4k
Open
Copy link
Description
Pitch
Currently, I see three parameters that take an ISO 639 string in the statuses API.
POST /api/v1/statuses:languagePOST /api/v1/statuses/:id/translate:langPUT /api/v1/statuses/:id:language
I suggest that we should expand them to accept a well-formed BCP 47 string, or if any compatibility concerns, make another parameter (such as locale?) that can store them. The ActivityPub content property readily accepts BCP 47, so I think this is just a Mastodon API restriction.
Motivation
-
ISO 639 alone is not a "practical" approximation of concrete languages people perceive
- In short, a single ISO 639 code may look a reasonable identifier in most of the European region, it often doesn't in other parts of the world. It is either because history, politics (ISO is voted by countries), or simply mismatch of technology and culture. Sometimes multiple subtags combined to be the "idiom" for a user-perceived language.
- I already found many people reporting various issues in Add more options to language selection #18538
- But if I'd to add another, for example, "Spanish" variants across the Atlantic are already enough divergent that a random everyday word in one region is a profanity in another (example), that would seriously harm the usability of profanity filter (Scunthorpe problem).
- Machine translation providers, such as Google Translate or DeepL already support AmE (
en-US) vs BrE (en-GB) and Brazillian Portuguese (pt-BR) vs Portuguese Portuguese (pt-PT), which Mastodon API cannot accept (edit: it was already reported in Consider the country when translating with DeepL #22707).
-
it affects wider audience than Mastodon
- Other software including Friendica, Pleroma, GoToSocial..., and various client apps rely on Mastodon API for compatibility, so it is restraining a much wider user base from implementing more flexible language selection on their own.
- Even if Mastodon has difficulty putting it in use anytime soon due to other design issues (though I'd like to see it happen), the API change is a helpful step I think "relatively easy" to do.
M2Ys4U, VyrCossont, onmyouji, poga, nikclayton and 3 more
Metadata
Metadata
Assignees
Labels
No labels