Re: On coordinating translations of debian-edu-doc: some thoughts
Hi Holger,
Holger Levsen schreef op do 24-10-2019 om 19:06 [+0000]:
> Hi Frans,
>
> On Thu, Oct 24, 2019 at 05:55:14PM +0200, Frans Spiesschaert wrote:
> > Thank you for notifying me.
>
> I'll try to think off that in future, always. Is it enough to notify
> you
> via the list or would you prefer to be cc:ed?
Thank you for this offer. But in fact, it's not that vital, because I'm
subscribed to debian-edu-commits@alioth-lists.debian.net (thanks to
you, if I remember well).
> > But if I would do a reset at Weblate now, I'm afraid that debian-
> > edu-
> > buster-manual.hr.po and debian-edu-buster-manual.pt_PT.po would get
> > lost.
>
> can't you upload those files directly to weblate?
Yes, and I will have to do so for now, I suppose, if I go on with this
and execute a reset at weblate.
But I don't consider it to be a viable solution in the long run,
because with those files present on weblate and absent on salsa, there
will be always unavoidable merge conflicts.
At the weblate side I am unable to merge individual files onto salsa. I
only can try and do a global merge. That's the reason why merging all
weblate translation updates into salsa before a manual update from the
wiki happens, is so important to avoid merge conflicts.
>
> would maybe using a different branch for weblate help? (a branch
> where
> not-yet-ready translations could stay...)
Probably this could offer a way out.
A long-lasting branch "branch-hosted-weblate" (or a much cuter branch
name) at salsa, with the not-yet-ready translations included, and that
mirrors the master branch at salsa except for the not-yet-ready
translations, and that functions as origin for hosted-weblate (this is
configurable at the weblate side), would at least bring us back to a
situation that can be managed the way I was used to before not-yet-
ready translations showed up.
With such a setup and with a local copy of salsa and of hosted weblate
on my PC, I could merge in individual files and I would be able to
solve possible merge conflicts the way I was used to in the past.
If we would chose to try out this solution, I woud prefer first to
handle things manually for a certain time, in order to get used to the
new situation and in order to learn more on possible drawbacks, before
moving forward in looking for a procedure that gets things done
automatically as much as possible, while avoiding merge conflicts.
>
> > I have no clue on how to handle this.
>
> me neither :)
>
> > Suggestions are very welcome.
>
> I tried...
Very much appreciated.
>
>
--
Kind regards,
Frans Spiesschaert
Reply to: