Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"translation progress issue" reading #531

Open
joaquinelio opened this issue Jul 22, 2021 · 17 comments
Open

"translation progress issue" reading #531

joaquinelio opened this issue Jul 22, 2021 · 17 comments

Comments

@joaquinelio
Copy link
Member

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

Artículo | Traductor | Fecha | PR
[Modifying the document] | @joaquinelio | 2021-03-16 | #494
[Keyboard: keydown and keyup] 
[ArrayBuffer, binary arrays] 
[IndexedDB] | @joaquinelio | 2021-03-09 | #491
[Custom elements] | @joaquinelio | 2021-03-19 | #495
[Shadow DOM slots, composition] 
[Shadow DOM and events] 
[Catastrophic backtracking] 
@iliakan
Copy link
Member

iliakan commented Jul 22, 2021

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

@iliakan
Copy link
Member

iliakan commented Jul 22, 2021

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?

@joaquinelio
Copy link
Member Author

joaquinelio commented Jul 22, 2021

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?

@iliakan
Copy link
Member

iliakan commented Jul 22, 2021

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?

@joaquinelio
Copy link
Member Author

joaquinelio commented Jul 22, 2021

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.

@joaquinelio
Copy link
Member Author

joaquinelio commented Jul 22, 2021

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

@iliakan
Copy link
Member

iliakan commented Jul 22, 2021

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

@joaquinelio
Copy link
Member Author

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

@iliakan
Copy link
Member

iliakan commented Jul 22, 2021

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.

@joaquinelio
Copy link
Member Author

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

@iliakan
Copy link
Member

iliakan commented Jul 23, 2021

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

@joaquinelio
Copy link
Member Author

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 )

@iliakan
Copy link
Member

iliakan commented Jul 23, 2021

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?

@joaquinelio
Copy link
Member Author

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

@joaquinelio
Copy link
Member Author

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

@joaquinelio
Copy link
Member Author

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.

@iliakan
Copy link
Member

iliakan commented Jan 11, 2022

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

@iliakan iliakan reopened this Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants