There is currently a patch in gerrit, https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around for a few months. To me it seems like an easy patch with some obvious benefits.
JackMcbarn suggested this might need wider discussion/notice so putting it up here to get a little more visibility.
Erik B.
Please don't; signatures belong as a feature of the discussion and voting systems and don't belong in wikitext. They're crufty enough as is and I'd recommend against making them cruftier.
-- brion
On Tue, Sep 30, 2014 at 1:57 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
There is currently a patch in gerrit, https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around for a few months. To me it seems like an easy patch with some obvious benefits.
JackMcbarn suggested this might need wider discussion/notice so putting it up here to get a little more visibility.
Erik B. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Some folks in #wikimedia-parsoid are still real excited about the idea though, so a couple more notes should people decide they like it anyway. :)
* Consider either a wikitext wrapper like {{#sig:Username}} (my preference) or a markup tag like <sig>Username</sig> (Gabriel's preference I think?) to go in the wikitext; this will make the resulting sigs look less crufty in talk and vote pages (which do still exist, alas!)
* Use a span as the actual HTML rendering that can be parsoid-friendly and thus VisualEditor-friendly.
* Consider though whether the HTML should be "spoofable" and what happens if you do.
* Consider that old revisions and archived talk pages will not have this markup, so there could be inconsistency. Beware what you use it for etc.
-- brion
On Tue, Sep 30, 2014 at 2:28 PM, Brion Vibber bvibber@wikimedia.org wrote:
Please don't; signatures belong as a feature of the discussion and voting systems and don't belong in wikitext. They're crufty enough as is and I'd recommend against making them cruftier.
-- brion
On Tue, Sep 30, 2014 at 1:57 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
There is currently a patch in gerrit, https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around for a few months. To me it seems like an easy patch with some obvious benefits.
JackMcbarn suggested this might need wider discussion/notice so putting it up here to get a little more visibility.
Erik B. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Sep 30, 2014 at 6:00 PM, Brion Vibber bvibber@wikimedia.org wrote:
- Consider either a wikitext wrapper like {{#sig:Username}} (my preference)
or a markup tag like <sig>Username</sig> (Gabriel's preference I think?) to go in the wikitext; this will make the resulting sigs look less crufty in talk and vote pages (which do still exist, alas!)
I think {{#sig}} would be bad, since {{}} is for the preprocessor, which this shouldn't have anything to do with. <sig> wouldn't be bad though.
- Consider though whether the HTML should be "spoofable" and what happens
if you do.
Signatures are spoofable now. I don't think this is even worth worrying about.
Jackmcbarn
On Tue, Sep 30, 2014 at 6:05 PM, Jackmcbarn jackmcbarn@gmail.com wrote:
On Tue, Sep 30, 2014 at 6:00 PM, Brion Vibber bvibber@wikimedia.org wrote:
- Consider though whether the HTML should be "spoofable" and what happens
if you do.
Signatures are spoofable now. I don't think this is even worth worrying about.
The point of this exercise seems to be to be able to identify signatures programmatically in some manner that is supposed to be official "this is a signature, not just a blob of wikitext". But along with the officiality comes the need to consider what happens if someone puts an "official" signature (maybe for someone else) in the middle of their post.
OTOH, if you somehow strip the "official" signature markers then what happens when it's an archive bot copying posts to an archive? Or someone moving a misplaced talk page post to the correct location?
From the standpoint of programmatically detecting a signature, the above could be cleaned up and work well enough.
Would this mean that if people had a fancy sig, and they changed it, it would automatically update everywhere with this magic tag instead of just applying to new signatures? (Which might be cool)
Downside to that you might have some tricky issue where people change their sig after the fact to be something malicious (For some definition of malicious), and then all the old sigs change without an edit to track it and generally be a vehicle for mass vandalism. (Didn't that use to be an issue on /. ?)
I haven't looked at the actual patch yet, but based on the discussion it seems like this code would allow us to update pages if people's signatures changed? I too am not sure this is a good idea.
I do though support the idea of wrapping signatures in a <sig> markup to make it easier to programatically detect them. That <sig> markup could be rendered as a span with a class="sig" as well which allow those who are just scraping the HTML of the page to be able to detect them as well.
This also makes working out what the state of the page at time X quite hard for things like "Please note that I am being paid to edit by XYZ Inc." that come and go from month to month to be seen.
This is one of my biggest concerns as well.
Thank you, Derric Atzrott
The idea of <sig> seems fine to me as a way to semantically designate signatures, however I'd like to caution against using a <span> in the expanded text, as while it may not be an issue with WMF wikis, some third-party wikis format signatures like you would in a forum (in that there is a signature "block" underneath the post, alas I cannot find that wiki again so no example), and these signatures can contain block-level elements. Rendering to a <span> may break that style of discussion, perhaps we can instead render to a <div> and set display: inline for it in the default css. Then a wiki could override this to move it wherever or display it as a block if they so choose.
Another alternative is keep the span, but add a hook to allow extensions to fully modify the output (including changing the span to something else), that way we can keep the sig semantically valid for the 99.99% of them that are actually used inline.
Also, +1 from me on *not* automatically changing old sigs as they get updated, as we could lose valuable temporal information that way (such as the aforementioned "I'm being paid to edit" disclosure). Wrapping existing signatures in <sig> seems fine if someone wants to code that system, but that's the extent I would personally go with modifying existing signatures.
Regards, Ryan Schmidt
On Oct 1, 2014, at 7:42 AM, Derric Atzrott datzrott@alizeepathology.com wrote:
From the standpoint of programmatically detecting a signature, the above could be cleaned up and work well enough.
Would this mean that if people had a fancy sig, and they changed it, it would automatically update everywhere with this magic tag instead of just applying to new signatures? (Which might be cool)
Downside to that you might have some tricky issue where people change their sig after the fact to be something malicious (For some definition of malicious), and then all the old sigs change without an edit to track it and generally be a vehicle for mass vandalism. (Didn't that use to be an issue on /. ?)
I haven't looked at the actual patch yet, but based on the discussion it seems like this code would allow us to update pages if people's signatures changed? I too am not sure this is a good idea.
I do though support the idea of wrapping signatures in a <sig> markup to make it easier to programatically detect them. That <sig> markup could be rendered as a span with a class="sig" as well which allow those who are just scraping the HTML of the page to be able to detect them as well.
This also makes working out what the state of the page at time X quite hard for things like "Please note that I am being paid to edit by XYZ Inc." that come and go from month to month to be seen.
This is one of my biggest concerns as well.
Thank you, Derric Atzrott
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 1 October 2014 08:17, Ryan Schmidt skizzerz@gmail.com wrote:
The idea of <sig> seems fine to me as a way to semantically designate signatures, however I'd like to caution against using a <span> in the expanded text, as while it may not be an issue with WMF wikis, some third-party wikis format signatures like you would in a forum (in that there is a signature "block" underneath the post, alas I cannot find that wiki again so no example), and these signatures can contain block-level elements. Rendering to a <span> may break that style of discussion, perhaps we can instead render to a <div> and set display: inline for it in the default css. Then a wiki could override this to move it wherever or display it as a block if they so choose.
Another alternative is keep the span, but add a hook to allow extensions to fully modify the output (including changing the span to something else), that way we can keep the sig semantically valid for the 99.99% of them that are actually used inline.
Or, more simply, span.sig { display: block; } in your site CSS, rather than putting the burden on, as you put it, the "99.99%"… :-)
J.
2014-10-01 17:17 GMT+02:00 Ryan Schmidt skizzerz@gmail.com:
The idea of <sig> seems fine to me as a way to semantically designate signatures, however I'd like to caution against using a <span> in the expanded text, as while it may not be an issue with WMF wikis, some third-party wikis format signatures like you would in a forum (in that there is a signature "block" underneath the post, alas I cannot find that wiki again so no example), and these signatures can contain block-level elements. Rendering to a <span> may break that style of discussion, perhaps we can instead render to a <div> and set display: inline for it in the default css. Then a wiki could override this to move it wherever or display it as a block if they so choose.
Using a <div> inside list markup (and we inexplicably use list markup for discussions) will probably cause HTML Tidy to throw up all over the output, a <span> is probably the only option. As you can see by the list of blockers to https://bugzilla.wikimedia.org/show_bug.cgi?id=2542 , Tidy will horribly break most of interesting kinds of markup.
(Not that I think trying to mark up sigs is a very good idea in general, for the reasons Brion mentioned.)
My summary based on reading and looking at discussions:
Options are:
(a) use a regexp to identify sigs -- dirty, but can apply to old discussions (b) new markup <span>/<sig>/{{#sig:..}} added via PST -- cleaner, but applies only to new discussions, but new wikitext markup (c) don't do it and leave it for discussion systems to handle signatures
As for what direction to go with (a)/(b)/(c), that is a different issue.
If (b), I think parsoid folks (and jackmcbarn) are advocating for a markup like <sig>..</sig> rather than inline <span> as in the patch or a parser function. The <sig> allows for rendering to be semantic, html to be tweaked as needs change (with the same markup), etc.
Subbu.
On 09/30/2014 05:00 PM, Brion Vibber wrote:
Some folks in #wikimedia-parsoid are still real excited about the idea though, so a couple more notes should people decide they like it anyway. :)
- Consider either a wikitext wrapper like {{#sig:Username}} (my preference)
or a markup tag like <sig>Username</sig> (Gabriel's preference I think?) to go in the wikitext; this will make the resulting sigs look less crufty in talk and vote pages (which do still exist, alas!)
- Use a span as the actual HTML rendering that can be parsoid-friendly and
thus VisualEditor-friendly.
- Consider though whether the HTML should be "spoofable" and what happens
if you do.
- Consider that old revisions and archived talk pages will not have this
markup, so there could be inconsistency. Beware what you use it for etc.
-- brion
On Tue, Sep 30, 2014 at 2:28 PM, Brion Vibber bvibber@wikimedia.org wrote:
Please don't; signatures belong as a feature of the discussion and voting systems and don't belong in wikitext. They're crufty enough as is and I'd recommend against making them cruftier.
-- brion
On Tue, Sep 30, 2014 at 1:57 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
There is currently a patch in gerrit, https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around for a few months. To me it seems like an easy patch with some obvious benefits.
JackMcbarn suggested this might need wider discussion/notice so putting it up here to get a little more visibility.
Erik B. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Sep 30, 2014 at 3:11 PM, Subramanya Sastry ssastry@wikimedia.org wrote:
My summary based on reading and looking at discussions:
Options are:
(a) use a regexp to identify sigs -- dirty, but can apply to old discussions
This was written[1] for Echo a couple years ago at the beginning of the project. This particular implementation is far from perfect, but here are a couple of the complexities involved:
* a single regexp doesn't currently match timestamps in different languages, so a timestamp regex is generated based on the $wgContLang timestamp output. * wiki's each control their own signature[2]. Changing the signature exposed a bug[3] in Echo which caused it to stop sending mention notifications. * The fix[4] for above basically switches the code around to extract wikilinks from the wikitext and run their content through Title to determine if a link is to NS_USER, NS_USER_TALK, or the Contributions page of NS_SPECIAL, all of which appear in signatures.
From the standpoint of programmatically detecting a signature, the above
could be cleaned up and work well enough.
Erik B.
[1] https://github.com/wikimedia/mediawiki-extensions-Echo/blob/master/includes/...
[2] https://ru.wikipedia.org/wiki/MediaWiki:Signature [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=71353 [4] https://gerrit.wikimedia.org/r/#/c/163651/
(b) new markup <span>/<sig>/{{#sig:..}} added via PST -se- cleaner, but
applies only to new discussions, but new wikitext markup (c) don't do it and leave it for discussion systems to handle signatures
As for what direction to go with (a)/(b)/(c), that is a different issue.
If (b), I think parsoid folks (and jackmcbarn) are advocating for a markup like <sig>..</sig> rather than inline <span> as in the patch or a parser function. The <sig> allows for rendering to be semantic, html to be tweaked as needs change (with the same markup), etc.
Subbu.
On 09/30/2014 05:00 PM, Brion Vibber wrote:
Some folks in #wikimedia-parsoid are still real excited about the idea though, so a couple more notes should people decide they like it anyway. :)
- Consider either a wikitext wrapper like {{#sig:Username}} (my
preference) or a markup tag like <sig>Username</sig> (Gabriel's preference I think?) to go in the wikitext; this will make the resulting sigs look less crufty in talk and vote pages (which do still exist, alas!)
- Use a span as the actual HTML rendering that can be parsoid-friendly and
thus VisualEditor-friendly.
- Consider though whether the HTML should be "spoofable" and what happens
if you do.
- Consider that old revisions and archived talk pages will not have this
markup, so there could be inconsistency. Beware what you use it for etc.
-- brion
On Tue, Sep 30, 2014 at 2:28 PM, Brion Vibber bvibber@wikimedia.org wrote:
Please don't; signatures belong as a feature of the discussion and voting
systems and don't belong in wikitext. They're crufty enough as is and I'd recommend against making them cruftier.
-- brion
On Tue, Sep 30, 2014 at 1:57 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
There is currently a patch in gerrit,
https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around for a few months. To me it seems like an easy patch with some obvious benefits.
JackMcbarn suggested this might need wider discussion/notice so putting it up here to get a little more visibility.
Erik B. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 09/30/2014 05:23 PM, Erik Bernhardson wrote:
This was written[1] for Echo a couple years ago at the beginning of the project. This particular implementation is far from perfect, but here are a couple of the complexities involved:
- a single regexp doesn't currently match timestamps in different
languages, so a timestamp regex is generated based on the $wgContLang timestamp output.
- wiki's each control their own signature[2]. Changing the signature
exposed a bug[3] in Echo which caused it to stop sending mention notifications.
- The fix[4] for above basically switches the code around to extract
wikilinks from the wikitext and run their content through Title to determine if a link is to NS_USER, NS_USER_TALK, or the Contributions page of NS_SPECIAL, all of which appear in signatures.
From the standpoint of programmatically detecting a signature, the above could be cleaned up and work well enough.
I agree. If we can solve this with a reasonable amount of tech and elbow grease in a way that works for old discussions too, then I think we should do so.
Gabriel
On 9/30/14, Brion Vibber bvibber@wikimedia.org wrote:
Some folks in #wikimedia-parsoid are still real excited about the idea though, so a couple more notes should people decide they like it anyway. :)
- Consider either a wikitext wrapper like {{#sig:Username}} (my preference)
or a markup tag like <sig>Username</sig> (Gabriel's preference I think?) to go in the wikitext; this will make the resulting sigs look less crufty in talk and vote pages (which do still exist, alas!)
- Use a span as the actual HTML rendering that can be parsoid-friendly and
thus VisualEditor-friendly.
- Consider though whether the HTML should be "spoofable" and what happens
if you do.
- Consider that old revisions and archived talk pages will not have this
markup, so there could be inconsistency. Beware what you use it for etc.
-- brion
On Tue, Sep 30, 2014 at 2:28 PM, Brion Vibber bvibber@wikimedia.org wrote:
Please don't; signatures belong as a feature of the discussion and voting systems and don't belong in wikitext. They're crufty enough as is and I'd recommend against making them cruftier.
-- brion
On Tue, Sep 30, 2014 at 1:57 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
There is currently a patch in gerrit, https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around for a few months. To me it seems like an easy patch with some obvious benefits.
JackMcbarn suggested this might need wider discussion/notice so putting it up here to get a little more visibility.
Erik B. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Would this mean that if people had a fancy sig, and they changed it, it would automatically update everywhere with this magic tag instead of just applying to new signatures? (Which might be cool)
Downside to that you might have some tricky issue where people change their sig after the fact to be something malicious (For some definition of malicious), and then all the old sigs change without an edit to track it and generally be a vehicle for mass vandalism. (Didn't that use to be an issue on /. ?)
--bawolff
On 30 September 2014 20:58, Brian Wolff bawolff@gmail.com wrote:
Would this mean that if people had a fancy sig, and they changed it, it would automatically update everywhere with this magic tag instead of just applying to new signatures? (Which might be cool)
Downside to that you might have some tricky issue where people change their sig after the fact to be something malicious (For some definition of malicious), and then all the old sigs change without an edit to track it and generally be a vehicle for mass vandalism. (Didn't that use to be an issue on /. ?)
This also makes working out what the state of the page at time X quite hard for things like "Please note that I am being paid to edit by XYZ Inc." that come and go from month to month to be seen. I'd not be a fan of changing this expectation without a huge amount of prior notice, and definitely not doing to retrospectively…
J.
On Tue, Sep 30, 2014 at 8:58 PM, Brian Wolff bawolff@gmail.com wrote:
Would this mean that if people had a fancy sig, and they changed it, it would automatically update everywhere with this magic tag instead of just applying to new signatures? (Which might be cool)
Other downside of this would be the performance hit of looking up all those signatures. Some pages have hundreds, if not thousands, of different users' signatures.
Jackmcbarn
On 01/10/14 01:25, Jackmcbarn wrote:
On Tue, Sep 30, 2014 at 8:58 PM, Brian Wolff bawolff@gmail.com wrote:
Would this mean that if people had a fancy sig, and they changed it, it would automatically update everywhere with this magic tag instead of just applying to new signatures? (Which might be cool)
Other downside of this would be the performance hit of looking up all those signatures. Some pages have hundreds, if not thousands, of different users' signatures.
Another issue if you try to do something like this is that on some projects, the timestamps are often included inside the signature. And given the visual disparity of the signatures themselves, we also sometimes just look at prominently styled signatures and gauge the general time period from the appearance instead of reading the entire timestamp, since reading visual affordances like that tends to be quicker.
Wrapping the entire thing in a <sig> without trying to do anything overly fancy to the content, however, wouldn't pose any problems here.
-I
wikitech-l@lists.wikimedia.org