chore(knowledgbe/blog): removed deprecated knowledgebase

[ovflowd]

This PR removes the deprecated/outdated knowledgebase and translated blog posts.

• The knowledgebase is super outdated, extra files that need to be build every time and haven't been actively maintained since a decade ago.
• The blog posts should not be translated (It is even within the Crowdin configuration) as it also creates an increased difficulty and overhad on maintaining content.

[AugustinMauroy]

It hurts to remove this content knowing the time spent translating it.

But it's important to remove this old junk.

[Trott]

We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:

1. Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
2. Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.

Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation

[ovflowd]

But it may be that the best way to do that is to remove it and field complaints.

Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.

Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).

Sounds like a good idea. I was thinking about adding an locale/en/knowledge/index.md but that would only work if they tried to access /en/knowledge/ not any of the knowledge files.

I will make a PR to the build repository to add a rewrite of /knowledge/ to this "explanation" page.

Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint.

I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then.

Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content).

[ovflowd]

Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs.

[ovflowd]

Also:

• Most of the pages already have their content hidden behind a "collapsable accordion" saying that this content is not maintained and hidden.
• Some of these pages shouldn't even be hosted under nodejs.org, like, "What is JSON", https://nodejs.org/en/knowledge/javascript-conventions/what-is-json/.

[aduh95]

LGTM with or without Trott's suggestions

[XhmikosR]

It seems there are unrelated Markdown changes, probably prettier Extension...

[ovflowd]

It seems there are unrelated Markdown changes, probably prettier Extension...

Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier)

[ovflowd]

I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas.

[ovflowd]

This PR removes the deprecated/outdated knowledgebase and translated blog posts.

• The knowledgebase is super outdated, extra files that need to be build every time and haven't been actively maintained since a decade ago.
• The blog posts should not be translated (It is even within the Crowdin configuration) as it also creates an increased difficulty and overhad on maintaining content.

[AugustinMauroy]

It hurts to remove this content knowing the time spent translating it.

But it's important to remove this old junk.

[Trott]

We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:

1. Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
2. Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.

Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation

[ovflowd]

But it may be that the best way to do that is to remove it and field complaints.

Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.

Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).

Sounds like a good idea. I was thinking about adding an locale/en/knowledge/index.md but that would only work if they tried to access /en/knowledge/ not any of the knowledge files.

I will make a PR to the build repository to add a rewrite of /knowledge/ to this "explanation" page.

Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint.

I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then.

Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content).

[ovflowd]

Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs.

[ovflowd]

Also:

• Most of the pages already have their content hidden behind a "collapsable accordion" saying that this content is not maintained and hidden.
• Some of these pages shouldn't even be hosted under nodejs.org, like, "What is JSON", https://nodejs.org/en/knowledge/javascript-conventions/what-is-json/.

[aduh95]

LGTM with or without Trott's suggestions

[XhmikosR]

It seems there are unrelated Markdown changes, probably prettier Extension...

[ovflowd]

It seems there are unrelated Markdown changes, probably prettier Extension...

Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier)

[ovflowd]

I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas.

[ovflowd]

This PR removes the deprecated/outdated knowledgebase and translated blog posts.

• The knowledgebase is super outdated, extra files that need to be build every time and haven't been actively maintained since a decade ago.
• The blog posts should not be translated (It is even within the Crowdin configuration) as it also creates an increased difficulty and overhad on maintaining content.

[AugustinMauroy]

It hurts to remove this content knowing the time spent translating it.

But it's important to remove this old junk.

[Trott]

We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:

1. Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
2. Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.

Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation

[ovflowd]

But it may be that the best way to do that is to remove it and field complaints.

Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.

Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).

Sounds like a good idea. I was thinking about adding an locale/en/knowledge/index.md but that would only work if they tried to access /en/knowledge/ not any of the knowledge files.

I will make a PR to the build repository to add a rewrite of /knowledge/ to this "explanation" page.

Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint.

I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then.

Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content).

[ovflowd]

Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs.

[ovflowd]

Also:

