*Apologies for cross-posting*
Hello. I'd like to let you know that Wikimedia Deutschland’s Technical Wishes https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes team is planning to deploy a new feature for sub-referencing.
For many years, community members have requested https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Sub-referencing/History#Where_a_solution_to_this_problem_was_requested_%E2%80%93_examples an easy way to re-use references with different details. Soon, there will be a MediaWiki solution for this, and it will work in wikitext and in Visual Editor. If you want to know more, take a look at this project page https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Sub-referencing.
Please note that the new feature will be *optional* – if you prefer other ways of referencing, you can keep using them. However, you will probably encounter sub-references in articles written by others.
To make sure that sub-referencing works well for you, we are asking for your feedback: https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Sub-referencing#Test
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Sub-referencing#Test - https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Sub-referencing#TestPlease try https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Sub-referencing#Test the current state of development on beta wiki and let us know what you think https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Sub-referencing . - Sign up here https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Sub-referencing/Sign-up to get updates and/or invitations to participate in user research activities.
We plan to deploy this feature to the Wikimedia wikis later this year. Before that, we will check in with creators/maintainers of reference-related tools and templates. And we will send more announcements when we get closer to the deployment date. If you can already help us spread the message on your wikis, that would be much appreciated!
For Wikimedia Deutschland's Technical Wishes team, Johanna Strodt Community communications Technical Wishes
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?
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/
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. - https://wikimedia.de
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/
"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/
On Fri, Aug 23, 2024, 9:00 AM Adam Wight adam.wight@wikimedia.de wrote:
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.
Sounds reasonable. Couldn't attempt a larger uniqueness requirement anyway without a working global namespace ;) and some sort of cache to make checking against it fast. S
wikitech-l@lists.wikimedia.org