openzim / mwoffliner

Mediawiki scraper: all your wiki articles in one highly compressed ZIM file
https://www.npmjs.com/package/mwoffliner
GNU General Public License v3.0
268 stars 70 forks source link

Problem about tree structure of a page #1501

Open zkosk opened 2 years ago

zkosk commented 2 years ago

In the page "Perturbationtheory(quantum_mechanics)", some subtree are put at the same level as their parent: image

"Generalization to multi-parameter case" is the parent node, all the others in the picture are its child nodes. But they are not hidden then the parent is collapsed. Not sure whether it is a problem of online Wiki or the offliner tool.

maxi Version "6,134,097 articles in English"

kelson42 commented 2 years ago

I confirm the bug, look at http://library.kiwix.org/wikipedia_en_all_maxi/A/Perturbation_theory_(quantum_mechanics).

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

MananJethwani commented 2 years ago

@kelson42 the current implementation for tree structure considers dropdown structure to be followed only for the first level, and puts all others on the same level, as far as I remember this was discussed in some other issue as well, do you want me to implement a proper method that might use recursion or stack to implement a proper tree structure. or the current method should be kept?

kelson42 commented 2 years ago

@MananJethwani I really wonder about that. Sounds kind of "crazy". Obviously it has to manage an indefinite level of depth.

the-illuminatus commented 2 years ago

is the issue still open?

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

kelson42 commented 1 year ago

Wondering if this makes sense to implement this just before #1664?!

Jaifroid commented 1 year ago

Personally I'd agree that #1664 is higher priority, and it's possible it could make this issue redundant. But we won't know that till the new endpoint has been implemented.

kelson42 commented 1 year ago

Lets implement #1664 first