On coordinating translations of debina-edu-doc: some thoughts

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

On coordinating translations of debina-edu-doc: some thoughts

Frans Spiesschaert
Hi,

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.

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.

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.

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.

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.

Comments and criticism welcome :-)

--
Kind regards,
Frans Spiesschaert

Reply | Threaded
Open this post in threaded view
|

Re: On coordinating translations of debina-edu-doc: some thoughts

hoxp18
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 | Threaded
Open this post in threaded view
|

Re: On coordinating translations of debina-edu-doc: some thoughts

Holger Levsen-2
In reply to this post by Frans Spiesschaert
Hi Frans,

thanks for taking the time for this write up!

On Fri, Jun 14, 2019 at 05:26:15PM +0200, Frans Spiesschaert wrote:
> 1. Concurrent but different translation updates on both weblate and
> salsa are difficult to manage.
>
> 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:

just two words: yes, agreed.

> Nowadays I see debian-edu-doc updates from the wiki happen with
> irregular time intervals and see them happen unannounced.

i'm not sure how to change this without (other) downsides.

> 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.
 
cant we sync from weblate to git more often, like daily?


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment