Page MenuHomePhabricator
Feed Advanced Search

Jul 4 2020

Jc86035 added a comment to T169320: Navbars and hlists don't display or work properly on mobile site.

This is about Minerva.

Jul 4 2020, 2:40 PM · MinervaNeue (Tracking), Reading-Web-Local-Wiki-Issues, CSS

May 14 2020

Jc86035 added a comment to T252795: Ogg Vorbis audio from the Score extension is not transcoded to MP3 on iOS.

This might be related to T68722, but I'm not sure if this particular issue occurs only in Safari or in the app as well.

May 14 2020, 4:29 PM · Browser-Support-Apple-Safari, MediaWiki-extensions-Score
Jc86035 created T252795: Ogg Vorbis audio from the Score extension is not transcoded to MP3 on iOS.
May 14 2020, 4:27 PM · Browser-Support-Apple-Safari, MediaWiki-extensions-Score

May 6 2020

Jc86035 added a comment to T249293: Prevent DiscussionTools from being enabled on pages they should not be.

Are these pages marked in anyway that would let us know they are archived?

May 6 2020, 4:49 PM · Editing-team (FY2020-21 Kanban Board), OWC2020, DiscussionTools

Apr 21 2020

Jc86035 added a comment to T244672: Many file descriptions added from Commons Android app (Suggested Edits) are unhelpful.

Has there been any progress on this issue? Within my watchlist, the distribution of edits seems to remain about the same as it was three months ago:

  • A few users are labelling some of the images based on the wheelchair. (Those images form a minority of my uploads but the wheelchair still seems to be by far the most or only recognizable feature.)
  • A few users are copying or translating the generic English caption.
  • A few users appear to have a fairly poor command of English but are trying anyway, with mixed results (1, 2, 3, 4).
  • The rest – including some of the former group – appear to be disseminating their own personal information (primarily names and locations), which could be problematic from a privacy perspective if it's not considered self-promotion.
Apr 21 2020, 8:12 AM · Structured-Data-Backlog, Wikipedia-Android-App-Backlog, Commons, Android-app-feature-Description-Editing
Jc86035 removed a watcher for DiscussionTools: Jc86035.
Apr 21 2020, 7:04 AM
Jc86035 removed a watcher for OWC2020: Jc86035.
Apr 21 2020, 2:34 AM

Apr 8 2020

Jc86035 added a comment to T245628: Preview does not correctly parse five or more tildes at the end of the comment.

I don't mean to suggest that someone would actually be using five tildes, because there's no clear application for it. Sometimes people type three or five tildes instead of four by mistake; I've seen it several times. It's often left uncorrected, I think especially in contexts where it's obvious who authored the comment.

if a comment ends in a group of tildes, the automatic signature should only be omitted if the group contains 5k−1 tildes where k is a positive integer

The reason I suggested it in this way is that implementing it in this specific way would have this result:

  • Three or five tildes would result in the four-tilde signature being inserted automatically at the end of the comment (in addition to the three/five-tilde signature). The behaviour wouldn't change from the status quo for four tildes.
  • For longer strings of tildes, if the string of tildes would result in a four-tilde signature being emitted, then a duplicate one would not be added. However, this is probably unnecessary.
Apr 8 2020, 6:07 PM · Verified, MW-1.35-notes (1.35.0-wmf.30; 2020-04-28), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020 (OWC2020 Replying 1.0)

Apr 2 2020

Jc86035 added a comment to T237700: Require user signatures to contain a link to their user page, talk page or contributions.

@Izno Would it make more sense to have a blanket ban on all extension tags, rather than just TemplateStyles? I can't see <poem></poem> being useful in this context, for instance. Prohibiting magic words might also be appropriate. That said, the requirements seem to be primarily directed at making parsing easier, whereas the use of TemplateStyles probably wouldn't affect parsing in a meaningful way.

Apr 2 2020, 1:56 PM · User-Ryasmeen, MW-1.36-notes (1.36.0-wmf.1; 2020-07-21), MW-1.35-notes (1.35.0-wmf.41; 2020-07-14), Editing-team (FY2020-21 Kanban Board), DiscussionTools, OWC2020, MediaWiki-Parser, MediaWiki-User-preferences
Jc86035 added a comment to T249184: Make "Reply" link easier for people at ar.wiki to discover/notice.

What about making the formatting the same as or similar to the section edit buttons (i.e. "[ reply ]" in Vector and most skins, "reply" with an icon to the left in Timeless)?

Apr 2 2020, 1:52 PM · Editing Design, OWC2020 (OWC2020 Replying 1.0)

Apr 1 2020

Jc86035 added a comment to T249036: Enable the Reply tool in the Project namespace (Wikipedia:) and other "wgExtraSignatureNamespaces".

