Template talk:Hcard-bday

Problem with vertically-formatted parameters

The vertical example simply does not work. I believe this to be a problem with {{Birth date and age}} rather than this template per se. — SMcCandlish [talk] [cont] ‹(-¿-)› 12:42, 24 July 2007 (UTC)

Which example? They're all working, for me. Is it a skin issue? Andy Mabbett | Talk to Andy Mabbett 12:53, 24 July 2007 (UTC)

I use the default WP skin. This example:

lorem {{hcard-bday
|Tim Berners-Lee
|birth date and age
|1955
|06
|08
}} ipsum

is producing:

Lorem Tim Berners-Lee ([[June 08 ]] [[1955 ]] (age 52)) ipsum

And I don't mean it is producing that wikicode, I mean it is producing that rendered output; the [[...]] markup is being escaped, and note also the odd extraneous spaces in there.

This can be seen live at User:SMcCandlish/Sandbox. Putting the parameters all on one line causes it to display correctly. — SMcCandlish [talk] [cont] ‹(-¿-)› 13:19, 24 July 2007 (UTC)

PS: It is quite clearly turning the line breaks into additional spaces that do not belong there; unless there's a clear way around this, the vertical format should be abandoned. It works fine with things like {{WPBiography}} because the parameters are parsed as conditional options, not as text to echo back out. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:27, 24 July 2007 (UTC)

Reformat for consistency, grammar

This template should be redone to use the small, bracketed super-scripting of virtually every other inline annotation template on the system. As for consistency, the template as it stands right now produces ungrammatical output: "Tim Berners-Lee (08 June 1955 (age 52))". We don't use paretheses inside parentheses. — SMcCandlish [talk] [cont] ‹(-¿-)› 12:42, 24 July 2007 (UTC)

It is intended to wrap existing, in-line text with microformat mark-up. It is not intended to change the appearance of the page. What would you envisage being superscripted? Andy Mabbett | Talk to Andy Mabbett 12:52, 24 July 2007 (UTC)

There's a proposal at Template talk:Birth date and age#use_in_hCard_microformat to merge the functionality of this template into {{Birth date and age}} and {{Birth date}}, so that this template will become redundant. Users will then be able to format the name and birthday elements separately without additional parentheses or forced positioning. The only opposition comes from the creator of this template. --Para 13:07, 24 July 2007 (UTC)

Perhaps I'm misunderstanding something. To my mind this has only one of three possible purposes:

1. Adding microformatted metadata inline into article prose, e.g. taking "...invented by Tim Berners-Lee in..." and doing "...invented by {{hcard-bday|Tim Berners-Lee|birth date and age|1955|06|08}} in..."; if this is the case, then it is like any other inline meta-note on Wikipedia, like reference citations, inline cleanup notes, etc., and should use the format that is almost universally settled on for such things, namely:

...invented by Tim Berners-Lee^{[08 June 1995 (age 52)]} in...

not what it's presently doing:

...invented by Tim Berners-Lee (08 June 1955 (age 52)) in...

Actually, even in this example, it should have a "b. " or "born " in there.

2. Adding microformat stuff to existing birth information in the lead of an article, in which case this template conflicts with the Manual of Style. An article would typically begin something like: Tim Berners-Lee (b. 08 June 1955...), and I can't see how even with modifications this template could easily handle that, other than by adding "(b. " in there, adding the age calculation, as ", age 52", and leaving the close-parenthesis off, because the editor may need to add other information, and would still need to add birthplace manually, in the middle of this, as in: (b. 08 June 1955 in Anytown, USA, age 52...)

3. Adding microformat stuff and an age calculation to an existing passage that already had all of this detail other than current age, as in: ...invented by Tim Berners-Lee (b. 08 June 1955) in.... If that is the intended use, it conflicts with MoS again by just slapping an ambiguous date after the name without "b. " or "born "), and I don't see at all what it is supposed to "buy" us that isn't already provided by {{Birth date and age}}, which can be used inline after one types out the name and stuff: Tim Berners-Lee (b. {{Birth date and age|...}})" (though even this will have the problem of introducing bogus parens-inside-parens; even the BDAA template there needs work). I don't see any microformat stuff, really, just some classes. So, maybe I'm missing something and someone can clue me in if I am. - SMcCandlish

Your concerns seem to be more to do with {{birth date and age}} than this one, which is intended to take existing cases of firstname lastname {{birth date and age}} (of which there are many), and wrap them in microformat mark-up, without changing the visual appearance of the page. AS it stands, {{birth date and age}} uses neither "b." nor superscript. Andy Mabbett | Talk to Andy Mabbett 14:22, 24 July 2007 (UTC)

The BDAA template doesn't use b., and shouldn't since it is not always used inline in this manner; rather, the prose should read "firstname lastname, b. {{birth date and age}}" (even better it would be "firstname lastname (b. {{birth date and age}})", after there is a way to stop making BDAA put the age in parens), otherwise the output of the BDAA template is an ambiguous nonsequitur. I do now see what you mean, and agree that the superscripting isn't needed, because the material in question was part of the original prose, not a meta-interpolation. I do also have some BDAA concerns, though simply adding "b. " to this template resolved many of the overall problems. For article lead usage, we'd need something quite a bit more complex, a bit like an infobox, with all of the necessary parameters; something like:

{{Hcard-lead-bio|name=|pretitles=|posttitles=|altnames=|foreignname=Templates for Chinese, etc., representations go here|bdate=|partialbdate=To bypass the hCard bday code and 'Template:birth date and age' code if we have something like "ca. 1912" or anything else that can't be ISO date-formatted|bplace=|living=Because absence of death date doesn't necessarily mean living|ddate=|dplace=}}

and probably other parameters; would take some substantial research into WP bio articles and what may appear from the opening bolding of the name to the end of the foreign-names-and-birth/death-info parenthetical after the name, all before the beginning of the "is a notable whatever..." main prose. A similar {{Hcard-lead-geo}} would be needed for places and such.

P.S.: The "forced parens" issue with BDAA could be fixed with a simple optional parameter at that template: fmt=comma. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:08, 24 July 2007 (UTC)

Quite a bit more complex indeed... and looking at how many exceptions bio infoboxes at Wikipedia:WikiProject Biography/Infoboxes have needed already, it's obvious that prose can never be "templatised" this way. As seen in the discussion here already, placement of the name and birth date and any words between the two is controversial, and enforcing the manual of style through article review is much easier and more scalable than crafting complicated templates. The proposed change to the standard templates only gives the microformat part of the output an editor defined name, with no change in the formatting most Wikipedia readers see. --Para 19:40, 24 July 2007 (UTC)

The fact that I'm the creator of this template doesn't make your proposal any less faulty. Andy Mabbett | Talk to Andy Mabbett 14:32, 24 July 2007 (UTC)

Merge dispute resolution

Andy and Para, could youse guys summarize what your views on this are, without all the side topics and logic debates this stuff has wandered into, here and on other relevant pages? I'm pretty good at dispute resolution when I put a mind to it. NB: I mean your views about what should or should not be done, not with regard to each other. >;-) — SMcCandlish [talk] [cont] ‹(-¿-)› 15:08, 24 July 2007 (UTC)

I've asked for Image:Names Hcard-bday template bug.jpg, which illustrated the problem, to be undeleted. Andy Mabbett | Talk to Andy Mabbett 15:21, 24 July 2007 (UTC)

If you get any WP:DRV guff about that, you can just e-mail it to me, and I'll put it up on my web host. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:29, 24 July 2007 (UTC)

Thanks, but there was no problem. Compare the (PoV) name in the first line, and the missing name in the third. Para's requested edit also breaks when CSS is disabled. Andy Mabbett | Talk to Andy Mabbett 15:36, 24 July 2007 (UTC)

OK, so the dispute isn't really about whether a merger is possible, it's just about code specifics then?

Andy, you appear to be able to demonstrate that your issues with the code are genuine, but would you be okay with a merge that actually resolve those issues before it took place?

And Para, are do you have any problem with the issues as they've been presented (namely that the third template which I surmise is intended to be a replacement for this template, the first one, and is based on and extends the code of the second one, is not performing as expected? As for the CSS issue, is it something minor like what I was confused about over at {{Birth date and age}} talk? That should be a trivia matter for us to collectively agree on. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:56, 24 July 2007 (UTC)

If the functionality currently in {{hcard-bday}} remains fully available, in a way that works, is accessible, degrades gracefully, and does not encourage bad practise; I'll be content, whatever template produces it. I've never said otherwise. Andy Mabbett | Talk to Andy Mabbett 16:43, 24 July 2007 (UTC)

I am not aware of any issues with the proposed change to {{Birth date and age}} (the second template) to produce the output of the third, CSS or otherwise. I assume the "issue" is the one Andy keeps insisting on, that when data is entered to a template that generates microformat html and uses the entered data, the same data must be displayed on the page specifically from that instance of the template. When the data is something static like a name (which is the proposed additional parameter), I do not agree that it should be displayed there and then, but that editors should be allowed the freedom to place the associated name as they wish, with any necessary words between the name and the date. The template could of course be modified to allow all of that with all sorts of parameters, but I think that would again make it unnecessarily complex for people to use. For the reasoning I explained related to my views below, I would oppose any birth date template that doesn't bring any additional value to annotation of the encapsulated information, be it called birth date and age with name or hcard-bday. --Para 17:50, 24 July 2007 (UTC)

I gather that Andy has demonstrated that your version has CSS problems that cause it to degrade poorly. I'd be utterly shocked if 5 minutes of brainstorming between you two couldn't resolve at least issues easily. I realize you've irritated each other a bit lately, but this would be a good opportunity to let byegones be byegones and do that wiki collaborative thing. :-) Anyway, I can see both points, and would suggest that the default could do what Andy wants, and there could be at least a few options to do what Para wants, and everyone should be happy. That is, there is no actual inherent conflict between "[display the name] there and then" and "editors [being] allowed the freedom to place the associated name as they wish". Or vice versa; perhaps the default would have to be that the name would not be displayed (e.g. because it already has been in the title of the infobox or whatever), but that a simple parameter, like showname=yes (or even the very presence of the name parameter in the first place), would make it do so? I have not read every word of the prior arguments, because they got a bit personal, angry and off-topic, but I'm having a hard time believing this cannot be resolved really easily. I do a LOT of template work myself, when I'm in "full-on Wikipedian" mode, and I've come to the conclusion that very, very few issues raised cannot be resolved. Cf. {{CompactTOC8}} as an example; it does virtually anything (in context) that anyone could want it to, has sensible and no-brainer default behavior, and any missing feature (within sane boundaries) can be added rather trivially. 'Snot rocket science. :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 20:17, 24 July 2007 (UTC)

I haven't seen Andy demonstrate any CSS problems, but if he is worried of CSS, let's correct the CSS. The screenshot above of my sandbox shows the same view as my Firefox does with CSS enabled. When I disable it, it displays like so:

hcard-bday
    Bad Markup, b. January 01, 1999 (1999-01-01) (age 8)
Birth date and age
    January 01, 2000 (2000-01-01) (age 7)
Birth date and age with name
    February 20, 2002 (Better Markup,2002-02-20) (age 5) 

What needs to be fixed in the third template output? I suppose there could be a space after the comma, is that what has been holding things up all along? Or is it the name display issue again? In my opinion a template called birth date and age should not display a name at all. I don't see why someone wouldn't want to obey a display:none rule, but in the rare case that someone would do that, a readable output will be visible. If adding a showname=yes parameter made the single voice of opposition quiet, that'd be great, but later on there will be trouble with such a solution when people start to argue which is more logical to get "Firstname Lastname (born 8 June 1955)", writing "Firstname Lastname (born {{birth date|1955|06|08|name=Firstname Lastname}})" or "{{birth date|1955|06|08|name=Firstname Lastname|showname=yes}}", and then with the showname version finding it impossible to control anything between the elements name and date. --Para 21:25, 24 July 2007 (UTC)

