openfoodfacts / openfoodfacts-server

Open Food Facts database, API server and web interface - 🐪🦋 Perl, CSS and JS coders welcome 😊 For helping in Python, see Robotoff or taxonomy-editor
http://openfoodfacts.github.io/openfoodfacts-server/
GNU Affero General Public License v3.0
658 stars 387 forks source link

[multilingual] Display product pages in alternate languages - URLs scheme and navigation #314

Open stephanegigandet opened 8 years ago

stephanegigandet commented 8 years ago

@hangy is proposing to display on the product page links to the product page in other languages that are on the label.

One way to do that is to link to the subdomain of the current country with the alternate language. e.g. for a French product, if it has ingredients in Spanish, we could link to the product page on the fr-es.openfoodfacts.org subdomain.

One issue is that all navigation becomes written in Spanish, and all navigation links then use the fr-es subdomain, potentially creating millions of URLs to index

We could try to find a different way to display products in alternate languages. We'll need two thing: an URL scheme, and how to display. For instance we could use language tabs in the product display page as well, and use urls with &product_lc=es to display the Spanish information but keeping the current subdomain and language for everything but the product.

Part of

hangy commented 8 years ago

I think, I see where you're coming from.

One issue is that all navigation becomes written in Spanish, and all navigation links then use the fr-es subdomain, potentially creating millions of URLs to index

I might be wrong, but those are available today anyways. Adding some rel=alternate links from the product page - maybe followed by some concept of the rel=canonical links, could actually avoid search engines taking different language versions as duplicate content.

If server load caused by search engines is an issue, we could see in how far supporting If-Modified-Since for product pages, adding sitemap.xml with a useful changefreq could help. In the case that this does not help at all and too much is indexed, we could potentially forbid search engines to index (noindex, nofollow) anything on country pages not in the countries main language.

For instance we could use language tabs in the product display page as well, and use urls with &product_lc=es to display the Spanish information but keeping the current subdomain and language for everything but the product.

This could cause a whole different problem, as most search engines will index those pages, too. Then, we would have a &produc_lc=xx url for a product on every language and country subdomain, which would multiply the amount of indexed urls. Using AJAX probably would not help either, as search engines have grown to execute and index JavaScript. An advantage that I see in using the existing subdomains is that those are not only already there, but that the behaviour is kind of consistent with selecting a different country in the dropdown (top left). The links can be used to build a semantic relationship between the different country URLs (rel=alternate, hreflang=xx).