No, that's not what I meant. The magic word is not on the subpages (or on some of their parent pages, for that matter), which means that users will not be able to comment on those pages using the extension unless the magic word is added. At the same time, it may be inappropriate to add the magic word (e.g. because the edit button would create the wrong section header level).

Apr 1 2020, 5:24 PM · Skipped QA, MW-1.35-notes (1.35.0-wmf.30; 2020-04-28), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools
Jc86035 added a comment to T246035: Videojs player for audio opens a dialog, which is unexpected.

As a direct UI comparison, SoundCloud and Spotify's websites display a horizontal bar along the bottom of the screen for audio player controls. Usability-wise, I think something like that (if possible with CSS) would be an improvement over the full screen overlay, which seems unnecessary.

Apr 1 2020, 4:31 PM · VideoJS player
Jc86035 added a comment to T246035: Videojs player for audio opens a dialog, which is unexpected.

Would it be significantly more difficult to replicate the functionality of the old player? I would consider this a regression, since it would no longer be possible to read and listen at the same time in the same window. (Even if it has to be in a pop-up overlay, it doesn't mean that the overlay has to cover 100% of the screen.)

Apr 1 2020, 4:13 PM · VideoJS player
Jc86035 added a project to T246035: Videojs player for audio opens a dialog, which is unexpected: Regression.
Apr 1 2020, 4:10 PM · VideoJS player
Jc86035 merged T249130: Audio player should not be a pop-up by default into T246035: Videojs player for audio opens a dialog, which is unexpected.
Apr 1 2020, 4:10 PM · VideoJS player
Jc86035 merged task T249130: Audio player should not be a pop-up by default into T246035: Videojs player for audio opens a dialog, which is unexpected.
Apr 1 2020, 4:10 PM · Regression, TimedMediaHandler
Jc86035 updated the task description for T249130: Audio player should not be a pop-up by default.
Apr 1 2020, 4:06 PM · Regression, TimedMediaHandler
Jc86035 updated the task description for T249130: Audio player should not be a pop-up by default.
Apr 1 2020, 4:06 PM · Regression, TimedMediaHandler
Jc86035 created T249130: Audio player should not be a pop-up by default.
Apr 1 2020, 4:04 PM · Regression, TimedMediaHandler
Jc86035 added a comment to T249036: Enable the Reply tool in the Project namespace (Wikipedia:) and other "wgExtraSignatureNamespaces".

What about discussion pages in project space that don't use __NEWSECTIONLINK__, such as subpages of project pages like Wikipedia:Articles for deletion? Would communities be expected to add the magic word to all of those pages (or templates on those pages)?

Apr 1 2020, 1:30 PM · Skipped QA, MW-1.35-notes (1.35.0-wmf.30; 2020-04-28), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools

Mar 19 2020

Jc86035 added a comment to T246058: Should not be able to post empty reply.

I would note that there are some rare cases where posting "empty comments" is actually done at the moment, such as WikiProjects' lists of users and situations like petitions and votes. It might not really make sense to use this tool to do that, but if the current use cases continue to exist, it may be necessary to allow empty comments to be posted.

Mar 19 2020, 12:10 AM · Verified, MW-1.35-notes (1.35.0-wmf.25; 2020-03-24), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020 (OWC2020 Replying 1.0)

Mar 5 2020

Jc86035 added a comment to T154844: New Wikitext Editor: Previews should use the article-view rendering engine.

But wouldn't a change of the rendering engine also fix T212085?

It might well, but this task has been largely dormant for almost three years. I think that task will probably be resolved some other way.

Mar 5 2020, 3:52 PM · VisualEditor, VisualEditor-MediaWiki-2017WikitextEditor

Feb 29 2020

Jc86035 added a comment to T240360: Determine our approach for displaying date and time a comment was made, in a user's local timezone and preferred date format.

I don't think it makes sense to change the timestamp display upon hovering by default, since it could be difficult for users to discover this (particularly on mobile). I think it would be nice to have as an option, though. Similarly, I don't think the relative time should be the only string displayed by default, particularly if it isn't made clear whether the string is based on the current time or the time that the page was loaded.

Feb 29 2020, 5:39 PM · DiscussionTools, Editing-team (Tracking), Editing Design, OWC2020
Jc86035 added a comment to T240360: Determine our approach for displaying date and time a comment was made, in a user's local timezone and preferred date format.

You know, you could just display both...

Feb 29 2020, 5:30 PM · DiscussionTools, Editing-team (Tracking), Editing Design, OWC2020

Feb 25 2020

Jc86035 removed a watcher for Desktop Improvements: Jc86035.
Feb 25 2020, 5:05 PM
Jc86035 added a comment to T245890: Enable DiscussionTools on pages where `__NEWSECTIONLINK__` is present.

Other previously discussed possibilities, I think, would include

  • allowing this to be enabled or disabled for pages with a certain prefix (e.g. all subpages of Wikipedia:Articles for deletion)
  • recognizing discussions automatically (e.g. by detecting signatures on every page with the default content model regardless of namespace)
  • using the magic word to indicate a discussion type (e.g. #::::-format indentation, or the future equivalent if the syntax changes, for votes) and/or other metadata
Feb 25 2020, 5:03 PM · Skipped QA, Editing-team (FY2020-21 Kanban Board), MW-1.35-notes (1.35.0-wmf.27; 2020-04-07), OWC2020, DiscussionTools
Jc86035 added a comment to T246073: Consider including additional metadata in signature output.

I've mentioned this a few times elsewhere, but I thought it would be clearer if this were proposed as a discrete task.

Feb 25 2020, 9:11 AM · Editing-team, MediaWiki-Parser, OWC2020, DiscussionTools
Jc86035 created T246073: Consider including additional metadata in signature output.
Feb 25 2020, 9:10 AM · Editing-team, MediaWiki-Parser, OWC2020, DiscussionTools

Feb 24 2020

Jc86035 added a comment to T245960: Late reply to early comment added in unexpected place in the discussion.

@Whatamidoing-WMF, I think it would help if you were to provide an example of a page on which this happens, since I think this is already supposed to be handled for the case in which all of the existing comments are correctly parsed.

Feb 24 2020, 10:07 AM · Editing-team (Q3 2019-2020 Kanban Board), OWC2020 (OWC2020 Replying 1.0), DiscussionTools

Feb 19 2020

Jc86035 created T245628: Preview does not correctly parse five or more tildes at the end of the comment.
Feb 19 2020, 2:26 PM · Verified, MW-1.35-notes (1.35.0-wmf.30; 2020-04-28), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020 (OWC2020 Replying 1.0)

Feb 9 2020

Jc86035 updated the task description for T244672: Many file descriptions added from Commons Android app (Suggested Edits) are unhelpful.
Feb 9 2020, 8:46 PM · Structured-Data-Backlog, Wikipedia-Android-App-Backlog, Commons, Android-app-feature-Description-Editing
Jc86035 updated the task description for T244672: Many file descriptions added from Commons Android app (Suggested Edits) are unhelpful.
Feb 9 2020, 8:42 PM · Structured-Data-Backlog, Wikipedia-Android-App-Backlog, Commons, Android-app-feature-Description-Editing
Jc86035 created T244672: Many file descriptions added from Commons Android app (Suggested Edits) are unhelpful.
Feb 9 2020, 8:41 PM · Structured-Data-Backlog, Wikipedia-Android-App-Backlog, Commons, Android-app-feature-Description-Editing

Feb 5 2020

Jc86035 added a comment to T237175: Caption display errors with beta audio player on pages with multiple audio files with captions.
Feb 5 2020, 9:15 AM · VideoJS player, TimedMediaHandler-TimedText

Feb 4 2020

Jc86035 added a watcher for Desktop Improvements: Jc86035.
Feb 4 2020, 9:45 AM

Jan 27 2020

Jc86035 added a comment to T241391: Unable to respond to specific comments.

[...] a comment begins on the line after a signature, and it runs to the end of the next signature. Any markup or change of indentation in between is irrelevant.

Jan 27 2020, 10:31 AM · Verified, Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020

Jan 26 2020

Jc86035 updated the task description for T243705: Lexemes: in English, "unknown language" appears instead of "English" in search, and "Q1860" appears instead of "English" on lexeme pages.
Jan 26 2020, 8:57 AM · MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), User-Addshore, Regression, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞), Wikidata Lexicographical data, MediaWiki-Internationalization, Wikidata
Jc86035 renamed T243705: Lexemes: in English, "unknown language" appears instead of "English" in search, and "Q1860" appears instead of "English" on lexeme pages from Lexemes: in English and qqx only, "unknown language" appears instead of "English" in search, and "Q1860" appears instead of "English" on lexeme pages to Lexemes: in English, "unknown language" appears instead of "English" in search, and "Q1860" appears instead of "English" on lexeme pages.
Jan 26 2020, 8:56 AM · MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), User-Addshore, Regression, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞), Wikidata Lexicographical data, MediaWiki-Internationalization, Wikidata
Jc86035 updated the task description for T243705: Lexemes: in English, "unknown language" appears instead of "English" in search, and "Q1860" appears instead of "English" on lexeme pages.
Jan 26 2020, 8:49 AM · MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), User-Addshore, Regression, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞), Wikidata Lexicographical data, MediaWiki-Internationalization, Wikidata
Jc86035 created T243705: Lexemes: in English, "unknown language" appears instead of "English" in search, and "Q1860" appears instead of "English" on lexeme pages.
Jan 26 2020, 8:47 AM · MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), User-Addshore, Regression, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞), Wikidata Lexicographical data, MediaWiki-Internationalization, Wikidata

