Last modified: 2008-09-11 16:36:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1136 - localized transclusions
localized transclusions
Status: RESOLVED DUPLICATE of bug 2085
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
unspecified
All All
: Low enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-20 11:55 UTC by David Monniaux
Modified: 2008-09-11 16:36 UTC (History)
3 users (show)

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


Attachments

Description David Monniaux 2004-12-20 11:55:11 UTC
On commons etc. it would perhaps come handy to have localized transclusions: ex,
{{foobar}} would map to different templates (say, {{foobar.en}}, {{foobar.fr}})
depending on language choices.
Comment 1 Tisza Gergő 2008-02-22 22:53:41 UTC
Commons uses the templatename/langcode format now (eg. {{GFDL/de}}). It would be nice to be able to select which one to use: just linking them from the english version is not too user-friendly.

Maybe a new template modifier could be created for this: {{local:Template}} could look for the subpage corresponding to the interface language, then trying fallback languages (if any), and finally the base template.

This can be done already with something like {{ {{#ifexist:{{{1}}}/{{CONTENTLANGUAGE}}|{{{1}}}/{{CONTENTLANGUAGE}}|{{{1}}}}}, but doing it in the software would be surely more effective.
Comment 2 Finn Pauls 2008-04-10 11:23:07 UTC
{{CONTENTLANGUAGE}} is always 'en' in commons. This variable should stick to the userpreferences or '?uselang=de'. That would solve the problem, too.
Comment 3 Robert Leverington 2008-04-10 14:45:20 UTC
No, it shouldn't. The content language is the one set in the wikis configuration and this should be the same no matter what to ensure cache consistency. While Commons is indeed a multi-lingual wiki the content language in this context refers to the default.

It would of course quite easily be possible to develop a magic word that refers to the current users language, but again that would encouter cache problems. It is quite difficult to find a solution to this bug that ensures cache consitency and provides reasonable functionality -- I believe similar bugs like this have been closed in the past as LATER or WONTFIX.

JavaScript hacks can also be used, but this isn't very clean nor accessible.
Comment 4 Tisza Gergő 2008-04-10 20:42:02 UTC
There must be some to avoid cache problems, as {{intl:...}} already does this, except that it's constrained to the MediaWiki namespace.
Comment 5 Mormegil 2008-09-11 16:36:42 UTC
This request is functionally equivalent to the {{USERIFCODE}} request (the requested functionality would be trivially implementable using something like {{foobar/{{USERIFCODE}}}}). So that I am marking it as a duplicate of bug 2085 (which is marked as WONTFIX).

*** This bug has been marked as a duplicate of bug 2085 ***

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


Navigation
Links