Re: Re[4]: How to manage github pull requests?

On Wed, 20 Jan 2021 at 18:48, André L F S Bacci <andrebacci.listas@gmail.com> wrote: > On Sat, Dec 26, 2020 at 9:44 PM Andre Polykanine via phpdoc < > phpdoc@lists.php.net> wrote: > >> Hello André, >> >> > Yes. At least for pt_BR translation. >> >> What can be done to make it possible for other languages, namely >> Ukrainian and Russian? >> > > Hello Andre, > > After the docs SVN migration to git, my roundtrip process through a > particular GitHub is now pointless. I'm about to delete that repository. > > For all, > > It's now missing two things to complete the migration: > > 1. A big rewrite of Doc Howto [1], especially the new git commands and > public git repositories and/or GitHub mirrors; > 2. A working revcheck.php. > > I could try help with (2) btw. Where is the last developing effort? > > André > > > > [1] Remember this old fella? http://doc.php.net/tutorial/ > https://gitlab.com/php-infrastructe/doc has my latest WIP for a revcheck Currently hosted on http://doc.php.gpb.moe/tools/revcheck/ although I didn't setup an automatic build so it's currently outdated. The main issue I have is that with the migration to git some commits which only touched svn attributes didn't get propagated so a bunch of files are considered outdated although the diff is empty. It would be great to be able to generate patches which would adjust the revision number for translations. A secondary issue is making the diff page on git.php.net, Nikita did find a way to get a diff between 2 revisions just for a file (something GH doesn't support), but for some reasons the link I'm generating are a bit bogus and haven't had time to look into this again. The relevant conversation is here: https://chat.stackoverflow.com/transcript/message/51268245#51268245 A final thing, as I was going with a full rewite of the doc.php.net site so that it can be generated statically and hosted on something like GitLab pages it might be a bit incompatible with the current repo, but Sergey was working on something a bit more streamlined with less of the cruft. In any way, PRs are welcomed. :-) George P. Banyard