Jan 22 2020

Jc86035 added a comment to T230683: New syntax for multiline list items / talk page comments.

So, in the interest of reducing the number of proposals to evaluate, I would pool them all in one class of proposals and distinguish them in terms of whether they propose custom syntax only for talk-page-list items, all-list-items, or reuse syntax from other uses. And perhaps other concerns specific to the proposals (ex: <<dd> has other issues).

Jan 22 2020, 11:12 AM · DiscussionTools, OWC2020, MediaWiki-Parser
Jc86035 added a comment to T243251: Conduct a control test of as-is new discussion workflow.

Might it be useful to test on a Project-namespace discussion page as well, such as w:en:Wikipedia:Help desk?

Jan 22 2020, 11:12 AM · OWC2020 (New Discussion 1.0), Editing Design, Editing-team

Jan 18 2020

Jc86035 added a comment to T194311: The interface direction of the Lemma is based on direction of the user interface and not the Lemma's language.

This would also be an issue with certain CJK Unicode characters, since their rendering and stroke order may vary between languages.

Jan 18 2020, 3:12 AM · Design, WMDE-Design, RTL, Wikidata, Wikidata Lexicographical data, I18n

Jan 13 2020

Jc86035 added a comment to T235923: Replies v1.0: release replying to specific comments.

