Page MenuHomePhabricator

Jc86035
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Friday

  • Clear sailing ahead.

User Details

User Since
Sep 26 2015, 6:00 AM (230 w, 4 d)
Availability
Available
LDAP User
Jc86035
MediaWiki User
Jc86035 [ Global Accounts ]

Recent Activity

Yesterday

Jc86035 removed a watcher for Desktop Improvements: Jc86035.
Tue, Feb 25, 5:05 PM
Jc86035 added a comment to T245890: Allow non talk pages to be treated as talk pages using a magic word.

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
Tue, Feb 25, 5:03 PM · OWC2020, Editing-team (Tracking), 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.

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

Mon, Feb 24

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.

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

Wed, Feb 19

Jc86035 created T245628: Preview does not correctly parse five or more tildes at the end of the comment.
Wed, Feb 19, 2:26 PM · Editing-team, DiscussionTools, OWC2020 (OWC2020 Replying 1.0)

Sun, Feb 9

Jc86035 updated the task description for T244672: Many file descriptions added from Commons Android app (Suggested Edits) are unhelpful.
Sun, Feb 9, 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.
Sun, Feb 9, 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.
Sun, Feb 9, 8:41 PM · Structured-Data-Backlog, Wikipedia-Android-App-Backlog, Commons, Android-app-feature-Description-Editing

Wed, Feb 5

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

Tue, Feb 4

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

Mon, Jan 27

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.

Mon, Jan 27, 10:31 AM · Editing-team (Q3 2019-2020 Kanban Board), Editing QA, 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-∞), 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-∞), 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-∞), 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-∞), 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 · 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, 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 · 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 · 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 · 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 · 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 · OWC2020, MediaWiki-Parser

Jan 8 2020

Jc86035 added a comment to T241388: When inserting {{welcome}} reply preview is different 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 · OWC2020
Jc86035 updated the task description for T239978: Flexibility in adding to and creating discussions.
Dec 30 2019, 11:06 AM · OWC2020
Jc86035 added a comment to T241388: When inserting {{welcome}} reply preview is different 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 different 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 · 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 · 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 · 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 · 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 · OWC2020, DiscussionTools, Editing-team

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 · OWC2020, DiscussionTools, Editing-team
Jc86035 created T240347: Introduce linter, error messages, tracking categories or similar for discussion pages syntax.
Dec 10 2019, 3:18 PM · 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 · OWC2020

Dec 6 2019

Jc86035 created T239978: Flexibility in adding to and creating discussions.
Dec 6 2019, 10:57 AM · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · Editing-team, 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
Jc86035 created T230651: VideoJS beta video player captions menu does not work properly when overlapping with page header(s).
Aug 17 2019, 12:00 PM · VideoJS player, TimedMediaHandler-TimedText
Jc86035 created T230650: "caption-container" CSS class is used by both TimedMediaHandler beta and GallerySlideshow.js, causing display issues.
Aug 17 2019, 11:21 AM · 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, 10:58 AM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), User-TheDJ, Kaltura player, TimedMediaHandler-TimedText
Jc86035 created T230649: In beta audio player (VideoJS), line breaks in TimedText are not recognized.
Aug 17 2019, 10:53 AM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), User-TheDJ, Kaltura player, TimedMediaHandler-TimedText

Aug 12 2019

Jc86035 added a comment to T229666: librsvg has broken attribute handling for masks.

I've reported this in the librsvg issue tracker.

Aug 12 2019, 4:35 PM · Upstream, Wikimedia-SVG-rendering

Aug 9 2019

Jc86035 added a comment to T230114: Create HIDPI logos for Wikivoyages.

I've checked all of the Wikivoyages' logos. Two of the logos (el, uk) seem to be raster-only; should they be redrawn/vectorized as SVGs?

Aug 9 2019, 3:44 PM · Patch-For-Review, Wikimedia-Site-requests
Jc86035 updated the task description for T230114: Create HIDPI logos for Wikivoyages.
Aug 9 2019, 3:42 PM · Patch-For-Review, Wikimedia-Site-requests

Aug 8 2019

