User talk:CBDunkerson/Frank

I was visiting Uncle Ed Poor, and saw you'd worked together on templates in category:date math, so decided to pick on you (you lucky devil!) <g>

1. Thanks, btw, for the quickfix on the 'indent template' I ported over from wikisource (last week? whenever!).
2. Can you take a look at a gripe I've got in general on lack of some sort of datestamp on certain templates: User_talk:Fabartus#Commonwealth_English_.27OR.27_lack-of-debate, which should give you the gist. The template Mr. Shear cites has a see also list which are 'lesser offenders' by my lights, but all would none-the-less benefit from having a noticible date embedded. (The older/longer it's been, the more likely it should be removed or at least purused carefully, save for unref types). This wouldn't be necessary if people properly documented on the Talk pages when applying same, but the usual seems to be no coresponding talk edit at all. So I'm looking for a fallback solution!
3. Of particularly nettlesome kind, the merge-to/merge-from templates seem to go sans action (or discussion) fairly often. I've chased several down that were put in place well over six months earlier and one nearly went a year, without a sufficient note in the edit summary (I finally caught on to the use of the words 'tag' and 'tagged' vice template <g>) but even so, if the article gets edit action, it takes quite a while to track back through history to find the actual edit and date applied.
4. A self-dating template would thus save a lot of man-hours when one is trying in good faith to clear one of these templates. (e.g. See Talk:Commonwealth English history for the effort I went through to find out when and who applied that 'Original Research' allegation, then the clear way I documented removing it. Most people aren't that consciencious when the girlfriend has come in or something!

In any event, if you have something that will subst the current date into these things, I'm prepared to do something to get them inserted in the key templates. It'll save me a lot of time in the long run, no matter how many talk page arguements I have to conduct in the short run! After all, I don't think there is much hope at getting editors to actually annote the talk pages when placing such consistantly!

Also, is there any common category or a few categories that these things cause to be asserted? I know the unref, clean, copyedit ones assert a category, but do they all manifest on some super category (list) I can browse as well? What do I need to key in on — the cat nesting construct to tell for myself?

Thanks // FrankB 07:36, 6 June 2006 (UTC)[reply]

Hi Frank. All of the templates in Category:Wikipedia maintenance templates are supposed to add pages they are transcluded on to one of the sub-categories of Category:Wikipedia maintenance. Thus, you should be able to use that category to browse open issues. For the 'self-dating' aspect you are looking for take a look at {{prod}}, {{DYK-Refresh}}, and {{fix}}. None of them are ideal, but those include three different ways that dates are currently inserted. The 'fix' template and most others just has an optional 'date' field which is usually left blank... even in templates where it is mandatory. DYK-Refresh includes a required Julian Date timestamp and always displays the current time/template format on the last line for easy copying. Prod probably comes closest to what you are looking for - it displays the date the template was added to the page and even adds the page to a dated sub-category. The problem with Prod is that it only works if substituted, which means that you get a big block of wikimarkup on the article page. That wouldn't be accepted for most of these maintenance templates. However, there should be a way around it using nested templates. If you substitute in 'template A' which does nothing except call 'template B' with the same parameters you set plus one more which is the substituted current date, then you would end up with a call directly to 'template B' on your article with the date automatically hard-coded. The only problems with this method are that the user has to use the 'subst:' tag for it to work properly and users can still go directly to 'template B' without including the date. If you are interested we could probably do something along the lines of the 'fix' template to cover the existing maintenance scenarios with a hard-coded date as above. --CBDunkerson 12:03, 6 June 2006 (UTC)[reply]

Help! Seriously! <g>

re: Demo at Template talk:Indent, and notice the morph I tried {{space}} (using &emsp or &nbsp makes no(?) sig. diff). Can't figure out how to suppress unwanted newline after template. Is this a side effect of parser 'switch', the system software implimentation of templates in general (Doesn't strike TRUE to my experience hereon), or some trick I don't know. (I'm in denial that it's 'impossible'! <g>)

What I seek is one or the other (assume it's the 'space' version to allow:

1. {space|1}{space|5}test text1
2. {space|3}{space|3}test text2
3. {space|2}{space|4}test text3

to have all three test lines lined up nice and purty!

OTOH, (assuming all three of these lines are right justified to start)

• {space|1}{space|5}test text1

{space|3}{space|3}test text2

{space|2}{space|4}test text3

Should display like (Fill in yer own mental 'spaces' <g>):

• {space|1}{space|5}test text1{space|3}{space|3}test text2{space|2}{space|4}test text3

So 'Doc', is there any hope of this? Thanks for the time! // FrankB 22:47, 7 June 2006 (UTC)[reply]

Back quick!

Intriguingly, this shows space doing just what I would expect! Harrumph! // FrankB 22:53, 7 June 2006 (UTC)[reply]

There are a number of bugs and odd behaviours around the use of spaces in templates - all of which seem to be coming into play here. Since templates were designed to ignore large gaps of blank space to allow formatting of the 'template code' they often handle actually intended gaps in the display incorrectly.

One trick I have used in the past is to alternate &nbsp and ' '. As in; '*&nbsp &nbsp *' = *    *

I'm not sure whether that will help, but I'll test out some options. --CBDunkerson 23:50, 7 June 2006 (UTC)[reply]

Thanks for the trials and post on me Talk! Hope you're right... I noticed (see prior version using 'indent' which is our 'space' for the moment here pending your fix (I had faith!) that this and Template:History_of_Europe were behaving entirely differently when I ported the modified version back to en.wikiP! I'll let you know if I have a bug there too! This HTML psuedo-implementation (not to mention browser issues, esp. with IE6!) must keep you guys busy.

Also, pass the word that I've created Category:Historical Period Templates which should be added to any template bearing on matters historical... Should cut down redundant template creation in the long run, not to mention let editors survey what's already out there. Are there any other template categories, such as perhaps a Category: template categories to give people a head start on doing such poking around? (I guess I'm into categories lately! <g> Some big diffs on the Commons and here that need ironed out!

Thanks again muchly! // FrankB 00:37, 8 June 2006 (UTC)[reply]

No problem. For template browsing see Category:Wikipedia templates. --CBDunkerson 13:09, 8 June 2006 (UTC)[reply]

btw on templates and cats

These should both be Category:Templates using ParserFunctions since they use the switch function (???), correct? // FrankB 00:43, 8 June 2006 (UTC)[reply]

Yes, probably. --CBDunkerson 13:09, 8 June 2006 (UTC)[reply]

Hi again. Need a little template expertise ... how to get an simple 'if branching' action.

To whit, in this commons template want the output of the second line to match this, but iff (if and only if) Arg1 is presented. Otherwise want no display for the second (Main Article) link generation line. Note in the category lines' 'parameter' (number is '1' now, needs to be '2' in {WikiPcat2}...) will then need be morphed to {{{2|{{{PAGENAME}}}| etc. (like this edit).

FYI: 'WikiPcat2' has only one page linked to it, and has no arguements, so it can be safely changed directly, as the default Category is still going to be the default category output.

Not bad though—I've gone from knowing nothing about templates to writing nearly a dozen in four daZe <g> (see: useage and notes in {{Commonscat2R}}, {{Commonscat4M}}, etcetera for a hint), or modifying another 4 or 5 too for the commons.

Are there BOOLEAN capabilities? One application I have in mind will need a bounds test against two values with apropos branching, computations, and output generation. I don't recollect seeing any in the math set you and Ed Poor were discussing.

I'm also interested in persuing that 'date' issue using 'fix' (iirc) eventually, but want to get this commons vs WikiP category normalization stabilized first. Besides, I figure I need to learn more about these danged things besides how to use them first!

Thanks fer hold me hand, as it were. Best regards, // FrankB 16:03, 10 June 2006 (UTC)[reply]

Gratziass, or however that's spelled! I was just tearing apart 'succession' which seems to use some modular coding to build the display. Dang! Something grabbed me in another browser tab... I started writing this about the time you finished your answer OMT! Sigh... I'll probably edit confict with my self now! Best! // FrankB 00:44, 11 June 2006 (UTC)[reply]

Briefly browsing Help:variable, I gather this is what you were refering to about the subst issue:

So I infer you were saying to set up one template 'substtime' with 16:38 called by another where you want the datestamp, such as one of the merge/clean/etc. templates. Seems to be a piece missing... the template is still going to be called each time the file is edited... ever renewing itself, I'd guess, hence we'd need a numeric equivilent date to feed a template that then subst's that into a call to the 'output' template... which construct holds the aggragated arguments to a display template. Complicated! reminds me of working strings back in the bad old days of FORTRAN. No wonder it's not been done! // FrankB 16:38, 10 June 2006 (UTC)[reply]

Getting A strange side effect in using {{see also}} in that this group of categories ALL prefixed by ':' has one showing up to categorize the listing page... which happens to be an AfD page I'm involved with wearing my 'fix up the article hat'. In any event, short of removing the post, I'm not sure what to do (if anything). To be clear, the Afd page is showing up as a Page in the category: Maps showing the history of the Early Middle Ages under 'W'.

There was a second file manifesting there (I can't recall it's name, but was also under 'W') as well until this edit: 22:37, 10 June 2006 (hist) (diff) Wikipedia:Articles for deletion/List of fictional universes (→List of fictional universes - del spc from see also template - was putting listed category in AFD!) diff

• Bold translates to removing the space after the first pipe character. IIRC, the category had shown at the bottom of the Afd page before that, and it went away... but didn't really. When I got back to the page, there it was right where I first noticed it!

1. 23:39, 10 June 2006 (hist) (diff) m Wikipedia:Articles for deletion/List of fictional universes (→List of fictional universes - assert noincludes around Early Middle Ages) (top)
2. 23:36, 10 June 2006 (hist) (diff) Category:Maps showing the history of the Early Middle Ages (Equalize cats to project Europe & Commons) (top)
3. 23:26, 10 June 2006 (hist) (diff) Category:Maps showing the history of the High Middle Ages (fx up cats and groups and export to equalize commons) (top)

After seeing it again, I tried to figure out how to keep the integrity of the Afd file, and decided to try putting a nested pair of noinclude ... /noinclude around the file or file group. That did nothing I could observe. (This edit: assert noincludes around Early Middle Ages.)

While grabbing links writing this, I tried to use Further instead on the earlier version (before the includes)... It bombs out almost totally, only showing the one link, this first one giving the problem. I stayed in preview, so I don't know what it did with respect to the category manifestation.

I'm beginning to suspect someone has fiddled with something and the routines aren't robust anymore. Need a bullet proof vest! (or locked files!).

Well, this is no big deal, but it's strange! Maps are supposed to show up on that page carried down from the commons, not Afd sub-pages. I say this next thing with all seriousness and a straight face (suppressing a BSEG)— Have Fun chasing this one! (Ahem) <g> Best! // FrankB 00:16, 11 June 2006 (UTC)[reply]

The problem is that [[ :Category:<whatever>]] is treated as [[Category:<whatever>]] rather than [[:Category:<whatever>]]. The 'leading :' markup only works if the colon is the first character after the brackets... just a limitation of how it works. I don't think categories were considered when 'see also' and 'further' were set up... they are primarily used to link to other articles. The reason 'further' only showed the first item you listed is that it only takes one parameter... so you would need to input it as, {{further|[[:Category:<whatever>]], [[:Category:<somethingelse>]], et cetera}}. --CBDunkerson 01:14, 11 June 2006 (UTC)[reply]

Thanks for fix on {{see also}}... don't see any changes! What if anything did you do? The category no longer shows the page... or am I seeing a manifestation of database lag of some type?

Regardless... Can you bend some thought on how to bullet-proof that in see also type listing... I was thinking to adapt it as a template for a systematic cross-linking of 'branch-nodes' in the commons tree structure, and here where a category:Wikipedia navigation templates would be a parent along with a cell to provide the [[:Category: Peram + Parent Peram]] e.g. {{dummy|Old maps of Europe|Old maps of|France|Germany|Italy|...|Netherlands|... |Ukraine}} would output the centered title:Old Maps of Europe, and have under the list of category links built 'Old maps of', as I said similar to the MBTA, or simplier {{1632 series}} type of navigation templates.

Right now there is no (?) 'short list' of templates that lists groups of links that allow easy traversal... e.g. simplest example to me is succession or succession box, but {{MBTA}} is more like the model I've in mind for Images and Map cats on the commons... I was hoping to write some 'subroutine' template that takes the first article (parent cat) and the bare names (list in pipe seperated form) and builds lines using a derivative of see also... so the thing would have very wide scope THERE... and be fairly easy to use. Probably add a segment like one adds complexity to {{succession box}}. But just a notion now, pending feedback from a couple folks I mentioned it to there. Just because cross links seem good to me, doesn't mean the commons culture will like the thought.

The rains up here have finally stopped for a few days and me yard is screaming for me to minimize wikiTime the next few days. In any event, Thanks again // FrankB 16:21, 12 June 2006 (UTC)[reply]

No, I didn't make any changes to 'see also'. Was just explaining what was causing the issues you saw. It would be difficult to do so without breaking some of the numerous existing uses of the template. Making it 'bulletproof' for the category links you are looking for would best be accomplised by changing it to accept just the category names as parameters and then automatically apply the [[:Category:<param>]] to that. The navigation system you are talking about seems similar to {{navbox generic}}. That code could be adapted to build category links like your example. I'd suggest creating a separate template to cover this as the desired functionality is fairly specific. I'll put something along the lines of what I think you want at {{category tree navbox}}. --CBDunkerson 13:21, 14 June 2006 (UTC)[reply]

Thanks for the fixes!

I've been 'bugged' by my hot button issue of the default skin hiding categories from the user for around two months, and this related thing punched the button pretty much dead center as the same point has been nagging at me as is made by the originator. Seems to me a VP listing ought be made on both, as it were, by at least a mention 'synopsis' with link, and the common debate on kept this page. This seems preferable, as both VP:Technical and VP:policy are certainly apropo venues for a link posting, and I think we've all seen some of the bad effects of the current trend. This point made by the originator is sparse, but on point and imho, important. By keeping the discussion there, it can be similarly referenced on other BB's (Meta for one), and there are a few others. I'm much too focused on wikiEditing to keep up with all the discussion forums, so where should it go, should it be given a seperate venue (Yet another 'proposed guideline'!), or what? In sum, seems to me the 'Internal links' section with such a category template would solve both problems with minimal edit dislocation.

My confidence is high that a structural problem in presentation is present under current standards (editorial guidelines), but my crystal ball shattered some years back <g>, so I can't measure it's severity there and it's hard to gauge it's exact magnitude using anything but inductive reasoning. Personally, I rarely visit the nether regions of a web-page, and admittedly tend to attribute that to other 'oldsters' as well. I guess the key question is: If one is reading casually, what reason have they, 'our customer-readers' for looking lower down past the references? Advice? Best regards! // FrankB 15:59, 14 June 2006 (UTC)[reply]

It took me a while to figure out what you mean because I use the 'Classic' skin where the categories actually are displayed more prominently. Note that the appearance of all the skins is adjustable. I don't know if there is some reason behind the placement of the category links on Monobook, but note that all details of the skins can be changed either for the individual user (User:Fabartus/monobook.css), for the site (MediaWiki:monobook.css), or all of Wikimedia (m:MediaWiki:monobook.css). This even allows special handling of text - for instance I don't care for spoiler warnings (if I was afraid of something being 'spoiled' I wouldn't read the article) so I have a section in User:CBDunkerson/standard.css which causes the 'spoiler' class (set by the {{spoiler}} template) to be hidden. Thus I would suggest discussing it on the CSS talk pages and/or taking a look at m:Gallery of user styles for examples of how to change it for your own configuration. --CBD 19:59, 17 June 2006 (UTC)[reply]

I'm back, See second email before doing anything! FrankB 23:26, 10 July 2006 (UTC)[reply]

• He's baaaaaack. Can you clue me in on how to shut up the ({{Ut}}) 'if statement' in this test (bottom) (bad as a teenaged girl! Noisy!)

If I knew how to give a Barnstar, I'd give you two. 'ACE!!!' and 'Ole Reliable'. Yippie, less typing! (I'm basically lazy, even if I didn't go to bed last night!) <g> All Star Game WikiBreak coming up!!! // FrankB 23:16, 11 July 2006 (UTC)[reply]

• btw - if someone deserves a Barnstar today, see Petros471 and refer the matter to whomever is empowered. // FrankB 23:16, 11 July 2006 (UTC)[reply]

Hey! Pegship just asked my why a template is broken, and I originally suspected someone did some deletion sans checking into what links here. After looking at it, seems to be a parsing issue or mystery, so taking both together I reason we need an admin that is expert in templates to see what happened and is up! Guess who is elected? <G>. See this and see what you think. My worry is more what other templates may be having the same issue, vice fixing this test or template set; this was a test of the competing system I applied in a few cats only herein.
  In actual fact, once you take a look see (You'll have to go back in history, I saved the page with an inuse and added lts in front of the funny output... which is also manifesting in the component template 'parts' (such as this one) as repeated sequential line filling 'Template:Void 3 Template:Void 3 Template:Void 3' redlinks) and figure out what happened, we should just delete it in both cats too. In sum, I have no clue why those are appearing in several members of the set.

After you investigate, we probably need to speedy-D the whole set (consider them db-authored if we can expedite things so since I ported them, that should do.) as like I told Peg, was a test so I could argue virtues and vices with Jimbo and commons bigwigs. There are only two cats affected here, and several user pages. With them being broken, I wouldn't worry about any of us users... mine is certainly on a temp scratch page.

Thanks in advance. If I can do some of the grunt work, say what. // FrankB 03:20, 8 December 2006 (UTC)[reply]

I think I resolved the problem, but it looks like some people have started using these since you introduced them. For instance, User:Vilallonga and User:Krzysiu Jarzyna have them to identify/link other projects they contribute to and someone added it to Category:Pharmacy. --CBD 11:03, 8 December 2006 (UTC)[reply]

1. Well, Thanks. I have no real objection to them staying, but we might consider the matter at WP:TFD. Should I raise it, or let it ride. The commons will be using theirs for the forseeable future, though it's frequency of use has hardly grown at all in several months. I think they've lost enthusiasm for such since it's so cumbersome, ugly and large in edit space. I sure do like my one

line version better there!

1. I have to deal with real life for the rest of today. Can you take a look at Template:Wet noodle award(edit talk links history) and figure out how to get the links and signature to behave. The fonts sizing just jumped on me too, so check the last few minor changes I made in diff to see the issue. I've an edit window open for to apply this unfinished, overdue tool! (Slavering at the bit, so to speak! This is my biggest pet peeve here for sure, and a way to fight it!)
2. If easy, let me know by email what the trouble was in sisterlinks. Thanks as always. Should be back available late evening or at least by Midnight. (Social thingy too!) // FrankB 20:19, 9 December 2006 (UTC)[reply]

   Sorry, I had explained the problem on Talk:Pegship rather than here. Basically, the 'void3' template was deleted a couple of days ago and I just had to change references to that template to instead call Template:Void (which does the same thing as Void3 did).

   For the wet noodle template, I made some adjustments for what I think you were looking for. The signature will now work if the template is substituted (i.e. {{subst:Wet noodle award}}). There is no way to force a signature without substitution because the person calling the template would change each time. Most such templates leave off the sig and expect the user to add one manually. --CBD 15:38, 10 December 2006 (UTC)[reply]

I'm stacked up in several Wikipedia page edits, and along the way needed and wanted a quick way to access the talk page on a shortcut page (Wikipedia talk:Categories for discussion or the analog of WP:CFD, so to speak). I'm not sure of the url expansions and precedents, much less the causal needs to derive the desired link given the 'CFD' as a second perameter once I stubbed something out. Not even sure this is possible, but figured you can assess that quickly.
  If you have a moment, can you take a look and leave a suggestion or impliment. Seems like a useful template to have as an alternative, since will access all the Wikipedia talk pages if we can build one that is generic. 'WT' AND 'WPT' are preused disambig abbreviations, so I figured the name to be 'WP/T' ala 'WP:AN/I' as a good choice. The effort is here] with my meager success. (?Why aren't we both watching Bowl games? <g>) Happy new year! // FrankB 19:38, 1 January 2007 (UTC)[reply]

Hi Frank. Ok, the problem you are running into is that 'CSD' isn't defined as anything. There is a page at WP:CSD which is a redirect to Wikipedia:Criteria for speedy deletion. There is also a Wikipedia:CSD page which redirects to the same spot. However, there is not a Wikipedia talk:CSD page. The 'CSD' by itself doesn't mean anything... only the full 'WP:CSD' string because that is a specific redirect page set up in advance. So to get this to work as I think you intend you would have to set up redirects to the talk pages. There are some examples of that like WT:AUM, which redirects to Wikipedia talk:Avoid using meta-templates. Obviously that would take alot of work to set up all the redirects. --CBD 22:20, 1 January 2007 (UTC)[reply]

• Also found WT:CSD after posting this to you, but that 'many redirects' solution was what was trying (hoping) to avoid. Have enough trouble remembering shortcuts, so thought to pervert them to need if wanted to refer to a talk instead. (You DO have a habit of referring me to interesting talk pages! LOL. This one's a good one to keep in mind. I'm somewhat guilty, I think.)
    I guess UR saying there couldn't be a general solution as I'd hoped using localurl's and other esoteric link build avenues. Sigh! Guess on reflection, that would violate causality... the shortcut expansion would have to know the WP:CSD belonged to a given namespace page. I was thinking fuzzy I guess. I had it in my mind that perhaps another sub-template could return the proper namespace link, and this concoction would massage that with prefixing 'Wikipedia talk:'. Duh and oh dang! Thanks as always! // FrankB

See: this and especially this ASAP. Thanks // FrankB 00:23, 5 January 2007 (UTC)[reply]

amplification

• Note the non-protected... {{editprotected}}! // FrankB 00:25, 5 January 2007 (UTC)[reply]

thnnks1] and thnks2. Suggest similar 'user help' on the locked {{cfd}} Cheers! // FrankB 17:00, 5 January 2007 (UTC)[reply]

PING vs renaming request by email -- If can't do that, reply my talk and I'll db-author instead, or other recommendation. Thanks // FrankB 20:10, 29 January 2007 (UTC)[reply]

Hi! See this use of the protected {{commonscat}} template... which on my Firefox browser is just showing the white box, sans any contents. Ditto for IE6. Best regards // FrankB 00:27, 23 January 2007 (UTC)[reply]

Hi Frank. If you check the history link you supplied above you will see that the text was there... it was just displaying outside the box over on the left. This was because the template call was on the same line as the preceding sentence and thus the text was continuing from where the other text left off. I just moved the template call down one line and now it is ok. --CBD 12:44, 23 January 2007 (UTC)[reply]

PING --seems I was wrong in my email. // FrankB 23:01, 28 January 2007 (UTC)[reply]

But the question's still a good one. DK apparently has a life... the 'Bad Things happened a while earlier... which apparently triggered his query. Best! // FrankB 05:57, 7 February 2007 (UTC)[reply]

(2) there any way to make such like work?
   A) Template:SIG(edit talk links history)
   B) Template:Inuse-until(edit talk links history)
   C) nowiki's should have been disarmed by 'here'???, so I guess this page is proof the try failed. ?subst:??? Best! // FrankB 04:25, 8 February 2007 (UTC)[reply]