How many levels of indentation does the tool need to support

For what it's worth, {{outdent}} on the English Wikipedia has a default of 10. I've almost never seen it used at 5 levels. I think for 1.0 it would be acceptable to never outdent, particularly since the existing outdent templates are not consistent across wikis. (In future versions it might make sense to introduce a parser function or CSS class to avoid having to rely on templates.)

Jan 13 2020, 5:57 PM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools
Jc86035 added a comment to T239978: Flexibility in adding to and creating discussions.

As part of this work, we'd value knowing what about the existing workflows stands out to you. More specifically, we are curious to know:

  • What issues/point of frustration do you encounter when creating a new discussion section and when adding a new comment in an existing section without any comments? What about these workflows do you think could be improved?
Jan 13 2020, 1:27 PM · DiscussionTools, OWC2020

Jan 10 2020

Jc86035 added a comment to T230683: New syntax for multiline list items / talk page comments.

This is a comparison table of the various proposals and existing constructs that I'm currently aware of, with a focus on the syntax differences. (n is the nesting level; indicates a line break; the "Compatible?" column indicates whether the proposal would allow mixing of old and new syntax.) There (understandably) aren't a lot of editors putting out fully realized proposals, so I've had to guess how Wnt and Jeblad's proposals would have worked syntax-wise.

Jan 10 2020, 10:57 AM · DiscussionTools, OWC2020, MediaWiki-Parser
Jc86035 added a comment to T230683: New syntax for multiline list items / talk page comments.
: Hi, I'm power user one! I've been editing for decades, never gonna change my markup.

On the other hand, it's nominally acceptable to correct people's formatting errors, though it's not clear what the actual community reaction would be if people started fixing talk page nesting all the time. It would have to happen at some point depending on the syntax, since there would be tens of thousands of ongoing discussions at the point in time that the syntax is introduced, but it would probably be somewhat messy unless the implementation's unusually smooth.

Jan 10 2020, 10:40 AM · DiscussionTools, OWC2020, MediaWiki-Parser

Jan 9 2020

Jc86035 added a comment to T230683: New syntax for multiline list items / talk page comments.

Although in implementation I'd suggest handling it more like you'd probably handle any of the above proposals: collect the lines in the block, parse them, then inject them into the nested structure.

Jan 9 2020, 4:49 PM · DiscussionTools, OWC2020, MediaWiki-Parser
Jc86035 updated subscribers of T230683: New syntax for multiline list items / talk page comments.

Is it really appropriate to keep using definition lists for comment nesting? As @stjn notes in this topic, it's semantically incorrect to do so. If new syntax is introduced, it just doesn't make sense to me to keep using definition lists for nesting in discussions. Perhaps it could be justified from a usability POV, but it otherwise seems short-sighted.

Jan 9 2020, 3:02 PM · DiscussionTools, OWC2020, MediaWiki-Parser

Jan 8 2020

