This is an archive of past discussions about Template:Infobox writer. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I'm looking into adding lang tag validation to Module:ISO 639 name, but it'll probably be some time. (It can be 'improperly' be used for validation by using formal and dataset=iana and checking for output.) — lfdder22:16, 16 April 2014 (UTC)
@Pigsonthewing: So why has this been marked as answered? — lfdder 20:50, 17 April 2014 (UTC) It's not acceptable to reject all codes other than ISO 639-1 until such time that it's 'fixed' (which probably won't be any time soon). — lfdder20:52, 17 April 2014 (UTC)
What part of "consensus should be obtained before the template is added" is unclear to you? You have to stop reactivating this request, per the template's documentation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits14:15, 18 April 2014 (UTC)
You should put some effort into what you write. I thought you meant this template's documentation. — lfdder14:22, 18 April 2014 (UTC)
1) I've removed mention of this parameter from the doc, so that -- if anything -- people don't get tripped up by it in the future. 2) I've set answered back to 'no', 'cause this hasn't actually been answered. It's not your call to make; it'll be answered when we've agreed. — lfdder12:53, 18 April 2014 (UTC)
.... it DOESN'T work. Jesus Christ. I remember why I gave up last time I tried to do anything with templates. And I'm flipping it back in the hope that someone sane will come along. Also, {{Check ISO 639-1}} will never work for this purpose unless it gets rewritten from the ground up as a lang tag validator. Language tags are a lot more than just the 639-1/3 codes. — lfdder14:05, 18 April 2014 (UTC)
Please don't make the documentation deliberately not match how the template actually works. The issue has been addressed. The check will stay, but will be fixed. Consensus seems to be that it should not be removed in the interim. Jackmcbarn (talk) 16:13, 19 April 2014 (UTC)
So there's me saying it should go and Pigsonthewing saying it should stay, which makes....consensus that it should stay? You must be pulling my leg. Mr. Stradivarius has said that he won't be fixing it any time soon, and I've explained why it can't just be 'fixed' anyway. There's not one thing Pigsonthewing has said that makes me think he understands the situation. He decided that it should stay without as much as having a single word with me. — lfdder16:32, 19 April 2014 (UTC)
No, there's you saying it should go, and me, Mr. Stradivarius, and Pigsonthewing saying it should stay. And stop making the doc page deliberately incorrect. I've already reverted you once and you've reverted me back. I'm not going to revert again, but I encourage you to do so. Jackmcbarn (talk) 16:37, 19 April 2014 (UTC)
You didn't say that before now. It seems to me Mr. Stradivarius is sitting on the fence, but I might be wrong. Not as bad as making using language tags 'deliberately incorrect', is it? I'm not reverting it, but thank you for encouraging me. Give me a shout when you decide you want to discuss the issue. — lfdder16:45, 19 April 2014 (UTC)
Since I started this I think I should comment. The system of applying language codes to the native name in infoboxes is not unique to Infobox writer. Many other infoboxes need to do the same function. However, this template seems to implement the system in a unique way. Other infoboxes do not validate the input. They work on the basis or rubbish in, rubbish out and leave it to the editors to input the correct codes. Validating the input is a basic of computer programming and so it is commendable that the implementation here tries to do that. On the other hand, writing two different lines of code to do two identical jobs when you could write one line to do the same job twice, is bad practice. All the infoboxes should be running this function off a common code. It shouldn't be left to one or two coders on this template to do the task. Language codes are complex and the reason other infoboxes don't validate them is that doing so is not a trivial coding task. Other infobox template contributors should be pinged to assist and a single common validation function created. In the mean time please try to be civil, there's never any reason to use the f word outside the article of that name. Rincewind42 (talk) 15:13, 20 April 2014 (UTC)
I want and try to be understanding, but I do get annoyed when people insist that something should be done this or that way, all the while being unwilling to engage in discussing the issue. It's glaring WP:OWNership behaviour. This is not the only infobox that uses {{Check ISO 639-1}} for this purpose. — lfdder17:33, 20 April 2014 (UTC)
Since no one's provided any reasoning for the addition of {{Check ISO 639-1}} and they've refused to respond after it's been explained to them how foolish it is, I ask that it's reverted. The change is in the sandbox. — lfdder18:23, 23 April 2014 (UTC)
What you should do is revert it. Page protection isn't an excuse for circumventing consensus-building processes. I've had about enough with you lot. — lfdder18:40, 23 April 2014 (UTC)
You requested a change. The burden is on the requester to demonstrate consensus for controversial changes, which this one clearly is since multiple people have opposed it. Jackmcbarn (talk) 18:47, 23 April 2014 (UTC)
I've requested a change because it's the only way the interface allows me to go about it. I'm not the one who made the addition. The burden is on whoever's added it to explain why it should stay. And he's made no effort to explain anything at all. (And neither have you.) In other words, if this template were unprotected, I'd have reverted the change and I'd have been completely in the right, and those in favour of having it there might've tried to explain why. In other words, I saw this shit coming from miles away when the template editor usergroup was first proposed. — lfdder19:09, 23 April 2014 (UTC)
Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. There still doesn't seem to be a consensus reached here. Please achieve a consensus before using this template to request the edit be made. Thanks. — {{U|Technical 13}}(t • e • c)22:19, 24 April 2014 (UTC)
@Technical 13: there needs to be a consensus for adding it in the first place. There isn't one. Again, if this template were unprotected I'd have reverted the change and I'd have been in the right. Pigsonthewings and his enablers are, in essence, abusing their privileges. — lfdder22:28, 24 April 2014 (UTC)
lfdder, my reading of the discussion here is there is consensus for the check added by Andy to stay, and the burden of consensus to remove that check is on you good sir. I see that you were working on a module that would improve the way the check worked, has that been completed? — {{U|Technical 13}}(t • e • c)22:32, 24 April 2014 (UTC)
Right then, so where templates are concerned, we've thrown WP:BRD right out the window? No, it's not been completed, and the longer this farce continues, the more my interest in completing it wanes. If the people here can't appreciate how flawed this present implementation is, I very much doubt they'd appreciate my fixing it. — lfdder22:36, 24 April 2014 (UTC)
It's way worse than 'not ideal'. You do realise that the way it is now means we can't tag text with any of the 7k-something languages that are part of 639-3? Part 1's only got about 150-odd languages (many of which are 'macrolanguages'). We can't even tag Ancient Greek, for God's sake. — lfdder23:09, 24 April 2014 (UTC)
....aaand silence. If you're incapable of discussing the issue, why do you hold that it should be kept? This is quite frustrating. — lfdder00:13, 25 April 2014 (UTC)
I agree that the status quo is bad. I disagree that letting things be entered willy-nilly in the language field is better. Instead of arguing this ad nauseam, why not help fix the module to check other language codes? Jackmcbarn (talk) 00:44, 25 April 2014 (UTC)
I obviously disagree that it's better to omit 7k languages 'cause someone somewhere might plug in the wrong code. Instead of arguing this ad nauseam, why not help fix the module to check other language codes? Because a half-arsed fix is not the answer -- some thought needs to go into it. For a start, do we validate codes or tags? If we choose to validate codes, how do we let people who know what they're doing enter tags? Should we validate input at all? Why not go for maintenance cats? What's the scope of it -- where else is it gonna be used? — lfdder01:00, 25 April 2014 (UTC)
I think we should remove the check until it's actually fit for purpose. I wasn't aware of all these issues when I first made {{Check ISO 639-1}}, and I actually removed it from quite a few infobox templates after Andy first added them when I realised it was causing errors on pages with perfectly legitimate language codes. The best thing would be to have a module that correctly validates the codes, but no check is better than the current situation where the majority of language codes are not recognised. — Mr. Stradivarius♪ talk ♪06:04, 25 April 2014 (UTC)
Agree it should be removed. I don't know how exactly the check module works, but if it is blocking entries as obviously necessary as "Ancient Greek", then it's doing far more harm than any good it might possibly be doing. Fut.Perf.☼06:58, 25 April 2014 (UTC)
Done and updated the documentation to correspond. Uncontroversial addition, and doesn't affect currently applied templates. —cyberpowerChatOnline11:55, 5 June 2014 (UTC)
We have the parameter |period. Its documentation is brief --"Dates from first publication to last publication."-- which evidently takes for granted that publication dates are definitive for writers. I commonly use a qualifier such to cover discrepancies, such as "(fiction)" for someone with published writings but unworthy in an earlier career. --P64 (talk) 20:56, 27 August 2014 (UTC)
Website parameter
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
please could the following change be made, so that the behaviour is in line with the parent template:
| data31 = {{#if:{{{website|}}} |<hr/>{{URL|1={{{website|}}}}} }}
changed to
Done – Ohc – I tested some more stuff and it looks like this ibox is now more in line with the parent ibox. Hope it meets with your approval. – Paine03:52, 29 August 2014 (UTC)
Hi, Frietjes – curious as to what is happening or going to happen. Are "reader-friendly" labels going to be used? Is this being, or has it been discussed somewhere? I would imagine that some might prefer the bare URLs because they are readily noticeable as "websites". Just curious. – Paine22:31, 1 September 2014 (UTC)
Paine Ellsworth, the guidance for most infobox templates (e.g., {{infobox person}}) is to use |URL=. I imagine the best thing would be for a single pass with a bot to change them to use the URL template, and if anyone doesn't like it, they can change it back. Frietjes (talk) 13:21, 2 September 2014 (UTC)
Have we recently disabled coverage of bare domain names as parameter values? I must be the "author" of more than 100, maybe 500 (perhaps never flagged in the edit summary). Such as Anne Bishop. One by another editor in July is Dan Santat.
I see that you added template {{Category TOC}} and suppose there is no convenient navigation without it. Thanks, I'll try to remember it.
Glancing at the category display I now recognize several page names. Checking a couple of them confirms that the tracking has been fixed to cover parameter values domain.name (Cleary) and www.domain.name (Colfer), as well as http://www.domain.name (Cooney). I suppose some editors are able to handle these semi-automatically in three passes, if not automatically in one.
This message is to notify you that there is an RfC ongoing on whether to add pronunciation info to {{Infobox person}}, a discussion which may also affect this template. Your comments on the matter are appreciated. The discussion can be found here. Thanks! 0x0077BE(talk · contrib)17:14, 16 November 2014 (UTC)
There's why this infobox doesn't have everything that Infobox person has, and then there's why this infobox doesn't have that particular field.
Why this infobox doesn't have everything that Infobox person has:
A generic infobox like Infobox person tries to have every field that could ever be useful. Everything including the kitchen sink. That's it's misfortune. Whereas a specific infobox like this one includes any given field only if it is really relevant to the overview of an article as a member of the collection that the infobox caters to. In this case, Infobox writer shouldn't have fields that aren't pertinent to a writer's character as a writer. For example, we do not, and hopefully never will, have a "religion" field here; religion can influence a writer, but it would be grossly inappropriate and prejudicial to classify writers by religion.
Why this infobox doesn't have a "residence" field:
On a quick search, there are apparently some discussions in the archives of this talk page about "residence", or "nation of residence", in relation to "nationality". The arrangement of those fields is something that's evidently been struggled with. If we were going to tinker with that part of the infobox design, it would be worthwhile to investigate in more depth the history of discussions of the nationality, citizenship, and ethnicity fields.
The documentation states that entries in "Notable works" should be separated by a line break (<br />). This is inconsistent with other fields for which we are instructed to separate entries using {{Plainlist}}. List markup would seem to be more correct, semantically, but does anyone know if there is a particular reason why line breaks are to be used for "Notable works"? Thanks. – Wdchk (talk)01:46, 21 September 2015 (UTC)
The birth date section of the parameters table offers the following instruction—"Insert the person's birth date if known as: month day, year or day month year as appropriate."—which is totally incomprehensible. Can it be rewritten? – Arms & Hearts (talk) 17:41, 30 January 2016 (UTC)
If I'd understood what it was supposed to mean I would've done it already! But it occurs to me now that what confused me was probably the comma after the first "day," which I mistook for a part of the structure of the sentence rather than that of the example, if you see what I mean. I think it should read "month day year (e.g. January 31, 2016) or day month year (e.g. 31 January 2016)". That way the need for the comma is made clear in the example without confusing the sentence structure. – Arms & Hearts (talk) 15:42, 31 January 2016 (UTC)
Proposed other_names field
template:infobox person has an "other_names" field (aka "other names", "othernames", "othername", alias") which I don't see present here. Could these serve the same purpose as "pseudonym" or something different? If same could we alias these? If different can we add this field? 184.145.18.50 (talk) 19:24, 4 March 2016 (UTC)
Truthfully, I don't think that would be an appropriate field. We've strongly resisted adding miscellaneous fields to this infobox that aren't related to the subject's identity as a writer. Particularly, we don't have a field for religion, and we don't want one — in fact, we want not to have one. (If some religion had an influence on the writer, it should be presented as an influence.) --Pi zero (talk) 21:27, 15 September 2016 (UTC)
This has very little to do with religion per se. For hundreds of years, until the mid 18th century, birth dates were not routinely recorded, but baptism dates, which were, are a close approximation. {{Infobox person}} is coded such that the baptism date does not show if a birth date is present. If it's good enough for Ludwig van Beethoven... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits21:30, 15 September 2016 (UTC)
