Hemmelig.app
Hemmelig.app copied to clipboard
HemmeligOrg
i18n support
Hi, I'm the guy who asked about translation support in Reddit. Would you consider a PR with some support? Frontend maybe.. I think I can add some basic implementation of react-i18n...
👋
Please do. Hopefully the frontend code is not to spaghetti. I know strings are thrown around all the places. Even with ternary operators.
react-i18n is 👍 to me!
Hey, What do you think? https://github.com/luismanson/Hemmelig.app/commit/563ffbf7cca9c49f56fd3cfdb1f9522cb0a6def8 it's not very complete, but the basic front strings.
@luismanson added a comment: https://github.com/luismanson/Hemmelig.app/commit/563ffbf7cca9c49f56fd3cfdb1f9522cb0a6def8#commitcomment-83183511
To me it looks great. You do not have to add the loader component for the Suspense, but if you do it would be cool. Feel free to open a PR :)
new PR: https://github.com/HemmeligOrg/Hemmelig.app/pull/83
Thank you for your contribution :)
How would I go about adding more languages? I've created a new file public/locales/de/translation.json with the updated strings. Do I need to add this new language in src/i18n.js as well? And does the site itself already have some sort of system language detection or would that still be needed?
Hello, you need to set de as the default language in src/i18n.js.
Language switch/detection has not implemented yet.
PS: @bjarneo I'll submit my translation in the next day or so.
If i can figure out at what point the strings are loaded, maybe I can whip up a language detection & automatic switching method. Wish me luck 🤞🏼
check this doc: https://react.i18next.com/latest/using-with-hooks the example has some comments about language detection and file loading
Reopening this issue.
One thing to consider here is to have an option to set the default language for the instance. This can be solved by adding an env var called SECRET_LANGUAGE. Then add than env var to the client config here: https://github.com/HemmeligOrg/Hemmelig.app/blob/main/config/default.cjs#L63
Which means you can fetch it like this: https://github.com/HemmeligOrg/Hemmelig.app/blob/main/src/client/routes/home/index.js#L51 One important note here is that the config that is imported and used in the frontend, is coming from this file: https://github.com/HemmeligOrg/Hemmelig.app/blob/main/src/client/config.js
I have added you both @luismanson and @RainerZufahl as contributors to this repository. Let me know if something is not right about the settings. Should be allowed to create branches and PRs
Thank you! I've already created a fork of the repo which I'm working in, should I scrap that and create a new branch in this repo?
How should we handle new strings? I think this has to be as transparent as possible.
I noticed later that new strings could be written as t('some_string', 'Some String') but there are other options as Runtime Extraction and some plugins.
Hm. Interesting. I have to look into this.
But, of course, using t('some.string', 'Default string') is a good start, because that means if a language does not have the translation, it will automatically fallback to the default english string?
Yes, it should. If i understand correctly, this would even work with an empty default LANG setting.
I think that would be the first approach for this. How would runtime extraction and plugins work with create-react-app?
But, of course, using t('some.string', 'Default string') is a good start, because that means if a language does not have the translation, it will automatically fallback to the default english string?
That would mean that the english translations are hardcoded into the program, instead of an external string file, correct? While practical in some ways, that would make adjusting the english strings later on more complicated again.
Yes, that's right, it's a "good start" as @bjarneo called it and we can all agree that hardcoding stuff is a big no-no... However this would allow us to still translate the app without adding too much work at the default strings or new code, this is where some for of extraction/tool could come in handy.
Continuing from #212
- Currently,
SECRET_FORCED_LANGUAGE=??does not result in the language changing. - It's fine that there's an option to force the language, but imho this should not be the default behavior. Instead:
- Don't set
SECRET_FORCED_LANGUAGEby default indocker-compose.yml. If set, use the defined locale. - Use the browser's preferred language list to determine the language
- Fall back to English
- Don't set
- I tried to force a language by changing the fallback language in
i18n.js, but that doesn't work either. I think the entire i18next logic is faulty at this time.
@bjarneo Any luck trying to find out what's causing this? It's pretty hard to onboard people if there's a language barrier (especially with the knowledge that the translation is in fact already present 😅).
@ltguillaume this PR solves the SECRET_FORCED_LANGUAGE issue: https://github.com/HemmeligOrg/Hemmelig.app/commit/1404f0ac58e82f4e57b275aa0cbda57d89d6f26a
Test with German:
Yeah, that would've been something
Well, when I looked at the code a while back, it seemed like the logic to do that is already there, but perhaps it doesn't actually get the values from request header to properly evaluate them against the available languages, thus defaulting to English (or SECRET_FORCED_LANGUAGE)?