Last modified: 2011-07-20 03:07:20 UTC
Problem: In template tags, parameter values sometimes are linked and sometimes are not. Inserting those values into double brackets (in template code) may conduce to four-bracketed links. In the other hand, not inserting them into brackets may conduce to 0-bracketed not-linked titles. Proposal: Add a new "delink" function that eliminates internal-linking double brackets. * {{delink:[[Title]]}} &arr; Title * {{delink:Title}} &arr; Title * {{delink:[external link]}} &arr; [external link] And possibly a "link" counterpart. * {{link: [[foo]] }} &arr; [[foo]] * {{link: foo }} &arr; [[foo]] * {{link: [external] }} &arr; [external] It should also be very useful for parameter comparison: {{#ifeq: {{delink: {{{1}}} }} |my title|yes|no}} An alternative (or additional) option to help bypass the problem could be to introduce a overall wikitext conversion of four brackets into two, wherever it occurs: * [[[[ &arr; [[ * ]]]] &arr; ]] comments? Gustavo
I would recommend just getting the template straight -- figure out what format it takes, and use that. Be consistent; if you see errors, edit and fix them.
(In reply to comment #1) I agree about getting the template straight: In a given field, values must sometimes be showed as links and sometimes not, and that condition is defined in tags. It's ok. Now suppose you pretend evaluate that bunch of values to gate another condition, not simple *to show* them. Handling and comparison of already-linked parameters are sometimes necessary. Just see these unexpected results with pagenames parser functions: *{{TALKPAGENAME: [[Foo]] }} → (expected Talk:Foo) *{{#ifexist: [[Piano]] |yes|no}} → no (expected yes) *{{NAMESPACE:[[Help:Bar]]}} → (expected Help) Brion: Please consider adding automatic delinking capability to all parser functions instead, proved that the parameter is a whole and unique link (ie. not a string with some portions linked). I'll enter this as a different bug.
(In reply to comment #1) > figure out what format it takes, and use that. Be consistent; if you see > errors, edit and fix them. (and in reply to bug 29970#c1) > Again I recommend correctly factoring the template & template parameters to > begin with. Brion, you do not seem to think so about {{lc:}} and {{uc:}}. What's the main and wider use of those functions? It's to normalize and facilitate comparison of parameters, isn't it? {{#ifeq: {{lc:{{{1}}}}} | foo |yes|no}} is more effective that a simple {{#ifeq: {{{1}}} | foo |yes|no}} Same happens here: {{#ifeq: {{delink:{{{1}}}}} | foo |yes|no}} will be more effective that a simple {{#ifeq: {{{1}}} | foo |yes|no}} I can't see the condition that makes this function invalid. As any other function, it should be used where is needed and being consistent, of course.