Jc86035 added a comment to T241388: When inserting {{welcome}} reply, preview is indented differently to saved content.

@Jc86035, are you able to expand on the "reliable" point a bit more? What do you think would make the preview more "reliable" than it currently is?

Jan 8 2020, 10:27 AM · Editing-team (Tracking), DiscussionTools
Jc86035 added a watcher for DiscussionTools: Jc86035.
Jan 8 2020, 10:22 AM

Dec 30 2019

Jc86035 updated the task description for T239978: Flexibility in adding to and creating discussions.
Dec 30 2019, 11:09 AM · DiscussionTools, OWC2020
Jc86035 updated the task description for T239978: Flexibility in adding to and creating discussions.
Dec 30 2019, 11:06 AM · DiscussionTools, OWC2020
Jc86035 added a comment to T241388: When inserting {{welcome}} reply, preview is indented differently to saved content.

The task you wrote says to change the rendered page to match the preview. That's logically backwards. Making random changes to how pages render is dangerous, potentially breaking an unknown number of existing pages.

Dec 30 2019, 11:04 AM · Editing-team (Tracking), DiscussionTools

Dec 24 2019

Jc86035 added a comment to T241388: When inserting {{welcome}} reply, preview is indented differently to saved content.

This is somewhat similar to T240696: Make linebreak behaviour consistent regardless of indentation level, in that both issues result from the way that indentation is added for replies. I think it would be appropriate to give both tasks a shared parent task, perhaps titled something like "handle markup consistently in all comments to avoid unexpected behaviour".

Dec 24 2019, 12:06 AM · Editing-team (Tracking), DiscussionTools

Dec 19 2019

Jc86035 added projects to T240347: Introduce linter, error messages, tracking categories or similar for discussion pages syntax: MediaWiki-extensions-Linter, Parsoid.
Dec 19 2019, 12:54 AM · DiscussionTools, Parsoid, MediaWiki-extensions-Linter, OWC2020

Dec 18 2019

Jc86035 added a comment to T240640: [Feedback] Not supporting adding multiple signatures in a comment.

Regarding the RfC example, if there is any sort of markup change (e.g. T230683), it's possible that comments could become more clearly delineated (both on the rendered page and in the wikitext source). In the case where the end of the comment is marked only by the signature, the code example would continue to work; but in the case where the end of the comment is marked by something else, it's very possible that the software would inadvertently include the section headers inside the comment (and possibly other things; e.g., if the user chooses not to sign the long explanation, they might not want that inside their comment either).

Dec 18 2019, 3:42 PM · User-Ryasmeen, Verified, OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools
Jc86035 added a comment to T212085: TemplateStyles not loaded in NWE preview.

This appears to be more or less the same issue as in T188143: VisualEditor does not like TemplateStyles; the <style>...</style> tags are gone and only <span about="#mwt1"> </span> tags are left.

Dec 18 2019, 3:23 AM · User-Ryasmeen, MW-1.35-notes (1.35.0-wmf.24; 2020-03-17), Editing-team (Q3 2019-2020 Kanban Board), VisualEditor, VisualEditor-MediaWiki-2017WikitextEditor, TemplateStyles
Jc86035 created T241025: 2017 wikitext editor does not like TemplateStyles.
Dec 18 2019, 3:18 AM · VisualEditor, TemplateStyles, VisualEditor-MediaWiki-2017WikitextEditor

Dec 13 2019

Jc86035 added a comment to T239978: Flexibility in adding to and creating discussions.

Considering T240696: Make linebreak behaviour consistent regardless of indentation level, the output behaviour for comments would presumably have to change with the introduction of new markup (i.e. multiline list item syntax / multiline comment syntax), since it would no longer be necessary to prefix characters to each line of the output. This would presumably make it easier to introduce new syntax at some point before introducing actions 2 and 3 (or any other action in which a top-level comment is added).

Dec 13 2019, 6:31 PM · DiscussionTools, OWC2020
Jc86035 added a comment to T240696: Make linebreak behaviour consistent regardless of indentation level.

Does the editor currently output any comments without indentation? Currently it can only be used through the “reply” button, so there will always be a parent comment, and so under this behaviour it would always prefix at least one indent.

Dec 13 2019, 6:28 PM · Editing-team, DiscussionTools, OWC2020

Dec 12 2019

Jc86035 updated the task description for T240257: Add auto-save to the reply widget.
Dec 12 2019, 4:43 PM · User-Ryasmeen, MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), Editing-team (Q3 2019-2020 Kanban Board), OWC2020 (OWC2020 Replying 1.0), DiscussionTools

Dec 10 2019

Jc86035 added a comment to T240257: Add auto-save to the reply widget.

