Author: mediawiki.wayne

Description:

Context

Let's say I maintain my own bird website. I give info about birds and for each
bird I also add an hyperlink to the appropriate Wikipedia page (on my "Eagle"
page, I link to "http://en.wikipedia.org/wiki/Eagle").

Now, people from around the world propose translations for my website; every
translator must find a replacement for each and every Wikipedia link.

Proposition

A simple enhancement: a GET "API" for automatic "translation" of Wiki pages. By
that I simply mean a link to a wiki page but with a language preference. Example:
http://en.wikipedia.org/wiki/Eagle?pref=fr

This link would bring me to the french version of Eagle
(http://fr.wikipedia.org/wiki/Aigle_%28oiseau%29). If no french page match the
"Eagle" english page, the link would give me the english page as a fallback.

Why?

This would help a lot for translating web pages; advantages I see:

• Simplification for translators: no need to look for a translation for every link;
• Automatic update of links: if the french page for "Eagle" changes URI, no need

to change anything on my website; I must only keep an eye on the original
(english) language.

• Pre-translation: if no translation exists yet in a given language, a link can

be written now, knowing the translated page will appear one day.

Why can't I just write a wrapper?

I could write a wrapper on my side, fetching the english page, parsing the DOM,
looking for links in the "in other languages" box and give my visitors the right
page, but I feel it wastes wikipedia's resources and adds a big overhead for
something that (I think!) could be easily added in wikimedia's codebase.

Version: unspecified
Severity: enhancement