Re: On coordinating translations of debina-edu-doc: some thoughts
Dear Frans Spiesschaert, and debian-edu Japanese translators,
First, thank you for Weblate Japansese activation for me, again.
> After being in charge of merging debian-edu-doc translation updates
> from weblate into salsa, I want to share some observations.
>
> 1. Concurrent but different translation updates on both weblate and
> salsa are difficult to manage.
I totally agree.
It is just recent when I can barely understand how hard it is.
> So I propose that languages that use salsa for translation updates
> should be deactivated at weblate, and that languages that were using
> weblate and are willing to switch to salsa should do this only after
> having announced this on the mailing list before doing so: this would
> give the opportunity to Mike (or me) to commit the final updates from
> weblate and to deactivate the language at weblate before new updates
> arrive via salsa.
Personally, now I can do translations on salsa directly,
thanks to your documents, advices and kindness.
It's okay for me to deactivate Weblate Japanese section.
> 2. The hosted.weblate tool is conceived in the first place to promote
> and facilitate the translation of user messages of programs (rather
> than manuals).
> In order to avoid conflicts, it expects a program developer to apply
> the following steps (that weblate can partly automate on his behalf if
> he wishes so):
> - pulling in all pending translations from weblate.
> - temporarily locking the weblate git repo.
> - updating his template file (xgettext -j)
> - merging the new pot with existing translations (msgmerge)
> - merging these updates into the weblate git repo.
> - unlocking the weblate git repo.
>
> Applied to debian-edu-doc this would mean:
> - pulling in all pending translations from weblate.
> - temporarily locking the weblate git repo.
> - updating debian-edu-doc from the wiki
> - applying msgmerge to existing translations
> - merging these translations with an updated pot into the weblate git
> repo.
> - unlocking the weblate git repo.
This sounds fine,
Basically I'm planning to salsa-only-translation-workflow.
However, weblate is also helpful to find fuzzy and untranslated, even read-only.
> Nowadays I see debian-edu-doc updates from the wiki happen with
> irregular time intervals and see them happen unannounced. In most cases
> at that moment unapplied translations are te be found on
> hosted.weblate. This would result in merge conflicts when one would try
> to merge in the salsa updates into weblate.
> And they regularly did, namely each time I had failed to notice that
> such an update from the wiki had occurred.
> In such a case one has to
> - merge the new pot and the current weblate translations outside the
> weblate environment
> - commit the so merged translations to salsa
> - reset from within weblate all changes made to the local weblate
> repository
> - pull into weblate all translations from salsa.
Even in this "irregular and unannounced" situation,
weblate can tell me where should be fixed. I think it is a great advantage of weblate.
> This is in my opinion a rather tedious and inelegant workflow.
> So I would prefer if we could come to a coordinated workflow (see above
> under "Applied to debian-edu-doc this would mean....") between salsa
> and weblate, e.g. once a week at a given time.
Once a week sounds nice.
For example, I'll do,
1. Once a week, I check weblate if there are some (new) fuzzy and untranslated.
2. Then I "git fetch" from salsa and check logs, update po, commit, and push it.
3. (even without edit feature on weblate, it would be helpful).
And thank you so much. I didn't notice how hard/complicated it is.
Regards,
Reply to: