Bug#845297: Bug #845297: Website transition from CVS to Git
Hi Laura,
> 3.- Which are the next steps? (I guess attack the Perl scripts,
I'd love to help with those scripts but I'm afraid I lack the
experience of the translation team to understand what is that
needs to be done. I found the issues listed on the wiki page
WebsiteGitTransition, but I can't figure out the changes that
need to be made in the Perl scripts from those.
Thus, if someone could elaborate on the details I may provide
some code. In particular, I think it'd be best to split the
scripts from the translations in webwml repo, so they could
evolve separatedly and the scripts could be migrated to salsa
sooner.
> or find a way of facilitating translators the work to keep
> translations in sync with the "english" folder). About this,
> I have some new ideas (not sure if they are good or silly. Just
> throwing them here for the case it rings a bell for anybody):
>
> * Maybe Gitlab CI can help to "generate a translator dashboard"
> in a simpler way than the scripts that currently create the
> pages of the type:
> https://www.debian.org/devel/website/stats/es
Gitlab Pages can be built in the CI and then published as
https://{team-name}.pages.debian.net/{whatever}.html
We build the former pkg-perl website using this feature:
https://perl-team.pages.debian.net/
You can see the build script is pretty straight forward:
https://salsa.debian.org/perl-team/perl-team.pages.debian.net/blob/master/.gitlab-ci.yml
> * I'll try to explore the integration with a Weblate instance.
I like the idea of using PO files for translating very much,
since I was member of the translations team for GNU website long
time ago. I would've loved to have something like Weblate...
Some time after I left, Yavor Doganov created GNUnited Nations,
also based on PO files, though it isn't packaged for Debian
either.
Therefore, I think moving to PO files would be worth the effort
the sooner the better. Even if that means breaking the current
workflow for a while, it sure will help getting more people into
translating Debian texts.
Hope this helps,
Alex
signature.asc
Description: PGP signature
Bug#845297: Migration to Salsa
Hi Steve, > I'm thinking of taking some vacation (a week or so) from my day > job during May to get stuck in here. When are other people > available? I'm attending a conference from May 8 to 10, so I guess I'll be more available than usual in working hours the whole week. > What can I help with? I'm OK-ish in perl, so I'm thinking of > looking at the translation workflow stuff, unless that's > already in hand. Laura explained the translation workflow to me, and I thought that we wouldn't need to keep track of current CVS revisions because using the last commit id from a file and checking if a commit id is ancestor to another should be enough: $ git log -1 --oneline english/license.wml 8e8136309fa use https for the link to www.spi-inc.org $ git log -1 --oneline catalan/license.wml 8e8136309fa use https for the link to www.spi-inc.org $ git merge-base --is-ancestor 8e8136309fa 8e8136309fa $ echo $? 0 However, I didn't take into account that sometimes there are changes applied to several files at the same time that have nothing to do with translations (as showed in the example above). Therefore, it seems that we'll need to translate CVS revisions to commit IDs at least once after the repository has been migrated finally to git and before any translation is performed. Since we can't be sure that people translating will stop during the migration, maybe we can add a kill-switch in the scripts so we can enable it before migrating and removing it to enable the translation work after everything is setup correctly in git. Something like this makes sense? 1. People translate on CVS. 2. Add a kill-switch to translations scripts. 3. Let people translate on CVS until migration date. 4. Enable kill-switch so people cannot translate. 5. Migrate repo to git. 6. Setup new workflow. 7. Make changes to translations docs. 8. Remove kill-switch. 9. Let people translate on git. Steps 5-7 should take the shortest time possible to avoid impact, of course. The kill-switch should be very easy to implement, e.g.: my $kill_switch = 0; die "Sorry! webwml migration in progress. Check the wiki.\n" if $kill_switch; Since I'm not very familiar with the translation workflow yet, I'd like to work on the Perl scripts that will deal with the files in git, etc. But I'm fine doing something else if someone prefers to do that. Cheers! Alex signature.asc Description: PGP signature
Bug#845297: Migration to Salsa
Hi Paul, > Please note that smart_change.pl needs to work with the new workflow. > This means that we can't use git commit IDs in translations headers, > unless we want smart_change.pl to make two commits instead of one. Thanks for pointing that out. I've been studying smart_change.pl and I couldn't find where that commit you mention is happening. > The alternative is to use git file+metadata hashes, which can be > calculated before a commit happens, placed into translations headers > and used to diff between two versions of a file. I'm not sure how well > this will fit with the existing webwml VCS modules though. Could you elaborate a bit more on the git file+metafile details? I'm not following you, sorry. Thanks! Alex signature.asc Description: PGP signature
