Open
Description
I've always had a hard time getting English-speaking groups to use Hackfolder, and it seems to mostly be a reflection of the non-English language communicating "this is not for you".
I'd like to discuss how multilingual support (i18n) might be possible :)
Here are some thoughts -- 🔍 facts, feelings ❤️ and 💡 ideas -- related to this issue:
- 🔍 hackfoldr is totally client-side
- 🔍 Multilingual support on same page can hurt SEO.
- 🔍 The recommended tactic for best SEO is to use different routes for each language:
example.com/en/:slug
- 🔍 No pages of hackholdr.org or subdomains are indexed in Google right now.
- ❤️ I feel that perhaps we could ignore SEO advice because we already aren't very SEO-compatible.
- 🔍
i18next
is a popular multilingual JS framework. - ❤️ I feel uncertain whether i18next is right for us
- 🔍 i18next has a browser language detector plugin for apps like hackfoldr.
- 💡 We could use i18next without language routes, since we're not getting hit by SEO and this will be minimal change from current hackfoldr.
- 🔍 i18next can easily pull translations from a url stored at one of the app's endpoints.
- 🔍 This is a codepen example of the simple behavior described above.
- 💡 The MVP could use javascript's
navigator
property to auto-detect language. - 💡 We could later add a langauge selector and use the detector's cookie/localStorage features.
Metadata
Metadata
Assignees
Labels
No labels