This seems like a good idea. Could you submit a PR with your recommended workflow?

The snake seems to be eating its tail: #1121/files#diff ;-)

I'll revisit this in a few days once there is a difference between my translation_branch& upstream/master to check whether the above initial idea is viable.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This is a tough nut. I tried the following today:

1. Copy ID of last own commit in _articles/de.
2. git switch master && git pull upstream/master
3. git diff --word-diff $LAST_OWN upstream/master _articles/*.md > TODO-translate.txt
4. git switch $translation_branch
5. git rebase master
6. Go through TODO-translate.txt & implement the English source's changes accordingly in the _articles/**/*.md translation(s). Because of the "own commit" step initially, one will sometimes notice already implemented changes by other translators. Skipping those seems less problematic, than remembering to only update the translation_branch after diffing.

@katrinleinweber FWIW this is something I suggested a while back: #288 (comment). It'd be nice to have it fully scripted so that it'd be easier to automatically check it...

Yeah, that might be a more convenient step 1., but it would require each translation session to cover all of the English updates, wouldn't it?

Because those can occur in parallel to minor translation updates (correcting links, wording, or spelling), there is a risk of overlooking significant English updates that occured before such a minor update's SHA is recorded in the translation metadata, no?

What about considering using some professional translate tools instead of using Git directly?
Git is powerful but not the best tool for translating articles. Contributors have to use additional steps to check the difference, and it seems hard to automatically merge new contents into translation. And, The smallest unit of Git comparison is the lines, not sentences. These problems mean additional manual work.
But these professional translate tools like Transifex, Crowdin, and Weblate can do these things automatically, with lots of additional features. They can cut articles into sentences and track all the modifications of source articles. They can handle all the issues about translation from minor changes to new articles. Translators only need to translate all the sentences that marked as "need to be translated", and all the other things like generating the translation files can be done by the platform. And these tools can also help check the translation itself, like machine translation hints, word lists to keep the same word to have the same translation, and similarity check to help translators see the existing translation from these similar sentences and avoid duplicate work. These platforms can work with Git and commit changes, and all the other workflow won't be affected. These tools provide free services to open source projects, so maybe it's a good idea to consider using these platforms to make the translations easier to maintain.

What about considering using some professional translate tools instead of using Git directly?

This is being discussed in #1133 and is on my list to investigate further (hopefully over Christmas).

@MikeMcQuaid That tool seems to be different from the platforms I suggested. GitLocalize looks like a lightweight translation tool working with Git, and what I suggested are professional translation platforms with lots of additional features. And these platforms are more famous (according to the number of search results) and their documents are better.
For example, https://github.com/github/opensourcefriday are using Transifex. Maybe you can try to visit their project and see which type of tool is more suitable for this repository.

For example, https://github.com/github/opensourcefriday are using Transifex. Maybe you can try to visit their project and see which type of tool is more suitable for this repository.

I created the translation solution for both this project and Open Source Friday. The Transifex/Open Source Friday solution is unsuitable here as this repository is a Markdown document-based translation flow rather than lots of small strings.

#1133 will be the next investigation and, if it seems an improvement on what we currently have, will be the next method of translation for this repository.

Hi

1119

How about we collect some advice in docs/translations.md under Keeping translations up to date or similar?

Working on #1118 I naively scrolled through the commit list and looked at merge commits that seemed to add content. Would git diff $translation_branch master _articles/*.md or similar be better?

You are right

Yes

gi

How about we collect some advice in docs/translations.md under Keeping translations up to date or similar?

Working on #1118 I naively scrolled through the commit list and looked at merge commits that seemed to add content. Would git diff $translation_branch master _articles/*.md or similar be better?