Last modified: 2014-05-23 01:42:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20616, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18616 - Local evaluation of magic words for commons files
Local evaluation of magic words for commons files
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-28 20:38 UTC by Cenarium
Modified: 2014-05-23 01:42 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Cenarium 2009-04-28 20:38:15 UTC
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.
Comment 1 Happy-melon 2009-04-30 23:08:41 UTC
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. 
Comment 2 Chad H. 2009-04-30 23:22:12 UTC
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.
Comment 3 Chad H. 2009-11-28 04:41:56 UTC
Mass component change for merge of "File/Repo" and "Images and Files"
Comment 4 Bawolff (Brian Wolff) 2014-05-23 01:42:47 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links