What happens if the parent comment is deleted or moved? Will the reply be discarded? Or is it expected that the user will only be drafting one comment at any given time?

Dec 10 2019, 3:22 PM · User-Ryasmeen, MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), Editing-team (Q3 2019-2020 Kanban Board), OWC2020 (OWC2020 Replying 1.0), DiscussionTools
Jc86035 created T240347: Introduce linter, error messages, tracking categories or similar for discussion pages syntax.
Dec 10 2019, 3:18 PM · DiscussionTools, Parsoid, MediaWiki-extensions-Linter, OWC2020

Dec 8 2019

Jc86035 added a watcher for OWC2020: Jc86035.
Dec 8 2019, 3:05 PM

Dec 7 2019

Jc86035 updated the task description for T239978: Flexibility in adding to and creating discussions.
Dec 7 2019, 3:16 PM · DiscussionTools, OWC2020

Dec 6 2019

Jc86035 created T239978: Flexibility in adding to and creating discussions.
Dec 6 2019, 10:57 AM · DiscussionTools, OWC2020

Nov 26 2019

Jc86035 added a comment to T238971: Consider revising Junior Contributor definition.

We divert one of our experienced high-wage-value workers to make this edit.... instead of doing whatever other work they would have done.

I would disagree with two of the assumptions here:

  • That Wikipedia editors won't decide to spend more time editing because of such concerns being raised. Contributors typically don't spend 100% of their free time editing, and hypothetically an increase in the number of such valid concerns could encourage a contributor to spend some more time fixing those issues.
  • That editors would need to be diverted to resolve the issue. Some editors specifically find value in helping new users (e.g. regulars at the help desk), so it's possible that they would actively seek out such comments on talk pages (e.g. by filtering recent changes to find such comments).
Nov 26 2019, 2:23 PM · Product-Analytics, VisualEditor (Current work), OWC2020
Jc86035 added a comment to T239231: Calculate guardrail metrics.

It seems sort of inevitable that if a tool is made easier to use there will be more unproductive things done with it (simply because it will be easier). Perhaps it would be better to, e.g.,

  • measure if such edits are being successfully reverted;
  • consider methods of actively reducing the rate of such edits.
Nov 26 2019, 1:37 PM · DiscussionTools, Product-Analytics, OWC2020

Nov 24 2019

Jc86035 added a comment to T238218: Control whitespace in injected wikitext for multi-line comments.

Why is it preferable to save raw HTML? Wouldn't it be better, from the perspective that wikitext should be as readable and compact as possible, to, say, use a parser function or extension tag (e.g. at start and end, or within the signature) that results in the same HTML being inserted into the page? Doing so would also allow for the parser function/extension tag to be modified without changes to the wikitext (making comments from v1 and v2 of DiscussionTools forward-compatible), and could potentially allow for substituted (i.e. fake) comments to be distinguishable from real comments in some way.

Nov 24 2019, 12:14 PM · DiscussionTools, OWC2020, Parsoid

Nov 13 2019

Jc86035 added a comment to T235923: Replies v1.0: release replying to specific comments.

Is the current plan to eventually allow tables to be used without any additional syntactical/formatting difficulty (i.e. would it definitely be possible by version 3)? If so, would changes to the parsing of talk pages be made in the first version?

Nov 13 2019, 8:54 PM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools
Jc86035 added a comment to T235923: Replies v1.0: release replying to specific comments.

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

I think you're describing just putting the table non-indented after the list item? Which would be a solution to our problem, I guess, but it isn't a great solution. It's not possible to actually indent a table, as far as I know, unless you use HTML syntax for either the list or the table (which is another not-great solution).

Nov 13 2019, 10:21 AM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools

Nov 6 2019

Jc86035 added a comment to T235923: Replies v1.0: release replying to specific comments.

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

Nov 6 2019, 10:17 AM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools
Jc86035 added a comment to T230653: Use a parser function to encapsulate signatures.

I think the easiest way to avoid the transclusion problem, while still using such a parser function, would be to insert the complete HTML of the signature into a parameter of the parser function (or to include it before/after the parser function) and add any other necessary user/revision data in other parameters upon page save. While this would introduce redundancy, it would presumably be easier to implement without breaking certain things; e.g. if the user ID is included as a separate parameter, the new talk page interface could link to the user's current userpage regardless of what username is stored in the signature. (I imagine this could cause issues if talk page discussions were imported between wikis, though...)

Nov 6 2019, 9:59 AM · DiscussionTools, Patch-For-Review, OWC2020, MediaWiki-Parser
Jc86035 added a comment to T232780: Write a client-side parser for signatures (username & timestamp), comments and threads.

Thanks for the link. I hadn't noticed that task.

