"translation progress issue" reading about es.javascript.info HOT 17 OPEN

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;
};

from es.javascript.info.

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-01

Or are tables better (they're not sortable in GitHub)? What do other maintainers think?

from es.javascript.info.

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 boost

should we put the suggestion in the eng repo?

from es.javascript.info.

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?

from es.javascript.info.

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 lot

But 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.

from es.javascript.info.

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 helpful

from es.javascript.info.

If the date is needed only for the script, then we don't have to show it in the issue.

from es.javascript.info.

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 well

from es.javascript.info.

Dates may be needed for manual cleanup... What else? Is there any other need?

The script can run daily, to check the dates and cleanup.

from es.javascript.info.

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-14

very 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 line

from es.javascript.info.

A 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).

from es.javascript.info.

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 PR

2020-12-27 is the date of the (last [art] ) comment with 👍 from BOT
when * [ ] [Shadow DOM and events] (@XXXXXXX) was added

1. 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)

2. 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 )

from es.javascript.info.

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?

from es.javascript.info.

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 sheet

about order, the only I used was claimed date, but I prioritized 1st section before start cleaning the other 2

from es.javascript.info.

it works for me,
you may want to make an automatic cleaning tool

didnt 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 stuck

https://joaquinelio-zone17.glitch.me/
https://github.com/joaquinelio/zone17

lang/issue fr / 3, de / 1

from es.javascript.info.

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.

from es.javascript.info.

Sorry for not implementing this yet, @joaquinelio , I think the idea is good.

from es.javascript.info.