Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

• Username
• Password
• Remember me

• Sign in using OpenID
• Remember me

• Forgot your password?
• Apply for membership

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory internal-categories k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

1. • CommentRowNumber1.
   • CommentAuthorRodMcGuire
   • CommentTimeNov 16th 2013
   • (edited Nov 16th 2013)
   • PermaLink
   Author: RodMcGuire
   Format: MarkdownItex__I THOUGHT I HAD A SPIFFY SOLUTION TO THIS ISSUE BUT IT TURNS OUT NOT TO WORK__ When I use Google to find things in the nLab it often gives hits based on the text at the bottom showing links from other nLab pages. I find this unhelpful. Does anybody think this is useful or would it be better if this indexing was prevented? Likewise Google indexes the right hand side floating context menus - Googling [`"representable functor" site:http://ncatlab.org`](https://www.google.com/search?q="representable+functor"+site%3Ahttp%3A%2F%2Fncatlab.org%2F) gives [[free functor]] as a hit where "representable functor" only appears in the context menu. Assuming the consensus is to prevent this: Google does provide a HTML mechanism, [`fish <!--googleoff: index-->shark<!--googleon: index-->mackerel`](https://developers.google.com/search-appliance/documentation/68/admin_crawl/Preparing#pagepart) that in this case will keep "shark" from being indexed but but this only works for an organization running their own Google Search Appliance, not for the Google Bots that index the web. (Why not?) The only currently working ways to prevent part of a page from being indexed are * Include the text in Javascript and at load time insert the HTML into the page. * Load the text into iframes (from external files not srcdoc internal iframes) for the "linked from" and "context menu" stuff. While menus such as [[category theory - contents]] exist as separate HTML pages, a different variant without stuff at the top and bottom would be needed.

   I THOUGHT I HAD A SPIFFY SOLUTION TO THIS ISSUE BUT IT TURNS OUT NOT TO WORK

   When I use Google to find things in the nLab it often gives hits based on the text at the bottom showing links from other nLab pages.

   I find this unhelpful. Does anybody think this is useful or would it be better if this indexing was prevented?

   Likewise Google indexes the right hand side floating context menus - Googling "representable functor" site:http://ncatlab.org gives free functor as a hit where “representable functor” only appears in the context menu.

   Assuming the consensus is to prevent this:

   Google does provide a HTML mechanism, fish <!--googleoff: index-->shark<!--googleon: index-->mackerel that in this case will keep “shark” from being indexed but but this only works for an organization running their own Google Search Appliance, not for the Google Bots that index the web. (Why not?)

   The only currently working ways to prevent part of a page from being indexed are

   • Include the text in Javascript and at load time insert the HTML into the page.

   • Load the text into iframes (from external files not srcdoc internal iframes) for the “linked from” and “context menu” stuff. While menus such as category theory - contents exist as separate HTML pages, a different variant without stuff at the top and bottom would be needed.

2. • CommentRowNumber2.
   • CommentAuthorTobyBartels
   • CommentTimeDec 21st 2013
   • PermaLink
   Author: TobyBartels
   Format: MarkdownItexI\'d be all for moving the "Linked from" stuff to an external page entirely (like MediaWiki does it), similar the source and history pages. This requires a change to Instiki, which we could probably pull off.

   I'd be all for moving the “Linked from” stuff to an external page entirely (like MediaWiki does it), similar the source and history pages. This requires a change to Instiki, which we could probably pull off.

3. • CommentRowNumber3.
   • CommentAuthorMike Shulman
   • CommentTimeDec 21st 2013
   • PermaLink
   Author: Mike Shulman
   Format: MarkdownItexWhile we're at it, any chance we could make "Linked from" look through redirects?

   While we’re at it, any chance we could make “Linked from” look through redirects?

4. • CommentRowNumber4.
   • CommentAuthorRodMcGuire
   • CommentTimeDec 22nd 2013
   • PermaLink
   Author: RodMcGuire
   Format: MarkdownItex> I'd be all for moving the “Linked from” stuff to an external page entirely (like MediaWiki does it), similar the source and history pages. This requires a change to Instiki, which we could probably pull off. Sometimes the linked-from stuff does provide some info. If I google up a page called "toposes and alien abductions" the number of links to it is some sort of indication of how central the page is to the nLab - that is if the nLab has a linking philosophy and contributors actually follow it. I've read pages that need more links and sometimes I've put them in. Maybe "linked from ..." should be replace by "linked from 4 pages" and clicking on that will insert the full linked from text that is stored in a subdirectory that Google has been told not to index. All of this is to circumvent a Google problem. I still don't understand why Google doesn't want to be told not to index things. If I read some news story and want other takes on it I run into the problem that news sites often have an "other stories" sidebar or whatever that will give spurious hits.

   I’d be all for moving the “Linked from” stuff to an external page entirely (like MediaWiki does it), similar the source and history pages. This requires a change to Instiki, which we could probably pull off.

   Sometimes the linked-from stuff does provide some info. If I google up a page called “toposes and alien abductions” the number of links to it is some sort of indication of how central the page is to the nLab - that is if the nLab has a linking philosophy and contributors actually follow it. I’ve read pages that need more links and sometimes I’ve put them in.

   Maybe “linked from …” should be replace by “linked from 4 pages” and clicking on that will insert the full linked from text that is stored in a subdirectory that Google has been told not to index.

   All of this is to circumvent a Google problem. I still don’t understand why Google doesn’t want to be told not to index things. If I read some news story and want other takes on it I run into the problem that news sites often have an “other stories” sidebar or whatever that will give spurious hits.

5. • CommentRowNumber5.
   • CommentAuthorTobyBartels
   • CommentTimeDec 22nd 2013
   • PermaLink
   Author: TobyBartels
   Format: MarkdownItexGood ideas from both Mike and Rod, IMO!

   Good ideas from both Mike and Rod, IMO!

6. • CommentRowNumber6.
   • CommentAuthorRodMcGuire
   • CommentTimeDec 27th 2013
   • PermaLink
   Author: RodMcGuire
   Format: MarkdownItexBeyond spurious Google indexing here is another reason to separate out the right hand context menus. A page such as [[preorder]] includes the context menu [[(0,1)-category theory - contents]] which mentions [[top]] ($\top$ - greatest element). While [[preorder]] might discuss defining the top of a preorder it doesn't. None the less [[top]] is "linked from" [[preorder]] because of the context menu. Even worse, since [[Stone duality]] also is in that menu, its "linked from" is highly spurious. In general this makes the "linked from" for anything mentioned in a context menu rather useless, and contributes to the spurious Google indexing problem.

   Beyond spurious Google indexing here is another reason to separate out the right hand context menus.

   A page such as preorder includes the context menu (0,1)-category theory - contents which mentions top ($\top$ - greatest element). While preorder might discuss defining the top of a preorder it doesn’t. None the less top is “linked from” preorder because of the context menu. Even worse, since Stone duality also is in that menu, its “linked from” is highly spurious.

   In general this makes the “linked from” for anything mentioned in a context menu rather useless, and contributes to the spurious Google indexing problem.

7. • CommentRowNumber7.
   • CommentAuthorUrs
   • CommentTimeDec 27th 2013
   • (edited Dec 28th 2013)
   • PermaLink
   Author: Urs
   Format: MarkdownItexAs far as I am concerned the "linked from" functionality is generally not useful and might better be switched off entirely. Even without the context menus the uncommnted and unordered "linked from" list is but a minimal standin for what we should all aim to do by hand: on the creation of any new entry it should be cross-linked with related entries, in the entry text, that is and preferably with a minimum of indication of what makes any two entries be related. Also the "linked list" functionality is not consistent in itself, for the list below any entry is updated whenever that entry is updated, not however when links to it are created. This way for instance in many category:people entries, where the automatic list would be useful, it is in fact often not up to date. If in addition it confuses Google, it would be better to just switch it off entirely. Might help to save resources that are more urgently needed for core functionality, too. But then, such discussion of what would be desireable concerning the nLab software are all in vain unless somebody who actually can and wants to implement anything is participating or is contacted.

   As far as I am concerned the “linked from” functionality is generally not useful and might better be switched off entirely. Even without the context menus the uncommnted and unordered “linked from” list is but a minimal standin for what we should all aim to do by hand: on the creation of any new entry it should be cross-linked with related entries, in the entry text, that is and preferably with a minimum of indication of what makes any two entries be related.

   Also the “linked list” functionality is not consistent in itself, for the list below any entry is updated whenever that entry is updated, not however when links to it are created. This way for instance in many category:people entries, where the automatic list would be useful, it is in fact often not up to date.

   If in addition it confuses Google, it would be better to just switch it off entirely. Might help to save resources that are more urgently needed for core functionality, too.

   But then, such discussion of what would be desireable concerning the nLab software are all in vain unless somebody who actually can and wants to implement anything is participating or is contacted.

8. • CommentRowNumber8.
   • CommentAuthorTobyBartels
   • CommentTimeDec 28th 2013
   • PermaLink
   Author: TobyBartels
   Format: MarkdownItexI wouldn\'t want to turn it off entirely, since I have used it to check that a small, obscure page has links to it. But it certainly needs less emphasis!

   I wouldn't want to turn it off entirely, since I have used it to check that a small, obscure page has links to it. But it certainly needs less emphasis!

9. • CommentRowNumber9.
   • CommentAuthorAndrew Stacey
   • CommentTimeDec 31st 2013
   • PermaLink
   Author: Andrew Stacey
   Format: MarkdownItexIf someone wants a change to the instiki software, thinks would go a lot faster if they could provide the following: 1. A description of exactly what needs changing in terms of the code (a `diff` against the current version of instiki would be the best). 2. Proof that this won't mess up anything else. 3. The steering committee's okay on the change.

   If someone wants a change to the instiki software, thinks would go a lot faster if they could provide the following:

   1. A description of exactly what needs changing in terms of the code (a diff against the current version of instiki would be the best).
   2. Proof that this won’t mess up anything else.
   3. The steering committee’s okay on the change.