-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Update some docs links #2571
Update some docs links #2571
Conversation
@nickfloyd as part of adding the GH Action to check links, I saw that the following text in
Is there a new beta packages link? Or should I remove that section? |
⚠️ I'm not sure if this is the right path. Should we update the gist list links to point to the most specific docs possible?
Find: `https://(developer.github.com)/v3/(activity|issues|orgs|pulls|repos|gists|users|git|apps|search|reactions|checks)/\n` Replace: `https://docs.github.com/rest/$2/\n` Reviewed all results by hand.
Find: `https://(developer.github.com)/v3/(activity|issues|orgs|pulls|repos|gists|users|git|apps|search|reactions|checks)"` Replace: `https://docs.github.com/rest/$2/"` Reviewed by hand.
Find: `https://(developer.github.com)/v3/(activity|issues|orgs|pulls|repos|gists|users|git|apps|search|reactions|checks)/"` Replace: `https://docs.github.com/rest/$2/"`
This reverts commit 9e84148.
Hmm....tried configuring Lychee to fail when links are redirected, since most of the links we're seeing are 301 permanent redirects. However, setting |
That should now be removed - good catch, thx! ❤️. Also, you are an absolute hero for picking this one up! Thanks for giving it a go! |
ℹ️ 💡 @nickfloyd while changing links in the The For now, I will remove the top-level "misc" link as it no longer exists, and will add text to refer to the doc link at the method level. |
If you get the chance, please feel free to create an issue so that we can get what you're suggesting here implemented. Thanks! |
ℹ️ Realizing that lychee doesn't support anchor tags so its usefulness will be limited in this case. Will likely end up removing it, as the majority of the links are in C# files and we'd need to convert them to UTF-8 first and then I'm still not sure we'd get the benefit. |
@nickfloyd question for you -- how important is linking to the correct anchor tag on the page? If we wanted to go more toward the 80/20 rule, we could remove the anchor references in the links and link to the correct page. This would let us update the links quickly, but we'd lose some specificity, and the links would be more fragile as heading/anchor names change. I'm fine to proceed either way, but if you don't care about anchor-level specificity, I can remove them. |
It turned out not to provide a ton of value: * Would have taken some adjustment for C# files to be converted to UTF-8 to be scanned with it * Doesn't have the ability to check anchor links, where there's a lot of drift here.
ℹ️ Removed lychee -- it wasn't going to provide enough value to guide the process and I'm not sure a lot of the drift would have been detected by it going forward. Plus, it would take a bit of elbow grease to get it to work with the C# files. |
@nickfloyd I realized that this is going to be a larger effort than thought so I'll split it over multiple PRs. I'll probably update #2474 with a breakdown list so that we can slice it in more meaningful ways going forward. I'm going to do a review pass for basic fixes & comments and then it'll be ready for review / merge and I'll zoom out prior to next steps. |
Actually as much as this pains me, I'm going to close this PR and start over because:
Look for smaller, targeted PRs toward this task going forward. |
Supports #2474.
This PR:
https
./en
from existing routes.Remaining Work
/en
from all changed links (docs know how to handle language now)http
links in changed links