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,
