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

So much good information it's outgrowing a single-page GFM Markdown format? #730

Open
RogueScholar opened this issue Jul 4, 2019 · 6 comments

Comments

@RogueScholar
Copy link

First of all, let me say I think this project is incredible, and remains well-organized despite the sheer volume of what's been collectively amassed. When I have a shitty day and need something to settle my weary mind, just 30-45 minutes of cruising through the links is usually more than enough to restore my perspective (and usually add one or two new cool baubles to my rather ornate shell, haha).

I want to throw out a thought I had recently while doing so, which is that GitHub is as great for assembling a diverse and productive team of contributors as it is atrocious at letting them do anything more sophisticated than plop changes into plain text and keep it all in one piece. (Just my opinion, naturally; I'm sure others would disagree.) If there were a way to, say, gain the layout advantages found in a more robust framework like what is found in WikiBooks, this already magnificent resource could easily acquire a couple more orders of magnitude of awesomeness. It leads me to a couple of fundamental questions:

  • Does anyone know of any libraries or other tools that are targeted at converting/migrating GFM Markdown to something close to WikiMedia syntax?
  • If someone were masochistic enough to want to experiment with what that might look like, would you have any objection to the attempt?

I'm not naïve enough to think that the evolution of the list could ever move away from GitHub. What it's already grown into makes it self-evident that this is the way to keep it in front of the right type and volume of eyeballs to keep it growing. I see it as akin to the way source usually needs to be compiled into a different form altogether to become truly useful, so too it might be that a natural symbiosis could happen between the list as it is here and a downstream "fork" that was focused on applying digital typography to it. This list of resources + the ability to tastefully and easily embed images + multiple pages looping back in on each other + collapsible tables...well, I'm sure you get the idea. 😁

I'm interested to hear any and all thoughts on the matter.

@unixorn
Copy link
Owner

unixorn commented Jul 15, 2019

I'm open to any tools that render the markdown into different output formats, but the authoritative source is going to remain markdown. That said, it's written in markdown because GH handles rendering it to HTML automagically and markdown is way easier to write than HTML.

I'm not sure what benefit WikiBooks format would have, mainly because I haven't worked with it at all. An issue I see is that GH automatically displays the markdown as HTML without me having to do anything other than merge a PR - if we added another output format, where would it get hosted?

@FredHappyface
Copy link

Not sure if this has the exact format you are looking for but here is a tool you can use to automagically generate other formats. It reckons to be able to do the likes of .odt which seems pretty impressive. Anyway, here is the link: https://pandoc.org/

@ss-o
Copy link
Contributor

ss-o commented Feb 15, 2022

I think that it is worth wrapping README.md into one README.json file to parse from. 🏗️

The file README.json could be processed and offered separately as an alternative to view content or processed by those who might be interested. 🔍

The repository itself could stay with no visual changes or dependencies, with minimal additional requirements e.g: ☑️

1 Assign (...) to README.md
1 Assign link, description to README.json

Personal opinion: everyone should be unified within some limits, so projects are treated more equally.

So this might ✨ spoil ✨ many great visual alternatives 🙊

@unixorn
Copy link
Owner

unixorn commented Feb 15, 2022

My concern with going to a JSON or YAML format and then processing that to create markdown is that it'll make contributing more hassle for occasional contributors. It'll also make code review a little more painful, but I could live with that.

@ss-o
Copy link
Contributor

ss-o commented Feb 20, 2022

Everything has a price 🙃, however, this particular decision can be biased, and opinion-based.

It might be worth sketching the roadmap. ✍️ ( Just an idea ) 🙈

I'll try to support you when the decision is made. :octocat:

@happycod3r
Copy link

  1. You may be able to use Pandoc (not quite sure) which is a versatile document conversion tool that supports a wide range of input and output formats. While it might not have a direct conversion between GFM and Wikimedia syntax, you could potentially use Pandoc to convert GFM Markdown to a common intermediate format (such as HTML) and then further manipulate the HTML to conform to Wikimedia's syntax.

  2. Or depending on the complexity of your GFM content, you might be able to write custom scripts or regular expressions to perform the necessary transformations. This approach might work well for simpler conversions, but it could become unwieldy for a ton of data.

If you have a good understanding of both GFM and Wikimedia syntax, you could write a custom script or program to perform the conversion. You would essentially need to parse the GFM Markdown and replace its elements with the corresponding elements in Wikimedia syntax. Writing a parser may be a good idea. I hope this helps a bit

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

5 participants