happy.melon.wiki wrote:

In general, I don't think that magic words should be expanded with local values; the nicest way of thinking about it is probably that the page on foowiki is a 'window' onto the page at commons; it's still a page *at commons*, not on foowiki. However, I agree that {{CONTENTLANGUAGE}} has the strongest case for being an exception to that rule.

In general, when fetching remote content we prefer to have it render before fetching. There's no guarantee that the local wiki knows how to handle all of the magic words that the foreign one does. This can end up with poorly-rendered content.

(In reply to comment #0)

So it would be very helpful for readers to only show the description in the
local language, using {{CONTENTLANGUAGE}} (one may even give the option to show
other languages if desired). So this magic word would be evaluated locally. For
other magic words, I imagine there may be reasons not to do it, we may ask at
commons about that.

FWIW, we should already be doing this. I added fetching remote descriptions with uselang back in r46369...which btw, is a big hack for commons mostly, and should be replaced with a more defined interface for fetching descriptions, rather than hoping action=render gives us what we want.

Repurposing as a FileRepo bug, because it has nothing to do with language setup @ Wikimedia, nor is it really an i18n issue at all.

Mass component change for merge of "File/Repo" and "Images and Files"

I'm going to wontfix this. Well I could see {{CONTENTLANGUAGE}} as having a valid use case here, there is the {{int:lang}} hack already working (and in use). Furthermore, having all the magic words use local meaning would totally mess up image pages in all probability (especially if you threw templates into the mix as being evaluated locally). Especially on third-party (non wmf) wikis that might have very different configurations.