Nov 6 2019, 9:53 AM · OWC2020, VisualEditor (Current work)

Nov 5 2019

Jc86035 added a comment to T230658: Syntax for list item attributes.

The syntax that I suggested back in February (during the phase 1 consultation) was:

>4*
[arbitrary wikitext] ~~~~

The number(s) would indicate the indentation level, and the list item after the number(s) would indicate some sort of comment styling (as opposed to being directly analogous to the current list item markers). Use of the new syntax would perhaps be optional (i.e. >4* could be omitted in place of **** or :::*). The metadata would be provided entirely by attributes within an extension tag in the signature (as proposed in T230653).

Nov 5 2019, 7:42 PM · DiscussionTools, OWC2020, MediaWiki-Parser
Jc86035 added a comment to T230658: Syntax for list item attributes.

More or less, an experienced user is going to want to be able to save this sort of comment through any of the available editing interfaces, regardless of the level that the comment is nested at, using the syntax that they learned years ago (or something very close to that).

Nov 5 2019, 7:12 PM · DiscussionTools, OWC2020, MediaWiki-Parser
Jc86035 added a comment to T230658: Syntax for list item attributes.

How is the syntax to get into the page source? Is it going to be saved directly or is something like an extension tag going to generate the HTML?

Nov 5 2019, 6:56 PM · DiscussionTools, OWC2020, MediaWiki-Parser
Jc86035 added a comment to T234046: Create OWC metric definitions.

"Junior contributor" and "senior contributor" strike me as terms that will be confusing and/or have unintended implications (e.g. that users with 500+ edits are unambiguously regarded as having higher seniority), especially since this seems to be the first time they've been used in a MediaWiki context. While I think it does make sense to use the terms, it would probably be worth explicitly defining their meanings whenever they're used (or, alternately, replacing them with more common and/or less ambiguous terms like "experienced contributor").

Nov 5 2019, 6:39 PM · Product-Analytics, VisualEditor (Current work), OWC2020

Nov 4 2019

Jc86035 added a comment to T234966: Decide on HTML format for machine-readable signatures.

Would this be generated by an extension tag or parser function, or would that HTML be directly saved into the page by the editor? The former approach would presumably be cleaner in terms of the wikitext source code.

Nov 4 2019, 11:22 PM · DiscussionTools, OWC2020
Jc86035 added a comment to T234403: Create a VE-based text input for replying.

While I am a Flow user and have it enabled on my Wikidata talk page, I do have some reservations about using VE directly without any alternative. I think it's likely that users will complain that there is no non-JS option (see e.g. VE vs. 2010 editor; Old Reddit vs. New Reddit). Furthermore, considering the relatively troubled history of VE, I imagine that it will inevitably face extra scrutiny from experienced users, and it would be disappointing to see this also get stuck in beta indefinitely.

Nov 4 2019, 11:13 PM · User-Ryasmeen, DiscussionTools, MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), Patch-For-Review, Editing-team (Q3 2019-2020 Kanban Board), OWC2020 (OWC2020 Replying 2.0)
Jc86035 added a comment to T235592: Replies v1.0: Create mockups.

I think it's possible that the inline "reply" button might not be visible enough, since it just looks like a normal link enclosed in parentheses. Perhaps it could be given different formatting to allow it to be distinguished more easily?

Nov 4 2019, 11:10 PM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), OWC2020 Replying 1.0, Editing Design
Jc86035 added a comment to T232780: Write a client-side parser for signatures (username & timestamp), comments and threads.

This seems like something that could be easily broken by signature customization and possibly page formatting. I imagine matching signature output would work reasonably well if users are cooperative, but that may not always be the case, and it would be preferable to avoid things that don't work with what is currently allowed.

Nov 4 2019, 11:08 PM · OWC2020, VisualEditor (Current work)
Jc86035 updated the task description for T237175: Caption display errors with beta audio player on pages with multiple audio files with captions.
Nov 4 2019, 3:34 PM · VideoJS player, TimedMediaHandler-TimedText
Jc86035 updated subscribers of T236252: Add a button on URL fields to archive the URL.

Could you be more specific about what this would entail? (I'm assuming based on your title that you're requesting something different to that proposed in the linked proposal, as the proposal is for archival being requested automatically as soon as an edit is made.)

  • It's already possible to archive individual URLs to the Wayback Machine using e.g. Firefox/Chrome extensions (or, of course, the Internet Archive website). Since equivalent functionality already exists outside of MediaWiki/gadgets/user scripts, this would only provide additional functionality for mobile users.
  • On the other hand, there is likely a use case for archiving all of the external links in an article; in addition to being less tedious than the former approach, additional functionality (e.g. screenshots, recursive archival) could be accomplished through use of the new Wayback Machine Save Page Now software and its API. It's possible it could be done using a gadget or user script, but I'm not sure if it would be fine from a security standpoint.
