Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5

This page has archives. Topics inactive for 60 days are automatically archived by Lowercase sigmabot III if there are more than 5.

I would like to suggest a new optional parameter, ethnicity. To show its usefulness, consider for example the case of Italian or German artists active before 1861 (Italian unification) or 1871 (German Unification): they cannot be defined as being Italian/German nationals, since Italy/Germany did not exist at that time. In those cases, at present we use the parameter "nationality", giving to it the meaning of ethnicity. With the new parameter we could either leave the nationality parameter empty or use it to describe the state where they were citizen/subject (for example, in the case of Titian, the Republic of Venice). In all the other cases (when ethnicity and nationality coincide), we can ignore the ethnicity and fill only the nationality field. Alex2006 (talk) 08:13, 25 May 2014 (UTC)[reply]

Please could we add a DAAO record field? The daao_record field is a new URL field that points to the Design and Art Australia Online biography of the artist. The DAAO provides high quality, community moderated biographies of Australian practitioners.

There is an uncontroversial discussion on the WikiProject_Visual_arts page and (earlier) on the Template talk page for Infobox_artist.

I have implemented the change in the sandbox and added a test case here (its a sub page of the normal test case as I didn't want Vincent to be deleted or attributed a DAAO record). Sandbox testcase here.

Thanks! Queen Victoria (talk) 02:54, 6 June 2014 (UTC)[reply]

Hmmm... Not much of a discussion. If no one comments, I'll apply it in a few days.—cyberpower ^Chat_Online 23:47, 9 June 2014 (UTC)[reply]

•  Working — {{U|Technical 13}} ^{(e • t • c)} 16:27, 14 June 2014 (UTC)[reply]
  • Okay, so I've made some changes in the sandbox so this works more efficiently and gives a clearer result. Queen Victoria, do these changes look good to you and do what you want? In order to get this extra row to show, all that the editor needs to do is put in the name of the person from the URL (E.G. |daao_record=mike-par) and the template will do the rest. If the url is always the name of the person, and always uses hyphens to replace spaces, it is possible to adjust the template further to automatically add the link without the |daao_record= parameter (which would still be available for overrides) but instead take the |name= and convert it to lowercase and replace the spaces with hyphens if "most" of these artists have daao records. Please ping me with your answers to those questions and we'll develop more in the sandbox until we come up with some good code and then I'll apply it for you. Andy, do you have anything to add here? — {{U|Technical 13}} ^{(e • t • c)} 16:52, 14 June 2014 (UTC)[reply]
    • I'd avoid doing anything so clever; consider William Morrison Wyllie aka William Wyllie. Also, we should be able to pull data from Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:01, 14 June 2014 (UTC)[reply]
      • Well, those types of cases are why there would still need to be a |daao_record= parameter that would override the attempt to automatically detect. Simply for those edge cases. — {{U|Technical 13}} ^{(e • t • c)} 17:39, 14 June 2014 (UTC)[reply]
        • Thanks for getting that underway and sorry I've been AWOL. I like the sound of your extension to the template -- sounds much cleaner. Looks like Netoholic has undone those changes though. Should I just roll back to your last version Technical 13? Queen Victoria (talk) 08:02, 1 July 2014 (UTC)[reply]
          • Probably not until Netoholic's concerns are answered. I personally support DAAO links as it seems to be acceptable as an Authority Control on the topic. Not having it almost seems to me like saying a baseball's MLB page shouldn't be linked in an infobox or something. I'm not convinced by Netoholic's objection, but we should give them time to clarify or for other objections to come to light. If nothing happens in a week or so, we'll assume that there are no further objections and you can feel free to restore my change. — {{U|Technical 13}} ^{(e • t • c)} 11:50, 1 July 2014 (UTC)[reply]
            • The DAAO is community-edited (a lot like IMDB or MusicBrainz) but does not seem to have the data reciprocity needed to be considered a strong authority control. If it was one, then Template:Authority control would be where you'd add this, not the infobox. The DAAO resource is best presented in External links, because there is no special reason that the site should be elevated above any others that provide biographical information (and in fact as a rule we prefer links that are not community-edited). We don't put IMDB links for actors and films/series in infoboxes, so we shouldn't put DAAO links either. --Netoholic @ 19:57, 1 July 2014 (UTC)[reply]
              • While being community edited the DAAO has a strong system of moderation including marking fields that have been edited but not moderated. The DAAO provides metadata to harvesters via OAI including the NLA. It consumes other sources of biographies and artworks that are online and (importantly) offline. The NLA is an Authority control for Wikipedia already but doesn't provide access to the richness of artists' works and events that the DAAO maintains. Therefore I think it is a valuable addition to the sidebar and fits well with the purposes of the sidebar. Does that address all your points Netoholic? Please let me know if you have any other concerns. Queen Victoria (talk) 23:04, 7 July 2014 (UTC)[reply]
                • Unfortunately, it really doesn't. There are potentially many (even better) resources out there that could be included in infoboxes, but we don't do it. DAAO doesn't give us anything special enough to elevate its status above any other normal External Links. If DAAO data connects even partially to NLA, then Template:Authority control should reflect that data, but for the other stuff, a standard external link is the appropriate place to link to the DAAO. --Netoholic @ 23:11, 7 July 2014 (UTC)[reply]
                  • I am struggling to understand why DAAO is not acceptable as an authority for Australian artists. It's developed and moderated by two of Australia's leading universities in the arts as a scholarly activity; its development has been funded by the Australian Government over a number of years to be a single authoritative source in its field. Yes, it is open to input from the community but that input cannot be anonymous, all users have to provide an email address to create an account, citations are requested, the contributions are moderated and can obviously be questioned via email if the moderator is not satisfied. And I doubt that it attracts contributions from the general public; being a specialised topic, I rather suspect the contributing community is small and is predominantly made up of academics and researchers. Can someone point me to a more authoritative source for Australian artists? Kerry (talk) 07:37, 8 July 2014 (UTC)[reply]
                    • I trust that DAAO is an amazing resource and very well-respected. But we still don't put arbitrary external links about people into infoboxes ( {{Infobox person}} doesn't include IMDB links, for example). There is dedicated WP:EL section to each article where links to resources like this belong. You might also use DAAO as a citation if its considered reliable enough. --Netoholic @ 08:36, 8 July 2014 (UTC)[reply]

