Jump to content

User talk:MargaretRDonald/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5Archive 6Archive 7Archive 8Archive 9Archive 10→Archive 15

Apology

Hello Margaret,

I have only just realised that I did not have my Wikipedia email preferences properly set. Sorry - I can only read as far as "Hi Geoff, I note that we have a disagreement concerning the use of...". I think I have fixed the email problem. I'd really like to see the rest of you message if you wouldn't mind sending it again. Gderrin (talk) 03:35, 21 December 2020 (UTC)

Sorry Margaret - email still not received. Can we talk here? I don't think we have a disagreement. It's just that when the Q code was added to Philotheca myoporoides subsp. brevipedunculata, the italics were not showing in the reflist. (There was already a small mistake in the ref. citation.) Gderrin (talk) 04:36, 21 December 2020 (UTC)

Hi @Gderrin: my emails were as follows:

"Hi Geoff Thanks for getting back to me. It was just an email attempting to persuade you that cite Q was useful even though it fails to format species names (and I think if we were to format species names in cite Q searches would not find matching articles....) So I think in the end it may just boil down to yours and my individual preferences... Articles in which one may see the very real usefulness are: https://en.wikipedia.org/wiki/Cephalization (ref 8), https://en.wikipedia.org/wiki/Polychaos_dubium (ref 4) and a whole pile more where I was linking Laura Wegener Parfrey via cite Q but inadvertently linking other authors simply by its use. The email was as follows:

Hi Geoff,

I note that we have a disagreement concerning the use of cite Q. In the article https://en.wikipedia.org/wiki/Philotheca_myoporoides_subsp._brevipedunculata I see that in addition to retaining the italics you have also changed the url to point to a page in BHL rather than to the full Muelleria pdf.

I think it is a pity to ignore the very real advantages of using a single reference in wikidata rather than the potentially many references in wikipedia. It is easier to correct a single use rather than the many.

Additionally

  1. All of the Muelleria articles uploaded to wikidata point to the pdf. (while many users - not you - fail to point to any external source at all.)
  2. If an author has been disambiguated in wikidata, and has an enwiki article, the use of the the Qitem automatically links to the author article. (I think it is also very important to link authors to their work, which again you do for taxon authorities, but more generally, the use of a Qitem links to any disambiguated author you may be citing, taxon authority or no)

For me these considerations outweigh the formatting issue. I have too much respect for you to wish to change your articles without your consent, but am hoping that ultimately you may come to see the usefulness of a Qitem for citing an article.

My best regards, as always, Margaret"

(with respect to other errors I may have forgotten to use the page parameter of cite Q to ensure that the pages in the citation were those of APNI even though the full pdf is always pointed to when using cite Q) MargaretRDonald (talk) 04:57, 21 December 2020 (UTC)

Hello again Margaret,
Regarding the use of cite Q, it seems to me that there has been a long discussion about it, and that the result of the discussion was that there was no consensus (at 2 October 2017). The way I read the discussion, the conclusion was that "usage of this template should be extremely vetted to ensure that all of the transcluded information is accurate". I don't know whether there has been further discussion, but my opinion is that cite Q should not be used where transcluded information is incorrect. Giving a reference with binomials that are not in italics, is incorrect. (My taxonomy professor Roger Carolin would be horrified. He deducted marks when binomials in handwritten work were not underlined.) The Cite Q template is a work-in-progress.
I would prefer that plant articles always had binomials in accordance with WP:FLORA, including in the reflist.
I see no problem with the use of cite Q in the two articles (Cephalization and Polychaos dubium) you mentioned.
I used the BHL in the reference to Philotheca myoporoides subsp. brevipedunculata in preference to the full Muelleria article so that a reader does not have to search through the whole journal. Gderrin (talk) 08:24, 21 December 2020 (UTC)
Hello again Geoff. There has been an enormous amount of recent work on cite Q and I have found it works very well. (Andy Mabbett and others recently got a wikimedian grant to work on it and perfect(?) it.) And it would be nice if searches on articles which include italics in their names could be sorted out so that there would be no drama with titles... Italics would be nice, but what is particularly good about cite Q is that as people get articles then if a cite Q template has been used in an article citing that author, nothing need be done to an article citing the author to give an author link in the citing article. This is in strong contrast to wikipedian editors failing to create red links, when to correct each article to give a blue link each article must be found and individually be blue linked. I have written a zillion queries to find such articles and blue link them. Thus you can see why I am enthusiastic about a tool which means work need not be done and redone. So simply because cite Q was used in Cephalization a further link was generated to the author Laura A. Katz. However, I do see, that given that so many botanical article titles contain names needing italicisation you will not be using Cite Q in the immediate future. Cheers and thanks for the discussion. MargaretRDonald (talk) 08:51, 21 December 2020 (UTC)
I'm not sure that's something we can resolve in {{Cite Q}}, because it's not something that {{Citation}} (for which {{Cite Q}} is a wrapper) handles:
{{citation|title=Foo ''bar'' bas}}
Foo bar bas
You would need to raise the matter on that template's talk page; but note that its documentation says "Do not include Wiki markup '' (italic font) or ''' (bold font) because these markup characters will contaminate the metadata.". Even then, Wikidata does not store italics (nor other markup) in title properties, nor labels. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 21 December 2020 (UTC)
Thanks, @Pigsonthewing: I did think that the issue was not easily resolvable. MargaretRDonald (talk) 19:57, 21 December 2020 (UTC)

Margaret, Geoff, I have both your talk pages on my watchlist, so I was already aware of this conversation, but hadn't wanted to step in (sorry, I've been pretty avoidant of user talk pages for a while; and at this point I'm rather daunted by the number of messages on my own talk page I haven't replied to).

Genus and species should absolutely be italicized.

At this point, {{Cite Q}} represents a tiny fraction of instances of scientific names missing italics on Wikipedia. There's a lot of italics that need fixing; academic terms ending in December bring organism articles expanded by student editors who almost never get italics right (charitably, I'll assume the problem is being unfamiliar with wiki markup). Even scientific journals don't always italicize scientific names. Chemistry/pharmacology journals are very bad about italicizing scientific names of organisms from which chemicals are derived. Biologists studying Drosophila melanogaster as model organism invariably call it Drosophila in running text, which is an utter abomination (if I were reviewing these articles, I'd accept lower-case unitalicized drosophila as a common name for the model species in running text, or unitalicized Drosophila as title case in the actual title; and if drosophila scientists actually care about another branch of science they should use the binomial with italics). Arabidopsis thaliana workers are about as bad. I've gone through incoming links to the genera Drosophila and Arabidopsis and refined them to the common model species in the past (and I should probably check them again, now that I think of it). In doing so, I've done [[Drosophila melanogaster|drosophila]] in running text, but haven't presumed to add italics to titles of references.

OK, leaving italics aside.

Sure, {{Cite Q}} has some advantages. I haven't used it, and I'm not about to (I haven't really even looked into it so far). Italics aside, at Philotheca myoporoides subsp. brevipedunculata, the major difference has been linking to the reference. Margaret linked a PDF via Wikidata on a government site. Geoff linked BHL. I don't find BHL's interface especially user-friendly; the PDF is better in this regard for me. As a Wikipedian (interested in free knowledge), BHL appeals to me more than a proprietary PDF format. As an editor, when I add references to journals, I'm usually using this tool, which depends on a DOI. It doesn't support italics in article titles, but the references I add usually don't mention taxon ranks that should have italics in the title. When adding DOI based references, I also search for any non-paywalled versions, and add it to the reference (typically as a PDF, often via ResearchGate).

The issue aside from italics here is how to link to references. BHL? Australian government? DOI? Non-paywalled links from a DOI? DOI and BHL are likely most stable and persistent. Plantdrew (talk) 04:43, 22 December 2020 (UTC)

There are other problems with {{Cite Q}}. When an article uses {{Sfn}} and other Harvard-based templates to generate short references that link to a Bibliography, it doesn't (at present) generate the correct anchor for the link, which fails. Its default is CS2 style citations, which are then inconsistent in an article that uses CS1 style citations, contrary to the MoS.
In general, {{Cite Q}} depends on style and formatting decisions made at Wikidata, whose editors come from many different countries, and are used to different conventions. I remain unconvinced that it should be used here; I will certainly not be using it at present. Peter coxhead (talk) 09:33, 22 December 2020 (UTC)

Cite Q

Hi, {{Cite Q}} needs to be used with great caution as yet. It breaks the links from short Harvard style references to a bibliography list, as it did at Botanical garden. It also by default produces CS2 style citations (i.e. with commas) which then aren't consistent as they are required to be in an article which uses CS1 style citations. Peter coxhead (talk) 08:00, 22 December 2020 (UTC)

FYI@Pigsonthewing: MargaretRDonald (talk) 20:29, 22 December 2020 (UTC)
Could I ask that rather than simply reverting cit Q edits, that the author links produced by cite Q be honoured. In an encyclopedia it is important that people be linked to their work. MargaretRDonald (talk) 20:29, 22 December 2020 (UTC)
You are welcome to add the author links as you go through and revert your CITEVAR errors. Please remember to use the Preview button to ensure that your links are working as intended and going to the right person's article. – Jonesey95 (talk) 21:20, 22 December 2020 (UTC)

Please stop adding Template:Cite Q when it violates WP:CITEVAR

Please stop adding Template:Cite Q when it violates WP:CITEVAR. This edit changed a last/first, Citation Style 1 citation to a first last, Citation Style 2 citation, in an article where the former is the dominant citation style. I suggest that you ask the folks who are working on Cite Q to support |mode=cs1 and last/first citations. – Jonesey95 (talk) 18:09, 22 December 2020 (UTC)

I have reverted some of your recent changes that went against CITEVAR. Please fix or revert the rest. – Jonesey95 (talk) 18:21, 22 December 2020 (UTC)
Also to be acceptable in a taxon article, the generated citation needs to respect the italicization of any taxon names in the title of the source – it looks very unprofessional to me otherwise. Another issue is the access date when there's a url in the citation; for changeable web pages, this needs to be when the editor here consulted it. I cannot see that {{Cite Q}} is yet ready to be deployed, although I admit I haven't studied it in depth. Peter coxhead (talk) 19:39, 22 December 2020 (UTC)
@Peter coxhead: The parameter "access-date" can be added to cite Q so that is not an issue. With respect to the italicisation of taxon nemes within article titles, that seems unlikely to be able to be fixed. MargaretRDonald (talk) 20:38, 22 December 2020 (UTC)
FYI @Pigsonthewing: MargaretRDonald (talk) 20:38, 22 December 2020 (UTC)
@Peter coxhead: citations that are amenable to being called via {{Cite Q}} are published in scholarly journals that have stable urls via one or more identifiers. They do not need access-date even when they have a url parameter. Help:Citation Style 1 #Access date explains. --RexxS (talk) 01:57, 23 December 2020 (UTC)
@Peter coxhead: I've been trying without success to find examples of where CiteQ is failing to italicise a taxon name in the title of the source. Could you provide an example, please? --RexxS (talk) 22:25, 24 December 2020 (UTC)
This edit fixed one. – Jonesey95 (talk) 00:22, 25 December 2020 (UTC)

It would be courteous to maintain the functionality of an article by maintaining its author links. In Algae December 19,2020 reference 21 has links to three authors Laura Wegener Parfrey, David J. Patterson and Laura A. Katz. Reversion of the cite Q edit produced: December 22, 2020 with no author links. It would be courteous to maintain these author links rather than to destroy them by a simple "revert edit". The article of 19 December links primary authors of subject matter to the subject and these links should be maintained with subsequent edits. MargaretRDonald (talk) 00:50, 23 December 2020 (UTC)

Well, that may be so, but for anybody to realize that the deletion of a full citation and its replacement by Zog-speak from planet Vulcan ("{{Q|vulcanID987654321}}") has actually added some morsel would require them to a) view the Vulcantext, b) load the original full citation and preview it alongside, c) manually check for (wholly unexpected) Vulcan-extras, and d) manually transcribe the inaccessible Vulcancoded authorlinks into conventional, visible authorlinks. Sorry but that's not a realistic process for those of us without spare spacecraft. If you want to add authorlinks, please just add them in the usual way. Popping little edit-comments about how courteous it would be for other editors to follow the above algorithm is, well, kind of hokey, really. Chiswick Chap (talk) 08:41, 24 December 2020 (UTC)
{{Cite Q |Q15625490}} → Jeffrey T. Williams; Kent E. Carpenter; James L. Van Tassell; Paul Hoetjes; Wes Toller; Peter Etnoyer; Michael Smith (21 May 2010). "Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles". PLOS One. 5 (5). Bibcode:2010PLoSO...510676W. doi:10.1371/JOURNAL.PONE.0010676. ISSN 1932-6203. PMC 2873961. PMID 20505760. Wikidata Q15625490.{{cite journal}}: CS1 maint: unflagged free DOI (link)
{{Cite Q |Q15625490 |expand-yes}} → {{Cite journal |author-link1=Jeffrey T. Williams |author-link2=Kent E. Carpenter |author1=Jeffrey T. Williams |author2=Kent E. Carpenter |author3=James L. Van Tassell |author4=Paul Hoetjes |author5=Wes Toller |author6=Peter Etnoyer |author7=Michael Smith |bibcode=2010PLoSO...510676W |doi=10.1371/JOURNAL.PONE.0010676 |id=[[WDQ (identifier)|Wikidata]] [[:d:Q15625490|Q15625490]] |issn=1932-6203 |issue=5 |journal=[[PLOS One|PLOS One]] |language=en |pmc=2873961 |pmid=20505760 |publication-date=21 May 2010 |title=Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles |url=http://europepmc.org/abstract/MED/20505760 |volume=5}}
The real "kind-of hokey" is your inability to use the simple tools provided to fix problems. If you can't work that out for yourself, perhaps take a look at the documentation. --RexxS (talk) 22:25, 24 December 2020 (UTC)
@Peter coxhead: @RexxS:@TShafee: Further discussion may be found at Australian Biota Talk page: Use of Cite Q MargaretRDonald (talk) 00:50, 23 December 2020 (UTC)
I see your point about the author links, but the author names are displayed incorrectly (First Last), and Katz is missing the full stop after the middle initial "A", contrary to MOS. Changes that introduce discrepancies like that are straightforward violations of CITEVAR and can cause an article to fail reviews such as FAC. If maintaining the author links were a simple copy-paste from the previous revision, I would consider maintaining the links, but they are hidden behind the opacity of Cite Q and Wikidata. I am sure that this is frustrating for you, as you have found a new way to cite journal articles that appears to have multiple benefits, but unfortunately, you'll have to figure out how to keep the benefits while adjusting the display of Cite Q to match the existing citation style in articles. See Template talk:Cite Q for more discussion about how to customize each transclusion of Cite Q to do this. – Jonesey95 (talk) 01:20, 23 December 2020 (UTC)
@Jonesey95: I disagree that the display of author names is incorrect, although it may be inconsistent depending on the article. I also disagree that MOS insists on a full stop after initials in author names, otherwise Vancouver-style would not exist on Wikipedia. WP:CITEVAR is not part of the MoS. If CiteQ produces an format inconsistent with the rest of the article, then an editor can still add author names in whatever format they choose, because {{Citation}} allows that, and the local values will override anything on Wikidata. --RexxS (talk) 01:57, 23 December 2020 (UTC)
The author naming convention was inconsistent within a single citation, which is not allowable anywhere on Wikipedia. I agree that an editor can still add author names, which is why I encouraged MargaretRDonald to read the template talk page, and why I asked them to fix or revert their edits. As long as citations are displayed consistently within an article and do not break any functionality, there should be no problem. – Jonesey95 (talk) 05:39, 23 December 2020 (UTC)
That was an unusual error caused by the Wikidata entry Evaluating support for the current classification of eukaryotic diversity (Q21090155) having object named as (P1932) "Laura A Katz" for Laura A. Katz (Q56782243), but no corresponding qualifier for David J. Patterson (Q5235476). It's symptomatic of the haphazard state of data curation on Wikidata and needs to be fixed there. I sympathise with your concern and am frustrated by those sort of problems. --RexxS (talk) 00:05, 24 December 2020 (UTC)
Frustrating, yes, but not unusual. I have seen many author initials in Cite Q templates in the form "A.B." instead of the usual "A. B." with a space. Editors will have to fix those or customize the author display in an article in order to maintain consistency with MOS:INITIALS, which is usual (but not required, of course) in citations. – Jonesey95 (talk) 05:47, 24 December 2020 (UTC)
Curation of Wikidata entries is a key issue, and will remain so even if all the current problems with Cite Q are fixed. There are many fewer editors over there than here; many items are created by bots and never checked by editors. I edit mostly taxon articles, which usually have a {{taxonbar}}. I'm now reconciled to having to create or correct Wikidata taxon items at least half the time that I create or expand a taxon article here in order for the taxonbar to be correct. If I have to correct Wikidata citation items as well, it will just add to the workload. Having to interact with Wikidata also discourages new editors, in my experience.
If I were cynical (heaven forbid!) I would say that templates like Cite Q are a good way for Wikidata to force editors from language wikipedias who care about accuracy and style consistency to do work over there. Peter coxhead (talk) 11:39, 24 December 2020 (UTC)
How does MOS:INITIALS, a part of WP:Manual of Style/Biography apply to citations? It simply doesn't fit with Vancouver-style:
  • {{cite journal |last1=Mouse |first1=Michael |last2=Duck |first2=Donald |last3=Fairy |first3=Tinkerbell The |date=24 December 2020 |title=Quantum Chromodynamics for Toons |url=https://www.example.com |journal=Science}} → Mouse, Michael; Duck, Donald; Fairy, Tinkerbell The (24 December 2020). "Quantum Chromodynamics for Toons". Science.
  • {{cite journal |last1=Mouse |first1=Michael |last2=Duck |first2=Donald |last3=Fairy |first3=Tinkerbell The |date=24 December 2020 |title=Quantum Chromodynamics for Toons |url=https://www.example.com |journal=Science |name-list-style=vanc}} → Mouse M, Duck D, Fairy TT (24 December 2020). "Quantum Chromodynamics for Toons". Science.
I'm not cynical (I hope), but I do think that using Wikidata for Wikipedia content does help to leverage Wikipedia's considerable editor resources to help less fortunate language wikis. For me it's part of the mission to make the sum of human knowledge freely available to every person on the planet. --RexxS (talk) 22:57, 24 December 2020 (UTC)
@RexxS: I agree that MOS:INITIALS doesn't immediately apply to citations, because of WP:CITEVAR, which is interpreted to allow a very wide range of citation styles that have some external support, provided they are consistent within the article. (And exceptions are made for other styles in citations, such as YYYY-MM-DD dates, that are not allowed in running text.) If we were starting again, I would argue for settling on a single approved citation style, as we have settled on other contentious style issues (such as capitalization). However, we are where we are, which means that CiteQ and other citation-generating templates have to be able to fully support multiple styles, and, barring a new RfC which decides to the contrary, it is allowed to change occurrences of CiteQ to other templates used in the article. Peter coxhead (talk) 11:07, 25 December 2020 (UTC)
@Peter coxhead: I agree that having a consistent "house" style for citations would eliminate a lot of completely unnecessary argument, because I don't believe that the minutiae of citation formatting are in any way important. CiteQ passes all of the information it collects through the standard {{Citation}} template and therefore fully supports all of the multiple styles supported already. Of course, anybody can change any citations to improve them as CITEVAR explicitly allows. What is important is what we present to the reader and we should be welcoming advances such as auto-correction of inaccuracies and automatic tracking of sources that have been retracted. --RexxS (talk) 16:22, 25 December 2020 (UTC)
@Jonesey95: @Peter coxhead: @RexxS:{{Cite Q|Q102898970}} produces Darren M. Crayn; Michael Hislop; Caroline Puente-Lelièvre (2020). "A phylogenetic recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae)". Australian Systematic Botany. 33 (2): 137–168. doi:10.1071/SB18050. ISSN 1030-1887. Wikidata Q102898970. in Styphelia stomarrhena, listing three authors, none of whom currently (2020-12-26) has an enwiki article. But the moment an article appears for any one of these authors, this Cite Q template will link to that author. This capacity to produce links long after one has finished with an article, is an essential difference from the one by one referencing (with its multiple capacity for all problems of referencing) espoused by many who have contributed to the discussion.
Note that the same citation can be modified: {{Cite Q|Q102898970|first1=Darren M. |last1 =Crayn|first2=Michael C|last2=Hislop|first3=Caroline|last3=Puente-Lelievre}} to produce: Crayn, Darren M.; Hislop; Puente-Lelievre, Caroline (2020). "A phylogenetic recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae)". Australian Systematic Botany. 33 (2): 137–168. doi:10.1071/SB18050. ISSN 1030-1887. Wikidata Q102898970.. In other words, one can write names any which way. Thus it is always possible to write names that satisfy the criticism above. One simply uses the parameters available in {{Citation}}
To sum up (for me) the capacity to produce links long after one has finished with an article, is an essential difference from the one by one referencing, and alone justifies its use. (But it is of course far easier to get one thing right (the wikidata for an article) than to correct 200 references which fail to link to either author or article.) MargaretRDonald (talk) 04:40, 26 December 2020 (UTC)
You can add author links with {{cite journal}} quite easily; missing articles will be red links, indicating to interested editors that an article is needed for that person. As for this citation immediately above, it is missing italics for "Styphelia" in the article title. They should be added. At that point, you are retyping the author names and the title, which (to my mind) reduces the advantages of Cite Q until Wikidata can store those values. – Jonesey95 (talk) 04:58, 26 December 2020 (UTC)
Perhaps you might give an example of such easy linking. I would appreciate it. MargaretRDonald (talk) 08:38, 26 December 2020 (UTC)
Sure. Like this: Crayn, D. M.; Hislop, M. C.; Puente-Lelièvre, C. (2020). "A phylogenetic recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae)". Australian Systematic Botany. 33 (2): 137–168. doi:10.1071/SB18050. ISSN 1030-1887. Wikidata Q102898970. – Jonesey95 (talk) 16:56, 26 December 2020 (UTC)
But the title should appear as "A phylogenetic recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae)", i.e. with the genus name italicized. So even with all the authors' names re-entered, the citation is not correctly formatted. Right now, Cite Q does not support fixing it by the obvious {{Cite Q|Q102898970|first1=Darren M. |last1=Crayn |first2=Michael |last2=Hislop |first3=Caroline |last3=Puente-Lelièvre |title=A phylogenetic recircumscription of ''Styphelia'' (Ericaceae, Epacridoideae, Styphelieae)}}, since this produces Crayn, Darren M.; Hislop, Michael; Puente-Lelièvre, Caroline (2020). "A phylogenetic recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae)". Australian Systematic Botany. 33 (2): 137–168. doi:10.1071/SB18050. ISSN 1030-1887. Wikidata Q102898970.. [The third author's name is "Puente-Lelièvre" not "Puente-Lelievre".]
Cite Q is simply not ready for deployment yet. Peter coxhead (talk) 10:21, 26 December 2020 (UTC)
Also, in most of the articles I edit, I would also need to add |mode=cs1| name-list-style=amp}}. So, assuming that the Cite Q editors fix the italics, the reduction in typing amounts to the smallest part of the citation – the journal name, volume, pages, and permanent identifiers. This isn't nothing, but is it worth the extra obscurity of the wikitext? Peter coxhead (talk) 10:21, 26 December 2020 (UTC)
Italicisation is now fixed, although it only affects a tiny minority of citations. The author's name, Caroline Puente-Lelièvre, is rendered correctly and always has been. Nobody has to type author names and links if they just copy and paste them in the cases where they are needed.
"Cite Q is simply not ready for deployment yet": utter nonsense. You're ignoring the ability of a dynamic template to track any updates and to flag up when a source has been replaced or retracted. Nobody's forcing you to use CiteQ yourself, but it's not acceptable to badger editors who reach a different conclusion from yours on the balance between advantages and disadvantages. --RexxS (talk) 21:13, 26 December 2020 (UTC)
Re: "always has been": No. I fixed it on Wikidata, which, frustratingly, does not allow for normal edit summaries when making a change. If someone reverts my edit, the name will be broken here, but that change will not show up on the watchlist for this page, which may be why RexxS thought it had not changed. Sometimes I wonder WTF, how is any of this considered ready for prime time? – Jonesey95 (talk) 21:32, 26 December 2020 (UTC)
The template has always correctly dealt with the information in Wikidata. Of course if the information there is wrong, then it needs to be fixed there, but how on earth does that make the template not ready for deployment? The very act of using it here results in an improvement in the quality of information available to 300+ language wikis. If somebody vandalises the entry or reverts your correction, it is 75 times more likely to be noticed here than on Wikidata. It's really demoralising to see the kind of "Wikipedia is an island, and the other projects can go to hell" attitude on display. --RexxS (talk) 21:58, 26 December 2020 (UTC)
@RexxS: this is far from my attitude. I regularly edit taxon items in Wikidata for example. My view, based on my personal experience, and hence necessarily partial, is exactly the reverse. The far smaller number of editors at Wikidata seem not to accept that Wikidata should be a vital service to other projects and must therefore be designed to support the way in which those projects work, not vice versa. (An issue totally unconnected with Cite Q is the refusal to allow non-1:1 linking across projects, which causes real problems in linking taxon articles and in deploying {{Taxonbar}}. See User:Peter coxhead/Wikidata issues#Non-1:1 relationships. I'm far from indifferent to other projects; I've assisted other language wikis to transfer over parts of the automated taxobox system, for example.)
I really want Cite Q to work properly; it has the potential to save substantial amounts of editor time and produce better referencing. But it will only succeed in its aim if it fully respects the way in which all the different projects use citations. Here, this means that it must support the separation of names into last and first fields. As Cite Q is right now, it doesn't properly support the English Wikipedia's approach to citations, and is simply prejudicing editors here against it. Peter coxhead (talk) 10:19, 27 December 2020 (UTC)
My experiences at Wikidata have not been pleasant, but I understand that the editors there are not a homogeneous group. The issue that taxes me is the attitude that the database is designed to make it easy to add content, with scant regard to the problems of using that content later. Almost nobody understands that Wikipedia pages can't use the WDQS and that the tools we have to do that job are crude, slow and resource-hungry when we try to do anything complex. I intend to do a substantial reorganisation of how CiteQ works internally, but that takes time. If there were a simple means of accepting author (P50), author name string (P2093), object named as (P1932) and the many ways they can be formatted, along with the presence or absence of series ordinal (P1545) (and the possibility of gaps), and then reformat any of those into "last, first" format when required, believe me, I'd have done it by now. At some point, I would like to test a naïve reformatting for "last, first" and see what proportion then needs to employ a more complex algorithm.
The problem with trying to introduce a new template that potentially makes use of 25,000,000 database entries for use in up to 6,000,000 articles is that none of us can anticipate every possibility for things to go wrong. The last/first issue was, of course, entirely predictable, but we felt that the ability to manually override parameters would produce a workable template that still needed less effort than manually adding a citation. I am thoroughly discouraged by the thought that editors will become prejudiced against it, and it makes me wonder whether it is productive to spend any more time on it. --RexxS (talk) 17:07, 27 December 2020 (UTC)

@RexxS: the idea of pulling citations from a database is an obvious and very sound one, and I for one would be sad if it had to be abandoned. The real question is whether Wikidata can be that database. I'm sceptical that it can unless the first/last separation can be done there. Surely Wikidata entries for citations should be based on something like the COinS metadata which is generated by the citation templates, and which does provide fields for first, last, middle initial, etc. Otherwise we need to use or create some other database that does conform to this metadata model. Pigsonthewing surely knows about this? Peter coxhead (talk) 17:46, 27 December 2020 (UTC)

@RexxS: Please do not be discouraged. I had hoped that this airing of what some editors find problematic might be a way of recognising some deficiencies and fixing them. I have every intention of continuing to use cite Q (though not where references already include an external link and satisfy the first last issue). And indeed, many other editors also continue to use it. The capacity not to have to revisit articles to link authors is a major leap forward, and the suggestion that all authors could be red-linked as an alternative is in my view silly when many may never satisfy notability criteria. MargaretRDonald (talk) 20:35, 27 December 2020 (UTC) And remember that those taking part in the discussion are but a tiny subsection of wikipedia and wikidata editors. MargaretRDonald (talk) 20:38, 27 December 2020 (UTC)
I also think that Cite Q has potential, but right now, with Wikidata's limitations, it is too easy to misuse it. I too have been mystified and frustrated by my forays into Wikidata, and fail to understand why there is not an easy way to use markup in data values, or provide separated surnames and first names for authors, or provide edit summaries when making a change to a piece of data(!!!), or find the help that I am looking for (this last one is probably my failing). The very useful {{Cite doi}} system of templates, which did everything that MargaretRDonald is hoping that Cite Q will someday do, was wiped out on en.WP years ago, with the promise that the holy grail of Wikidata would replace it with something far better, but that promise has been a hollow one. I am happy to help editors here improve this template; I just want to ensure that it is used in a way that makes en.WP better. If Wikidata and other WPs are improved along the way, that is great. – Jonesey95 (talk) 23:40, 27 December 2020 (UTC)

Wikidata weekly summary #448

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Ongoing: rC3 (remote Chaos Communication Congress). Several Wikidata-related talks and meetups happening on December 27th, 28th and 29th: introduction to Wikidata, Wikidata for datajournalists, Wikidata meetups in German and English, and a Query Service workshop. (see Wikipaka schedule for more details)
  • Other Noteworthy Stuff
    • Project Grants open call for proposals in 2021. Changes in the review process for Project Grants in 2021; the open call for community organizing proposals will be from January 11 to February 10 and the open call for software and research proposals will be from February 15 to March 16.
  • Development

Due to the winter holidays, the development team is taking a break and no deployment is happening for Wikidata at the moment :)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

A New Year With Women in Red!

Women in Red | January 2021, Volume 7, Issue 1, Numbers 182, 184, 185, 186, 187, 188


Online events:


Other ways to participate:

Facebook | Instagram | Pinterest | Twitter

--Megalibrarygirl (talk) 03:02, 29 December 2020 (UTC) via MassMessaging

Wikidata weekly summary #449

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Other Noteworthy Stuff
  • Development
    • Due to the winter holidays, no deployment has happened for Wikidata in the last two weeks.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Wikidata weekly summary #485

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Upcoming:
      • WikidataCon update: you can now check in the program of the first day of the online conference
      • Transbordados: WikidataCon's preconference for Latin America - September 14, 21 and 28 (21h UTC) - with simultaneous translation for Portuguese and Spanish, via YouTube - set of events to discuss Wikidata and decoloniality, knowledge organization and digital dissemination of collections in Latin America contexts. Join us!
        • 14/09 - Towards a decolonial wiki: overflowing knowledge from the Latin American horizon - speakers: Amanda Jurno (Wiki Movimento Brasil), Bianca Santana (journalist, writer and activist) and Silvia Gutiérrez (El Colégio de México) - watch it in PT-BR / ES
        • 21/09 - The universe of libraries: Wikidata and the multiplication of knowledge potencies - speakers: Lilian Viana (GLAM das Bibliotecas da USP) and Maurício Genta (Wikimedia Argentina e Biblioteca Nacional da Argentina) - watch it in PT-BR / ES
        • 28/09 - Digital collections and Wikidata: organizing a network of knowledge - speakers: Evelin Heidel (a.k.a. Scann; Wikimedistas do Uruguai) and Karen Worcman (Museu da Pessoa) - watch it in PT-BR / ES
      • Demo of the Query Builder live on Twitch and in French by Vigneron, September 14 at 18:00 CEST
    • Ongoing:
      • Data Quality Days - several sessions happened over the past days and more are coming this week. Recordings, slides and notes are linked in the program
    • Past:
      • Forex - 36C3 Wikipaka WG: Live querying: let’s explore Wikidata together! - YouTube
  • Tool of the week
    • Wwwyzzerdd for Wikidata is a browser extension that allows you to view and edit Wikidata information from Wikipedia (demo video). Install it in Firefox or Chrome
  • Other Noteworthy Stuff
    • Face The Facts mobile app allows you to scan election posters and see the true facts about politicians.
    • Wikidata now has over 150,000 Senses on Lexemes!

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Wikidata weekly summary #486

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Press, articles, blog posts, videos
    • Videos
      • Mapping the Scottish Reformation - using Wikidata, Wikipedia's sister project - YouTube
      • OpenSym 2021: WDProp: Web Application to Analyse Multilingual Aspects of Wikidata Properties - YouTube
      • Wikipedia Weekly Network - LIVE Wikidata editing #53 (user scripts and gadgets that can help you edit) - YouTube


You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Books & Bytes – Issue 46

The Wikipedia Library

Books & Bytes
Issue 46, July – August 2021

  • Library design improvements deployed
  • New collections available in English and German
  • Wikimania presentation

Read the full newsletter

Sent by MediaWiki message delivery on behalf of The Wikipedia Library team --11:15, 22 September 2021 (UTC)

Wikidata weekly summary #487

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Open request for adminship: BrokenSegue (RfP scheduled to end after 27 September 2021 14:36 UTC)
  • Development
    • Changed the formatting of low year numbers so that they now show as e.g. “5 CE” instead of “5” to reduce ambiugity in dates like “March 5 (CE)” (phab:T104750)
    • Working on fixing an issue where two Properties could have the same label in a given language (phab:T289473)
    • Working on preventing a few more cases where two Items could have the same sitelink (phab:T291377)
    • Mismatch Finder: Continuing to work on showing mismatches on the results page so that they can be reviewed
    • Continuing to work on technical improvements to how changes on Wikidata are propagated to Wikipedia and the other Wikimedia projects

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

October 2021 at Women in Red

Women in Red | October 2021, Volume 7, Issue 10, Numbers 184, 188, 209, 210, 211


Online events:


Special event:


See also:


Other ways to participate:

Facebook | Instagram | Pinterest | Twitter

--Rosiestep (talk) 01:36, 29 September 2021 (UTC) via MassMessaging

Wikidata weekly summary #488

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Closed request for adminship: BrokenSegue. Welcome onboard \o/
  • Development
    • Finished preventing a case where the same sitelink could be added to two different Items (phab:T291377)
    • Continuing work on the Mismatch Finder. Currently focusing on showing the details of the mismatches to the person reviewing mismatches.
    • Continued work on not allowing two Properties to have the same label after undo/revert (phab:T289473)
    • Continuing work on improving how changes on Wikidata are propagated to Wikipedia and the other other Wikimedia projects. The new system is being rolled out to all wikis now. It should not change anything for editors and just be a technical improvement in the backend.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Wikidata weekly summary #489

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
  • Development
    • Mismatch Finder: We are continuing the work on the review part of the system. We are now working on letting reviewers indicate if the mismatch is on Wikidata, the other database, both or neither.
    • Fixed a bug where it was possible for two Properties to have the same label in a given language by undoing/reverting an edit (phab:T289473)
    • Fixed a confusing error message that was being shown when trying to save geoshape / tabular data that doesn’t exist (phab:T285758)
    • Removing some unnecessary entity link formatting in edit summaries and special pages to improve performance (phab:T292203)
    • Fixing an issue with invalid dates that the API accepts but should not (phab:T289417)
    • Migrated all Wikimedia wikis to use the new change dispatching system. This system is responsible for notifying the other wikis about edits made on Wikidata that affect their articles so the article is refreshed and edits are added to recent changes and watchlists.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:MargaretRDonald/Archive_8&oldid=1195902086"