Nov 4 2019, 11:36 AM · ProveIt-Gadget

Nov 3 2019

Jc86035 created T237175: Caption display errors with beta audio player on pages with multiple audio files with captions.
Nov 3 2019, 5:40 AM · VideoJS player, TimedMediaHandler-TimedText

Sep 23 2019

Jc86035 created T233564: Timeless contains non-standard/deprecated flexbox CSS.
Sep 23 2019, 12:41 AM · Timeless

Aug 27 2019

Jc86035 added a comment to T221345: Regressions caused by Timeless-specific form styles removal and related changes.

@Isarra I'm not sure if there's already a ticket for this, but GeoHack coordinates are misaligned again for me (possibly because of the recent change to where the language links are displayed). It looks like this is because the position is now set based on the top of the prose, so the coordinates usually end up floating above the infobox area. I also have the XTools gadget turned on, which adds additional vertical space between the h1 line and the start of the prose.

Aug 27 2019, 2:22 PM · MW-1.34-notes (1.34.0-wmf.3; 2019-04-30), CSS, Timeless

Aug 21 2019

Jc86035 added a comment to T230661: TimedMediaHandler audio captions are out of sync in Firefox (and possibly other browsers).

Safari 12.1.2 on macOS 10.14.6; video captured and edited using QuickTime Player; audio redirected using Soundflower; exported using ffmpeg.

Aug 21 2019, 10:08 AM · Kaltura player, TimedMediaHandler-TimedText
Jc86035 added a comment to T230661: TimedMediaHandler audio captions are out of sync in Firefox (and possibly other browsers).

Firefox 68.0.2 on macOS 10.14.6; video captured and edited using QuickTime Player; audio redirected using Soundflower; exported using ffmpeg.

Aug 21 2019, 9:56 AM · Kaltura player, TimedMediaHandler-TimedText
Jc86035 added a comment to T230661: TimedMediaHandler audio captions are out of sync in Firefox (and possibly other browsers).

There's four-sevenths of a second between each beat, and I don't think the delay exceeds that.

Aug 21 2019, 8:37 AM · Kaltura player, TimedMediaHandler-TimedText
Jc86035 renamed T230661: TimedMediaHandler audio captions are out of sync in Firefox (and possibly other browsers) from TimedMediaHandler captions are out of sync in Firefox (and possibly other browsers) to TimedMediaHandler audio captions are out of sync in Firefox (and possibly other browsers).
Aug 21 2019, 8:30 AM · Kaltura player, TimedMediaHandler-TimedText

Aug 17 2019

Jc86035 created T230661: TimedMediaHandler audio captions are out of sync in Firefox (and possibly other browsers).
Aug 17 2019, 5:35 PM · Kaltura player, TimedMediaHandler-TimedText
Jc86035 renamed T230649: In beta audio player (VideoJS), line breaks in TimedText are not recognized from In beta video player (VideoJS), line breaks in TimedText are not recognized to In beta audio player (VideoJS), line breaks in TimedText are not recognized.
Aug 17 2019, 1:11 PM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), User-TheDJ, Kaltura player, TimedMediaHandler-TimedText
Jc86035 updated the task description for T230650: "caption-container" CSS class is used by both TimedMediaHandler beta and GallerySlideshow.js, causing display issues.
Aug 17 2019, 1:05 PM · VideoJS player, TimedMediaHandler-TimedText
Jc86035 updated the task description for T230649: In beta audio player (VideoJS), line breaks in TimedText are not recognized.
Aug 17 2019, 12:55 PM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), User-TheDJ, Kaltura player, TimedMediaHandler-TimedText
Jc86035 updated the task description for T230651: VideoJS beta video player captions menu does not work properly when overlapping with page header(s).
Aug 17 2019, 12:03 PM · VideoJS player, TimedMediaHandler-TimedText
Jc86035 updated the task description for T230651: VideoJS beta video player captions menu does not work properly when overlapping with page header(s).
Aug 17 2019, 12:02 PM · VideoJS player, TimedMediaHandler-TimedText
Jc86035 updated the task description for T230651: VideoJS beta video player captions menu does not work properly when overlapping with page header(s).
Aug 17 2019, 12:01 PM · VideoJS player, TimedMediaHandler-TimedText
Jc86035 updated subscribers of T230650: "caption-container" CSS class is used by both TimedMediaHandler beta and GallerySlideshow.js, causing display issues.
Aug 17 2019, 12:00 PM · VideoJS player, TimedMediaHandler-TimedText