Thanks for the diagnosis. You're right, so

<li role="menuitem"><a href="{{href}}" class="{{stringOrArray class}}">{{text}}</a></li>

just turns into <a class="" href="/wiki/index.php/Special:Notifications">0</a>, and Echo notification counts aren't styled.

Will the result of this be an RFC to replace doxygen, or just a proof of concept?

We discussed this in E92: RFC Meeting on IRC 2015-11-25 22:00 UTC (T118932: Raise PHP version requirements), meeting minutes.

• conclusion:
  • Requirement statement for users: PHP 5.5+ or HHVM 3.x+ ;
  • requirement statement for developers: the subset of features that behave consistently on both platforms
• We'll give traits a shot with implementation proposals / documentation, scoped to ContextSource / LoggerAware and make a decision re: broader usage sometime in February.
• updating the requirements documentation is tracked in T75901: Drop PHP 5.3 support

@Galorefitz

• When exactly do your classes start in January? (Google wouldn't say :) ).
• You left out Past experience from your proposal. You made some fixes in gerrit in May (thanks!), have you been active in any other FOSS projects as a user and a contributor?

Ubuntu puts contrib/completion/git-prompt.sh in /usr/lib/git-core/git-sh-prompt, so it's available in MW-Vagrant.

In T110607#1633472, @mmodell wrote:

@Spage: upstream is working on path/to/repo support in diffusion. See upstream task.

Is "id" in getId() and findPageById( $id ) a page ID, revision ID, or articleID? The proliferation of IDs in core is confusing.

It's great to have this meeting, but we need to identify the agenda and desired outcome of it.

[Unsolicited redesign skins] almost always look pretty, but then fall apart as soon as you try to apply reality to them. They often have no concept of core wiki things like history, or languages, or models of editing and workflows

The script works for me, a few minor comments:

I disagree with @Tgr, I think line numbers are a useful way to specify a snippet. The wiki editor should use them with an unchanging commit (otherwise the file contents change), but its her choice

Nicely done! A few comments:

• Phabricator's diffusion needs to be one of the supported repositories. We are moving away from GitBlit (git.wikimedia.org). I would argue it even needs to be the first supported, though there's a big issue with its "call signs" that needs to be resolved.
• What's the name of the extension? What's the name of the parser tag? Are both TranscludeGit ?

"Saving the content to the database...

• What do you mean, an actual DB table? Do we need this for first version? I believe to start this extension should just rely on the page cache and maybe the parser cache. If not, spell out what you're doing with a database.

... and rendering wikitext (.mediawiki), plain text (.txt) and code (.php, .py, .json, etc)."

• Those three formats each hide a lot of work, I would split into separate steps. I would pick rendering wikitext first since as I understand it it's the simplest.
  • How does the wiki editor specify which format she wants? Does the parser function infer it from the file extension? It seems you need a parameter to override.

Fetch extension.json and parse it to feed it as input to the infobox template

• Why is that part of this extension? Surely it is part of "use [raw text] for further processing (eg. processing text through a lua module)". This extension would make the file contents available to Lua modules, which can do stuff like parse extension.json, process the docs/hooks.txt file, etc. If you just mean this is a use case for the extension, or that you propose to build such a Lua module, say so.

It should support other text file extensions.

Special:Version assumes anything not ending in .txt is wikitext it can output, so it should probably only support .wiki and also .mediawiki (depending how strict we are with text file format conventions).

@Akangupt and others,
This task's description, under Possible/desirable features, mentioned:

• Transcluded content appears in a tag or template that identifies source, so that users can edit the text around it.
  • for simple transclusion MVP, simply invoke it from a wiki template similar to Template:Api_help).

I think the first bullet is a holdover from when this task was titled " "technology to push or pull remote text content into wiki pages"". If a system could push git content into a wiki page then editors would obviously want to know where it came from, e.g.

blah blah blah
<!-- the following wikitext came from extensions/SemanticResultFormats/README.wiki, inserted by MyMagicPushContent on 2015-11-06 -->
Semantic Result Formats (a.k.a. SRF) is an extension to MediaWiki that ...
The individual formats can be added 
...
<!-- end of wikitext from extensions/SemanticResultFormats/README.md -->
blah blah blah

Now that this task has been refined and narrowed to a pull technology, that doesn't apply. Wiki editors will see