I feel like this is a bad addition to the template. Sites like DAAO are better used as References or External links in the article. This could easily get out of hand as we could add many, many other websites with artist pages to the infobox. Some things just aren't meant for the infobox, and external links just aren't (except for an official website). -- Netoholic @ 21:31, 18 June 2014 (UTC)[reply]

Even though the recent TfD discussion resulted in a speedy keep, there are still some gains to be made from changing the artist template into a wrapper for Template:Infobox_person so as to preserve a consistent look among all biographies. I've made a version in the Template:Infobox artist/sandbox (permanent) which pass through the in-common parameters to Infobox_person, while keeping the artist-specific ones available by using the module function. It turns out that only 3 artist parameters don't have an equivalent in Infobox_person. Here you can view the Template:Infobox artist/testcases. Some parameter names and row labels change slightly, but I've preserved support for the old parameters. Here is a list of the changes:

• Removed - bgcolour. Title colors is a deprecated practice and a holdover from very, very ancient infobox design. There's currently no documentation as to what colors to even use for what artists, so it leads to inconsistent appearance out in the articles. Birth name label is hidden, now part of Born
• Changed labels - Movement is now Style, Works is now Notable work(s), Alma mater becomes unlinked, Training is now Education, Field is now Known for
• Changed parameters (all old ones still supported) - movement is now style, works is now notable_works, training is now education, field is now known_for
• Infobox_artist specific - Patron(s) is now between Elected and Memorial(s)

This arrangement should make it easy to add more Infobox_person parameters to Infobox_artist, and also expand the artist-specific fields, if needed. -- Netoholic @ 22:47, 18 June 2014 (UTC)[reply]

• Added Style with {{{style}}}

Updated to reflect change to infobox person that now supports Movement natively - new permanent link. Requesting the edit (WP:SILENCE). -- Netoholic @ 22:54, 23 June 2014 (UTC)[reply]

Most at the TfD felt a merge would be inappropriate - that's not SILENCE. See Wikipedia:Edit_requests#General_considerations. Nikkimaria (talk) 02:14, 24 June 2014 (UTC)[reply]

This isn't a merge, this template is still to be used separately and distinctly. The only impact is to make use of common elements for consistent look, while preserving the separate, unique functions. If you read those votes carefully, this exact wrapper option was brought up and echoed several times as an affirmative alternative to a full merge. -- Netoholic @ 02:49, 24 June 2014 (UTC)[reply]

 Done — Martin (MSGJ · talk) 08:29, 24 June 2014 (UTC)[reply]

MSGJ, please revert until there is consensus for this change. Netoholic, I read the votes carefully, and you still cannot claim SILENCE as consensus given what happened there. Nikkimaria (talk) 12:00, 24 June 2014 (UTC)[reply]

This solution seemed like a very reasonable conclusion to the discussion. Several people did mention converting it to a wrapper and no one explicitly opposed that. I got the distinct impression that some participants in that discussion did not appreciate/understand what was actually being proposed, and were merely piling-on. Anyway I will revert for now, but I would like to see some comments based on the merits of the proposal and the (very slight) noticeable differences in output, rather than some principled stand against using another template. — Martin (MSGJ · talk) 12:55, 24 June 2014 (UTC)[reply]

so what is the specific objection to converting it to a wrapper? it's clearly not a merger, but allows for common information to be displayed in the same order in both templates. seems very uncontroversial, so long as no new fields are added, and no information is removed. Frietjes (talk) 13:40, 24 June 2014 (UTC)[reply]

I think the wrapper is quite a logical and inevitable change to the template, supported by comments on the TfD, here, and on many other related templates. I posted the wrapper change and waited several days for any interested parties to raise objections. There still are none, just what seems to be a forgivable and minor technical misunderstanding on Nikkimaria's part about how a wrapper is different than a merge. --Netoholic @ 18:31, 24 June 2014 (UTC)[reply]

Except that it isn't supported by the comments at the TfD - making it a wrapper was proposed by the person initiating the nomination, and most respondents said "oppose". You can ask them to clarify if you like, but there's no indication that by "oppose" they actually meant "support turning it into a wrapper". The only person other than the nominator who explicitly supported making this a wrapper was the one who proposed a rather...novel...early closure. Nikkimaria (talk) 03:05, 25 June 2014 (UTC)[reply]

Do 'you', yourself, have any particular concern with the proposed change. I think we've given a lot of time for people to comment on my exact change, and I don't think we're going to get anywhere as you and I read the TFD completely different. Those here that have commented know the technical change is beneficial. The TFD seems like it was a pile-on by people more concerned with deletion of this template, and with trying to merge the unique parameters into infobox_person. Since my change does neither of these two things, unless you have a specific technical concern, I'd like to put this to change. We could go back and forth guessing at what people were actually voting oppose on, but its just delaying what is likely an inevitable solution here. Converting similar templates to wrappers is extremely common practice. --Netoholic @ 03:45, 25 June 2014 (UTC)[reply]

Better idea: ask the people who participated in the TfD to get involved here. That way we can find out what they were actually voting on, rather than presuming that oppose really means support. Nikkimaria (talk) 11:30, 25 June 2014 (UTC)[reply]

I am happy with the edit: consistent, logical, reasonable, as expressed by others above, --Gerda Arendt (talk) 14:15, 25 June 2014 (UTC)[reply]

Even better idea: actually discuss whether the proposal improves articles or not. In favour of the change to a wrapper are the following:

• A template that is a wrapper for a more generic template has less maintenance - for example, upgrades such as rewriting into Lua need only be done to the generic template and then cascade automatically onto the wrapper templates;
• Templates that share common code achieve consistency in display and performance without any effort to "match" them between articles;
• Changes that would affect the common code are likely to be considered by a wider audience as they apply to the generic template, while changes that would only affect the wrapper template are more likely to be considered by those who have a particular interest in the differences that make the wrapper specific to their field.

Whereas, looking at the test cases, some disadvantages can be seen:

• By changing from separate "Birth name" and "Born" rows to a single "Born" row, we lose data granularity - i.e. a parser has to extract the birth name from a larger block of data, rather than having the key-value pair "Birth name"-value readable directly. This is a cosmetic change that makes the data less available;
• Similarly, the "Website" row with its value has become disconnected - the key (label), "Website" now is on one row and its value is on a different row. That simply makes it harder for an automated parser for no good reason (not even cosmetic, as it actually looks worse in my humble opinion);
• Using the label "Notable work(s)" in place of "Works" results in the label column widening, leaving less room for the value data - this is a retrograde step as infoboxes really ought to reserve as much space as possible for the data, not for the labels.

There may be other pros and cons and I'd encourage other editors to debate them here, but bleating about interpretations of a TfD that didn't even address this proposal is not a productive use of this page. --RexxS (talk) 14:44, 25 June 2014 (UTC)[reply]

I'm in favour of the proposed change, and note that the objections appear to be misplaced procedural concerns, rather than substantive issues with the outcome. Of RexxS' three concerns: 1) Though there is one display field, there are still three input parameters (though I agree that this is suboptimal; however it could easily - and reasonably - be addressed at the person infobox's talk page); 2) is currently discussed on that infobox's talk page and 3) could also be addressed on the person infobox's talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 25 June 2014 (UTC)[reply]

Discussion seems to have ended for now, with consensus for conversion to wrapper. Hopefully some of RexxS's well considered comments can be developed on the parent template. — Martin (MSGJ · talk) 13:48, 30 June 2014 (UTC)[reply]

Though some artists are self-taught, many improve their skills through education (e.g. Pratt Institute, CalArts, etc...) I would like to propose a parameter for education for addition to this template. Thanks. Warrenchase (talk) 15:19, 20 June 2014 (UTC)[reply]

Several articles using this template correctly have a superfluous white line at the top; Karel Appel is an example. – Editør (talk) 20:59, 7 July 2014 (UTC)[reply]

It's not the info box but rather the article. Remove the newline between the content and the info box and watch the magic happen.—cyberpower ^Chat_Online 21:02, 7 July 2014 (UTC)[reply]

I don't think updating all artist pages is the best solution. Other infoboxes don't have this issue, such as {{Infobox museum}} in for example Rijksmuseum Amsterdam. – Editør (talk) 21:17, 7 July 2014 (UTC)[reply]

fixed. Frietjes (talk) 21:20, 7 July 2014 (UTC)[reply]

Thanks! – Editør (talk) 23:07, 7 July 2014 (UTC)[reply]