Difference between revisions of "User talk:Gero"

From FollowTheScore
Jump to: navigation, search
(Reply to "parsing problems")
(Reply to "parsing problems")
Line 169: Line 169:
  
 
:You are right. The latest release (1.2.9) handles this now correctly. So the original form you wanted to use should now work as expected.. [[User:Gero|Gero]] 08:48, 27 July 2007 (CEST)
 
:You are right. The latest release (1.2.9) handles this now correctly. So the original form you wanted to use should now work as expected.. [[User:Gero|Gero]] 08:48, 27 July 2007 (CEST)
 +
 +
::Very nice, thanks. Also though, the same bug still exists for pipes within <nowiki>"[[ ]]"s</nowiki>. (See Nigunda Test within [[Test section inclusion# include a single template parameter]]).

Revision as of 19:20, 31 July 2007

I am interested to promote DPL to become part of mediawiki / wikipedia. How do you feel about this idea?


I agree, it seems very useful.--Patrick 15:14, 17 February 2007 (CET)

Your message at my Wikisource talk page

Hi, and thanks for your message (you said to reply here).

I tool a look at your DPL extension. It looks nice, and I think I understand some of what you are trying to accomplish with it, but my technical expertise is limited and I don't fully understand it. I am also not entirely clear as to what elements of Labeled Section Transclusion are included in DPL.

As to how to promote these things: First, people with technical expertise have to build a working, tested extension. That has apparently been accomplished both with DPL and LST.

The next step is to get the senior developers to actually apply the extension live at Wikimedia wikis (for instance, LST was designed for Wikisource). I thought that this second step would be easy, but apparently it is not, because the developers are extremely busy and have a huge list of things to be implemented. So you have to keep reminding, lobbying, etc., for instance on IRC or Wikitech mail (I don't have access to IRC).

It would be great if you could further clarify, in layman's terms, about DPL and how it incorporates LST. And lobbying is useful too...

Best to reach me at my Wikisource page as you did. Dovi


please see my answer at the end of Talk:Manual --Gero 20:53, 19 February 2007 (CET)

Developer note

Hi! Thanks for the hard work on the DPL, it's so much more useful than when I used to work on it. Please see my message at Discussion. -- IlyaHaykinson 12:00, 25 February 2007 (CET)

Thanks for the compliment. I think something like DPL is really needed for MediaWiki and it´s worth investing time and energy ... -- Gero 15:31, 26 February 2007 (CET)

Quick turnaround

Gero, just wanted to thank you for your fix to "replaceintitle". We decided this morning to deploy DPL at http://busytonight.com/wiki, specifically because we need "replaceintitle" in one particular context. I tested, it didn't work as advertised -- then I noticed on the issues list here that you made a comment today that it had been fixed, based on a comment yesterday that it wasn't working as advertised in 1.0.7. So I opened an internal ticket for us to upgrade from 1.0.7 to 1.0.8. (The person I assigned it to said, "But I just installed it last week! How can I have to upgrade it already?" :-) Richmintz 18:36, 9 April 2007 (CEST)

glitch in Special:Allmessages

Your code is printing a warning upon loading Special:Allmessages. Just FYI.

cat1 AND cat2

Hi Gero I found no way for "cat1 AND cat2". Is there an example somewhere? 84.190.56.160 11:20, 21 June 2007 (CEST)

Ok, it's category=cat1 category =cat2 ... ;-) regards Tobias 84.190.56.160 11:28, 21 June 2007 (CEST)

css files

Greetings,

This is kind of an obscure request and not directly related to the dpl extension, but I was wondering if you could email me the css files used in your example pages. I'm trying to get wiki tables and html working together, and those pages have some good examples. Or maybe just the classes used? Either would be great! Feel free to email me directly if you'd like. Thanks! --Natebsi 02:29, 20 July 2007 (CEST)

There is no css code except the MediaWiki:Common.css file.

#n-Manual { background-color: #ffddaa; }
#n-Source { background-color: #ccccff; }
#n-Test { background-color: #ccffcc; }
#n-Type { background-color: #dedede; }
/* wikitable, sortable, and prettytable class definitions
** based on meta.wikimedia.org MediaWiki:Common.css 
*/
table.wikitable, table.sortable, table.prettytable {
  margin: 1em 1em 1em 0;
  background: #f9f9f9;
  border: 1px #aaaaaa solid;
  border-collapse: collapse;
}
table.wikitable td, table.sortable td, table.prettytable td {
  border: 1px #aaaaaa solid;
  padding: 0.2em;
}
table.wikitable th, table.sortable th, table.prettytable th {
  background: #E6E6FA; /* lavender; wikimedia: #f2f2f2 */
  border: 1px #aaaaaa solid;
  text-align: center;
}
table.wikitable caption, table.sortable caption, table.prettytable caption {
  margin-left: inherit;
  margin-right: inherit;
}

Is it that what you were looking for?

Gero 08:00, 20 July 2007 (CEST)
Thats exactly what I'm looking for, thank you so much! --Natebsi 18:35, 20 July 2007 (CEST)

Parsing problems

Recently the Guild Wars Wiki has installed DPL. Currently I'm trying to get DPL to work in a certain fashion. See this page. The problem I am having, is that I am trying to fill my output table with entries that contain a |-character (table cell separator). What I would like to know is, if the following is possible with DPL:

Page "A" (which is included in Category:Skills):

{{Skill infobox
| description = This skill does {{gr|10|100}} damage.}}

Page "B" calling a DPL function as follows:

<DPL>
category=Skills
includepage={skill infobox}:description
mode=userformat
listseparators=\n{| {{STDT}} class=sortable\n|- \n! ||Name||Description,\n|-\n|STYLE="padding: 0px;"|[[Image:%PAGE%.jpg]]\n![[%PAGE%]],,\n|}
secseparators=\n|
</DPL>

My output page will only show a table like this:

  Name Description
Skill image Skill name This skill does {{gr

Where I want it to show:

  Name Description
Skill image Skill name This skill does 10...82...100 damage.

Is this possible? CoRrRan --86.87.179.57 23:57, 23 July 2007 (CEST)

Reply to "parsing problems"

First, thank you for this clear explanation about what you want, what you tried and what did not work as expected. And then my answer:

  • The 'include= {macro}:parameter' syntax is meant for simple access to one parameter and indeed it takes the value of the parameter literally (mainly for performance reasons)
  • Therefore you will see the plain wiki text if the value of your parameter contains template calls.
  • But there is another way which should work:
    • write a "phantom" template which is used as a surrogate for the original template and use that template in the include statement.
    • For example: 'include={macro}.xyz' where 'xyz' would be a hopefully meaningful suffix to the name of the original macro (aka template). In your case the macro is named 'skill infobox', so just write 'include={skill infobox}.xyz'.
    • DPL will then use the template 'skill infobox.xyz' instead of 'skill infobox'. And in 'skill infobox.xyz' you can do whatever you want. It receives the same parameters as {skill infobox} PLUS additional parameters named %PAGE% and %TITLE% which you can access in the usual way with triple curly braces.
    • The trick is, that the call to {gr} will be resolved before the parameters are being passed to 'skill infobox.xyz'
    • Last hint: If you do not have a good idea what suffix to use (in place of 'xyz') you might use '.dpl'. This would at least make clear that this template is used within a DPL query. As its basename is the same as the original template, you will find them next to each other in an alphabetical listing.

Last comment: If you get everything to work based on this advice and if you think that others may have the same kind of questions, please create a DPL:FAQ document and use this as a first entry.

Gero 19:37, 24 July 2007 (CEST)
This is exactly the information I wanted to have! I have been able to modify my output table in such a way that my {gr}-template is now properly parsed before being put into the DPL table output.
Now another thing I would like to be able to do: would it be possible to dictate the output to certain table cells? For instance, I would like to be able to do something like this:
  Name Description Rest
{{{Image1|}}} {{{Name1|}}} {{{Description1|}}} {{{Energy1|}}} {{{Cast1|}}} {{{Recharge1|}}}
{{{Campaign1|}}} {{{Quest1|}}}  
{{{Image2|}}} {{{Name2|}}} {{{Description2|}}} {{{Energy2|}}} {{{Cast2|}}} {{{Recharge2|}}}
{{{Campaign2|}}} {{{Quest2|}}}  
Is this at all possible?
Anyway, I really want to thank you with your help on pointing me to the {skill infobox}.dpl-call, that really worked. If the next question isn't possible, that's not too big a problem, just a "nice to have". And regarding that DPL:FAQ : is there a page already for it, because the link you created resulted in a red link... Regards, CoRrRan --86.87.179.57 00:24, 25 July 2007 (CEST)
Yes, this is possible. You just have to create the subtable structure within the "alternate template". The template creates a row of a table each tikme it is called, and one field of this row is another table. I assume that the template has enough information to create the row completely. Maybe Test identical chapters can give you an idea how it works.
Regarding the FAQ: Just go ahead and create it!
Gero 05:10, 25 July 2007 (CEST)

I think the original problem here was actually due to DPL not retrieving the literal value of the parameter. In Page "A", which has:

{{Skill infobox
| description = This skill does {{gr|10|100}} damage.}}

Is the complete description parameter represented by

description = This skill does {{gr|10|100}} damage.

or does that pipe symbol after "gr" signal the end of the parameter and start of the next?

description = This skill does {{gr

By MediaWiki standards, the former is correct, but DPL seems to go by the latter in this case.

You are right. The latest release (1.2.9) handles this now correctly. So the original form you wanted to use should now work as expected.. Gero 08:48, 27 July 2007 (CEST)
Very nice, thanks. Also though, the same bug still exists for pipes within "[[ ]]"s. (See Nigunda Test within Test section inclusion# include a single template parameter).