• Most of the pages already have their content hidden behind a "collapsable accordion" saying that this content is not maintained and hidden.
• Some of these pages shouldn't even be hosted under nodejs.org, like, "What is JSON", https://nodejs.org/en/knowledge/javascript-conventions/what-is-json/.

[aduh95]

LGTM with or without Trott's suggestions

[XhmikosR]

It seems there are unrelated Markdown changes, probably prettier Extension...

[ovflowd]

It seems there are unrelated Markdown changes, probably prettier Extension...

Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier)

[ovflowd]

I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas.

[ovflowd]

This PR removes the deprecated/outdated knowledgebase and translated blog posts.

• The knowledgebase is super outdated, extra files that need to be build every time and haven't been actively maintained since a decade ago.
• The blog posts should not be translated (It is even within the Crowdin configuration) as it also creates an increased difficulty and overhad on maintaining content.

[AugustinMauroy]

It hurts to remove this content knowing the time spent translating it.

But it's important to remove this old junk.

[Trott]

We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:

1. Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
2. Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.

Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation

[ovflowd]

But it may be that the best way to do that is to remove it and field complaints.

Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.

Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).

Sounds like a good idea. I was thinking about adding an locale/en/knowledge/index.md but that would only work if they tried to access /en/knowledge/ not any of the knowledge files.

I will make a PR to the build repository to add a rewrite of /knowledge/ to this "explanation" page.

Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint.

I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then.

Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content).

[ovflowd]

Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs.

[ovflowd]

Also:

• Most of the pages already have their content hidden behind a "collapsable accordion" saying that this content is not maintained and hidden.
• Some of these pages shouldn't even be hosted under nodejs.org, like, "What is JSON", https://nodejs.org/en/knowledge/javascript-conventions/what-is-json/.

[aduh95]

LGTM with or without Trott's suggestions

[XhmikosR]

It seems there are unrelated Markdown changes, probably prettier Extension...

[ovflowd]

It seems there are unrelated Markdown changes, probably prettier Extension...

Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier)

[ovflowd]

I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas.

[ovflowd]

This PR removes the deprecated/outdated knowledgebase and translated blog posts.

• The knowledgebase is super outdated, extra files that need to be build every time and haven't been actively maintained since a decade ago.
• The blog posts should not be translated (It is even within the Crowdin configuration) as it also creates an increased difficulty and overhad on maintaining content.

[AugustinMauroy]

It hurts to remove this content knowing the time spent translating it.

But it's important to remove this old junk.

[Trott]

We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:

1. Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
2. Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.

Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation

[ovflowd]

But it may be that the best way to do that is to remove it and field complaints.

Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.

Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).

Sounds like a good idea. I was thinking about adding an locale/en/knowledge/index.md but that would only work if they tried to access /en/knowledge/ not any of the knowledge files.

I will make a PR to the build repository to add a rewrite of /knowledge/ to this "explanation" page.

Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint.

I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then.

Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content).

[ovflowd]

Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs.

[ovflowd]

Also:

• Most of the pages already have their content hidden behind a "collapsable accordion" saying that this content is not maintained and hidden.
• Some of these pages shouldn't even be hosted under nodejs.org, like, "What is JSON", https://nodejs.org/en/knowledge/javascript-conventions/what-is-json/.

[aduh95]

LGTM with or without Trott's suggestions

[XhmikosR]

It seems there are unrelated Markdown changes, probably prettier Extension...

[ovflowd]

It seems there are unrelated Markdown changes, probably prettier Extension...

Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier)

[ovflowd]

I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas.

[ovflowd]

This PR removes the deprecated/outdated knowledgebase and translated blog posts.

• The knowledgebase is super outdated, extra files that need to be build every time and haven't been actively maintained since a decade ago.
• The blog posts should not be translated (It is even within the Crowdin configuration) as it also creates an increased difficulty and overhad on maintaining content.

[AugustinMauroy]

It hurts to remove this content knowing the time spent translating it.

But it's important to remove this old junk.

[Trott]

We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:

1. Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
2. Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.

Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation

[ovflowd]

But it may be that the best way to do that is to remove it and field complaints.

Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.

Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).

Sounds like a good idea. I was thinking about adding an locale/en/knowledge/index.md but that would only work if they tried to access /en/knowledge/ not any of the knowledge files.

I will make a PR to the build repository to add a rewrite of /knowledge/ to this "explanation" page.

Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint.

I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then.

Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content).

[ovflowd]

Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs.

[ovflowd]

Also:

• Most of the pages already have their content hidden behind a "collapsable accordion" saying that this content is not maintained and hidden.
• Some of these pages shouldn't even be hosted under nodejs.org, like, "What is JSON", https://nodejs.org/en/knowledge/javascript-conventions/what-is-json/.

[aduh95]

LGTM with or without Trott's suggestions

[XhmikosR]

It seems there are unrelated Markdown changes, probably prettier Extension...

[ovflowd]

It seems there are unrelated Markdown changes, probably prettier Extension...

Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier)

[ovflowd]

I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas.

[ovflowd]

This PR removes the deprecated/outdated knowledgebase and translated blog posts.

• The knowledgebase is super outdated, extra files that need to be build every time and haven't been actively maintained since a decade ago.
• The blog posts should not be translated (It is even within the Crowdin configuration) as it also creates an increased difficulty and overhad on maintaining content.

[AugustinMauroy]

It hurts to remove this content knowing the time spent translating it.

But it's important to remove this old junk.

[Trott]

We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:

1. Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
2. Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.

Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation

[ovflowd]

But it may be that the best way to do that is to remove it and field complaints.

Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.

Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).

Sounds like a good idea. I was thinking about adding an locale/en/knowledge/index.md but that would only work if they tried to access /en/knowledge/ not any of the knowledge files.

I will make a PR to the build repository to add a rewrite of /knowledge/ to this "explanation" page.

Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint.

I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then.

Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content).

[ovflowd]

Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs.

[ovflowd]

Also:

• Most of the pages already have their content hidden behind a "collapsable accordion" saying that this content is not maintained and hidden.
• Some of these pages shouldn't even be hosted under nodejs.org, like, "What is JSON", https://nodejs.org/en/knowledge/javascript-conventions/what-is-json/.

[aduh95]

LGTM with or without Trott's suggestions

[XhmikosR]

It seems there are unrelated Markdown changes, probably prettier Extension...

[ovflowd]

It seems there are unrelated Markdown changes, probably prettier Extension...

Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier)

[ovflowd]

I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas.

[ovflowd]

This PR removes the deprecated/outdated knowledgebase and translated blog posts.

• The knowledgebase is super outdated, extra files that need to be build every time and haven't been actively maintained since a decade ago.
• The blog posts should not be translated (It is even within the Crowdin configuration) as it also creates an increased difficulty and overhad on maintaining content.

[AugustinMauroy]

It hurts to remove this content knowing the time spent translating it.

But it's important to remove this old junk.

[Trott]

We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:

1. Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
2. Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.

Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation

[ovflowd]

But it may be that the best way to do that is to remove it and field complaints.

Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.

Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).

Sounds like a good idea. I was thinking about adding an locale/en/knowledge/index.md but that would only work if they tried to access /en/knowledge/ not any of the knowledge files.

I will make a PR to the build repository to add a rewrite of /knowledge/ to this "explanation" page.

Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".

This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint.

I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then.

Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content).

[ovflowd]

Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs.

[ovflowd]

Also:

• Most of the pages already have their content hidden behind a "collapsable accordion" saying that this content is not maintained and hidden.
• Some of these pages shouldn't even be hosted under nodejs.org, like, "What is JSON", https://nodejs.org/en/knowledge/javascript-conventions/what-is-json/.

[aduh95]

LGTM with or without Trott's suggestions

[XhmikosR]

It seems there are unrelated Markdown changes, probably prettier Extension...

[ovflowd]

It seems there are unrelated Markdown changes, probably prettier Extension...

Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier)

[ovflowd]

I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas.