"cid" is exactly what I wanted to ask about as well. What I've learned is that some wikis use an optional "cid" parameter https://it.wikipedia.org/wiki/Template:Cita#Parametro_cid_diverso_dal_cognome_autore, for example Italian Wikipedia's Template:Cita, that gives the rendered contents a known HTML id anchor. +1 if I understand correctly. This approach builds on web standards and even links elements beyond Cite refs. By "merge or split" CIDs what I imagine is simply that: * the CID is optional, * giving no CID results in an automatic anchor which should not be reusable from wikitext), and * there is one CID per main ref, so merging is done by relinking one main ref's subrefs over to the other main ref.
When you talk about a global CID namespace, I would be sure to avoid a global uniqueness requirement at the moment, it's enough that a CID is unique on its page and when transcluded. +1 that this should become possible in a later phase of the larger WikiCite https://wikicite.org/ project which builds on the current steps.
-Adam
On Fri, Aug 23, 2024 at 3:06 AM Samuel Klein meta.sj@gmail.com wrote:
My preference, now that subreferencing exists, would be to converge on a future where we have some FRBR-style clustering of sources (similar to what fatcat.wiki does for the range of different URLs / content hashes that refer to the same source, but compounded with the range of different ways it can be cited), which assigns CIDs, and lets curators explicitly merge/split CIDs where needed. Then we end up with one CID for each cluster of substantively identical sources.
This matches what any meta-analysis of citation usage, citation affect, source reliability, retraction, &c would want to make bidirectional source analyses useful. It's a bit of extra structural work up front, and would result in a CID namespace of O(100M) cited sources, but would be a clear and new public good useful immediately to our editors and to reuse and analysis beyond our projects.
I'm not sure what that means in the *immediate* future, but just as fatcat did when choosing its battles, a recognition that we will start using a CID namespace that supports future merges would let us start small and potentially refactor initial uses via merges into any slightly different future implementations.
On Thu, Aug 22, 2024 at 3:41 PM Strainu strainu10@gmail.com wrote:
I hit the same problem recently. My solution was very similar to what Adam proposed: build the same ref again (completely) and calculate the hash. Since in rowiki all interaction with Wikidata is through modules, it was trivial to extract the reference code and invoke it directly or from a template.
One nasty problem that I couldn't really solve nicely was that the CS1 module would add a templatestyle which on subst would be expanded to a different strip marker for each instance, causing "reference with same name and different content" errors. This meant I could use a template, but not substitute it. If I understand your use case correctly, you won't have this problem.
When this feature becomes available, you could simply adapt the template to generate the <ref extends> tag.
Hth, Strainu
Pe miercuri, 21 august 2024, Adam Wight adam.wight@wikimedia.de a scris:
Hi, I'm one of the developers working on this project. Thanks for the question! Currently, the state of our thinking around
reusing refs from a template is that it's problematic, but the simplest and safest existing workaround is to produce another ref in exactly the same way as the first. So if the CS1 family of templates is used (eg. Cite book / Literatur) then you can use the same or a similar template to generate the second ref, and if the parameters to CS1 match then your final refs will be identical and the footnote markers will be merged together into one symbol and one reflist item.
The second possibility would require a feature change which has some
questionable implications: that any two refs with identical content could be merged in reading mode, regardless of the "name" attribute. However, since the reference content can only be guaranteed to be identical if the same template is used, I believe the first solution (use the same underlying template and let it produce a name) is the best workaround for the moment.
Please do suggest any better ideas you might have... so far, it's been
hard to imagine what a more "stable link" might look like, maybe it's an explicit "cid" or HTML id, we're really not sure yet.
Regards, [[mw:User:Adamw]]
On Tue, Aug 20, 2024 at 10:47 AM Bináris wikiposta@gmail.com wrote:
I have just experienced a related problem recently. I am not sure if
it is in the scope of your project, so I just mention it here.
Original problem: a reference is given in Wikidata as source of death,
for example. It appears automatically in infobox.
Later in the article I need that for another purpose, and it will
appear on tha pege twice.
Question: can we make it appear once? Answer in huwiki: the link of Wikidata contains a hash, which can be
used as <ref name="this-hash"/>.
New problem: whenever the source is edited in Wikidata, the hash
regenerates, and the article will silently be spoiled. We can discover the error in ref name only accidentlly, and it is a head ache to guess the original.
Relation to this project: can we safely reuse the references
originating from Wikidata? Can it offer a stable link?
Or should I write this to Wikidata mailing list? _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
-- Adam Wight - Developer - Wikimedia Deutschland e.V. -
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
-- Samuel Klein @metasj w:user:sj +1 617 529 4266 _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/