search

kas-catholic / confessit-web

Source code for https://confessit.app
MIT License
18 stars 8 forks source link

Add a framework for translations #6

Closed kas-catholic closed 1 year ago

kas-catholic commented 3 years ago

Add support for other languages. I haven't looked into it yet, but I expect there's a framework or a standard way to do this for a single page React app, and we should use whatever tools we can that already exist and are common.

kas-catholic commented 3 years ago

Let's use https://react.i18next.com/

JohnRDOrazio commented 3 years ago

looks good!

JohnRDOrazio commented 3 years ago

I see it is built in a modular fashion, with a number of plugins for specific tasks. For example there is a plugin that allows you to scan the source files in order to pull out all the translation strings into an i18next json file (https://github.com/i18next/i18next-parser).

i18next json files can be converted to gettext format which is quite useful: https://github.com/i18next/i18next-gettext-converter . Because when it comes to handling a certain number of translation strings, especially if changes are made to the source files and translation catalogues need to be updated, you really need a platform to help handle this. i18next is pushing locize.com but locize.com is a paid service. There are plenty of free tier services out there for handling this kind of task, for example https://poeditor.com/ which I've used in some of my projects. If the project is open source, usage of the service is free.

JohnRDOrazio commented 3 years ago

Looks like there's another plugin for pulling translations in from an i18next json file: https://github.com/i18next/i18next-http-backend . Gettext .po files can be converted back to 18next json and then used in the app as language bundles.

kas-catholic commented 2 years ago

We're making progress on this!

I've merged code to main that puts a framework in place for our use of i18next.

Roughly, my plan from here is:

kas-catholic commented 2 years ago

I believe all English strings are now in the translation file. At this point, we should be able to support new languages simply by adding a translation file for them :smile:

JohnRDOrazio commented 2 years ago

Great! I started connecting with my weblate instance. However it will probably need permissions to create the weblate branch and open PR's from the weblate branch to the main branch. Also it would be nice to enable the webhook to https://translate.johnromanodorazio.com/hooks/github/ in the repository settings so that new translation strings will be picked up automatically. (See https://github.com/kas-catholic/confessit-web/pull/13#issuecomment-977171835 )

JohnRDOrazio commented 2 years ago

I believe the weblate instance is linked to my Github username @JohnRDOrazio , so in order for weblate to push translations to a weblate branch and open a PR, the user @JohnRDOrazio needs rights to create a branch and push to the repo. (I would still continue using my own fork for any code contributions I might make.)

JohnRDOrazio commented 2 years ago

Perhaps to make life easier for future development, if any translation strings are added or removed or changed in the source code, instead of manually updating the source language file, an automatic scan could be set up which will update the keys of the language files based on the source code.

I accomplished this in a repo in the Liturgical Calendar project, by setting up a Github workflow that uses i18n-scanner:

https://github.com/Liturgical-Calendar/examples/blob/main/.github/workflows/npm-gulp.yml

I based myself off of an example that used gulp, though I have never used gulp and am not familiar with it. I had to create a gulpfile in the repository:

https://github.com/Liturgical-Calendar/examples/blob/main/gulpfile.js

I'm pretty sure the same can be accomplished without gulp, simply using the CLI version of i18n-scanner.