My view is that there should be as few data entry templates as possible, that their standard use should be kept as simple as possible, and that special features such as microformats should be implemented inside the same templates. Everything in wikitext should be about the content as much as possible and not about how it might be presented to the reader, so templates should be designed for annotation, not solely for formatting.

This template is against these views by 1) being an additional data entry template, 2) too complicated to use for entry of simple birth dates, and 3) forcing editors to look at and use output format keywords such as hcard-bday, which should have no place in article wikitext. There are further points in the related discussions, but I wouldn't much enjoy re-reading the debate, so I hope I remembered the most important ones and that this thread won't turn into repetition of the same. --Para 17:50, 24 July 2007 (UTC)

I wouldn't like to see it go that direction either. I'm trying to bring a fresh eye to the matter and look for a clear way out of the forest. Anyway, to examine your points in order: #1 appears to be an argument for merge. For what its worth, I tend to sympathize with that; maybe that makes me a "mergist". #2 I don't quite understand; it doesn't seem any more complicated than BDAA itself, and after a merge I 'magine it would use BDAA's syntax (plus a name parameter). I'm not sure I get #3 either, unless it just means that the name of this template is geeky, but a mutually satisfactory merge would solve that as well. I'd like to hear from Andy what specific CSS or other changes would be needed for him to be happy with a merge (if I may still continue to play moderator). — SMcCandlish [talk] [cont] ‹(-¿-)› 20:17, 24 July 2007 (UTC)

Simplicity: {{hcard-bday|Firstname Lastname|birth date and age|1955|06|08}} vs {{birth date and age|1955|06|08|name=Firstname Lastname}}

Obfuscation: "hcard-bday" and "birth date and age" vs just "birth date and age". The name doesn't tell anything to most editors, is indeed geeky and at a wrong level at that (output presentation instead of information annotation), and does unnecessary wrapping of another template that might as well implement the same functionality of naming the generated microformat. As a temporary solution to a similar geekyness problem I renamed {{Hcard-geo}} to {{Coord named}}, but was reverted without explanation. That would only have solved the naming issue of the template though; the template usage itself would still have been repetitive ({{coord named|...|coord}} instead of just {{coord|...}}). --Para 22:53, 24 July 2007 (UTC)

Sorry; I misunderstood your original meaning. Can you be more specific, and recommending some fixes? I think we've gotten the point that you feel something is broken; its now a matter of unbreaking it. I use Safari, which doesn't have a CSS-free mode, so I'm not in a position to see the problem firsthand, or I could probably just go fix it myself. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:25, 24 July 2007 (UTC)

The fix is to use the mark-up and functionality in {{Hcard-bday}}. Andy Mabbett | Talk to Andy Mabbett 11:37, 25 July 2007 (UTC)

"but was reverted without explanation. " posting [falsehoods] like that doesn't help. Andy Mabbett | Talk to Andy Mabbett 11:22, 25 July 2007 (UTC)

You have not explained this so called consistency. Consistency would be if all hcard generating templates were named hcard-*, or if all templates were named after their type of content. Which in your opinion would be better? --Para 15:44, 25 July 2007 (UTC)

No CSS changes are needed; there are no "CSS problems" to demonstrate; the implementation is broken, and disabling CSS illustrates so. Andy Mabbett | Talk to Andy Mabbett 22:09, 24 July 2007 (UTC)

Ok, so CSS is not the problem then, great. Are there any other problems than the name display? --Para 15:44, 25 July 2007 (UTC)

Nothing to say anymore? I assume we can move forward with the merge then. --Para 15:27, 27 July 2007 (UTC)

