i18n?
Closed this issue · 4 comments
given most of the target demographic speaks english, is it needed to have this? open for discussion
it looks pretty simple to set up i18n here as it would mostly involve the task_list.json file. Its easiest to set up early in a project.
Essentially, we'd need to not reference text directly in task_list.json, but instead use some unique key
For Example
...
"task_description": "Collect 10 strawberries",
...
would change to
...
"task_i18n_key": "COLLECT_10_STRAWB",
...
and the maintain a separate json file with all the key -> text lookups, one file for each language.
...EN.JSON...
"COLLECT_10_STRAWB": "Collect 10 Strawberries",
...
...DE.JSON...
"COLLECT_10_STRAWB": "Sammle 10 Erdbeeren",
...
I could get an initial branch up explaining my ideas here, but I dont have much knowledge of php or your frameworks in use here.
I like keeping the content and localizations in separaje json files, it's simple and easy to access.
How would we enable i18n in front-end? I guess a select at top right would be the best bet.
with javascript you can ask the browser for its user locale, but that can be trouble. we should probably look for a library, i see that slim has some extension called twig that is an html templating engine that has support for i18n, but that would require some significant refactoring i think. ( though i do have limited php knowledge, maybe its easy?) see https://helgesverre.com/blog/i18n-slim-framework-translation-twig/
thinking about it more, a dropdown would by far be the easiest approach, we should try that first i think.
Implemented and fixed in new branch even-more-i18n