bcardiff
commented
4 years ago Until now there are a couple of pieces to make the translations work.
Getting English content from Github to Lokalise
On every build on master a i18n-en.json file is generated and uploaded to Lokalise. In https://github.com/flattenthecurve/guide/blob/master/.github/workflows/publish.yml#L35-L48 .
This is using a forked version of a GitHub Action to tweak some upload configuration needed for this project, and to upload the English content only. The commit history of manastech/lokalise-file-push@ftc should be self-explanatory.
Getting translations from lokalise to github
The https://ftc-lokalise-github.manas.dev/ service source code is configured as a webhook in lokalize. Its role is to debounce/throttle during 15min the callbacks per language. It also allows to manually trigger the workflow for a specific language if needed.
So, on every change of a translation on language X, it will wait during 15min for more changes. Once that time passed it will trigger the preview-translations workflow that will pull the new content for the language X and leave it in a branch with preview url.
The repository_dispatch: in the preview-translations is to allow triggering the workflow on demand.
The goal was that people without a git working copy could, via github, view the updates of lokalise and merge them into master for publishing.
If you are migrating the code to a cron and the waiting time for that is ok, then the external service can be removed.
Looks like both me and @bcardiff were working on improving the same process.
Brian has hooked Lokalise webhook to preview-translations workflow via https://ftc-lokalise-github.manas.dev/lokalise which is a black box as of now to me.
I have built cron-based latest-translations workflow using different branch naming scheme.
We should consolidate efforts and keep only one of the two. I think that direct integration with Lokalise is better (faster integration of new content) but we should document/explain how is the intermediate step implemented and how to manage it (afaik the code is not part of the github repo and the deployment of this webservice is a mystery).
Phase 2 of my efforts were exploring whether we could deploy preview to some stable domain names (e.g. $lang.preview.flattenthecurve.com) so that we don't have to muck around with pseudo-random now.sh domain names that are created whenever new content is published. Having stable domain name would allow us to navigate to known address whenever we want to check the new content.
This might also be a good chance to consider how we track our contributions to reduce the chance that we are working on the same thing without knowing about each other. I suspect neither of us really created a tracking issue for this. I have outlined my thoughts about this on Slack but I don't think we are all on it.