Jc86035 created T230122: Create HIDPI logo for Incubator.
Aug 8 2019, 11:45 AM · Wikimedia-Site-requests
Jc86035 created T230120: Create HIDPI logo for Wikidata.
Aug 8 2019, 11:39 AM · Wikidata, Wikimedia-Site-requests
Jc86035 created T230114: Create HIDPI logos for Wikivoyages.
Aug 8 2019, 10:51 AM · Patch-For-Review, Wikimedia-Site-requests
Jc86035 created T230113: Create HIDPI logo for Wikispecies.
Aug 8 2019, 10:48 AM · User-Zoranzoki21, Wikimedia-Site-requests
Jc86035 updated subscribers of T227793: First round editor gender surveys.

@LadyofShalott remarks on Wikipedia:Village pump (miscellaneous) on enwiki that the survey keeps reappearing even though she has already responded to the survey.

Aug 8 2019, 10:41 AM · Readers-Web-Backlog (Tracking), Wikimedia-Site-requests, Research

Aug 6 2019

Jc86035 triaged T229921: PetScan is down as Unbreak Now! priority.
Aug 6 2019, 11:48 AM · Tools, Wikidata
Jc86035 created T229921: PetScan is down.
Aug 6 2019, 11:47 AM · Tools, Wikidata

Aug 5 2019

Jc86035 created T229840: Sticky horizontal bar in user preferences does not move correctly in Firefox on macOS.
Aug 5 2019, 3:53 PM · MediaWiki-User-preferences

Aug 2 2019

Jc86035 added a comment to T229666: librsvg has broken attribute handling for masks.

I don't think it is. Only one of the issues in the search has been updated in the past six months, and it seems to be completely unrelated.

Aug 2 2019, 2:40 PM · Upstream, Wikimedia-SVG-rendering
Jc86035 added a comment to T229666: librsvg has broken attribute handling for masks.

Other examples of this problem (probably simpler examples, in fact, since there's only one mask in each image) are File:BSicon uetkKRZ3+lto.svg and File:BSicon evKRZ3+1o.svg. In the original revisions of both images, attributes on a <g/> element result in the opacity of a <path/> element being inadvertently reduced.

Aug 2 2019, 2:09 PM · Upstream, Wikimedia-SVG-rendering
Jc86035 updated the task description for T229666: librsvg has broken attribute handling for masks.
Aug 2 2019, 2:02 PM · Upstream, Wikimedia-SVG-rendering
Jc86035 created T229666: librsvg has broken attribute handling for masks.
Aug 2 2019, 2:01 PM · Upstream, Wikimedia-SVG-rendering

Jul 27 2019

Jc86035 added a comment to T228759: Merge the Phabricator Priority values "Low" and "Lowest".
Jul 27 2019, 1:44 PM · Phabricator

Jul 26 2019

Jc86035 awarded T122924: Merge Extension:Theme into core a Cookie token.
Jul 26 2019, 11:45 AM · TechCom-RFC, Patch-For-Review, Technical-Debt, Theme, Front-end-Standards-Group, MediaWiki-Interface

Jul 16 2019

Jc86035 added a comment to T189412: Granular protection for wikidata items.

See also T209243: Protection of classes of Wikidata items based on attributes of their statements; it might be more practical to (either additionally or alternately) allow protection of classes of statements (e.g. based on property). This would be somewhat similar to how MusicBrainz requires 7-day review periods for all edits to certain types of data.

Jul 16 2019, 10:45 AM · patch-welcome, MediaWiki-Page-protection, Wikidata

Jul 9 2019

Jc86035 added a comment to T227063: Database primary master failover on s8 (wikidatawiki).

Is there an existing procedure for reflecting the page moves and deletions that will occur during the period that Wikidata is read-only?

Jul 9 2019, 4:04 PM · User-Johan, CommRel-Specialists-Support (Jul-Sep-2019), Wikidata, User-notice

Jun 5 2019

MJL awarded T220432: Clean up "easter egg" short URLs before extension goes live a Pterodactyl token.
Jun 5 2019, 6:42 AM · MediaWiki-extensions-UrlShortener