blah blah blah
{{#MyMagicGitInclude: project=mediawiki/extensions/Wikibase| file=README.wiki}}
blah blah blah

So I will remove the mis-feature. I apologize for the confusion!

We held E85: RFC Meeting: Streamlining Composer usage (2015-11-04), see Meeting summary. From that:

• need to check if fingerprint in git verify-tag/commit output depends on gpg settings (jzerebecki
• AGREED: signed tag support in composer would be nice to have (TimStarling, 22:52:22)
• rough consensus that everything sucks and our lives will be horrible regardless of which solution is implemented (TimStarling, 22:56:13)
• @JanZerebecki will add more detailed full workflow into RFC

In T117828#1784552, @Mattflaschen wrote:

... But in order to mark a page Flow it has to exist in the page table.

A few random thoughts on this. I believe the "ugly" UUIDs of topics and posts are actually in chronological order, since they start with a timestamp. So if you could ask for posts in reverse UUID order then you could work back to the topics they are part of. This is what Recently active topics on a Flow board does. But you can't request topics in general, you always have to provide a page=Flow board title parameter to any Flow action, including submodule=view-topiclist&vtltoconly=true

This took place, E50: IRC office hour: Web APIs Hub

Hi there.

• Are we ready to "recommend debugging settings that display [DB] warnings"? Or perhaps the default settings and/or MW-Vagrant settings have been changed

Perhaps this task is complete \o/

OK. I thought we had more time, https://wiki.gnome.org/Outreachy/2015/DecemberMarch says
November 17 | accepted participants announced on this page at 7pm UTC

This happened to me, I often click on the wrong thing. I can only expand if I click after the text in the h2, but not too close to the watch star.

These days the .flow-topic-titlebar is no longer a mw-ui-button and doesn't always collapse/expand the topic's posts, so I'm closing this. Related newer discussion is in T103866: Better communicate that resolved topics can be expanded.

I aim to review feedback on API:Licensing and link to it from API:FAQ, other API pages, and maybe T104288: Blueprint skin has no footer or replacement (so no copyright).

I asked for review and got some feedback, so this is kind of Done.

This sounds like part of @Legoktm's T88596: Improving extension management RFC, proposal at https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management

Congrats on writing a proposal!

enwiki's {{Citation needed}} is working for me right now.

Cool! More meetings in the series

• https://phabricator.wikimedia.org/E66/7 - 2015-11-04 meeting
• https://phabricator.wikimedia.org/E66/8 - 2015-11-11 meeting
• https://phabricator.wikimedia.org/E66/9 - 2015-11-18 meeting
• https://phabricator.wikimedia.org/E66/10 - 2015-11-25 meeting

We held an RFC office hour meeting about this on 2015-10-21, E80: RFC Meeting (Heredoc arguments for templates), see summary and full log. There's overlap with other proposals for modules or widgets referencing structured data. No consensus reached.

We held an RFC office hour meeting about this, E84: Dependency Injection for MediaWiki core (RFC Meeting 2015-10-28), see summary, full log. No conclusion reached, but people are willing to develop an implementation. Daniel will update the RFC's wiki page.

ori asked me to take a look at the page, I added this to my long list :-) I already made a quick pass. It looks pretty good.

In T91626#1761145, @Akangupt wrote:

It can provide source code to the <source> tag or parser function to transclude highlighted source code into the page.

Does this project demand to have all the functionalities of SyntaxHighlight_GeSHi ?

If you look at https://tools.wmflabs.org/oojs-ui/oojs-ui/demos/#widgets-mediawiki-vector-ltr , it shows 1) framed primary buttons, then 2) framed not-primary neutral/constructive/progressive/destructive buttons, then 3) no-framed not-primary buttons. The LSG only shows Primary (1) and Quiet (3), but its Quiet text describes (2), hence I filed T116882: LSG Quiet button description doesn't match the buttons next to it, while OOUI demo has additional framed buttons..

https://commons.wikimedia.org/wiki/Template:Clickable_button isn't even using mw-ui- classes, I think it's using some jQuery UI precursor. The problem of garish buttons for links long predates Agora/MediaWiki UI, see Template:Big Blue Button :-) .

In T116690#1756555, @hashar wrote:

[list of files with no extension] Some are scripts but most others are actual plain file that sometime happens to use wikitext. I am not a fan of renaming them all with a .mediawiki or .md extension.