Last modified: 2006-05-17 21:16:25 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 2370 - request for a <inline> ... </inline> extension
request for a <inline> ... </inline> extension
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-06-10 12:24 UTC by lɛʁi לערי ריינהארט
Modified: 2006-05-17 21:16 UTC (History)
1 user (show)

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


Description lɛʁi לערי ריינהארט 2005-06-10 12:24:24 UTC
Dear friends,

I am puzzled if it is possible to crate an extension <inline> ... </inline>
which could be used together with [[ ]] and {{ }}.

I encountered this at
bug 2330: $1 should be refered as inline link :$1 in MediaWiki:Undeletedtext
and in template design where I simulated the
[[<inline><namespace>:foo</inline>]] but *not* the
{{<inline><namespace>:foo</inline>}} because I did not use pages from the
(manin) namespace as template like inclusions. I will provide an URL as soon as
Nuka-Wiki is online again.

At bug 2330 the proposed solution would have the leading colon also at the
(manin) namespace which does not look very nice.

Using two diffrenet extensions <inlinelink> ... </inlinelink> and
<inlinetemplate> ... </inlinetemplate> would be safest. Maybe it is possible to
use one extension only with the syntax <inline>[[foo]]</inline> *and*
<inline>{{foo}}</inline> .

Please comment. Best regards Reinhardt [[user:gangleri]]
Comment 1 Rowan Collins [IMSoP] 2005-06-10 15:36:08 UTC
If I understand you correctly, this would be a way of ensuring that a link was a
plain link, not a "magic" one (Category, Image, etc). (Some argue, of course,
that having [[foo]] not always have this role was a mistake in the first place).
A quick test reveals that the suggestion at bug 2330 to use "[[:$1]]" would
always work, and that this leading colon is always invisible, even when it is
not needed to suppress "magic" behaviour. This suggests to me that a new syntax
is unnecessary.

Also, what would <inline>{{foo}}</inline> do? The {{}} syntax never does
anything other than include the content of the named page, so there doesn't seem
to be any need for the same kind of syntax. The only thing I can think of is
that it refers by default to the Template namespace, not the main one, but this
is a somewhat different issue than being "inline". I think the appropriate
solution in that case is to use something of the form "{{<namespace>:<title>}}"
with the two parts as separate variables and the colon always there - that way,
if the main namespace is required, "<namespace>" can be omitted (i.e. given a
value of ""), leaving "{{:<title>}}".
Comment 2 lɛʁi לערי ריינהארט 2005-06-10 17:46:26 UTC
Thanks Rowan for the answer!

Please compare
[[en:User:Gangleri/tests/extension inline]]

Regarding "[[:$1]]" there is a "''cosmetical''" issue because an extra colon is
generated in the main namespace.

Regarding "{{$1}}" the behaviour differs regarding special pages. FiverAlpha
allows such inclusions but [[en:]] *not*. I agress that <inline>{{$1}}</inline>
is no help / no simplification because it would imply that templates '''must'''
be specified with namespace '''and''' pagename. But maybe I am wrong and there
would be cases where $1 contains these anyhow. Qustionable is also how
<inline>{{$1}}</inline> should handle special pages: restrictive - deactivating
or suporting.

Regards Reinhardt
Comment 3 Ævar Arnfjörð Bjarmason 2005-06-10 17:48:32 UTC
Isn't this the same thing as the new special page inclusion mechanism?
Comment 4 lɛʁi לערי ריינהארט 2005-06-10 18:18:16 UTC
in replay to comment 3
I am not aware of "the new special page inclusion mechanism" and could not find
much documentation using

Do you have better links? Regards Reinhardt
Comment 5 Rob Church 2006-05-17 20:11:54 UTC
Reviewing this now, I'm not sure how I see how it's needed...?
Comment 6 Brion Vibber 2006-05-17 21:16:25 UTC
I'm going to classify this WORKSFORME, since behavior of [[:x]] seems to now 
be what we want (the : is suppressed).

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