Repository navigation
"translation progress issue" reading #531
Description
Activity
Here's the Node.js module that does it.
First, I have the full tutorial tree, then I loop over articles and parse the issue.
const tutorial = require('engine/koa/tutorial'); const TutorialTree = tutorial.TutorialTree; const Article = tutorial.Article; const markit = require('engine/markit'); module.exports = async function(progressIssue) { await tutorial.boot(); const articles = TutorialTree.instance().getAll().filter(entry => entry instanceof Article); let restMap = new Map(); let info = progressIssue.body.match(/\* \[.+/g) || []; for(let item of info) { let [all, checked, rest] = item.match(/\* \[(.)\] (.*)/); checked = Boolean(checked.trim()); rest = rest.trim(); let translator = rest.match(/\(@(.*)\)/); translator = translator && translator[1].trim(); let prNumber = rest.match(/ #(\d+)/); prNumber = prNumber && prNumber[1]; let record = { checked, rest, translator, prNumber }; for(let article of articles) { if (rest.startsWith(article.title)) { record.rest = record.rest.slice(article.title.length).trim(); restMap.set(article.title, record); } else if (rest.startsWith(markit.escape(article.title))) { record.rest = record.rest.slice(markit.escape(article.title).length).trim(); restMap.set(article.title, record); } else if (rest.startsWith(`[${article.title}]`) || rest.startsWith(`[${markit.escape(article.title)}]`)) { record.rest = rest.match(/\[.*?\]\(.*?\)(.*)/).pop().trim(); restMap.set(article.title, record); } } } return restMap; };
Maybe keep the format compatible instead?
E.g. add the date after the PR number.
Like this:
* [X] [Title](https://github.com/.../path) (@user) #93 2021-02-01Or are tables better (they're not sortable in GitHub)? What do other maintainers think?
thanks!
I'll study it. Looks so clean... Guess I'll learn more than I wanted"other maintainers"
We dont need the change anymore, I already have the program that searches for the last claim date, I just need to fix regex (mine fails with dash-user)
the suggestion is for other repos, claim-date is easy to add right into the issue, no extra prg needed to get abandoned arts.or maybe spanish is a special case, we had LOTS of translators, when we freed one article the space was claimed quickly.
Knowing inactive articles made a big boost.
until now.
guess it was pandemic the reason of the boostshould we put the suggestion in the eng repo?
People taking an article and giving up is a general problem. It happens with every repo, just because, well, people are people. Usually, not a big deal, but surely we could help here.
So, there should be a script walks over PRs, gets dates (easy to do) and does.. What?
So, there should be a script walks over PRs, gets dates (easy to do) and does.. What?
Already done.
And nothing. 😆
The prg just does the list, maintainer says "uhm, 6 months and no PR..." then carefully edits the issue to erase the user.
did it a lotBut I suggest to add the date into the issue the moment the translator takes it. So no search needed.
Well, not from now on, older stay empty... wich is an indicator too.No need to walk PRs, just the comments, I took the date from there (last claim) and PR from your list. I asumed user followed procedure, they all did.
Usually, not a big deal, but surely we could help here.
Yes maybe you are right. I bet most langs have just a few translators. Maybe they dont need it.
Spanish community is big. There was a moment with few translations done and nearly all art were taken.
The script was really helpfulIf the date is needed only for the script, then we don't have to show it in the issue.
if the date is in the issue, we dont need the script
:)ok, only one must survive.
the script also filters. and can add some sort (didnt need it)
what a shame - just found another bug.
And I wrote it with paging loop, before reading your generators article
ugly
but served wellDates may be needed for manual cleanup... What else? Is there any other need?
The script can run daily, to check the dates and cleanup.
Date is all what I needed
In fact this is the actual report my script showed before the last manual cleanup (today list is 8 )
[Modifying the document] | @joaquinelio | 2021-03-16 | #494 [Keyboard: keydown and keyup] | @XXXXXXX | 2021-03-16 | [Focusing: focus/blur] | @XXXXXXX| 2021-03-31 | [ArrayBuffer, binary arrays] | @XXXXXXX| 2021-02-09 | [IndexedDB] | @joaquinelio | 2021-03-09 | #491 [Custom elements] | @joaquinelio | 2021-03-19 | #495 [Shadow DOM slots, composition] | @XXXXXXX| 2020-09-20 | [Shadow DOM and events] | @XXXXXXX | 2020-12-27 | [Catastrophic backtracking] | @XXXXXXX| 2021-05-14very few and under control, thats why I say we dont need anything here now.
True, you need to be careful manually editimg the issue.btw, I just "fixed" the count ( 165 of 173 tasks ) by marking the example line
* [ ] [Home Page](url) (@iliakan) #1(it shows but the counter ignores it)
does it affect any current task?
my report script used to ignore that first lineA script can easily retrieve the dates from github, given the PR number.
As you describe it, there's no need for a date in the issue (meant for humans to read).
A script can easily retrieve the dates from github, given the PR number.
We dont care PR.
the only date needed is from rhe comment claiming an article.going further we only care claimed articles with NO PR
from script
| Shadow DOM and events | @XXXXXXX | 2020-12-27 | |<- no PR2020-12-27 is the date of the (last [art] ) comment with 👍 from BOT
when* [ ] [Shadow DOM and events] (@XXXXXXX)was added-
if there is a date ,
not a human but a maintainer (I mean...) can read the 2020 and say "I dont think @x is commited to the job" then proceed to erase it leaviing* [ ] [Shadow DOM and events]again (mr. bot never complained the deja vu) -
The script is ok too (worked for me) but it has to walk bot aproved 👍 comments, not PRs.
2a) Bot could be a nice killer too, say "erase @ translators older than 3 months with no PR"
mmm what if maintaiener added it. ok bot can kill only the ones it added (those with bot👍comments )-
Ah, I get it. You mean claimed articles w/o PR. Yes, the info should be in the issue.
So, a table or a list?
without. w/o, wo. What's happening to my brain. sorry.
no prefference...
I put the script on glitchme,
too lazy , I didnt add sort,
so cut/paste result on a sheetabout order, the only I used was claimed date, but I prioritized 1st section before start cleaning the other 2
it works for me,
you may want to make an automatic cleaning tooldidnt put the links before because i'm not proud of the code, ( so many things I'd do differenly!)
but the result probed to be really useful, it helped me a lot in the past year,
over a hundred pending articles and lots of translators and the project started to get stuckhttps://joaquinelio-zone17.glitch.me/
https://github.com/joaquinelio/zone17lang/issue fr / 3, de / 1
Hi @iliakan, I'm closing this. (only one article left! )
But you may use the suggestion:
To add "claimed date" every time a translator picks an article.
so maintainers can consider to free it if it looks abandoned.
I did it a lot, it bursted the progress.May another suggestion:
Prevent translators to take a second article if the 1st one doesnt have a PR
There is no need to take more than one at once, there is also a "pleasedont" sign but entusiasts keep doing it.Sorry for not implementing this yet, @joaquinelio , I think the idea is good.
Hi @iliakan
Not very important,
woulld you kindly share the regex to read the translation progress lines?
just the regex, I have a little bug in mine.
Suggestion for other repos:
You may want to add "Date claimed" next to the user when it claims it.
date helped maintainers to decide the too-long-claimed articles to free