The problems remain unresolved, there's nothing more to say until they're fixed. Andy Mabbett | Talk to Andy Mabbett 15:41, 27 July 2007 (UTC)

Please at least answer the questions above, they're very related. --Para 15:43, 27 July 2007 (UTC)

I never said that the CSS was a problem. The template does not include any CSS, so how could it be? There are no other problems, only those already discussed - and still unresolved. Andy Mabbett | Talk to Andy Mabbett 16:25, 27 July 2007 (UTC)

So not displaying the name on the page is the only problem with the merge then? What about the consistency mentioned above? --Para 16:37, 27 July 2007 (UTC)

That's not what I said. There are problems, plural - another being the failure to degrade gracefully when CSS is not available. Andy Mabbett | Talk to Andy Mabbett 16:58, 27 July 2007 (UTC)

What is the problem with the display when CSS is not available? --Para 17:01, 27 July 2007 (UTC)

You didn't make it clear whether you still consider the consistency in template naming to be one of your plural problems. Care to clarify? --Para 21:08, 27 July 2007 (UTC)

AM appears to be stalling. I'm happy to support the merge. -- roundhouse0 17:14, 27 July 2007 (UTC)

"AM appears to be stalling" - that's bullshit, and an unacceptable distortion of fact.

"I'm happy to support the merge" - are you not bothered by the broken rendering?

Andy Mabbett | Talk to Andy Mabbett 18:18, 27 July 2007 (UTC)

You've been asked by several parties now to explicitly explain what "problems" (plural) you have identified, and specifically to ID what you feel to be wrong with the CSS-free rendering (I agree with Para's own assessment that a comma is missing). — SMcCandlish [talk] [cont] [cont] ‹(-¿-)› 00:35, 28 July 2007 (UTC)

I added a space after the comma for the non-CSS display then. Since Andy can't explain what's wrong with the proposed merge and is obviously opposing just for opposition's sake, can we move on with the merge already? The required modification is visible here. --Para 17:13, 29 July 2007 (UTC)

I am not "opposing just for opposition's sake"; your attempts to dismiss comments about the broken nature of your proposal are ludicrous. I can and have explained what's wrong with your implementation - and it has nothing to do with a comma. Try viewing it with CSS enabled. Can you see name? Now try viewing it with CSS disabled. Can you see a name? Does it "degrade gracefully"? Andy Mabbett | Talk to Andy Mabbett 18:01, 29 July 2007 (UTC)

There is nothing broken in it; your attempts to stop the merge just because you created the template and are willing to enable microformats at any cost are ludicrous. When a user chooses not to obey display:none and wants to see elements that are not intended to be shown, the proposed template still degrades gracefully and generates a readable output. There are no problems with the merge, plural or singular. --Para 18:25, 29 July 2007 (UTC)

Your accusations are baseless lies, and your scenario a red herring. You have done nothing to resolve the problems with your proposal. Andy Mabbett | Talk to Andy Mabbett 19:00, 29 July 2007 (UTC)

It is difficult to fix problems when you refuse to explain what they could be, and when you give contradicting "consistency" justification for template naming as hcard and again refuse to explain the sense in that. --Para 19:19, 29 July 2007 (UTC)

Andy, it looks like you are opposing for oppositition's sake, because you aren't making it clear what your issues are. In what way does it degrade ungracefully. Para, I think I do see one of Andy's points - the third example should surely be showing the name. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:10, 30 July 2007 (UTC)

Surely? Why should a template called "birth date and age" show a name? The proposed change to the template uses the name parameter as an identifier for semantic annotation such as for microformats, and with another template for eventual display as a title in map services. It is not an attempt to make article prose templated. The hcard-bday template doesn't allow any freedom to choose the words between the name and the birth date from the manual of style. I notice that Andy has also created another similar template {{Hcard-bday-place}}, which tries to force his preferred formatting. Enforcing the order or formatting of the lead section or any prose with a template is not editor friendly and must not be introduced on Wikipedia. --Para 11:02, 30 July 2007 (UTC)