Skip to content

Intercept links to known documentation #234

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

Open
gpgekko opened this issue Jul 15, 2015 · 10 comments
Open

Intercept links to known documentation #234

gpgekko opened this issue Jul 15, 2015 · 10 comments

Comments

@gpgekko
Copy link

gpgekko commented Jul 15, 2015

I wonder if it would be possible to intercept (either during scraping or when clicked) links to known documentation. For example, the Backbone documentation contains quite a few links to Underscore documentation pages. It would be nice if these would open within DevDocs, since both are available.

This would be an improvement for offline use, and would be a nice enhancement for online use too.

@Thibaut
Copy link
Member

Thibaut commented Jul 25, 2015

Thanks for the suggestion. This is quite a difficult thing to implement but I agree it would be a nice enhancement. I have no time to work on it at the moment (given my long list of todos and other high-impact features), but maybe in the future.

@Hipska
Copy link

Hipska commented Aug 26, 2015

I think this could also solve #36, #41, #71, #89 and #187.

@orionlee
Copy link

#514 is also a specific case for this request.

@JesseTG
Copy link

JesseTG commented Jan 2, 2017

What would make this difficult, exactly?

@Thibaut
Copy link
Member

Thibaut commented Jan 2, 2017

See my comments in #524

@JesseTG
Copy link

JesseTG commented Jan 2, 2017

What if, while parsing server-side, we maintained a map of old links to transformed links, and then exposed this map to other docs?

@Thibaut
Copy link
Member

Thibaut commented Jan 2, 2017

@JesseTG that would be quite complex and difficult to maintain. I agree fixing/improving this would be great, but if it comes at the cost of increased maintenance burden (I'm already maxed out) and dependencies between docs/scrapers, then I don't think it's a good trade-off.

@j-f1
Copy link
Contributor

j-f1 commented Oct 29, 2017

Here’s what I’m thinking:

  1. When parsing docs from URLs, include the original URL somewhere in the Entry object.
  2. Add a key to the generated JSON file with a mapping of originalURL => slug.
  3. When loading a documentation page on the client side, go through all of the external links and check if their domain and path are contained in the merged mapping of URLs for all enabled documentations. If they are, change them to an internal link.

Schema idea:

"url_mapping": {
  "developer.mozilla.org": {
    // ...
    // note that the URL’s path and domain are lowercased for case-insensitive matching.
    "/en-us/docs/web/javascript/reference/global_objects/string/endswith": "javascript/global_objects/string/endswith",
    // ...
  }
}

Why check the path and domain separately? by narrowing down the results to a particular domain by searching through a small set of domain names, the number of paths to check can be significantly decreased.

@Kaijiro
Copy link

Kaijiro commented Oct 30, 2017

I think you can apply this with enabled docs, not only installed.

@j-f1
Copy link
Contributor

j-f1 commented Oct 30, 2017

@Kaijiro

I think you can apply this with enabled docs, not only installed.

Good point! Fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants