[feature] Internationalisation

[ghost]

I suppose I'm just opening this to raise it for discussion. I've never built a project for internationalisation before so I dunno what options are on the table or what structural changes they impose. I know Mastodon uses Crowdin, which might offer some kinds of affordance for 'borrowing' translations for common UI elements like "follow", "post", "block" etcetera.

[tsmethurst]

Good one to open :+1: @f0x52 do you have any ideas for the best way of internationalizing the frontend (preferably keeping JS dependencies to a minimum if we can)

[f0x52]

hmm i'd expect to do this mostly through the templating, serverside. Not sure what Gin/etc provide for this

[ghost]

There seems to be a 'contrib' package for 'I18n' (ugh): https://github.com/gin-contrib/i18n

It appears to be able to use browser headers to infer language, though hopefully one can indicate from server-side which language to use, so user language choices can be respected without requiring them to make (fingerprintable) global changes to browser configs.

[ghost]

Looking at the scope to re-use the translations from Mastodon.. it might be hacky to make that work in a 'direct lift' sort of situation because both translation file formats use the templating systems of their respective languages/frameworks:

• Gin: https://github.com/gin-contrib/i18n/blob/master/_example/localizeJSON/en.json
• Mastodon: https://github.com/mastodon/mastodon/blob/main/app/javascript/mastodon/locales/en.json

Possibly one could actually brute-render the Mastodon text with defined inputs to facilitate reversing them into Gin templates, which might be a strategy to bootstrap into the language set supported by Mastodon for shared strings.

[tsmethurst]

Now that's a sneaky hack :') Alright, let's bear it in mind