Wow! (No other messages since!) You must be nearly wikimissing! <G> You enjoy yourself! Sigh. Wish I could do the same in good conscience. If it's the job... condolences!
  How about adding the Template:Unicode/doc page to the protected Template:Unicode. I'm open to ideas to how best to make {{Protected}} interwikized, as I'm sure it's gonna keep biting me. Thanks for the link to WP:RT too! Couldn't find the danged page again. I'll need to add that to my patrol.
  Best guess would be to incorporate the {{#ifeq:{{SITENAME}}|Wikipedia| <!--- Template Here --->}} coding you were noticing on my email. <Funny- t'was not the topic!>
  I have to do such wherever there is a 'Wikipedia only' reference like that, including some cats declaring a parent to a 'category:Wikipedia... something', where they involve porting issues. (The skeleton of cats affected is small, but support the whole... without changing our template categorization here.) If you agree, can you update that and drop me a note so that I can then export it's doc page, and test foreign wiki waters for loacl collisions if they use a {{protected}} equivilant. // FrankB 16:10, 10 February 2007 (UTC) (Edit conflict -- Fast BOT! LOL!)[reply]

I updated SIG so that {{subst:SIG}} will produce a viable signature. This can be included into other templates as {{<includeonly>subst:</includeonly>SIG}}. However, this generally is not done because more people automatically type ~~~~ at the end of their message and would thus end up with TWO signatures... or not subst the top level template and end up with gibberish.

I also inserted the {{/doc}} on the Unicode template. --CBD 20:29, 11 February 2007 (UTC)[reply]

1. Great on the sig fix... no-one subst's the Inuse templates, and when I find them, always wish they had a timestamp and party to contact... the wording is a little weird too, so I ended up reintroducing the 'until' version as it's easier to look at the clock and estimate the task will take X mins, and compute a 'should be done' time than it is to answer the 'for two hours' question (means what sans a reference time!). Sigh.
      
2. See Template:IWTG_tagging_templates_usage, and in particular the note under the {{template doc page viewed directly}} [When viewed directly! <g>]{{I'd like to see it added to that template, or something close to it, for these combined usage pages. I'm thinking triggered by testing '{{{1}}}', as it certainly isn't needed on a typical /doc page.
     Overall, I believe many templates can be documented similar to this one and {{Indent family usage}}, and I have in mind stuff like lc, cl, ccl, where the usage tends to refer to the others of similar function as 'see also' templates. In sum, I recommend you work that into WP:DPP as a preference.
     
3. I already did that as an alternative,iirc, but!, looks like you need to intercede with L... for me. He'd voted to delete IWTG as well, so I don't know why he'd trash that effort if the IWTG was an issue. Is he of the school of less documentation is better? Deleting the one {IWTG} line would have been enough, don't you think? Probably explains why you didn't comment on the change! 'Cept for the below, niggling problem, I've been pretty happy with it, AND {{interwiki doc page pattern}} for the most part.
     
4. Would also appreciate you taking (and adjusting) {{interwiki doc page pattern}} to create a page as per my version of WP:DPP, as I'm confused whether I fixed it off site, or didn't save in a browser, but seems that this version never nests properly viz the second IWTG... (I'm a little woozy with a very bad weekend!)
     In any event, the template cats, and the two calls to IWTG (one self, one for the template calling) need reconciled some with self cats and template cats and interwiki's. If I've extra 'broken in cludes', by all means cut the number, but please simplify it if you can. I seem to have to wind up moving the calling template's IWTG upward all the time and nesting it against it's cats--which puts it high verses any documentation on the page. I'm sure Ligulem would prefer it down low, and so for a fact do I most of the time. Maybe just move it's catgories down instead? Well... take a look, but you'll need to see the reverted WP:DPP to see how I've been using it.
      
5. On behalf of David and Mike Peel, let me invite you to kibitz at Category talk:Wikipedia templates#Category:Templates by namespace where our survey of templates is generating some ideas on a better or at least different categorisation scheme for templates.
      

Strange to be writing you by talk instead of email! My systems unstable right now and I dare not open email again until I close browsers out. I had regedit open, and changed settings, particularly a couple for IE and email, and blewy... my whole task bar and the mail program went away. Bare desktop save for one text file. Fortunately, I pulled up the task manager, and it's letting me close out open pages and even edit... just hard to switch or take notes as I go per my normal practice. Definitely gonna get a MAC next computer. TTFN // FrankB 04:13, 12 February 2007 (UTC)[reply]

There'a a technical point or two here that I believe you can shed light on. See down to where Rick Block made one attempt in a template.
http://en.wikipedia.org/wiki/Wikipedia_talk:Categories_for_discussion#Category_redirects_section_incorrect
Thanks // FrankB 19:26, 17 February 2007 (UTC)[reply]

re: Can you update this back to my code plus add the missing pipe after 'SISTER'... I just found the same goof on Meta, I'd tested it using the front-end templates tlxm/tlxc/tlxw, so didn't see the affect on normal usages. Thanks. Makes for a nice extended capability though! // FrankB 21:44, 18 February 2007 (UTC)[reply]

I put in the bit, but didn't convert it to use the /doc sub-page. While it makes sense to have a doc sub-page for that template I think it needs to be discussed on the talk because the documentation on the sub-page is very different from the current - in part because it is used by multiple templates. --CBD 01:41, 19 February 2007 (UTC)[reply]

• Re: thanks, but Querp? The display's the same, which is what makes SISTER pragmatic. The other three are just empty shells passing numbered parameters to this... 'filter macros' in effect.

• Template:Tlx/doc(edit talk links history) / Template:Tlx(edit talk links history) Could it be you got faked out by a noinclude block on the /doc page? I needed someway to track updated or not on versions, so hiding a brief summary with sig stamp cum date seems pretty efficient... and so the top of the doc page viewed directly vanishes in use on the actual templates. Thought that was a good compromise, meself.

... the newest included doc page is has two line brief acknowledgement of the front end templates, and from this following line and downwards:

"|template|first parameter|second|third|...}}→ (becomes) → {{template|first parameter|second|third|fourth|...}}"

is what's been around for a while, though 'that' exact format of the expansion originated on the commons or Meta... with the same guy that doubled the capacity, from three args to six, iirc.

So I took the best of two /doc versions (that weren't really all that far apart) about a week back and made them all equal and less prone to interwiki issues. But if you have a concern, I'm all ears! The usage talks about tlx, and has that table as it has for months. The only variation therein is the names were for a time W2, not X4 or whatever this one uses. Most sisters HAD W2, and don't have any of the X#'s.

I did just see something on the talk about either splitting that table in two, or eliminating the empty call cases.

I did reconfigure parts of that so the Doc also tests against PAGENAME iirc for proper categories (i.e. internal versus Interwiki link templates; though with SISTER=, in there will cat to both of those itself) or perhaps adds or subtracts a line by PAGENAME calling specific to that pagename. That's what I've been doing with combined usage pages for a few weeks now, especially those which refer to a lot of others. // FrankB 04:08, 19 February 2007 (UTC)[reply]

Can we settle-up on whether or not there is needed discussions on Tlx, or can I count on an inter-site version as I'd written the /doc page? All my IE6 browsers shut down on me abruptly two nights back loosing all kinds of almost ready inter-related edits, amongst which I'd had a suffixed version rear end for Lts called ltsany by which I mean, I'd created a general version of Ltsmeta, including a parameter to specify site language prefix. OTOH, I may have saved that on Meta or the commons, and I need to go look... but in the meantime ... Think that Language wrinkle should also go into Tlx, the concept being to suffix the three letter project mnemonic 'mta/wpd/wbk/... /wvy' in small front end filter templates ala {{tlxw}}/{{Tlxm}}/{{Tlxc}} which provide the site routing definitions "|SISTER=...|LANG=|" from the filter--The CAPS flavor being the call into the output template the lowercase, the pass parameter into said front ends.
  OTOH, I suspect your concern is the /doc page links now evince as and devolve to a full url link instead of a local wikilink, and so maybe we should be discussing all of such on a wider forum?
   --Not so sure that's not a bad thing, as it does decouple the 'what links here' from the docs pages.
   --But some may see that as a problem not a benefit.

• Regardless, it's clearly getting near if not past time I need to involve others in scheming this as well as actiely doing some of the remaining work.
     -- Among other factors, the project really needs people on each site now 'in the know' about local wikipolitics, in particular, category and template practices,
     -- and essentially the main project page needs:
     (1) finished and refined by community discourse
     (2) moved to Meta along with Doc page pattern ASAP, and
     (3) the other sisters to have local wikiprojects 'chapter houses' as it were, where local site co-ordination occurs.

• Bottom line, there is a lot of wikiwork I'd rather be about instead, and is going neglected in the meanwhile... I've somehow managed to put myself trudging away endlessly on a treadmill, attempting to empty a lake with a teaspoon, or move a beach with a thimble! So, I need some overt support and assistance for a while as I'm not even sure when to trust my judgement right now.
      It's got to have a coming out party and be accepted here soon as well, and if it's rejected here, then I've lost a good month of wikiwork for nada. Recommendations?

My concern with the /doc page wasn't any of the various things above. I just thought it was hard to find the basic TLX documentation in amongst all the other stuff that was on the page. I tried to re-arrange things a little so that the documentation TLX users are used to seeing appears at the top and the other stuff is minimized. --CBD 00:22, 23 February 2007 (UTC)[reply]

Several things that've come out crystal clear in sister porting are:
   a) /doc pages which display as redlinks are not welcome
   b) Even Tlx is not always sister appropriate, particularly on village pump pages where curly braces and expanded font face ends up being a little funky looking breaking the narrative flow,
   c) There exists a element of the population on some sites who are very anti-template. I don't know for sure why, but it smacks of cultural biases perhaps rooted in past recommendations (e.g. the dead issue about parserfunctions?), or people that don't understand templates as labor savers (out of personal preference and typing skills, work methods, or such? Or subconscious bias, perhaps even fears and which wouldn't let such people realize they are discommoding others manner of thinking and doing work, for it's certain we all think differently and work differently--so I'm thinking that such disruption must needs be subconscious or they're controlling people).

When you next be active, can you take a peek at this and see if you can get V0 to represent "V₀"... this looks like a great little asset for Wikibooks and Wikiversity, but something about the tech coding seems not to like the <sub/sub> nesting? Can that be fixed? If not, then the /doc page ought to spell out the proper work around that would work within the first numbered parameter. I haven't ever played in depth with the 'math' wikimarkup modifier, but would suspect one could flip out and then back in at need using "</math><sub>0</sub<math>" ? If that's valid, submit that could be generalized as a sub-template {{sub}} which should be mentioned in the /doc page as well. (What to my wondering eyes but appears, a blue link doing precisely that, in a category I've never seen! BTW-- what's the cat for the parserfunctions themselves--or are they keywords with no template part at all? But check out the 'code' behavior with the change I just added... to 'equation'.

I got to go make dinner -- this time of year alas, I'm a single parent! // FrankB 01:08, 22 February 2007 (UTC)[reply]

Most other projects don't use /doc sub-pages at all. They came into existence on Wikipedia solely because of the template transclusion limits. The other projects don't use anywhere near as many templates as we do and thus likely haven't even noticed that there ARE limits on how much can be transcluded onto a single page. As such they probably aren't familiar with /doc pages at all.

Parserfunctions do not use any templates. They are like the {{NAMESPACE}} and other 'magic words'... the Wiki parser picks them out and performs special handling in the php code. Thus, there is no way to see a category or 'what links here' for all pages with #if: and the like. --CBD 00:22, 23 February 2007 (UTC)[reply]

Can you take a quick peek at {{ltsany}} and note how {{ltsany/doc}} is not being included during the #ifexist: check. Is my syntax off, or did this start malfunctioning recently... it's endemic to other sites too, yet I'm 99% sure I've used similar tests before. Very puzzling! Thanks // FrankB 00:27, 28 February 2007 (UTC)[reply]

You had [[template:ltsanydoc/doc]] instead of template:ltsany/doc. --CBD 10:34, 28 February 2007 (UTC)[reply]

Thanks -- OIC, then my prior coding && tests shouldn't have worked either. Harumph. Good thing I'm starting to work back through those then... I'm refering to the interwiki category tagging sets. Finally figured out how switch works, and I'm going to cut things down to a basic on or two with more user friendly names. Thanks again. // FrankB 05:33, 5 March 2007 (UTC)[reply]

(Note started last night, then I had to crash... read to bottom before following links. Some things changed in the middle period.) This currently involves a couple of administrative pages links1, Links2 and not much else, but in a good library for WP:TSP to export. Basically, the two templates seem to be cloned from one another... and I'm not sure whether they are both necessary due to the techniques employed, or the duplication is unnecessary, making one (Lz3) essentially redundant.

This diff shows the 'Lz3' template to be the essential guts of the other 'Csn', and evidently, the truncation of usage into an early X/doc page attempt. More, Template:Lz3(edit talk links history) is awfully unmnemonic for a math function, and Wikipedia:Requests for administrator attention is for administrator attention sucking both it and Template:Csn(edit talk links history) in per the template list in edit mode, and that what links here list.

Further, it looks to me that Lz3 is a pure duplicate from this direct comparision.

In the meantime, See this change, which throws water on any 'fire' and urgency on this, but creates a mystery as asked about here, since the old version seems not different. [This diff's The change in the middle alluded to above]

Bottom line, someone more knowledgeable than me needs to check those two are untangled, or tangled, and if the latter, I'd suggest making it a sub-page of Csn, which is at least semi-mnemonic. Also, note it is likely the interlinking I saw was due to the cross connect in the respective /doc pages. But also note, and perhaps as the first order of business, that the Demo page Template:Csn/Csn demo(edit talk links history) or at least the two (Template:Csn/doc(edit talk links history) & Template:Csn/doc(edit talk links history)) pages now seems to be malfunctioning in their bottom section, and I'm clueless on why that is happening... and pretty sure it was fine before I moved it to a sub-page. So please take a look and see what I did. Sigh.

---

• A whole lot hotter... Is there a guideline or can you tell me how to define a named parameter in Specialpages/ExpandTemplates... it seems to be hell on wheels for defining PAGENAME, but limited, as it seems to ignore everything I try in a named parameter. Reply on this soonest on my talk please. Thanks // FrankB 19:45, 11 March 2007 (UTC)[reply]

Ping this here, X5 && X6, tests on Talk: X4 && Talk:X5 or X6 and email note on problem. Ware the Sandbot... Seems out of control and wiping these as a manual request. // FrankB 22:23, 12 March 2007 (UTC)[reply]

{{#ifeq:Main|{{NAMESPACE}}|Yes|NO}} and [User talk] which in an main space (article) is not displaying nor evaluating properly (gives a false) in the if statement given... got a fix you can suggest? It is also obviously inconsistent, since it's displaying here fine! Arrgh! No rush--off to my youngest son's 16th BD dinner-party. Thanks. // FrankB 22:18, 18 March 2007 (UTC)[reply]

The 'main' / 'article' space actually returns blank for {{NAMESPACE}}. So, {{#if: {{NAMESPACE}}|No|Yes}} should do what you are looking for. --CBD 00:27, 19 March 2007 (UTC)[reply]

Tisk tisk... Strange inconsistency there, but matches (consistent with! <g>) what I was seeing... just whether to cat or not for a maintenance template, but thanks as usual. // FrankB 05:18, 19 March 2007 (UTC)[reply]

• I see you fiddled with Template:DATE(edit talk links history) on the 19th...

I had an unpleasant run in with it yesterday, and decided to apply the KISS principle, as in the end, it's better as a robust typing-aid, suffering an occasional mal-application, vice a kludge no one wants to use. Do you see any down-side on such simplification?

Don't know if you're following Wikitech-I emails, etc. but the self-subst capability I asked for at bugzilla last week would be perfect for this kind of unwanted clutter in tagging.

Thanks for the endorsement on the commons! I'm a little intrigued no one is discussing the uplink tagging. Sometimes I wonder if I'm the only one editing in the default skin as a rule! Heh, heh! // FrankB 15:37, 23 March 2007 (UTC)[reply]

See: this... Just thought you might want to look into cause and effects since the main page is involved. // FrankB 15:35, 3 April 2007 (UTC)[reply]

Is there a way to force an HTML 'wrap-point' for a div style box. See Template:TOCnestright(edit talk links history),

1. http://en.wikipedia.org/w/index.php?title=Bharuch&oldid=124903592 This position,
      versus the 'improved template version' displacement below...
2. http://en.wikipedia.org/w/index.php?title=Bharuch&diff=prev&oldid=124950391
3. http://en.wikipedia.org/w/index.php?title=Arabian_Sea&diff=prev&oldid=124947829 And this which I can live with, but suffers the same sort of disconnect from point of application of the template.

In general, I'd been trying to eliminate ugly whitespace forced by large graphic bodies like infoboxes and battleboxes (e.g. see the change history in Battle of Jutland (edit talk links history), showing several differing trials using the wikitable method, abandoned in the template... before settling on a compromise format.)

The only approach I suspect would work would be to define named parameters like '|before= ...' and '|after= ...' which would have their own div /div context, all nested inside an outer div /div block about the template's TOC div /dic making a sandwich. Would that work? Other means? Suggestions? Thanks // FrankB 21:14, 22 April 2007 (UTC)[reply]

II

Playing (in a serious way--now that dinner's in the oven!) Get:

History of chemistry (edit talk links history)

Before

after1 -- diff1

after2 -- diff2

which are all three improvements to the good as far as packing down unnecessary whitespace is concerned, and Timeline of chemistry (edit talk links history), where the robust nature of a top position of the current template version is (again) proved out (as in one of the above examples).

Diff2 implies like adding a width limiting parameter is a 'Best Option' as well. Or would you suppose this sort of improvement is better left as the overt divs? Not everyone is comfortable with templates, though this be awfully simple. Since would have to use named parameters for any text which might enclose other templates using an equals sign, should be obvious enough as a template. Advice? Any problems with MOS on this? // FrankB 23:34, 22 April 2007 (UTC)[reply]

I wasn't sure what you were trying to do at first because alot of the before and after changes looked identical (or virtually so) at 1280x1024 screen resolution. However, after switching down to 800x600 resolution I could see some differences. Unfortunately, there is no way to determine what screen resolution the user has and getting things 'just right' for one resolution is often going to mean they'll be off for other resolutions. For instance, the 'width limiting' you were referring to will work very differently with 30% of a 1280 pixel wide screen than it does with 30% of an 800 pixel wide screen. The IE vs Firefox thing is apparently a bug in how IE renders 'stackable' HTML elements. It looks like 'TOCnestright' differs from 'TOCright' primarily in that it stacks the TOC to the left of other right aligned elements while 'TOCright' stacks it against the right margin below other right aligned elements. I think that's a valid display option for some pages, but I'm not sure there is any way to further tighten up the whitespace that will work for all resolutions / browsers / pages. Getting that precise would pretty much have to be done on a page by page (and screen resolution by screen resolution) basis. --CBD 12:38, 2 May 2007 (UTC)[reply]

Ahem!

Also see TFD... apparently one can't even work on wiki now without being a wiz at HTML. // FrankB 08:00, 28 April 2007 (UTC)[reply]

Something in the infobox on this page is operating extremely differently on Firefox versus MSIE (Seven at the moment, but looked the same over the weekend back in the home office on IE6)... here. On IE, the whole area to the left of the infobox is insisting on being whitespace with divs, or the {{TOCnestright}} trials. OTOH, I got it to work as anticipated in Timeline of chemistry. Can you take a peek under the hood and see if you can spot anything which would cause the whitespace gap when the two interact? // FrankB 17:51, 30 April 2007 (UTC)[reply]

It actually wasn't the infobox. The map image below that was causing the problem - though I'm not sure how. I moved the map down and it seems to be displaying better now. --CBD 12:04, 2 May 2007 (UTC)[reply]

Glad your back around

(Thanks and Grrrrrr [time to take a wikibreak and do some yard work instead apparently!)

... though I'm out and about away much now myself! I was just dropping the below assuming you were still busy off-wiki:

Could you take a bit of time to look into this (leads to several related discussions) 'Quality Control' issue, and give me any insights, etc. that may be helpful? No hurry. Thanks // FrankB 16:46, 3 May 2007 (UTC)[reply]

but!

Your answer above seems to indicate there is no real hope for the overall complex of problems (except perhaps limiting the page width rendering, as I believe I've seen in some websites), and I've spent an awful lot of time coming up with some thing which only works some of the time under some conditions... as is apparently true for {{TOCright}} and {{TOCleft}} as well given the last change made in this (edit summary's) complaint (Battle of Jutland (edit talk links history)). It does make one wonder how successful and reliable webpages are built by say Amazon.com or other complicated sites. Any further advice, as always, will be appreciated. Thanks // FrankB 16:46, 3 May 2007 (UTC)[reply]

• Was just checking for an answer on this. I'm about to send an couple of emails your way as soon as I find an edit I made that I want you to make to a protected template. Cheers! // FrankB 04:08, 7 May 2007 (UTC)[reply]

  Hi Frank. Wikipedia runs into trouble on page layouts because we use a mixture of markup and HTML, some elements (like TOC and the navigation bar on the left) are inserted automatically by the system, and anyone can add or remove text and thereby shift the positioning of elements. Amazon and most other websites don't have these problems... they design the screens from the ground up with one consistent methodology. If you look at the Main Page or the Wikipedia:Featured content page in various screen widths you'll see that it IS possible for Wikipedia pages with multiple 'stacking elements' to be formatted to work for all scenarios if they are protected and kept within carefully designed sizes/segments... but even there you get whitespace in some circumstances. I was involved in the current Main page setup and do most of the work on the Featured content page so I can tell you it was a huge hassle getting them formatted to look ok... trying to set up a TOC template which is going to work on every page/screen width/browser/Wikipedia skin seems like an unattainable goal to me. There are just too many variables... and you get it just right and then someone comes along and adds a paragraph or a new picture and throws everything into disarray. --CBD 11:46, 7 May 2007 (UTC)[reply]

• Yo! and Thanks. More play with this, including an all-nighter on Ronald Reagan (FAC page) has me cautiously optimistic that a reasonable working solution is attainable circa 80% of cases. I wrote Template:FixHTML(edit talk links history) and that solves the odd jarring disjoint wrapping quirks most all the time. What it won't stop is the height changes in the vertical packing as one zooms in and out with a browser. (I've been testing on five: Firefox, IE6, IE7, Netscape 8, and a MAC's). It's just a swtich shell with different Wikitable elements coughed up by the key command word begin/middle/end, but I felt it was superior to embedding |, {|, and |} sans explainations. It also solves the edit link stacking problem as noted in the Wikipedia how-to page it cites.

• A key issue becomes the length of the intro with respect to the length of the Table of contents, and whether or not the section or two below are long enough to absorb wrapping around the TOC as one zooms in or out. If the TOCnestright is applied up high in the intro, and one zooms to a painfully small font, and a long TOC is still shorter than or even with the boxes/images and other stuff stacked on the right while still being in the intro, it'll work every time so far as I've tested. If it's a bit longer in some zoom levels, not much of an issue either--one may get a little whitespace under the right floated stack, but the tallness proportional scaling stays in synch pretty well, and it's usually minor and affects only one extreme of the zooms range depending upon vertical location of the TOC top in the paragraphs of the introduction. Zooming back the other way, solves the problem--so a spotty occurrence at worst.

• If the TOC is short comparative to the intro and the right floated stuff, especially toward tiny fonts, works all the time.

• If the first section wraps into the TOC on medium small "effective font sizes" (selected per zoom setting, "effective" meaning relative to printers Pts s.a 10pt or 12pt at the given zoom) a couple of different remedial measures can be taken. The worst occurrences are if the editors on a page set a pic to the left at the top of that first section... on the more extreme zoom outs (small and tiny font Pts.), that may force the whole section below the TOC bottom, or cause a zig-zag unpleasant text wrapping look between the TOC bottom corner and pic top. (See the 'youth' pic on the left in Ronald Reagan (edit talk links history) for example.)
  
  Generally that little white gap is acceptable as most of us would use a bigger effective font for reading in most cases, so adding a {{-}} above the section heading fixes such issues. The zig-zag is dependent on text length of the introduction section, so one can usually find some important matters down in the body to summarize that were omitted, curing that issue most of the time. (IMHO, most non-GA/GAC/FAC and FA articles have too little in the introduction anyway, so this usually improves them more than just cosmetically and tends to better satisfy the MOS!)

• If the TOC wraps beyond the first section title in mid-size fonts, and has a long section title or contains a lot of long links (e.g. "Clarence Fitzsimmons Muckraker, Duke of Transylvania and Elector of Brandenberg" <g>) the only recourse is to generally suffer the TOC whitespace in the standard position. Double that with a left pic, and another long element floating right such as a dynasty box ({{House of Hanover}}, or such).

• However, if that first section title (or even two) is short (e.g. Overview, Early life, etc.), and has short links, it can wrap and float up, since the body length shrinks going to a smaller effective font both as the width of things also compress concurrent with the shrinking font heights, so as one zooms out toward that painfully small font limit you both get more on a line, and are in the worst case again when evaluating it. Expanding the zoom back to a more comfortable reading "effective font size", tends to eliminate the overlapping again, curing any issues. (Again, caveat on left pics.)

• The one caveat I have "in reserve" is that I haven't tested it on a screen density over 1280X1024 -- my monitor has a weak cap that I don't like to 'test' at that refresh rate, but inasmuch as there seemed to be bigger issues with browser rendering order, I'm optimistic. I've laid in enough testing trials (usually a few a day), that it will be interesting to see how the community reacts. So far, but for a few cases, the TOC's been staying where I put 'em without adverse comment or quick reverts. (Figures that 'Law' would have been one of the few exceptions! <G>).

• That's today's snapshot. Thought maybe you'd enjoy a status and some goodish news for a change instead of another problem! Play some yourself next time you see some whitespace... I think you'll find it effective. Cheers! // FrankB 04:23, 19 May 2007 (UTC)[reply]

no hurry on these

...I'm going to get some yardwork done this weekend or die trying!

(That's a laugh -- I'm working through my unsaved 'back buffers', and I wrote that a week ago (?two?)! LOL. I tend not to gravitate to this laptop if I'm home--no email I care to check! So I've revised the below dropping two requests in favor of planting the thought:

• Back when, Kirill Lokshin addressed a related question on the infobox-TOC corners misaligning wildly issue (the key, as it turns out was pointing me to Wikipedia:How_to_fix_bunched-up_edit_links) to some of the above good news, and turned me onto the following page. Do you think you might be interested in taking a stab at dumbing down the 'contextual assumptions' by the authors and perhaps interject some of the appropriate HTML definitions implicit in the discussion? The mentions of clear are in particular need. You know, HTML Stacking Elments for Dummies <g> I'd tackle more, but don't have your experience to know that I was right or just making a WAG! Just a thought! // FrankB 05:47, 19 May 2007 (UTC)[reply]

If you've got a moment for some light duty thinking, this major expansion (I got caught up in checking terms--what a derailment of my planned edit!) needs a proofing (some of my 'history' may be off a bit and need tweaked--I don't know!) and has some redlinks you perhaps know the proper substitute links to clear up. Address buss has to be covered somewhere, doesn't it? Can't believe such a fundamental term was so badly neglected so long! Thanks and Cheers! // FrankB 19:59, 31 May 2007 (UTC)[reply]

Hi! Long time no see. Can you follow the "trail" here, and especially the trial stab link I doc'd at the bottom and advise me as to whether something occurs to you for this guys problem (sic) (errr, desires"). Note I'd had a closing solution of sorts I ran up his flag pole that might work, so peek at his talk for that in the section I linked. Sigh! // 00:26, 23 June 2007 (UTC)[reply]

Hi Frank. Not around alot right now, but I took a quick look. If I understand the desired intent correctly then I think it just needs a 'border: none;' statement in the style settings. I made that change and the example at User:KuatofKDY/Sandbox is now doing what I think the user was looking for. --CBD 13:12, 25 June 2007 (UTC)[reply]

Thanks, I'll see what I can learn. I'm MIA a lot now myself. Have a great 4th! (Not to mention the rest of the summer!) // FrankB 01:45, 26 June 2007 (UTC)[reply]

HiYa! Minor template ((Template:Redirectstohere(edit talk links history)) issue for crunching... style sheet 'dablink' used to generate italic, as far as I can recollect for this template... and as you can see here is no longer formating that way. Note the template hasn't changed... indicating to my muddled way of thinking that the DABLINK class ITSELF (Ooops- STS!) has in common.css. (Which I wouldn't touch even if I could!). Can you poke around when you get some time and let me know what's what? (Don't email me, I've been ignoring such for months since my desktop died. Simplifies life in lots of ways! <g>) Thanks // FrankB 21:15, 25 September 2007 (UTC)[reply]

Hey Frank. At the end of August, as a result of this discussion, a change was made to treat italics within a dablink section as normal text. Since Template:Redirectstohere both sets the text to 'dablink' and sets italics with HTML <i> and </i> tags it is invoking this new 'normal text' setting. Removing one or the other should return the template to displaying italics. --CBD 22:35, 25 September 2007 (UTC)[reply]

Gracious thanks... don't know how you have time to keep up with such minutia, but yer still the best relief pitcher I know! Nice to see ya again. // FrankB 22:42, 25 September 2007 (UTC)[reply]

re: Template:Redirectstohere(edit talk links history) and displays of result such as Battle_of_Jena-Auerstedt

It took three tries so I replicated the prior (remembered) output behavior, and now that I got it, I'm not sure that I want it! What do you advise... keep the mixed format with articles only as italicized text or make it all italics, which at least seems better than all plain text, given how it's used (9:1) at the top of articles, the other as a section top inclusion. // FrankB 23:10, 25 September 2007 (UTC)[reply]

Well, the discussion which resulted in the change (the link to which I just fixed above) was about situations in which you'd want a mix of italicized and non-italicized text. I think all of the text generated by the template should be italicized by default, and only things which the user marks as italicized should be not italicized to differentiate it from the rest of the text. That's the general standard for most other 'hatnote' type templates. Just glancing at 'redirectstohere' I think that would mean removing all the HTML italics tags. --CBD 23:18, 25 September 2007 (UTC)[reply]

Yeah, but, also reinstalling the dablink style, if I understand correctly. OK, All ital is easy enough with a bit of notepad cut and replace all. Correct me if I misunderstand, but thanks otherwise (and regardless!) // FrankB 23:27, 25 September 2007 (UTC)[reply]

Harrumph! Nothing ever seems to go 'easy' here! Sigh! That should do it. Thanks again. // FrankB 23:43, 25 September 2007 (UTC)[reply]

Grrrrr! <g> Low priority... and NBD, but! Modification of Template:Cite episode(edit talk links history) is failing to display the new parameters quote=, timecaption= and time= . (This is more of that "class stuff" I'm usually unconfident about—at least I KNOW I'm ignorant thar! I really should go up aginst the learning curve on such in my copious non-spare time..., someday— sigh!) and so with the likely large number of links, trial and error fix is contraindicated. Hence crying to you!

re: real edit use (failing to show quote in references)

and

1. prior changes to {{cite episode}} and {{cite episode/doc}} (detail my intent)
2. Whether or not cites SHOULD show quote, seems to depend on cite template. THIS ONE was advertising it's general use of documenting single broadcast events (see history of /doc, before and after my changes, bottom section in, particular, of 'before' state.
3. I lifted the logic with minor changes from {{cite video}} which has it's own issues with documenting A/V programming. Hence the (new latest) try with this 'cite episode' template.
4. Spot checks of where used, show no harmful effects, so back-burner as needed. Thanks // FrankB 22:53, 2 October 2007 (UTC)[reply]

I made some changes and the example page is now showing the quotation. --CBD 16:57, 3 October 2007 (UTC)[reply]

FYI-- for action as you deem necessary...

See this note, where in the main section above, the template {{ANI-notice}} is (I think) supposed to be subst'd, and since it's not, is giving an edit link into the template itself when applied to the page. So far as I can parse it, the whole main section above is solely the template output. How it magically is applied, generated, and appears on the user talk page is opaque to say the least, but if it's supposed to be subst'd, someone's bot needs a boot in the rear, and should add {1} when applying from what I can deduce.

Including the section header in the template causes the edit link to point back to the template itself when the template is transcluded. This resulted in several people unintentionally editing the template and is not standard design (for that reason), and thus I removed the section header. --CBD 16:57, 3 October 2007 (UTC)[reply]

ALMOST trivia

Save is unexpected behavior by wikimarkup (What else is new, eh!)

See behavior of right margin in the first line I modified. (About 250px is acting like a margin causing premature wrapping). Any idea why that might happen? I tried adding a </div> after the wiktionary template call, but that failed. Shrug! // FrankB 16:29, 3 October 2007 (UTC)[reply]

The '**' markup on the left is being translated into HTML bullet points and that entire array of bullet points is constrained in width by the Wiktionary template. Inserting a blank line between rows or converting the '**' characters to '::' (indent, single line) clears the wrapping problem, but messes up the bullet point formatting. Can't think of any way offhand to keep the bulleted list format and not have the wrapping issue. --CBD 16:57, 3 October 2007 (UTC)[reply]

OKAY, Great, and thanks on all three above! At least I ain't hallucinating! You're a comfort on these annoyances, for sure, yabetchya! Thanks! // FrankB 17:38, 5 October 2007 (UTC)[reply]

Woops, before I could close... I was checking a technical issue I'd handed VPT, and while in contribs,
   dropped in to see this exchange and new answers: So please see this discussion[1] with the technical issue he reports. Thanks! // FrankB 17:38, 5 October 2007 (UTC)[reply]

The blank line is caused by the 'div' section. Converting it to 'span' will fix that, but then the indentation setting causes a gap between the ^ character and the start of the reference text. --CBD 18:47, 5 October 2007 (UTC)[reply]

Kinda hot... this edit beating me up, in that the table within the second Else (Debugging Marked as ELSE2) is not displaying. I know in working up some of the TSP templates we resorted to using HTML calls to get around this parser function branching versus tables contained within issues, but I'm very puzzled the first table(s) shows not at all in this. (Compare to undesturbed source page {{Cite news/doc}})

Can you take a quick peek under the hood and advise me? This is a follow 'project' on to the conversation on WT:Citation templates (here) (section below the above consultation and link) -- an attempt to extract selected excerpts from /doc pages into a "aid to editors compendium" (One stop shopping -- a cut N paste supermarket of citation templates).

Huntster (some) and I are working this up in Template:Tt1(edit talk links history), but this kind of annoyance is a real road-block. I'm not gonna sit here and do hours of trial and error! I did too much of that on WP:TSP! I really don't want to have to resort to multiple sub-doc pages, and would prefer including the primary /doc page, instead of an excerpt such as {{Cite book/docA}} (per comments here) in the compendium--the primary doc page would be a bit more complicated if such parser logic works, but that damn overloaded pipe operator just seems resistent to human preferential desires! :(

Sigh! OTOH, building the compendium from such extracts would simplify the logic needed in the primary /doc page.

None-the-less, this strange if-then-else to table interaction is still something that may bite us. Can you think of any way to side step this kind of issue easily? Ping my talk, when answered, please. Thanks, as always. FrankB 14:30, 9 October 2007 (UTC)[reply]

There are really only three options for conditionally displaying a table;

1. Put it on a sub-page and then conditionally display that page
2. Use {{!}} to replace all | characters in the table markup, as shown here
3. Use HTML table commands instead of MediaWiki piped markup, as shown here

There are benefits and drawbacks to each approach. If you are going to be using a table across multiple pages I'd probably stick with the first option as it allows the table to be updated in one place and automatically populate to every page it is used on. If the table is going to be conditionally displayed on just one page then the {{!}} method is usually easiest because HTML doesn't always play well with other Wiki-markup (for instance, I had to take out the ':' indenting on the table because it conflicted with the HTML logic). --CBD 21:25, 9 October 2007 (UTC)[reply]

Thanks--what I thought, and discovered in between... (What ever's currently expanding fourth in {{tt1}}--I'm else wise occupied-- (1) Was what I advised in Wikipedia talk last week, without quite recalling why that was my technical preference. The {{!}} and {{!-}} technique will also be needed if there is a debate as to which version to aggregate in a compendium page... such works fine inside the limited branching I want to implement. So changing the existing tables over to those means either tall tables or the laid out ones can go in the sub-page template. Would you agree that the desirable end 'name state' there would be a /doc2, or should I just figure on deleting those and using the /docA names? (Yeah pathetically trivial, but best to settle such 'now' before converting the rest of Category:Citation templates and having several suffixes!

Haven't heard from Hunster on what I've got together yet, so I'm holding pending some feedback from someone. Called in Pegship too, so dip in an oar if you like!

Creating more /doc2 pages which will need deleted makes no sense anymore. I've got the boundaries and methods down... we just have to iron out standards... like using Wikipedia:Citation templates II or some other page name. (Once in a while testing for that makes better logical sense, so things will show in the base template page and the doc page or both doc pages, but not the compendium, etc.)

I've really got to remember what my Multipage test template was called. T'was a nice bit of coding. Would take five pairs of things and return true or false if any pair was a match. That utility could test for multiple page names which might simplify some of this. With the way D. Kernow and co. in late spring recatted templates, I'm not even sure of where to look for it! Meta, I suppose! <G> Hmmmmm {{isequal}} isn't it. Darn! <G> Cheers with Thanks! // FrankB 22:09, 9 October 2007 (UTC)[reply]

• New quick 'HTML' issue: Can you fix this simple edit to work quickly? // FrankB 21:47, 11 October 2007 (UTC)[reply]

• I made a change which I think will do what you are looking for. --CBD 23:00, 11 October 2007 (UTC)[reply]

Thanks... It'll be a bit til I return to the edit where was using (to verify)... Not too long though. // FrankB 23:25, 11 October 2007 (UTC)[reply]

I ran into some naming troubles -- see {{sect-stub-1632}} and this discussion[2] If "process allows" since we have an agreement, I'd like to have the tool with it's new name ASAP, so wonder if you can close it out. (Geee! Have I ever asked you for a plebian Admin task before? Don't think so, excluding protected templates edits!) <G> // FrankB 23:25, 11 October 2007 (UTC)[reply]

I moved the template and made the SfD notice non-inclusive on article pages where it is used, but left the discussion open for now. Closing after only one day could cause a process wonk revolt and generate even more red tape than just letting it play out. In the mean-time you should be able to use it with the new name and not have the SfD notice appearing. --CBD 10:30, 12 October 2007 (UTC)[reply]

... #28 or something! <g>

re: Bug2257, Template:Cite GG01(edit talk links history) and 1632 Tech Manual.

The last, miscounts the middle (actually skips over), which seems to be Bug2257 biting my butt. I was also intending adding a tagging name inside the logic like:

ref {{#if:{{{rname|}}}|name={{{rname}}}>...

Since some quotes cover multiple issues.

If I've got the gist of that bugzilla thread, looks like there's a fix already. Then Tim! steps in with two cents, and I'm finding my limited understanding becoming more so, alas. So while It'd be good to have a early fix, need to know whether I can stand pat, stand pat plus add the snippet above, or whether I should suffer having to type endlessly boring <ref> ... </ref>'s when I'd thought I'd come up with a real tight labor saver. (The question impacts multiple templates, unfortunately!)

For starters, when is V1.4 due? If we're talking a few months or so, I think we can live with it. If it's a long term wait, the misfortune of that sad state would contraindicate standing pat and force taking my oh-so-obvious "ref" pairs out of the templates. Note the second cite in the given page used Cite GG01, and doesn't manifest in references. Both are in #The 1632 Slushpile. Thanks // FrankB 02:56, 19 October 2007 (UTC)[reply]

Second query--Is there anyway to tell when a parameter is used in a template of widely used scope... I'd presume a BOT perhaps? This is engendered by the discussion with Peg on my talk about cite book and the {editor} param. discussion here, which I stirred up again with a bottom post. Thanks2 // FrankB 03:50, 19 October 2007 (UTC)[reply]

I responded on the talk page for the Cite book issue. On the other item, we are actually currently on version 1.43.0-wmf.22 (52791dc). A fix for 2257 was devised months ago, but never implemented. The problem is that we've got alot of cases where we don't WANT tags to be passed in this fashion... for starters it could allow some truly nasty vandalism through the use of conditional <includeonly> type tags. --CBD 10:57, 19 October 2007 (UTC)[reply]

See reference notes 3 and 4 of article Eric Flint. The #3 was a subst'd version prior to re-editing of {{Cite GG01}} per the above outcome. (Thanks BTW-- thought I'd already said that here! It'll be interesting to see what they "do" with the possibility! [I've heard nothing yet])

Template:Cite GG03(edit talk links history) is a new adaptation of that, but as you can see in note 4 it generates, is embedding pipes in the stream inside the conditional if-else test on {'{long}'}. I surmise subst'ing the 01 version set up the pipes properly expanded in the proper order and time?

My latest edit added a noinclude about the innards of the if, but the issue is still present in those (witness note 4, Eric Flint), which I surmise to be strange. I'd thought the parameters were all streaming into one or another, but there aren't any "language=", "co-author=", etc. field names embedded disabusing that thought.

So the crux I think

Will that (includeonly inline) approach work if I undo the {{!}}'s, or is there a better fix? Thanks... no hurry. I'll go on expanding articles figuring we can fix these up. Note the same issue is evincing in 'Template:Cite GG01(edit talk links history)', as can be seen in the {{Cite GG01/doc}} page displayed by BOTH. Play with whichever. Thanks // FrankB 18:58, 19 October 2007 (UTC)[reply]

I made updates to 'Cite GG01' which should do what you were looking for. --CBD 20:40, 19 October 2007 (UTC)[reply]

Btw-- How are you generating this: [[User_talk:CBDunkerson#Back_burner|Link to response from CBDunkerson]] (eom) thing? Subst or long hand? Looks handy! // FrankB 19:12, 19 October 2007 (UTC)[reply]

I just cut and paste the talk subpage link and add the rest of it manually. --CBD 20:40, 19 October 2007 (UTC)[reply]

Gratious Gratcias, Senor! (Now you know my Spanish is even worse than me English, hard as that is to believe! <G>) Thanks! see also related discussion at some point. // FrankB 20:51, 19 October 2007 (UTC)[reply]

Wow! That's a lot of if's, wouldn't it be simpler to make a sub-template to bypass the pipe conflicts and use that within the if block I set up? Though you changed Template:Cite GG03(edit talk links history) vice 01! (Had me doing double-takes for a moment! <g>) There would be a benefit there in that since all is pretty much boilerplate that is or is not displayed, the subtemplate call would expand from a switch... or do I meet up with the same overused pipes operator issue? Hmmm, Dang it. Would take an additional seperate subtemplate per main template, wouldn't it? Or does the expansion of {{!}} separated code inside the switch logic cover that as it's in effect included in the stream before the if logic is done parsing? Advice, on whether it's feasible before I try it? // FrankB 21:13, 19 October 2007 (UTC)[reply]

An example of a similar design using sub-templates and a #switch can be seen at Template:ME-ref and it's sub-pages such as Template:ME-ref/FOTR. --CBD 22:25, 21 October 2007 (UTC)[reply]

Template:Mfd(edit talk links history) and {{mfdx}} (one edit made in latter, check me, incase!)

Can you take a look at the edit I was suggesting here, and complete the phrasing 'substitution' I was suggesting in the hard to read semi-footnote... I got lost even second time through trying to figure out where mfd2 and mfd3 go, so I could write that in. [Which is what needs finished!]

The linked referenced guideline used to have how-to (I think) saying subst this template on that page, and this template there, and so forth, and at the moment, these don't even have /doc pages giving a clue to those of us who hardly ever resort to nominating things for deletion should dot our tees and cross our eyes. Here I am forty minutes later (and now even later yet, having been pulled away by messaging), still scratching my head about simple process! {1}

Perhaps Wikipedia:Deletion_policy isn't the page that had the how-to I remember? In which case, I opine, whatever it is also needs linked on the various templates, or at least in their usage, which is abysmally missing! (Per my prior edit on the talk!) Preferably, by having the /doc pages included into the guideline with the template sub-page written with appropriate if-then-else tests for what to display where in proper WP:DPP fashion! (e.g. techniques discussed in Wikipedia talk:Citation templates#A new idea wrinkle—really just an extension of the idea someone used in the Wikipedia:Redirects page where the {R from ______} template itself documents itself in the guide line/help page. I've suggested a similar approach in the Citation templates workup here.

BTW-- what do you think of WP:BRD—looks like an enicement to flamewars! Look at how this alledged editor is using it, and then violated it in citing it! Sheesh! Can't understand why that's on the books. Thanks // FrankB 01:10, 23 October 2007 (UTC)[reply]

Hi Frank. I think this is the 'how to' guide you are looking for. Displaying or linking to that on the template page(s) would probably make sense. It looks like the redirects were created to save the effort of typing that extra 'f' character; which seems silly to me, but if people use them that way they might as well be left in place.

As for 'BRD', it is a longstanding/commonly referenced essay (meaning 'suggestion from some users', not 'on the books' in the sense of a policy or guideline), but I believe the intent is, 'go ahead and make Bold changes, if someone Reverts then Discuss rather than edit warring'... not, 'if someone makes a Bold edit then Revert it until they Discuss'. It is supposed to be an encouragement to try 'big changes', with the understanding that people may object and ask for more discussion. The downside is of course that the bigger the changes the more effort is 'lost' when someone reverts. However, that material can always be reverted back or parts of it cut and pasted back in from the history later... so it is never really completely 'lost'. --CBD 13:37, 23 October 2007 (UTC)[reply]

Thanks CBD, I'll at least get a back link into those on the how to issue. // FrankB 14:17, 23 October 2007 (UTC)[reply]

• Okay, one less side track... onto RL! Helps to find the help! // FrankB 14:53, 23 October 2007 (UTC)[reply]

re: display of http://en.wikipedia.org/wiki/Talk:FIFO#It_occurs_to_me (hanging comma= original problem) and new version test in
Template:Tt0(edit talk links history), see talk display of testing changes... to Template:Catlist(edit talk links history) where whole line is presented as one big link!

The hanging comma is shown in the snippet, but notice the ommision of a comma after Cybernetics, hence the fix attempt in {{tt0}}:

• I've accordingly added the cats: Cybernetics, Discrete mathematics and Information theory

Gotta go play taxi-dad, but the template is used a fair amount in article space, so to you! Thanks. (ammended--less than I thought) // FrankB 20:40, 24 October 2007 (UTC)[reply]

I got back to this (Edit says: Okay... span works, but no end comma evinces after next to last item. Tt0 version: outputs:

{{tt0| Cybernetics | Discrete mathematics | Information theory}} (And the two are and should be identical operative code, ignoring documentation annotation) However, the underlines were a edit area in the page above, but I really can't figure where and why I'm getting output of the form: "Link space, link space, link space, ..." etc., so take still a look if you would!

• Romanesque architecture (bottom) is biggest use in article space.
• New issue, with switch to span vice div (which did nicely in not forcing a newline to start), why is parameter END not evincing above on the same line?

*I've accordingly added the cats: {{pagelist|nspace=category| Cybernetics | Discrete mathematics | Information theory|END= to see if some other eyes have a interest in this point.}}

• ALSO, is there any other way around the inline flow end causing a newline, as it does above in the line beginning "(And the two are and should be identical", which is part of the calling line to Tt0 preceding!

I could really get to hate templates! Definitely low priority though! Thanks. // FrankB 00:03, 25 October 2007 (UTC)[reply]

The spacing problem is just the spaces in your call to the template; {{tt0| Cybernetics | Discrete mathematics | Information theory}}. If you remove those spaces around the | characters you get, {{tt0|Cybernetics|Discrete mathematics|Information theory}}. I'll have to find some time to dig around more to track down the newline problem. --CBD 14:34, 25 October 2007 (UTC)[reply]

Dhhhhh-OOoooohhhhh-oops! Think I knew that once upon a time... been a while since I used it. Thanks! // FrankB 23:50, 25 October 2007 (UTC)[reply]

This should be a quicky-- in this edit you can see where changing from font size="1" to font-size="10pt" both work, but for the matter, I'm desiring to fix the font so zoom in/out ignore the size change, and display the same. Any way to fix such? perhaps a blockquote style=????

I'm trying to wrap the usage in the pre blocks so the inline comments line up and don't overrun, and so forth. (To add insult to injury, tonight me keyboard is acting up and sometimes refusing to give me lower case vowels in the upper row, {e,i,o,u} in particular! Very peculiar failure mode...) Enjoy the series if you;re watching it! // FrankB 23:50, 25 October 2007 (UTC)[reply]

Text size settings in browsers and screen resolution in Windows operate independently on the content of the web page. They don't reference the HTML at all, and thus there is no way to 'tell' them not to adjust a particular section of text. --CBD 08:40, 27 October 2007 (UTC)[reply]

Aside from nudging you on the above <g>, I'm seeing a systemic misindexing on section edit links on 1632 characters, for example, try editing Dreeson, Veronica... you get the section above. I conjecture it may be the underconstruction or inuse tagging... or cosmic faeries dancing upon notability guidelines, can't believe they ram rodded that through. Sigh. // FrankB 05:32, 27 October 2007 (UTC)[reply]

One of the sections was included in a parameter passed to a function. It was thus creating an edit link to text which didn't actually exist on the page, but was instead only displayed through evaluation of the transcluded template logic. This extra edit link which didn't go anywhere threw off all the subsequent links by one. --CBD 08:40, 27 October 2007 (UTC)[reply]

Hmmmm, thanks, I've seen that before on article pages too. I'll take a good look at the diff. so can recognize it hereon out. Ahhhh!— figures, that's material I am merging together in fits and starts. Also a reason to not overuse templates I would guess [I'm not sure whether to keep that one, not my idea.]
   Well, while the diff shows the fix itself, it doesn't say how you detected it. Hoovering the edit links and seeing sections count change? (I'm sure Alberecht didn't you whistle down with a hearty—"Yo, over here Mac!" You'll just have to settle for my normal thanks! // FrankB 16:19, 27 October 2007 (UTC)[reply]

Can I jar your elbow with a fix of this that I have to replicate in the list here, along with the other I made changes in: {{35TCL}}. An lts edit link is in the box bottom of "in this" (link), where success or failure can be measured. In a nutshell, the case of specifying "i" or "I" as {{{2}}} seems to not work (Should italicise return string). If you can take a quick peek. Also, the query above about whether it is possible "to fix" the font generated to some absolute font (for the lower part of that help page) would be nice! Thanks // FrankB 18:14, 27 October 2007 (UTC)[reply]

The 'i' / 'I' thing seems to work. I made this edit and get: Test.

On the text sizing issue, I actually responded above at the same time I answered one of the other questions and then posted a link back to it on your talk. Basically, because that resizing takes place independent of the page logic I don't know of any way that it can be prevented for a particular section of text. --CBD 19:09, 27 October 2007 (UTC)[reply]

OK, on resizing... my "test" line, may be mis-programmed, since it's evident yours DID work...
   No worries on the sound and fury, though the attitude of antagonism versus one trying to be polite is illuminating. Thanks 4 all three. // FrankB 19:54, 27 October 2007 (UTC)[reply]

Duh-ohh! Sheese! (..."the forest for the trees" situation, I plead! <g>) FYI, this worked too. Which raises the question as to how the pipe gets processed... but both avoid the misbehaviors, so alls well as ends well! Sorry about the erroneous summary line slandering your towering rep!<g> Thanks! // FrankB 20:11, 27 October 2007 (UTC)[reply]

re: change with hide mode on Template:Redirectstohere(edit talk links history)

• http://en.wikipedia.org/w/index.php?title=Spain&diff=prev&oldid=167579431 *http://en.wikipedia.org/w/index.php?title=Denmark&diff=prev&oldid=167578337

Any way to suppress newlines when it's hidden? Both those examples and on other occasions would be better if it did less vertically. <span> versus <div> ??? // FrankB 06:27, 28 October 2007 (UTC)[reply]

P.S. consider archiving! <g>

They aren't new lines. The text is all still there, it is just 'displayed' with an opacity of zero... effectively making it transparent. It therefor still takes up the same amount of vertical space. I assumed that there was some reason that you wanted the text to be on the HTML of the page, but not visible to the user. I'm not sure what the purpose is... what's the intended difference between putting the template on the page with the 'hide' parameter and not putting it on the page at all? --CBD 10:23, 28 October 2007 (UTC)[reply]

Sorry - that be 'a 2am question', I think!—me thoughts were in page composition X At the least I could have tried the span, as I know it will do no harm! I was focused instead on closing out my add edit, and was getting sidetracked often enough doing that— apologies!

—But! The "used in A SECTION" idea is to document that the heading title is used so that someone doesn't rephrase it—and providing any backlink is semi-irrelevant (AND should not be done because of loops issues with respect to a standard redirect page!), except in cases like in those two mentions above— midpage links to sections from mid-page elsewhere. Overall, I just think it makes it far less likely to have someone fiddle with it, so the requested hide mode back when. So far as I can tell, no one has fussed with even the overt formatting on it once I put it down (impression modified by whatlinkshere— some mortality has occurred it would seem), but for one change to a title I had in bold... but it is useful for this kind of warning on a section title—see the "explain=" in the second diff in particular.

In OVERT mode, I've seen others doing the monkey-see monkey-do (adoption) of it* wherein it's generally used on page tops, to ease text composition in the introduction paragraph, particularly when a redirected term is somewhat buried down a para or two in the intro text... assuming the name or names is an obvious syntax permutation of some kind (e.g. "German Catholic League" redirecting to Catholic League (German)), but overt mode is also occasionally used on sections too when appropo... as the two above aren't—linking a history of section to a fiction article is crossing some kind of MOS line, I am sure! <g>

Which means HIDE mode is a fancy inline comment that one can still use an inline comment around at need... hence, "shortening" the expanded template display by arbitrarily branching to a different expansion... even one NOT testing whether the numbered params are used and arbitrarily pipetricking them, even if it breaks a link, is an option, save that it violates causality—the [[ ... ]] is generated external to the template code as the input parameters, so such can be done locally. (e.g. "|a", "|b", ..., "|z") That may be funny looking locally, but will shorten the overall body to a few bytes of page width—like I said, it was a 2am fuzzy-thinking question, (like this was a groggy waking up with first cup of coffee answer). 2x apologigies!

* — I conjecture it's spreading as {{redirect}}–{{redirect6}} are more rigid and bound up with the disambig messages.

In any event, looks like I need to revisit it and set up a proper /doc page, etc. or better yet, just tie it in with the one {{redirect}} is using. I'm thinking just making it return "&nbsp"; if hide is set gives the best flexibility--the links are disarmed so can't be accessed by the reading impaired disabled, so that's safest. Other than that back link documentation purpose, hide is useful on page tops to remind editors a particular phrase (alias) needs covered in the intro.

• aside: I found my multiple page name (or other equality comparisons) testing template! {{ifequal}}! Yeah! Cheers and thanks, I'll take it from here.
• OTOH, Template:Ifor needs a bit of documentation TLC, and parsing through it's permutations isn't working (too much sunshine here on the porch!) well for me. Check my change and improve how it's used when you get a chance. David Kernow is missing in action these days. // FrankB 17:42, 28 October 2007 (UTC)[reply]

... and the season is over!

see hist attempts (4? "retry" summaries, more or less) here and see if you can figure out how to stop the edit link from pushing the TOC leftwards. I'm out of patience and time! Low priority, thanks. // FrankB 03:42, 1 November 2007 (UTC)[reply]

I made a change which I think might be what you were looking for. BTW, there is an option in the preferences setting which allows users to turn on 'edit' links like those and a number of user scripts for customizing. I was actually getting two edit links on that section and a bit confused what you were trying for. --CBD 23:41, 1 November 2007 (UTC)[reply]

Thanks -- I take it you double click? The preferences is how I go, but for whatever mysterious reason, it doesn't enable one for section zero, though we can both guess why! The scripts I saw late one night when I already had too many things hanging—I gather they add a tab for editing section zero—which imho, ought to be automatic if one is logged in. (Sigh... "If I was running things... <g>") I was basically experimenting, but surprised it wouldn't line up properly. And no, that's not where I was aiming for, but much better than mine, so let it be with thanks! Putting it after should have occurred to me! (I plead I should have been in bed!) Thanks!

BTW, whats the acceptable upper limit on long list articles these days? I'm hitting 80k on one I've barely got started here, currently abridged top text. // FrankB 00:15, 2 November 2007 (UTC) (Just ans. here, I'll check back)[reply]

No, I use the edit links with a javascript to include the missing top one. I've seen suggestions of maximum article sizes in the past, but never anything like a 'rule' and plenty of articles much longer than that. Overall I'd say it depends on the topic and structure. If there is a sub-section which can reasonably be split out into a separate article of decent size then it makes sense to do so. --CBD 00:36, 2 November 2007 (UTC)[reply]

Thanks... yeah, I'm thinking of a three-fer, one of minor characters, one of historical, one of main stay repeating characters in the series. First comes building it then splitting may make sense. Point was 80k is barely openers, this might go 4-5 times that if it were inclusive. (I figured you all might have had some ceilings you hit with the JRRT universe, so thought I'd ask. // FrankB 00:44, 2 November 2007 (UTC)[reply]

Arrggghhh! Multiple self-reverts resorted to here!

1. Template:Tt0(edit talk links history) rev ver of Template:TOCnestright(edit talk links history) worked okay, I thought...
2. as evidenced on anther page in preview. After testing and "blessing" said change I installed as new TOCnestright, but spot checks show
   1. Failed badly on Austria (edit talk links history), where went from proper flow around to the big fat sucker now there (That's now looking at tt0... other pages see old version of TOCnestright.)
   2. Think I saw (maybe not also--could have just been pages with long title lines) other fat versions, in small sample of other pages before I got back to Austria as last test--where I'd seen my first try spitting out the "... formating ..." of the div block. (Which fix is apparently not a fix when limit is specified!)
   3. The problem is how the class is rendered apparently, in conjuction with 'limit' if block (?) ({{TOCnestright|maxwidth=220px|limit=2}} extracted from Austria), or nesting issues involving the class prefixing the TOC magic word; and you know what I don't know about class!
   4. I left a note in Austria that the change was tmp. Link set above.
3. Also it occurs to me now, my test of Tt0 was in preview only... might be problem shows only after ???
4. I can live without the prependinside= param, if we can't work around the flow it introduces. Have a definite case where appendinside= would help the page layout. (which is why this even came up again!)

• I'll add an appendinside to John II Casimir of Poland, also with tt0. [The pic captioned, "John II Casimir, painted by Jan Matejko"]

In the meantime my virtual mem is low, and I've pages that need close, etc. Thanks! // FrankB 18:28, 2 November 2007 (UTC)[reply]

---

2) While I've got your expertise, what happens when I purge cache using [CTRL]-[F5], in particular, will that risk or affect open edit pages in php previewed changes? Or is it safe? //FrankB 18:36, 2 November 2007 (UTC)[reply]

Complaint couched as a suggestion: How about adding your sig under your (eom) taglines. Just indent ":~~~~" will doooooo, so we have a date reference... I just got faked out by another post thinking it was you on the above. (can u tell I'm still having keyboard issues--the upper row is temperature sensative and sometimes won't work, then other times will finally respond with a splurt of whatever I'm hitting hard! [I'm on my deck---Brrrrr!] ttfn // FrankB 14:18, 3 November 2007 (UTC)[reply]

• Table of contents problem was caused by lack of a space between the style and class settings. The results of ctrl-f5 would depend on browser and site you are viewing, but is definitely not 'safe' for retaining unsaved changes. By design that is supposed to revert back to what the page showed when you loaded it. --CBD 18:16, 3 November 2007 (UTC)[reply]

• OKAY-- what I thought on the cache. Firefox--any idea how I can convince it to hang onto a longer stream of things mid-edit status... seems to drop about 32nd page last visited, which is costly if I get side tracked in something I need to do a lot of preview checks on... Also, would be nice if it didn't put edit pages in the History, just regular urls. Thanks on the fix. I added to my virtual memory and the cache size, but I was running real slow there for a while.
  
  Amazed I am, cleaned out 1227 things from my watchlist last night. Then edited the raw list mode to just keep article pages... 4586 articles left! Yikes, I do get around some in a slow steady way!

• unfortunately, Casimir's not showing the appendinside = Image change here and no one's changed the pages. It's also using `TT0'. Austria is as it was with your change to Tt0. 1?2?
  • Soooo can you follow that up too. I'll fix up the articles and transfer Tt0 to TOCnestright once you let me know about whether that can work... or not. Thanks2 // FrankB 19:33, 3 November 2007 (UTC)[reply]

• • • Is this what you were looking for? It puts the image inside the same 'div' structure as the table of contents called by the TOC 'magic word'. If you wanted the image inside the table of contents itself that would need to be manually built because 'TOC' is self contained and doesn't have any provision for adding things. --CBD 18:19, 4 November 2007 (UTC)[reply]

Ahem... Damn! The forest for the trees strikes again. Chagrin--my short term memories going faster than I think. Thanks, thought that worth a try since the flow is going around it somewhere anyway, and where it was giving unsightly jogging. // FrankB 18:31, 4 November 2007 (UTC)[reply]

Problem with related question:

1. Given a series of nn templates XXnn and subtemplates YYnn where the XX and YY versions (and for the purposes of this query may be considered mostly identical) are more or less the same lengths and further, assuming use of 5-12 (ii) per nn+ [estimate: nn * (2 or 3)] article pages...
   
   With respect to template pre-expansion limits, would the 'ii pairs used per page' take up more or less memory usage considered versus a single pair of the 'hypothetical' master subtemplates ZZ and (revised and single one of) YY called by the ii XX templates? (models follow below)
   
   1. IIRC, every instance of a template call counts against the pre-expand size, so there would be no benefit in space saving to calling the master subtemplates XX and YY, just causing the question to be which has less code length overall.
   2. I believe comments are stripped out before the saving in the pre-expand space, but can use confirmation!
   3. While the XXnn-->ZZ-->YY scheme would be easiest to maintain, it opens up an avenue for vandalism (or errant template updating) to affect huge numbers of page lines. Please give "Advice on that"!
      
2. Note my concern is more on the long list articles like 1632 characters where the "used count" will be in the hundreds. Tight code is unnecessary on typical pages I would think. (i.e. hundreds of either XX calls will occur per page. Whereas, direct calls to any kind of sub-templates should be darn near zero.)
   

Next

1. Consider the two Template:35TCL(edit talk links history) and the (subtemplate) Template:1635:TCL(edit talk links history) [as the promised models, ZZ and YY]
   
2. See the problem in the examples [link below] and the mysterious failure to treat the 's' param properly in the later... not when given by direct call to {{1635:TCL}}, but only when passed by (shorter named) {{35TCL}} [current 'XX' (or perhaps future 'ZZ') calling template].
   See the section "get CBD to peek", where I've grouped the problem occurrences and contrasted with the "direct call to" performance which work fine. In short, somethings screwy when its used as a sub-template... same case. Same logic used, it just breaks and mal-expands the link it does return.
      [I've confirmed that the call line in question is the first switch's default case of {{35TCL}}].
   
   The section "get CBD to peek" has tests and 'lts edit links' and shows these symptoms:
      1 The sub-T fails to form a link,
      2 and fails to evince the 's' parameter at all as the pipetrick,
      3 but direct calls to the sub-template do work properly!
      4 Note that 's=section' passed via the 'XX' template makes it to the link formation code of the subtemplate YY as it evidences as [[1635: The Cannon Law#section|]]... but fails to act/expand as a pipetrick as well. Whereas, passing such direct to the subtemplate works fine... as can be seen in the body of that test page.
3. Be advised the usage page shown is under revision as these settle out, though mostly accurate.

Put all together, I'm thinking these two could be written/morphed to be ZZ, and sub-template YY in the theoretical issue raised above with the first series of names becoming the XX calling templates for each books case; with a substitution of parameters 'linkname' and 'linkprefix' for "The Cannon Law" and "1635:" respectively auto-generated by the XXnn templates calling the ZZ and through them, the YY templates. But not if 's' and 'p' are failing, for those are needed to link sections on the specific stories in the anthologies article pages, and there are more anthologies than novels to discuss mentioning characters or events! // FrankB 02:38, 6 November 2007 (UTC)[reply]

• Generally speaking, it doesn't matter much if logic is kept in one template, two, or three... when the top level template is transcluded onto a page all of the logic in that template and the sub-templates it calls is transcluded. Where multiple templates CAN reduce the size is if you have lots of different conditional logic. If all the text resulting from the different conditions is kept in one template then it takes up alot of space. If the resulting text is instead split out into lots of different templates and only one of those is called based on the conditions then only the size of the text for that one condition is included... the text in the other conditions is in different templates which aren't transcluded. So, having '35TCL' always call '1635:TCL' results in roughly the same amount of transcluded text as having all the logic in one template would.
• Comments in a template are actually copied down to the target page, though you can only see them if you substitute the template, and thus are included in the transclusion size. Text within 'noinclude' tags does not count towards the final transcluded size.
• When you save a page with [[Link#subsection|]] it doesn't do anything special because the 'pipe trick' with links only acts to deal with 'Namespace:' and/or '(subtitle)' type text. It doesn't know how to evaluate a # character and thus the entire section is improperly formatted and displays as pure text rather than a wikilink. The call to '1635:TCL' only seems to work because the of logic in there; [[1635: The Cannon Law#{{{s|}}}|{{{p|{{{s}}} }}}]]. If 's' is set to 'glop' as in the example then that evaluates to [[1635: The Cannon Law#glop|glop]]... which is a valid wiki link. The call to '35TCL' doesn't work because it sets |p={{{p|}}}... that evaluates to p equal to BLANK, which is different from p being unset. {{{p|{{{s}}}}}} in the 1635:TCL code evaluates to blank if p is set blank, or s if p is not set. Since 35TCL set p to blank 1635:TCL winds up with [[1635: The Cannon Law#glop|]]. Instead of |p={{{p|}}} you probably want to do something like |{{#if: {{{p|}}}|p={{{p}}}}}... to set 'p' if it is currently valued, but not set it blank if it is not valued. --CBD 00:12, 9 November 2007 (UTC)[reply]

Curious and strange see this and it's target page -- how the heck are they different? // FrankB 02:16, 7 November 2007 (UTC)[reply]

• This is most likely caused by characters which look like standard english letters, but have a different Unicode value. For instance, Cyrillic 'е' is Unicode 'U+0435' but looks exactly like normal Latin 'e' (Unicode 'U+0065'). The Mediawiki software recognizes these as different characters and thus they can be used to create multiple page names which look identical to the human eye. --CBD 00:12, 9 November 2007 (UTC)[reply]

• Had a feeling you'd be answering--I saw you playing with comments in your sandbox seeing if you were around. Also figured out the unicode names part after dropping the note.

• Given the above on p and s, apparently I've a space (Blank?) defining p somewhere where I assumed a space was being discarded. I'd had difficulties with if statements in wikilinks too, so in part wrote around that to avoid such and keep them outside [[...]] formulations.

• Extending your point into a redirect for clarification— on always calling 1635:TCL into an extraploation, if the XX template feeds the text, pipetrick, and mode parameters, etc. and is "hung" by the editors; and the ZZ uses a single switch (which would just be a switch on {1} in this hypothetical) parser function so that it switches to one of nn YY templates— do the other branches in the switch (nn-1) which are not needed in that invocation get bypassed, or does the expansion of ZZ take on a more compact form and ignore other parts of ZZ — thus sucking in only the one needed (I'm assuming the YY's are individual permutations of the modes).

• Thanks friend, I note seeing the special archive! I can tidy up going forward! // FrankB 00:56, 9 November 2007 (UTC)[reply]

No, there is no space involved. In 35TCL you have calls to 1635:TCL which include parameter settings like |p={{{p|}}}. The way that evaluates is that if 'p' was set in the call to 35TCL then it is set to the same value in the call to 1635:TCL. However, if 'p' was NOT set in the 35TCL call then it BECOMES set, to blank, in the 1635:TCL call. When 1635:TCL is evaluated it then evaluates 'p' as 'set to blank' rather than 'not set'.

When a switch in template ZZ evaluates to call a single YY_nn sub-template the total size is just those two templates and not any others the ZZ template COULD have called if the parameters caused it to evaluate differently. This is thus smaller than a single XX template which contains the results of all the sub-templates would be. --CBD 11:32, 10 November 2007 (UTC)[reply]

• Seems to me that the glue piece I may need is understanding when in the preprocessing something like {{{p|{{{s|label}}}}}} is actually evaluated and expanded. Particularly in a cascade where one template is defining and passing a value such as |p={{{p|}}}, comprehending when a parameter is inserted in the stream versus when it's just a token awaiting assignment may be useful. I fear I still occasionally lapse and think of these things as function calls, and if the expansion is all on a context sensitive stack pushing and popping as {{ and }}, which is to say, on the fly and in-line, I guess that explains some things. //FrankB 01:12, 9 November 2007 (UTC)[reply]

Per the above, the problem with |p={{{p|}}} is actually that it changes the evaluation of 'p' from unset in the top level template to set blank in the sub-template... regardless of the order of processing. As to the order, my understanding is that parameters in a template or parserfunction call are evaluated before being submitted into the template/parserfunction processing. So, {{templateName|param1={{#expr: 2 * 3}}}} would evaluate to {{templateName|param1=6}} and then do whatever 'templateName' is for. --CBD 11:32, 10 November 2007 (UTC)[reply]

re: No, there is no space involved. In 35TCL you have calls to 1635:TCL which include parameter settings like |p=. The way that evaluates is that if 'p' was set in the call to 35TCL then it is set to the same value in the call to 1635:TCL. However, if 'p' was NOT set in the 35TCL call then it BECOMES set, to blank, in the 1635:TCL call. When 1635:TCL is evaluated it then evaluates 'p' as 'set to blank' rather than 'not set'.

1. Would a change of parameter name (e.g. |pipe= etc. matter in the second template. (I'm gathering no... suggesting)
2. Need to test it {{#if:{{{p|}}}|p={{{p|}}}... }} is needed in there somewhere.
3. I'm also puzzled I haven't seen a problem with 'nn/nonum/nl/nolink' as well. Is there a different evaluation since two parameters are being used to define the one pass through call? That would suggest using a dummy parameter 'x' would cure the problem passing along 'p' and 's' as intended... [...|p={{{p|}}}{{{x|}}}|s={{{s|}}}{{{x|}}}|...]

re: When a switch in template ZZ evaluates to call a single YY_nn sub-template the total size is just those two templates and not any others the ZZ template COULD have called if the parameters caused it to evaluate differently. This is thus smaller than a single XX template which contains the results of all the sub-templates would be.

I find this surprising. Why/how then does calls to YYnn differ, from having each case process and output a desired result? i.e. case 1: a plain link, case 2: the same with italics, case 3: a plain link sans the number prefix, case 4: ditto italics, and so forth. Are you saying if I subst'd a template formulated like that, the only case that gets into the page is that specific case? [I know I've seen some "Xfd if's" substituted (various Xfd templates) leave some residue parenthesies and pipes, but I can't recall whether they had any false conditions still imbedded as well... or such were skipped during the subst/expansion. Alas, my focus was usually on fixing link to page which went awry...but now that I think on it, the resultant code was skipping false cases.

Thanks, for timesavers, this concept has been "costly"! Have a great weekend. // FrankB 14:51, 10 November 2007 (UTC)[reply]

• No, having a different parameter name (e.g. |pipe={{{p|}}}) would not help.
• The nonum and nolink work in 1635:TCL because they use parserfunctions rather than default parameters... {{#if: {{{nolink|}}}|<whatever>}} evaluates to whatever nolink is set to or blank, so nolink set blank and nolink not set from the parent template both become blank, which evaluates as false for the if condition. This differs from {{{p|{{{s|}}}}}} because 'p' set blank causes the 's' to never be evaluated... p IS set, just to blank, and thus that blank value is shown rather than defaulting to s as it would if p were unset. The desired results can be gotten by changing it to {{#if: {{{p|}}}|{{{p}}}|{{{s}}}}}... then either p set blank or p not set would resolve to 's'.
• A single template with the four conditions above would have a 'pre-expand inclusion size' including all four conditions and a 'post-expand inclusion size' including only the conditions which evaluated true. A template which called one of four other templates for the same conditions would have a pre-expand size of the top template and the template it called (thus NOT including the size of the three templates not called) and a post-expand size of only the conditions which evaluated true. Basically, 'pre-expand' size is the total size of all templates called while 'post-expand' is the size of what is left when it has all been evaluated (the same as the size of what you get when substituting). There are limits on both pre and post expand inclusion size, but the pre-expand limit gets hit more often than the post-expand because the results after evaluation of the conditional logic are usually smaller. --CBD 12:23, 11 November 2007 (UTC)[reply]

revisiting this:

The call to '1635:TCL' only seems to work because the of logic in there; [[1635: The Cannon Law#{{{s|}}}|{{{p|{{{s}}} }}}]]. If 's' is set to 'glop' as in the example then that evaluates to [[1635: The Cannon Law#glop|glop]]... which is a valid wiki link. The call to '35TCL' doesn't work because it sets |p={{{p|}}}... that evaluates to p equal to BLANK, which is different from p being unset. {{{p|{{{s}}}}}} in the 1635:TCL code evaluates to blank if p is set blank, or s if p is not set. Since 35TCL set p to blank 1635:TCL winds up with [[1635: The Cannon Law#glop|]]. Instead of |p= you probably want to do something like |{{#if: {{{p|}}}|p={{{p}}}}}... to set 'p' if it is currently valued, but not set it blank if it is not valued. --CBD 00:12, 9 November 2007 (UTC)

Ok, I think I see, I've assumed "|p={{{p|}}}" is the same as "|p=|", but the "Blank" in the left code snippet is defining p, and presumably giving it a value of a null string (whatever storage structure it uses for strings)
   whereas "|p=|" with no expression on the right to eval, is discarded as not defined.
   Further {{#if{{{something|}}}|... is the analog of an assember's IFDEF test, which cares less for the value, only whether some storage exists.

The implication is then that if one is passing a parameter ZZ-->XX-->YY it needs defined checked in XX before attempting to pass it to YY. Otherwise, we get what I've seen. (With a fair amount of chagrin... at the moment, at least, it seems the oddity that burned me with nonum is the same effect once removed in different code. Shhhhhheeeeessshhh! You're remarkably patient with a dummy!)

It raises a couple of questions:

1. How does one code in "Blank" say to trap in a switch case or ifeq?
2. Is it possible to define a parameter within the template where it is used below to test such things as branching in that context (preview)?
3. Add in: If one wants to pass or not pass so many defined or not defined pass throughs, what should be done about pipes. {{!}} between the if's?

As always, many thanks... now I need to cut the gordian knots and do further template work, it would seem. // FrankB 17:06, 11 November 2007 (UTC)[reply]

• The table below shows what a top level template (like 35TCL) will pass to a lower level template (like 1635:TCL) based on how 'p' is set;

	p=42	p blank	p unset
|p={{{p|}}}	|p=42	|p=blank	|p=blank
|{{#if: {{{p|}}}|p={{{p}}}}}	|p=42	|	|
|p=|	|p=blank	|p=blank	|p=blank

• So, if the user called {{35TCL|p=}} (p set blank) and 35TCL had the code |{{#if: {{{p|}}}|p={{{p}}}}} the #if: would evaluate to nothing and leave just the '|' character from outside the if condition... that will evaluate to the equivalent of |1=| (parameter 1 set blank) and 'p' not set at all, which is fine if you don't actually have/use a parameter 1.
• Alternatively, the table below shows what a bottom level template (like 1635:TCL) will do based on how 'p' is set;

	p=42	p blank	p unset
{{{p|{{{s|}}}	42	blank	{{{s|}}}
{{#if: {{{p|}}}|{{{p}}}|{{{s|}}}}}	42	{{{s|}}}	{{{s|}}}

• So, if 1635:TCL had the code, {{#if: {{{p|}}}|{{{p}}}|{{{s|}}}}}, it would evaluate either 'p unset' or 'p set blank' to give the results of {{{s|}}} (s, or blank if s is not set).

1. A parameter can be set blank just by having nothing between the = sign and the next | or closing brackets. That is, {{Test|param=}}, would call template 'Test' with 'param' set blank. So if 'Test' contained the code, Say {{{param|Hello}}} the result would be "Say ". The 'Hello' doesn't get printed because that is the default if param is not set... but in this case param IS set, to blank. Similarly, a #switch statement can recognize a blank value by having nothing between the | and =; {{#switch: {{{param|}}}|one=1|two=2|=blank|#default=default}} would return "1" if param were set to "one", "2" if param were "two", "blank" if param were set blank, or "default" for any other scenario (param unset or set to something else).
2. The only way to test logic in preview is to insert default values... {{#if: {{{p|Example}}}|{{{p|Example}}}}}. The 'Example' default value will cause the #if: to evaluate true and print 'Example'. Of course, this is kind of a pain because you have to insert all the defaults and then take them back out again when done.
3. I'm not sure what you mean by, "defined or not defined pass throughs". Variables? You can do, {{test|{{#if: {{{a|}}}|a={{{a}}}}}|{{#if: {{{b|}}}|b={{{b}}}}}|{{#if: {{{c|}}}|c={{{c}}}}}}}. That will pass a, b, and/or c to template 'test' if they are set. If a were set to "One" and c were set "Two", but b not it would evaluate to; {{test|a=One||c=Two}}. The extra | in the middle there would then evaluate to |1=... setting parameter '1' blank. If none of a, b, and c were set it would evaluate to {{test|||}}... setting parameters '1', '2', and '3' blank. --CBD 17:45, 11 November 2007 (UTC)[reply]

Sigh, and thanks! Got it (for now) I thimk! // FrankB 17:53, 11 November 2007 (UTC)[reply]

Moved from main talk,

now // FrankB 00:41, 22 December 2007 (UTC)[reply]

...rearing up in this edit... Why is this not robust or does it not work reliably? Can it be bulletproofed... I expected the TOC BELOW the pic. // FrankB 22:55, 7 December 2007 (UTC)[reply]

The 'frame' and 'right' parameters of image markup get translated into HTML which includes commands to define how the image should stack with other screen elements. Those settings are over-riding the TOCnestright alignment options. If you remove those two parameters from the image markup then it will be placed as you expected, but the caption will only be displayed as a tooltip. --CBD 23:07, 7 December 2007 (UTC)[reply]

Damn you're fast!... didn't even have time to argue with the old lady! LOL! Guess that explains why some infoboxes use a imagecaption field. What about surrounding it by a span or another div, etc. No, no... from what you said, the problem is the one is inside already... which suggests "doubling the logic" and inserting it AS THE CAPTION... which would be messsy, subject to misconstrual, and probably non-robust and confusing as well... Well, just commenting out the one and adding the caption should work! Thanks! // FrankB 23:24, 7 December 2007 (UTC)[reply]

I have to run down the road, can you improve on {{tt0}} version to pack the right whitespace on BASIC??? ttfn // FrankB 23:54, 7 December 2007 (UTC) Trip canceled... #1 son called and is geting #2 son at work! Yeah! 'Ideas???' // FrankB 23:57, 7 December 2007 (UTC)[reply]

I initially fixed this by just inserting a line break, but eventually noticed that you had 'width=' instead of 'width:' in the style definition on Tt0. With that corrected the old version of the page without the line break now wraps correctly also. --CBD 00:22, 8 December 2007 (UTC)[reply]

You ARE A TREASURE!...I've been doing that 'error' and catching it myself... here and there as well, for quite a well. Add in typo misspellings and forgetting the ';' when needed. Sigh. Though all that/those not as long as I've been fighting my big fat clumsy fingers (my whole computing career... well before... since taking typing in Jr. High, really!), but I sure wish HTML was consistent in using ':' and '=', for I do that gaff alot! In any event, I thought I'd tested that mode before... but apparently NOT well enough. (You've got me looking at source code a lot these days... gives a thought or two on how to step around such problems!) Thanks... as per usual. // FrankB 00:34, 8 December 2007 (UTC)[reply]

Arrrggghhh!

and Duh!

Updated the usage, and realized a max-width parameter inside the table should work to bound the image... but! and so I thunked! ...
    what happens on firefox is the page grows a right margin to give a bottom slider bar... the slider can be moved to see the image plainer, the text stays columnized well inside THAT, more or less even with the TOC itself. IE7 does precisely the same thing. You want to poke around again? That article is the only place that mode is probably used given the way it failed earlier today, so I left it this way... Perhaps a table bounding the image alone??? Other than that, I'm out of inspired ideas... need to fix up some other open pages more. // FrankB 02:29, 8 December 2007 (UTC)[reply]

reverts in between

FYI...

You'll now have to backtrack your fix check to the eariest in this diff. See the cranky note left on my talk bottom (the Netherlands, with love, perhaps?) And he didn't even complain about this page (humming a few bars of me and my shadow..." <g>) Way past his bedtime (and mine!) anyways! Cheers! // FrankB 04:47, 8 December 2007 (UTC)[reply]

What were you trying to get the template to do differently than it did before you moved the max-width parameter? I'm not sure what the intended change is. --CBD 18:08, 8 December 2007 (UTC)[reply]

Trying to bound the image (pic) to a width, any width!!!... The one that fails created a scroll/slider bar on the page (i.e. adjusted width say 135% of normal) so that the text stopped short of the end of the rendered page... and the image "hung over" into that area, albeit, constrained on it's left. // FrankB 18:43, 8 December 2007 (UTC)[reply]

The only way to control the size of an image that I know of is with the size parameter in the image markup itself. Anything else just leaves the image at whatever size is specified and adjusts the frame around it... which either causes the image to pop outside the frame or obscures whatever portion of the image exceeds the specified frame. Thus you'd have to change the image markup in the actual parameter call or add image markup into the template. --CBD 19:24, 8 December 2007 (UTC)[reply]

I was cleaning up a page with lists and thought I'd implement your "column formatting" technique used in 32stories (Template:Top2(edit talk links history).

"Pre" block commented out (later) here

As you can see in {{top/doc}} it fails... (second group of examples, just above "Usage" section title.) I even tried putting a harmless "color call" in the code here and the sourcecode still ignores the style inside the if statement in {Top2}... SOOOOooo Help! (No hurry) // FrankB 16:48, 8 December 2007 (UTC)[reply]

It was a problem with the syntax of the background attribute. Should work now. --CBD 18:14, 8 December 2007 (UTC)[reply]

Thanks... looks yummy there (viewing the doc page direct) BUT! See {{top}} for a whole new sea of side effects! Woops. I gambled on your reliability and put it here too! where it seems to be failing. (doing nothing harmful though... daya think it has to be on a seperate line from {top}???). See 'answering note' on above section too. // FrankB 18:43, 8 December 2007 (UTC)[reply]

I don't see anything odd with {{top}}. Did you mean the text on {{top2}}? That was off because you didn't have a </div> on the template page to stop the column formatting. The usage on the Tor page wasn't working because it was on the same line as the 'top' template... I moved it down a line and it was ok. --CBD 19:27, 8 December 2007 (UTC)[reply]

From the busts out sideways screen (sourcecode)
<div style="float:right; margin: 1em 0 1em 1.5em; ;max-width:200px;">
<table style="border:1px solid black; width:200px; max-width:200px; padding:.25em; margin:0 0 0 .25em;">
<tr>
<td><a href="/wiki/Image:AtariBasicExample.png" class="image" title="Image:AtariBasicExample.png"><img alt="Image:AtariBasicExample.png" src="http://upload.wikimedia.org/wikipedia/en/8/85/AtariBasicExample.png" width="320" height="192" border="0" /></a><br /></td>
</tr>
<tr>
<td>Screenshot of <a href="/wiki/Atari_BASIC" title="Atari BASIC">Atari BASIC</a>, an early BASIC language for small computers.</td>

</tr>
</table>
<br />
<br />
<table id="toc" class="toc" summary="Contents">
<tr>
<td>

Such would mean building this line, n'est pa?

<td><a href="/wiki/Image:AtariBasicExample.png" class="image" title="Image:AtariBasicExample.png"><img alt="Image:AtariBasicExample.png" src="http://upload.wikimedia.org/wikipedia/en/8/85/AtariBasicExample.png" width="320" height="192" border="0" /></a><br /></td>

Note, 320X192 is pic attributes...

inserting <img alt="Image:AtariBasicExample.png" src="http://upload.wikimedia.org/wikipedia/en/8/85/AtariBasicExample.png" 

width="200" height="{{#expr:192*320/2}}" border="0" />

CURRENT CODE: (TOCnestright, reverted by the netherlands dude, apparently)

<div class="thumb tright">
<div class="thumbinner" style="width:322px;"><a href="/wiki/Image:AtariBasicExample.png" class="image" title="Screenshot of Atari BASIC, an early BASIC language for small computers."
><img alt="Screenshot of Atari BASIC, an early BASIC language for small computers." src="http://upload.wikimedia.org/wikipedia/en/8/85/AtariBasicExample.png" width="320" height="192" border="0" class="thumbimage" /></a>
<div class="thumbcaption"
>Screenshot of <a href="/wiki/Atari_BASIC" title="Atari BASIC">Atari BASIC</a>, an early BASIC language for small computers.</div>
</div>
</div>

Looks to me such is possible... (have to run... wife yelling!!!)

might be possible? // FrankB 20:07, 8 December 2007 (UTC)[reply]

That's essentially 'adding image markup into the template' as I was describing above, except that you're adding the HTML that the image markup gets translated to. I'll change the template to accept a resizeable image as parameters rather than in the text string as it does currently. You can revert if it isn't what you are looking for. --CBD 00:30, 9 December 2007 (UTC)[reply]

{{TOCnestright|prependimage=AtariBasicExample.png|width=200px|prependcaption=Screenshot of [[Atari BASIC]], an early BASIC language for small computers.}} will show an example of the resizeable image format. --CBD 01:01, 9 December 2007 (UTC)[reply]

So sorry to miss your first post... I was researching webcites, but here too... Delayed so's to dot my tees and cross my eyes. One less issue on the list. Looks like my original format inTemplate:TOCnestright(edit talk links history)... OIC. OK, I just put it in place on BASIC and looks fine to me. Thanks again. Any joy on the columns issue raised above?

OIC... I don't see anything odd with {{top}}. Did you mean the text on {{top2}}? ---Ans: Most probably,... Template:Top2(edit talk links history)... whatever I saw was messing up the usage on the doc page that gets sucked in on the bottom of {{top/doc}} which could be either (natch). Looked like a valign was going wild, so half the page was overwriting what had been there. A missing close div would make sense. The editor's at Tor Books look great! (So THEY say! <g>) Thanks. From my point of view these were all distractions... one errata leading to another article and to another... I haven't made a single edit ALL DAY I would have thought I'd have been making today. You are a lifesaver in that context! Verrry much appreciated! // FrankB 01:54, 9 December 2007 (UTC)[reply]

Comma Separated List templates (became {{32stories}})

from main talk moved to this archive // FrankB 00:50, 22 December 2007 (UTC)[reply]

Can you direct me to (or write for me) the guts of a template (showing comma list parsing) which will separate two fields of nn (Ten is a realistic max) data pairs.

• This ...

Moved discussion to Template talk:32stories

rather than junk up your page again. You ping me and vice versa. Thanks for the start! // FrankB 19:19, 13 November 2007 (UTC)[reply]

re: I think the 's' links on the Grantville Gazette ones just haven't been updated with the ROF-1 style code. If that's the kind of thing you are looking for then this should work so long as no author has more than one story in any given anthology. I looked around a little, but didn't see any cases where an author had two in the same anthology. --CBD 22:04, 13 November 2007 (UTC)

Wow thanks! That'll work I think. Co-authors may be an issue on some stories, but this is a great start. Cancel that! Co-authors be damned... I was going back the other way, not to the story like this! (Sinuses+Headache! Grrrr)

• You're correct on the updates to the GG's... I'm working the {{Cite GG02}} for a higher priority mod... citing the author of that given story. [see note 5 in 1632 institutions if you like.] Need to unclutter the boilerplate on most of these anyway... most cites are very brief relative to even my shortened outputs. Citing the article backlink in long mode should be enough I think. If someone complains, can always enable more disabled code!
• I'd had more synopses in, but didn't save the edits before they ended up falling off the end of firefoxes edit buffer for php pages... seems to have a limit of 30-32 pages, and if I go through a chain of pages before I back up... lost, like I never wrote it. My cache is set "HUGH", so that's not the limiting factor. Any idea as to what may allow me to keep from having that happen? (All too often, sigh!) IE6 let me keep stuff for months! OTOH, <shudder>! Thanks! I'll take it out for a spin tonight! // FrankB 22:45, 13 November 2007 (UTC)[reply]

• Hmmm, I haven't really tried to keep things open for extended periods like that. You could copy and paste them into a locally stored text file for safe-keeping. Or just prepare them in a 'Sandbox' page of your userspace and save them in whatever state they are when you need to leave the computer for a while. --CBD 05:59, 15 November 2007 (UTC)[reply]

what're you doing up so late! My problem is I chain edit... follow link, see something to fix, preview that, follow on that... repeat a number of times integrating the history things in particular I end up in. Then with multiple browser tabs I sometimes do that in three or four chains trying to finish one set, and get back to what I was doing originally! Ditto 1632... add a short story, check the writer link, add that, which needs a check in another book, or have a template "issue"... which can really eat up preview pages... I'm LOTS better than I was, but I'd put together three synopses in Ring of Fire one night that I lost all off, plus expansions on the two short sections that had prior content. It grates. Mostly I avoid getting burned, but it would be nice to have that old IE6 safety net!

Compare the current {{1635:TCL}} and {{35TCL}} and let me know if it makes any sense to do the XX--->YY--->ZZ thing from the space saving standpoint. I'm thinking I should anyway from the maintenance update standpoint. Opinion??? Those are pretty streamlined relative to the old if version (Latest on that was {{34TGA}} (and friend <G>), and I should update these tomarrow. All the {{32stories}} links I just added won't be working until I do! // FrankB 06:23, 15 November 2007 (UTC)[reply]

Hey Frank. Actually, was up early that day. Had a couple of very busy days at work and was going in at crazy hours. Looks like you got things sorted out though. --CBD 23:19, 17 November 2007 (UTC)[reply]

section archived

Moved from main user talk, same title // FrankB 01:00, 22 December 2007 (UTC)[reply]

Can you take a peek at 1632 writers and see if you can figure why I'm seeing "Template:1632-sectstub, Template:32stories, Template:GG04 (inconsistent-- some section links show as Grantville Gazette IV--wierd!) and etc." It's like I introduced some control characters into the stream ca this edit then perhaps cut and pasted them up higher. Yet, this history shows the sectstub template is unchanged for over a week, and I just added a self test to {{GG04}} which functions properly there, but not on the article! Neither explain why {{32stories}} packed it in either... I'm on vacation and my internet connectivity is really spotty. It took me well over an hour last night to just get enough of a signal (in mid-edit) to finally preview and make the last changes to that writers page... Really puzzled, as the "trashed page" is also showing on this, my wife's laptop... indicating such a contamination as I suggest to the source file. It's like I accessed some secret page mode that shows templates as links, by name, but without expanding them, which by occham's razor, seems to be the only thing that makes sense. One other alternative is I screwed up some syntax in or around the section Virginia DeMarce... regardless, trying to edit wiki under the current communications strength is raising my blood pressure, and NOT relaxing. A history page takes a geologic eon or so to load, and I shudder at what a diff does.

So please fix whatever, and figure I'm outta here until next weekend. Thanks. (At least you'll see your '32stories' was doing a nice job, with a couple of additional changes... turns out the odd 1634: The Ram Rebellion book will be best covered similar to the anthologies, since it is de facto in format, one even if listed as a novel. It has a lot of parents! // FrankB 16:38, 19 November 2007 (UTC)[reply]

The problem is that you are hitting the transclusion limits. When that happens subsequent templates just list out the name like that rather than the results. I'll try to look for ways to cut down the size of the component templates to avoid this problem. --CBD 22:18, 23 November 2007 (UTC)[reply]

• WTF!!! Sigh. Tis but a small page, and at that, a tenth it's likely eventual size...
• what is sucking up 2 Megs of capacity?!!!!!... this looks like it must be the GG... ROF-1, etc and so forth for each occasion, despite the common output pages... somehow in multiple because of {{32stories}}
• THATs the only thing that would make sense. Some kind of recursion, in effect. Looks like a call avoidance of those in your newest 32stories and it's subpage is in order using the switch organization you gave. (I just fixed up one problem set on the sub-page, which worked in the section, then failed when displayed on the whole page. So the problem remains if your diagnoses was correct. I'll proceed on that basis--eliminate all calls to the Series templates GGxx... 34TRR, ROF-X, for a single expansion. FLAG ME DOWN ASAP, if you have a better idea. Clearly this current or the older template design won't work if we're bumping our heads on this—we're barely started on listing writers forsooth! // FrankB 22:20, 25 November 2007 (UTC)[reply]

The change you made to the 32stories/List page reintroduced two explicit calls to the 34TRR template... so each time 32stories was called it was calling that 34TRR template, and each of the sub-templates it called, twice... regardless of whether 34TRR was used. I changed the 32stories template to cut down its size, but that has resulted in two changes to syntax. First, the 'ROF-1=Whatever story' syntax needs to be 'ROF-1|Whatever story' instead now. Thus, the 1st, 3rd, 5th, et cetera parameters define anthologies and the 2nd, 4th, 6th, et cetera parameters define the specific story in the immediately preceding anthology. A side effect of this change is that you can put the anthologies in any order you want or even use the same one several times... which eliminates the need for the 34TRRa, b, c, et cetera options... you can now just use {{32stories|34TRR|Story 1|34TRR|Story 2|34TRR|Story 4}}. I think you are still likely to have sizing problems eventually, though converting single calls in the text to simple italicized text and/or wiki-links as appropriate would definitely help. --CBD 23:26, 25 November 2007 (UTC)[reply]

Damn-- your lapping me! what's the deal? So far as I can see, everythings sucking in the same logic... the YY, and ZZ templates discussed last week, and THAT would be the problem. Thought the solution would be to expand this into inline phraseologies to return, but you've reverted my first fix... see section edit of Eric Flint on 1632 writers, will have similar repeats for Paula Goodlett and Virginia DeMarce in that title. See no reason for you to grunt and grind through such an expansion, but I'll stand clear until you tell me what to do. // FrankB 23:34, 25 November 2007 (UTC)[reply]

Per your concurrent post, I can see that... which is why I was about to expand the case logic to have individual lines like:

|34TRR=[[1634: The Ram Rebellion#{{{2}}}]] (''1634: The Ram Rebellion'')

...

which should fix that large expansion, n'est pas? // FrankB 23:34, 25 November 2007 (UTC)[reply]

Spelling out the text rather than calling the templates would result in smaller transclusion sizes. However, if you look at 1632 writers it isn't hitting the transclusion limit right now. That's because it doesn't have any explicit calls to the various anthology sub-templates... it has calls to {{{1}}}. Since that '1' doesn't get evaluated until expansion the template which it will eventually call does not count against the pre-expand limit. You had put in explicit calls to the '34TRR' template, which were then getting called multiple times and filling up the pre-expand limit. --CBD 23:41, 25 November 2007 (UTC)[reply]

III -- OK, your latest works, sortof... I'd had those indented I think, as I'm planning on "batch handling" some of the stories in that problematic page... hence the x version can still be used to format same. If I understand you correctly though, we'll still be having pre-expansion troubles as this page fills up... which suggests the brute force list suggested above in the preceeding pre-/pre would be the smallest way to write the subpage-subtemplate. Yes? NO? (And I can't blame you for not caring either! <G>) Tell me what to do... I be putty at your feet massa'! // FrankB 23:46, 25 November 2007 (UTC)[reply]

Based on the template's current size I'd estimate that it would break down somewhere around 30 authors... not considering the impact of other templates used on the same page. Having the 32stories template insert wikilinks and text rather than calling the various anthology templates (which then call 'Comsubtemp' and 'Comoutput') would reduce the size to the point that you probably wouldn't need to worry until you got up to a couple hundred authors. --CBD 00:02, 26 November 2007 (UTC)[reply]

OK, it be a comfort to know my instincts are still working okay. I'll expand it mindlessly once the Pats are up forty or so! <G> Thanks. Didn't know I was throwing you a bunch of breaking balls the other day, but I'm glad I got you involved.

What kind of expansion hit are we getting on the generic templates... Now you've got me concerned on 1632 characters... and that may require writing a set we can substitute! Is the pre-expand limit still 2 Meg? It boggles the mind this little page ended up with that sort of overhead.

Also strikes me as perhaps worthwhile to inline expand the {{top}} and {{bottom}} calls... you stepped around {{middle}} with some of your HTML magic ju-ju voodoo... but I figure we can trim down the formating to a mininum for a smaller footprint yet, and trimming out the inline comments will have a similar benefit... especially in the YY/ZZ subtemplates. You don't happen to know of a windows text editor that will process newline wrapping for general searching and replacing? That would be handy. I had one years ago on a non-IBM version of DOS-2, and before that on a PDP-8 (11? was an embedded system way back!) and DEC-10 (iirc), whatever. Something that allows changing the escape characters on the fly would be great.

BTW- This will do, more or less... as will the two sections following: 1632 writers#Flint, Eric. I'll just have to give them some consistent styling. Thanks! // FrankB 00:39, 26 November 2007 (UTC)[reply]

The pre-expand limit is still 2 meg and a single call to 'ROF-1' and the like is a little under 7000 bytes... so any given article can have about 300 calls to these templates. Unless some of these pages are going to be really big I'd think that should be plenty. Microsoft Word can do searches including newlines, tabs, and other control characters. I've also used an application called 'Textpad' which has similar capabilities. I don't know of any other Windows editors for this offhand, but I'm sure some are available. --CBD 23:43, 26 November 2007 (UTC)[reply]

WORD! My word! Who'd a thunk using a memory hog like that for simple text editing! OK, I'll have to try that with open office's "writer" ... 7K is a bit fatter than I'd hae guessed.

I gotta get out of templates tasks though, despite the below—so looks like the magic words string lack calls for a rethink on that one. Thanks! // FrankB 12:17, 27 November 2007 (UTC)[reply]

re: this stub in and http://en.wikipedia.org/wiki/Help:Magic_words... Is there any way to select just the starting char or nn chars of an template parameter? The first link 'template:mag' represents a magic word I thought existed. The paragraph shown should explain the intent... figured to index 1632 minor characters alphabetically by first letter, or perhaps if some span of the alphabet was "busy", by a three letter section title. My options are? (No rush, I'll just add them to 1632 characters for now -- the scheme is to use semi-colon prefixed titles no matter where such are added.) // FrankB 20:29, 26 November 2007 (UTC)[reply]

There is a StringFunctions extension which can do this, but it has not been installed on Wikipedia. There are 'ucfirst' and 'lcfirst' magic words to set the first character upper or lowercase, but nothing currently available on Wikipedia can separate out a portion of a parameter value. --CBD 23:52, 26 November 2007 (UTC)[reply]

Can you think of a way to get "__TOC__" into a 2, 3, or 4 column mode of display? Some of the formatting you put into {{32stories}}, perhaps? my try shoplifting THAT fails here, but I really don't know the interactions involved. Since THIS clearly won't do, I'll try something else [Did... I'll leave that for now--it's good for a laugh and doesn't hide anything at least! <G>], but if you can figure a way, this would be a good page to have a three or four column TOC. // FrankB 13:55, 27 November 2007 (UTC)[reply]

I've been fighting with this a bit and not having much luck. Something like <div id="toc" style="-moz-column-count:2; -webkit-column-count:2; column-count:2;">__TOC__</div> should work, but I can't find the right CSS declaration to impact just the list of sections rather than the whole table. The problem is that the table of contents CSS is defined at a higher level than MediaWiki:Common.css. I can probably track it down, but any special class to adjust this CSS would need to be defined at the Common.css level at the least... which would probably be difficult to get consensus on for a single page. The only other thing would be to manually build a TOC with something like Template:OnelinerTOC. --CBD 23:15, 27 November 2007 (UTC)[reply]

Thanks... just stumbled on {{TOChidden}} following your lead to Oneliner... Would what seems to be the "active template" here be a way around the .Css issue? I'm refering to ... {{MediaWiki:Toc}}</b>MediaWiki:Toc (edit talk links history) which is surprising in contents... errrr, ... lack thereof! Ahem! I've no clue as to what is going on there!!! Yikes. Magic!

In any event, I'm not thinking advocating a css change would be an optimal political solution... though I'd be surprised my three list articles would be the only beneficiaries were the facility available... 'I'd think instead 'most' list articles could use the tech... at least until I see it and dislike what I'm envisioning! [Figure both the historical characters article once split out, and the 1632 writers would probably benefit on my needs.] Note the change I made earlier today to {{32stories}} to enable a single column and or crunch the columns over (width+width2) to avoid the writer's TOC—which brings up the question as to why two HTML box structures were able to interpenetrate, one overwriting the other...? In any event, both features are currently on the writers page and got around the issue in several zoom levels.

On further mature reflection, frankly, I've seen a few articles with lengthy involved TOC's that would look better with a TOC "Section" as well, vice the long assed thing with the ugly whitespace... one of the reasons I wrote {{TOCnestright}}, which is a solution if the TOC titles are narrowish, but which can be problematic when they aren't. (One guy on Romania told me it was "ugly"... despite him being the one who hung eight and ten word section titles on the page!)

...Back to 'Stories' to finish... I think when I redo the under-template I may go with anthologies abbreviations "(GG-VII)" vice full titles like (Grantville Gazette VII), then no matter how long the story title, the hang over should stop short of the TOC if it stays long and right. How much you want to bet someone will tell me such abbreviations are unencyclopediac? Sigh...

The Template:OnelinerTOC certainly anticipates my "Plan B" thinking though, so if you can't crack the problem without the css change, perhaps that's the way to go. In the meantime, I think I'll (call it serendipitous discovery of a "Plan C") try the {{TOChidden}} or a left hand sided option of it as a way around the whitespace issue. In general, the way I've set up the various {{16char}}/{{16CHAR}}/{{16writ}} links, most times, people will be visiting the page by reference "Clicking" from those, so they'll not see a TOC as they jump to section anyways. Those that do, can pay the price of seeing the extra whitespace! (Sensitive, ain't I <G>? [Beats spending all my time maintaining templates when I've so much material to put up!]) If you do pursue the matter, let me know. Thanks as always. // FrankB 00:36, 28 November 2007 (UTC)[reply]

The {{MediaWiki:Toc}} is just transcluding the word 'Contents' onto the page... that's the same text section displayed at the top of every table of contents. If MediaWiki:Toc were edited to say 'Frogs' then every table of contents would have 'Frogs' at the top instead of 'Contents'. You'll notice that 'TOChidden' ends up showing the 'Contents' title twice. This is because the __TOC__ is defined in the actual mediawiki code. A CSS change to do multiple columns would need to be made here or possibly even in the developer code. I've tried messing around with the available TOC related CSS classes and only a couple of them are set up to adjust things 'inside' the __TOC__ section... basically you can mess with the numbers, the level of titles which are displayed, and possibly the color... but not anything else. <div id="filetoc">__TOC__</div> produces some column-like results, but is messy and not configurable in any way that I can see. --CBD 00:55, 29 November 2007 (UTC)[reply]

Yeah, that's pretty much why I was surprised. http://en.wikipedia.org/skins-1.5/monobook/main.css is above my paygrade, I'm afraid, though if you decide the list article benifits in general are worth preceding with the politics, you can count on my endorsement. At the moment, I've got enough politics on me plate from deleted articles that no longer support 1632 text links. (See discussion above your last on my talk... two articles apparently got in the cross-fire of Webpage notability guidelines. Why some piss-ant high school in stick-in-the-mud can have a page, and a webpage that has been producing best sellers can't is beyond my comprehension!) Cheers and thanks! // FrankB 19:05, 29 November 2007 (UTC)[reply]

this section

moved from main talk // FrankB 01:06, 22 December 2007 (UTC)[reply]

See unilateral page move of Template:FixBunching, which I agree has some virtue as a "purpose oriented" name. In practice, however, the majority of calls are to the redirect (original name Template:FixHTML) as is the usage... If you agree, I think the second (moved to) name ought be cited as a 'alias' and the content moved back to the original name. That makes for a double-move, which only an admin can do.

I even had to add the {R to other template} for the admin which did this unilaterally. I left the FixHTML/doc page open, so a simple move of that with the double swap of the working template and redirect pages will best fix things up, to my mind.

OTOH, it's no big deal either way, but for the fact the extent calls now go through the redirect, and add to the list of templates called at page bottom, which is where I saw the change and went to investigate. Then again, I've just spent time to rework and split out the usage and see no reason to change it further... at least nothing is broken this time <g>... it just seems to me somehow silly that the usage and template now mismatch, and if someone uses {{lts}} in preview, as is my practice to see {{FixHTML}}, then they're going to end up at a redirect page, not the working template. Darn busibodies! Do whatever seems best. // FrankB 18:23, 29 November 2007 (UTC)[reply]

The template should be left at its current location, namely Template:FixBunching. "FixHTML" was an extremely poor choice of names, and hopefully in time people will transition to the name "FixBunching". The old "FixHTML" still works perfectly well, nothing is broken. —Remember the dot ^(talk) 19:27, 29 November 2007 (UTC)[reply]

Actually, if I remember correctly anyone can move a page back over an existing redirect. Admin access is only needed to move a page to a location which already has an existing non-redirect history. That said, this probably isn't something worth fighting over. It was fine at the original name, but the redundancy and other issues caused by the new name aren't a big deal either. Wait a bit and someone else will probably come along and rename it Template:ArrangeBoxes or something. --CBD 22:39, 29 November 2007 (UTC)[reply]

• LOL -- too true. Particularly about de fight. So where's R-Dot get off making such a judgmental pronouncement. Shrug. Takes all kinds. Cheers // FrankB 23:45, 29 November 2007 (UTC)[reply]

(replying to message on my talk page as well) - Ah, well you have a point about my failing to update the template's documentation to reflect the new name. Sorry about that. As for {{R from other template}}, it's not particularly critical that this be applied to every redirect. I didn't even know this template existed. In any case, I'm glad that there are no hard feelings about this. —Remember the dot ^(talk) 05:29, 30 November 2007 (UTC)[reply]

Section from main user talk

Moved here ... FrankB 01:22, 22 December 2007 (UTC)[reply]

I'm 'refreshing' looking at source code and pre-expand sizes... dealing (eventually) with {{32stories}}, but first wanted to systematically examin what is causing size fattenings, so to speak. Since I like to pad with inline comments... I figured the lost production time would be worth the education time invested... but then comes a head scratcher...

In the following, sole change impacting numbers is using GG01 vs. ROF-1 vs. ROF-2 as the called template being contrasted with the others...

Take a look at the progression on {{tt0}}... I magically picked up 357 bytes post expansion simply by changing '1' to '2', which was from a "Packed template" (whitespace and comments minimized) to a "Formula template" (Not trimmed down).

HEAD TO HEAD

1. Template:ROF-1(edit talk links history) (packed down earlier today)
2. Template:ROF-2(edit talk links history) (left alone as was... should have been a close clone copy of the parent!)
3. Now the one template [{{ROF-1}}] has (anthology) in the article title and the template has to use a bias on the pipetrick to display Ring of Fire (anthology) as Ring of Fire, but dang if I can figure out how that would add up to near a half K difference in sizing. Repeat, the unpacked template shows up as being smaller in post-expansion size. Worse, it's like creating energy... you want to be able to repeat such effects.

Can you explain where that change is happening? [I'm going to go rewrite 32stories brute forcing the outputs, or that writers page is never going to work out. That'll give you time to look at this before I return to pack {{Comoutput}} and it's friend and caller {{Comsubtemp}}]. // FrankB 23:27, 1 December 2007 (UTC)[reply]

Keep in mind that the 'post expand' size includes Comsubtemp and Comoutput. The booktitle of ROF-1, 'Ring of Fire (anthology)', is 9 bytes longer than the name of ROF-2. Thus, every time that parameter gets used in Comsubtemp and Comoutput a call to ROF-1 is going to be another 9 bytes larger than a call to ROF-2. Likewise, ROF-1 will set 'p' to 'Ring of Fire' if neither 'p' nor 's' is defined by the user... whereas ROF-2 leaves it blank. That's another 12 bytes every time the 'p' parameter gets used in Comsubtemp and Comoutput. Those two factors are where your extra 'post expand' size on ROF-1 are coming from. --CBD 02:18, 2 December 2007 (UTC)[reply]

Duh... thanks... there's still something about this process/processing I'm failing to intuitively grasp in analysis, huh. Darn! I'd thought you implied last week if a path were true, that's pretty much what would be "filled in" in the expansion, so I guess I still don't grasp how one can write something so one can save space with the switch—guess I need to revisit that in your archive. But from what you just said, it's (the preprocessing) filling in all the paths during some intermediate processing step, then selecting the path and result... so the bloated and unused parts sum in with the part that gets "fullfilled".

I guess that makes sense, considering some of the unholy messes one gets when substing things. It keeps me off balance though, I'm seemingly never comfortable, so it's hard to be certain that this or that strategy is the best under these or those circumstances. Worse, it's got me so I'm not sure when I should and shouldn't add an if statement to guarantee this or that. Puts a damper on sureness of designs, fer certain... not to mention what it's doing to me confidence and all this while keeping me from adding/editing content!

It begins to dawn that the simpler these typing aids are, the smaller the overall cost. The way they add up in 1632 writers (which is over the limit again, as you predicted, BTW) is certainly worrisome—and I mean by that for the generic articles where one might discuss at some points how different aspects of the plot threads come from this work or that. Additive is additive at xK or so per occurance, a long article, like the series page itself may one day suffer the same sort of breakdown. Better to reset things now before some feature gets used! OTOH, I suspect just trimming out comments in the two subtemplates will have a big impact since those are additive too.

So, I suspect I need to rewrite yet again, limit cases (e.g. throw out the nonum options for openers, ditto the italicized links... really the only two used in any quantity are the italicised non-linked title, and the link form; complicated of course by the section linkto and pipetrick options. In the meantime, I'll do the brute force edit on 'stories' as I've been on family time since my last post to you. Looks like the KISS principle still reigns supreme! Thanks. // FrankB 03:24, 2 December 2007 (UTC)[reply]

This section archived

from main user talk // FrankB 01:28, 22 December 2007 (UTC)[reply]

endgame issues

FYI I did a lot of incremental testing and documenting of effects in {{32stories/doc}}
and Template:Tt0(edit talk links history) + Template:Tt1(edit talk links history)

1. Suggest you review the pre-expand/post-expand trends and results in the /doc for future needs... the point being the cost of using the morphed Doc Page Pattern method into the template set {{Documentation}} and the subpage template. Since there seems to be a body of folks applying that green page usage technique (set) to various template usage pages, I'm willing to bet someone is going to hit the pre-expand ceiling from a combination of such pages going forward. Other than that, is NBD, so FYI to be on guard and alert.
2. Don't invest much time, but I'm curious at the nets which show post-expansion size increases after moving out documentation... which is reflected in the numbers in multiples as well on {{tt0}} for those cases (3 most complicated to date) and the samplings I made on 1632 writers.
3. The puzzle I need help with is why the redlinked templates GG01x, GG03x, and ROF-1x (others???) are manifesting on tt0 at all, or ever given the current 32stories/List version in {{Tt1}}, as seen in previewing the page in tt0.
   
   For what I can see, the case is handled, and should not be manifesting as a template. At least as puzzling, is that the uses seem to be included in the formatted tables and displaying properly in the three test cases on/in tt0.

Don't you just love it when causality seems to be violated?

More FYI: I also trimmed down and simplified the Comsubtemp and Comoutput templates with parallel changes in the two 'lead' calling templates, and netted some nice diet effects; wish I could slenderize my waist so fast, you betch-ya! // FrankB 18:53, 2 December 2007 (UTC)[reply]

Note: with the reentrant form of this now, I figured on collapsing these all in case |x|X= in

<!--
-->|ROF-1x|ROF-2x|GG01x|GG02x|GG03x|GG04x|GG05x<!--
-->|GG06x|GG07x|x|X|34TRRx={{{2}}}

once I have time to clean up the calls in the writers page. It just occurred to me that this may be an effect of no if statement in Template:32stories(edit talk links history), but I didn't think so ca. 3am! ... I gotta do some RL things for a while, as the stormy weather you're having is due to hit here tonight. later! // FrankB 19:03, 2 December 2007 (UTC)[reply]

• I looked at {{32stories|GG01x|Whatever}} and it is doing what I would expect based on the logic in {{Tt1}} and {{32stories/List}}... it just displays the contents of the second parameter rather than a specific wiki-link and text. That's because all of those parameter values ending in 'x' are set '={{{2}}}' in the logic.
• On template size changes; have you tried using Special:ExpandTemplates? That will show you what a template call is evaluating to 'post expansion'. --CBD 20:26, 2 December 2007 (UTC)[reply]

Too much info? Look at Tt0 in preview... after the edit window... i.e. the list of templates at the bottom is showing two of those three (Add 34TRRx) as redlink calls.

I agree and reported, they seem to expand properly, otherwise near half the lines in 32stories under Eric Flint (the largest of the three) would also be missing... that's the mystery, why redlink AND also 'working' as expected ... the causality violation crack!

I can never get the special:ExpandTemplates to do anything much that's useful. There must be some trick to defining a parameter or parameters that I haven't mastered (I know we traded emails on that, but I never did get anything done with parameters using it), and... if you can't feed the beast, you can't tell much save that it has stripes and doesn't leave garbage characters cluttering up the floor, ceiling and wall.

Fixing "nesting 'parsing problems'" is about the only thing I've been able to get done with it. With scant success with it, remembering it's name quickly becomes problematic... I did try it for a few weeks though... a lot with Interwikitmp_grp and Interwikicat_grp development... but that's nine months and such ago... ancient history! If you can tell me how to define some parameters so I can test logic... that would be a really good thing!!! Cheers! // FrankB 01:54, 3 December 2007 (UTC)[reply]

• Ah, got it. I was looking at the preview itself rather than the list of templates used in the preview. The redlinks are coming from this part of the switch;

|GG08|GG09|GG10<!--
-->|GG11|GG12|GG13|GG14|GG15<!--
-->|GG16|GG17|GG18|GG19|GG20=<!--
-->*{{{{{1}}}|s={{{2}}}}} ({{{{{1}}}|o}})<!--

• Since Template:32L gets called all the parameters passed to it are evaluated and the last line of that above evaluates to *{{GG02x|s=Testing}} ({{GG02x|o}}). Since the switch does not evaluate to that line it doesn't actually get displayed, but it still gets listed as a template referenced in the page logic.

• As to ExpandTemplates... it doesn't handle parameters when you try to paste 'template code' into it, but it works fine with calls to templates. For instance, putting in, {{32stories|ROF-1|Testing}}, produces;

''Series short story contributions:''

{| border="0" width="100%"
|-
|bgcolor="transparent" valign=top width=48%|
{|

<div style="-moz-column-count:2; -webkit-column-count:2; column-count:2; background =transparent;">
*[[Ring of Fire (anthology)#Testing|Testing]] ''in ROF-1''
</div>
|}

• You can also subst things, but that doesn't expand multiple levels the way 'expandtemplates' does. --CBD 23:33, 3 December 2007 (UTC)[reply]

re: your answer

On 1, then gotchya: "no worries mate"

On 2, I'll have to try that as a debugging technique (obviously)... generally, I perceive a need for one, generalize the need (as needed), then use the initial occasion to debug by the case in point, so to speak. Since any malfunctions affect only the one or few places where its used... it's worked out. Gotta run. Thanks. // FrankB 00:05, 4 December 2007 (UTC)[reply]

from maintalk section

by same name... moved here // FrankB 15:40, 3 January 2008 (UTC)[reply]

AFAIK, sometime in the last year, some url command strings to the system changed syntax. OTOH, perhaps my memory is off.

At issue is whether one can still compare two pages with a different BASEPAGENAME.

http://en.wikipedia.org/w/index.php?title=Template:GG02&diff=&current&oldid=177990250 SHOULD have compared the new content in Template:GG03(edit talk links history) [ID: 17799902 ?] with the "just updated" Template:GG02(edit talk links history) "current version", or at least I think that would have worked with the old syntax... &current, I thought had been the key... Do you have a insight into the new sytax such that you can you write a generalized template that will take two page names (akin to {{las}}, where one can specify a namespace prefix "Template:", "Category:", etc.) and an template-template or switch selected version (C==cats, T=templates, or such like) that could allow a quick check on previewed pages.

Or is there another, already easy way? I certainly don't see anything in special pages, and how to find any such template in categories... well, where would one begin? Advice? // FrankB 16:08, 15 December 2007 (UTC)[reply]

FYI

http://en.wikipedia.org/w/index.php?title=Template:GG02&oldid=178085476&diff=&oldid=177990250

also fails.

http://en.wikipedia.org/w/index.php?title=Template%3AGG02&diff=178085476&oldid=176310686

the working self-diff to last version... suggests the modifier/specifier... "&current" is no longer functioning??? // FrankB 16:15, 15 December 2007 (UTC)[reply]

Hmmm, I've never tried messing with the URL to get it to compare two pages. What I usually do when I want to check something like that is open one page for editing and copy the whole thing, then open the other page and paste the other page in... then you can just click the 'show changes' button to see the differences between the two. --CBD 23:18, 16 December 2007 (UTC)[reply]

WOW! Something "obviouslicious" I'd tried and you didn't... who'd a thunk! LOL.

The key maybe in the syntax and command word syntax the system accepts in the url... "&action" words such as &old, &new, &current.... etc. and whatever (and whatever they be called!)... you know computers... they do exactly what you ask for... so the question devolves to is there guidance on such string commands, I suppose??? I may have an old diff command or two embedded in one of my old user pages... I can look, but I do recall some syntaxes changing in the url too.

Took some time and tidied up a bit up above. Don't think I missed anything long and technical, and the rest seems to me should stay in place. I'm feeling like crap "energywise" tonight... gave me a chance to see if this repaired laptop is working okay. My office may not be available before the newyear. sniff, sniff! Have a good weekend! // FrankB 01:44, 22 December 2007 (UTC)[reply]

Look what I found...

http://en.wikipedia.org/wiki/Help:Diff#URL

Bingo!!! ... But title and current seem busted...

t'was easier before

http://en.wikipedia.org/w/index.php?title=Template%3AGG02&diff=178085476&oldid=177990250 // FrankB 02:13, 22 December 2007 (UTC)[reply]

above archived today // FrankB 15:40, 3 January 2008 (UTC)[reply]

... Or why the heck does this work in eight or so templates and fail in twenty others! (give or take)

1. Before I go through another round of twenty updates, I would really like a reason the [seemingly equivalent] logic fails/works in the GG templates vs the novels templates.
   
2. FYI, Template:1632 series templates usage1 is written to show the tests of the current template page "PAGENAME", so shows all modes of a template when viewed... it is common to all these. The dynamic test codes show in the little greenish table inside the bigger one.
   
3. The problem... {1}/arg-1 not being passed to {{comsubtemp}} in the GG## templates, but works fine in the ##XXX main works templates such as 34TBC, 34TRR, etc.
   
4. Investigating observed failures in GG01... template Talk:Tt1 has a succession of tests with the last two of telling interest. In the later notice I annoted that I had to hand edit in the line that is not robust, and failed... an if statement test to pass param {1}... The added place can be seen in the last diff on that talk page. To summarize: the code of the switch in the subst'd Comsubtemp had no parameter defined in the switch, Adding {{#if:o|o|}} restores it to function properly, as the talk page currently shows.
   
5. Here's the beginning of a succession of edits to Template:GG01(edit talk links history). Note in the 3-4 summaries... coming forward in time:
   
   1. The first change adding {2} test was a mistaken recollection... and has no bearing.
      
   2. Note intermediately, I even hand copied the equivalent coded line from t working template '34TRR' to the failing template, which proceded to still fail!.
      
   3. Before posting you on this— in desperation, more or less seeing that the subst (for comparison) sequences of '34TRR' actually included the "if test" through to {{Comsubtemp}}—lastly, I altered the failing template to omit the overt "|1=" and try it as a simple place/order pass parameter... which works!
      
   4. So why A) did it and does it fail in the template majority population, and why does it work at all in the novels versions and why the heck when I copied from one to the other, did it still fail!!! (This stuff will soon drive me to drink!!!)
      
6. Advice or troubleshooting of cause needed. I'd have thought the "|1=if test" was about as bullet proof as I could have or get...

Harumph! // FrankB 19:03, 17 December 2007 (UTC)[reply]

I'm really not sure what you are trying to do. For instance, {{#switch: {{#if:o|o|}}. What is the goal of that? It is effectively identical to {{#switch: o... which will always evaluate to whatever the 'o' value of the switch is... removing any need for the switch in the first place.

The other bit of code you were pointing out; |1={{#if:{{{1|}}}|{{{1}}}|}} will set parameter 1 of the called template equal to either the value of parameter 1 of the calling template (if it is set to a non-blank value) or to blank. Setting it blank will cause any {{{1|Text}}} used in the called template to evaluate to blank rather than the value of 'Text'.

Removing the '1=' and using just {{#if:{{{1|}}}|{{{1}}}|}} will evaluate to {{comsubtemp|}}.
   Theoretically, that | character should be the start of a parameter and, since it is unnamed, automatically assigned to parameter 1. However, since there is no value between it and the closing brackets the parser instead treats it as just an extraneous pipe and ignores it...
   which causes parameter 1 to be considered UNSET, and thus evaluates {{{1|Text}}} to the value of 'Text'.

If you used {{#if:{{{1|}}}|{{{1}}}|=}} the '=' sign at the end would result in {{comsubtemp|=}}, which would set parameter 1 to blank and lead to no 'Text' in the called template. --CBD 13:30, 22 December 2007 (UTC)[reply]

Another misconnect... http://en.wikipedia.org/wiki/Template_talk:Tt1, "the" {{#switch: {{#if:o|o|}} was substED inTO what showed up in the subst of the second stage... which was switching on NOTHING, EVEN WHEN O OR o DEFINED in and to the if statement in GGXX (Look at any GGxx templage above GG03, the tests in the usage table should show the problem, e.g. {{GG04}} a link is generated, not the italicized book name string.

The alarm bells ring from the inconsistency in the IDENTICAL LOGIC... even after I cut and pasted in the identical from a novel template (34TRR?) when called in novel mode... worked/works fine. If you survey those using the same test look in the usage, they are uniformly all working.

The trouble/inconsistency is manifested in the trans-stage, ({{comsubtemp}})... A) defining {{{1}}} as |1={{#if:o|o|}} did not work correctly in the GGxx templates (The diff chain cited above to follow) yet does in the 34XXX templates, whereas relying on the place holder definition like {{GGxx|{{#if:o|o|}}|Arg2|Arg3}} does!!! (allowing for the fact there is usually NO Arg2 or Arg 3 passed from any GGxx template to comsubtemp.) Specifically, the edits 1 2 raise me eyebrows...

1. not least because it's a direct cut and paste of the working code from {{34TRR}}...
2. ... because I can't comprehend why the two are not identical in behavior, or effect... and your explanation above only sheds light, perhaps by suggesting the one defines a 'blank' (by which I believe you mean a Zero length string, iirc) but the other, the last pipe is apparently ignored, and does not... which is the very inconsistency that alarmed me.
3. Given what you say about the "trailing pipe", and the "unreliability of it when cut and pasted", looks like I should perform the equivalent edits to all as this one. Having the succession (group of) of trailing } chars is a small price to pay if the "else pipe" is going to cause a define (your blank, I presume) when I expect an undefined condition and test! If your advice is otherwise, given robustness and reliability being key, let me know ASAP! Thanks! // FrankB 21:27, 23 December 2007 (UTC)[reply]

Ok, I tracked it back and fixed the examples. The problem is that you were defining parameter 1 twice. The |1= set parameter 1 to whatever. However, then at the very end of the template before the closing braces you had another |... which was defaulting to parameter 1 again and over-riding whatever you originally set with a blank. When you changed '|1=' to just '|' that became parameter one and the extra pipe at the end then becomes parameter two rather than resetting 1. Just removing the pipe at the end fixes the problem. --CBD 16:16, 24 December 2007 (UTC)[reply]

Above archived today // FrankB 15:54, 3 January 2008 (UTC)[reply]