https://bugzilla.wikimedia.org/show_bug.cgi?id=31838
--- Comment #7 from Daniel Friesen <[email protected]> 2011-10-22 02:25:24 UTC --- I should make something clear. Doing a search for links from other sites to zh.wp gives me various forms of links: - Some pointing to http://zh.wikipedia.org/wiki/* - Some pointing to http://zh.wikipedia.org/zh/* - Some pointing to http://zh.wikipedia.org/zh-tw/* - Some pointing to http://zh.wikipedia.org/zh-hant/* - etc... If rel=canonical is removed, search engines will begin to consider the same article to be a different article depending on it's link. And that includes /wiki/ being considered a different article from the same article in the default variant. This can have a very negative effect on zh.wp in searches. Because of the /wiki/ and default variant separation zh.wp may be penalized for appears to be duplicate content. Users may end up finding unintuitive multiple results in searches. zh.wp pages may start to have lower ranks in search engines as people link to different variants and paths in the url causing the incoming ranking for a single page to be split amongst multiple versions of itself giving them all lower rank. This will also have a negative effect on the results users see. Instead of being based on what language a user has selected, search results will be based purely on what rankings pages have. In other words if most people link to a /zh/ page a user visiting Google with zh-tw will see search results linking to /zh/ because the /zh-tw/ page doesn't have as much ranking. Some possible actions: - Remove rel=canonical and accept the number of issues this will cause for zh.wp. - This will require a discussion on zh.wp and community consensus. As this change is already possible with MW this bug will be closed as WORKSFORME and if the zh.wp community achieves a consensus a shell bug to change the setting of $wgCanonicalLanguageLinks on zh.wp can be opened. - Facebook and other search engines implementing rel=canonical can implement support for the rel=alternate hreflang= so that they always serve urls relevant to the visitor's language. This bug will be closed as INVALID and someone can open a bug report in some place relevant. - We could implement a Content-Language based variant redirection on the /wiki/ path so visiting users will be redirected automatically to their variant. - There may however be some technical reasons this may not be possible. Users following links from sites that specific a specific variant may still end up on a variant they don't want. - Implementing og:url pointing to the current variant's url may be possible. Facebook and Google's +1 button both seam to implement support for this so it's a possibility. - This however will mess with opengraph and have a similar effect as the search engine effect within the number of shares/likes and +1s a pae has (ie: If 25 people like one article on zh.wp, 3 of them doing so on the zh-tw page while the rest do so on the zh page. A user capable of seeing how many likes a page got will see 3 likes when visiting the zh-tw page when in reality that page got 25 likes). This will also not fix any issue in search engines. By the way. rel=canonical was added by r75617 as an alternative option because there seamed to be issues with trying to implement conditional redirection. Relevant bug 21672. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
