Local evaluation of magic words for commons files
Closed, DeclinedPublic

Description

For commons files, magic words such as {{CONTENTLANGUAGE}} or {{SERVERNAME}} are not evaluated locally but with the commons values. File descriptions are often given in a variety of languages to make it readable in the language of as many projects as possible, but it clogs the description and makes finding the relevant language more difficult.

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.


Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz18616.
Cenarium created this task.Via LegacyApr 28 2009, 8:38 PM
bzimport added a comment.Via ConduitApr 30 2009, 11:08 PM

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.

demon added a comment.Via ConduitApr 30 2009, 11:22 PM

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.

demon added a comment.Via ConduitNov 28 2009, 4:41 AM

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

Bawolff added a comment.Via ConduitMay 23 2014, 1:42 AM

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.

Gilles added a project: Multimedia.Via WebDec 4 2014, 10:53 AM
Gilles moved this task to Closed on the Multimedia workboard.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.