I want to setup a workflow to maintain translations. Please think of a translated website with a canonical language and dependent translations. When a file in the canonical language is changed I would like to update the translations ASAP.
Currently my idea is to use git to track changes in the canonical files as git diff --name-only returns the changed files between two commits. This would imply that I tag my translations to have a point of reference. I am not sure whether this is a good idea. Especialliy if editors and translators are working at the same time. Maybe branches can solve this. But this is a manual solution, anyway.
I am looking for a better way to mark translations as outdated. I think the building blocks are there with the GitInfo object. Is it possbile to access the GitInfo object of the canonical file from the translation files? So that I can put a invisible hint in the footer: “this is the translation of name.md (47c7cbf)”
But I think that Hugo keeps track of changed files by itself eg. it only renders changed files with FastRender. Can I use this to display changed files?
For tracking translations, it really depends on how fancy you want to get. I don’t know of any translating teams that don’t use a centralized database/spreadsheet for tracking changes (built on top of tools for normal content auditing and tracking).
It’d be cool if someone does this with git, though.
I can think of two git releated workflows to manage translations.
Working with tagged releases. If a new tagged release is checked in the translators can start their work.
Working with branches. Every (major) change in a file is done in a branch so that translators tracking master only see relevant commits.
I guess the first workflow is better, because editors actively mark a commit as a release that has to be translated.
A third way could be that editors use certain keywords in the commit message like “please translate” that could trigger the translation workflow.
I would commit all translations to a branch which only gets merged when the translation is finished and approved.
I am not sure whether it is useful to include Hugo into the translation workflow at all.
A manual way of controlling the status is to have a param in the frontmatter like “version”. Each time the editor thinks that a new translation is needed he tags the commit and assigns the tag to the frontmatter params like "version: “v1.5.7”. The translator looks for the new version number, starts translating and also marks his translation as "version: “v1.5.7” in the frontmatter when it is finished. Comparing the values of “version” in all translations Hugo could generate a list of outdated translations.
Perhaps I am offtopic.
Have a nice day, all together.
If I were trying to do this, a starting point would be the fact that Hugo treats a set of files in a folder with the same filename but different suffixes as translations of one another. You know what the canonical file is based on the main language setting.
I’d then use githook scripts to do stuff like this:
for a given folder, when the canonical file gets changed, mark something in the associated translation files as “needs refresh”
auto send translators a ping, saying their file needs a refresh, maybe sending the SHA of the change commit
maybe make an issue in your git system via its API to flat what needs done and even assign
if marking the files in,say, their frontmatter is not quite right, then maybe make a manifest file of translation updates that could somehow be parsed.
Thinking about it, I think you hit the nail on the head when you mentioned what happens when editors and translators are working at the same time. Something has to “win”.
I’ve introduced a translation status page, keeping track of all outdated translations based on their git mod date and a manual version tag I added (not necessary but nice for translators). This is the code, and here is the actual output.
I still struggle with finding an equivalent for the i18n strings, see this forum post.
