In T33597#1315922, @Qgil wrote:

Did someone work on this project during#Wikimedia-Hackathon-2015? Otherwise please remove the label.

Yes, @Krinkle did at Wikimedia-Hackathon-2015.

Change 229852 had a related patch set uploaded (by Krinkle):
Implement mw-references list with responsive columns

https://gerrit.wikimedia.org/r/229852

T123896: Provide a way how to find out if there are no references or the number of references in given group relevant.

In T33597#795815, @Krinkle wrote:

See also https://phabricator.wikimedia.org/T53260#550341.

I'd like to see this implemented. But I'd like to question some of the requested configuration options.

[snip]

I would guess that there might be different requirements for the various non-Latin script languages (e.g. Farsi, Russian, and Japanese). Most citations in European languages I would guess extend to a full 1000-1200 px on a single line (e.g. from a web citation), but those languages might be able to fit a citation in a smaller amount of space, meaning their need for columns would come only with a larger number of citations.

Points applied mostly due to extremely delicate roll-out need to avoid disrupting community processes and content.

Change 341708 had a related patch set uploaded (by Krinkle):
[operations/mediawiki-config] Disable wgCiteResponsiveReferences by default for back-compat

https://gerrit.wikimedia.org/r/341708

Change 341708 merged by jenkins-bot:
[operations/mediawiki-config] Disable wgCiteResponsiveReferences by default for back-compat

https://gerrit.wikimedia.org/r/341708

Mentioned in SAL (#wikimedia-operations) [2017-03-08T00:08:37Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Disable wgCiteResponsiveReferences by default for back-compat (T33597) (duration: 00m 41s)

Change 229852 merged by jenkins-bot:
[mediawiki/extensions/Cite] Implement responsive columns for reference lists

https://gerrit.wikimedia.org/r/229852

OK, this is now live in master, and will be rolling out next week in wmf.16.

The code is disabled on pages by default on all wikis except test wikis and MW.org.

On the default-on wikis, reference lists will have multiple columns, and to disable this, uses of <references /> can be edited to opt out by changing them to <references responsive="0" />.

On the default-off wikis, nothing will change. Uses of <references /> have to be edited to opt in by changing them to <references responsive />.

The next task is to help each wiki's communities convert their templates over to use <references responsive /> explicitly, or opt out if they can't be fixed. Once they are fixed, we can then enable it for the entire wiki.

In T33597#3082547, @Jdforrester-WMF wrote:

OK, this is now live in master, and will be rolling out next week in wmf.16.

The code is disabled on pages by default on all wikis except test wikis and MW.org.

On the default-on wikis, reference lists will have multiple columns, and to disable this, uses of <references /> can be edited to opt out by changing them to <references responsive="0" />.

On the default-off wikis, nothing will change. Uses of <references /> have to be edited to opt in by changing them to <references responsive />.

The next task is to help each wiki's communities convert their templates over to use <references responsive /> explicitly, or opt out if they can't be fixed. Once they are fixed, we can then enable it for the entire wiki.

Migration details for template authors

<references responsive /> will automatically wrap the list in <div class="mw-references-wrap">. Any list with more than 10 references will also get the class mw-references-columns. In this mode, the references list is automatically split over multiple columns based on the available space on the screen. E.g. on narrow screens 1 or 2 columns, on wider screens 2 or 3. Given that this happens automatically, it is no longer necessary for editors to manually enable/disable the columns mode of a template.

Remember also that other customisations for the references list are best applied directly to the ol.references CSS selector in your wikis' MediaWiki:Common.css. Many wikis customise the font-size this way, for example. (No need to manually code it through a template). In case a DIV wrapper is needed for certain styles, the .mw-references-wrap CSS selector will apply to all references lists produced by <references responsive /> regardless of whether the columns were dynamically activated.

I've started https://www.mediawiki.org/wiki/Editing/Projects/Columns_for_references with some information for Wikimedia contributors.

@Jdforrester-WMF how does one know whether a wiki is default ON or OFF?

Wikisources which typically convert page footnotes to compiled endnotes, and we have typically not utilised columns (imagine a footnote table squashed into a column). I would suggest that they will prefer to be in OFF. Can that be taken as the default position and give those communities the ability to opt-in?

@Billinghurst it would seem to me that https://www.mediawiki.org/wiki/Editing/Projects/Columns_for_references has the answers to your questions does it not ?

Do you have example links of your 'typical' usage btw, that can always be handy.

In T33597#3097540, @TheDJ wrote:

@Billinghurst it would seem to me that https://www.mediawiki.org/wiki/Editing/Projects/Columns_for_references has the answers to your questions does it not ?

Do you have example links of your 'typical' usage btw, that can always be handy.

Okay, so the overt statement is ... default for all wikis is OFF, and wikis need to OPT-IN.

In T33597#3097540, @TheDJ wrote:

@Billinghurst it would seem to me that https://www.mediawiki.org/wiki/Editing/Projects/Columns_for_references has the answers to your questions does it not ?

Do you have example links of your 'typical' usage btw, that can always be handy.

You were after some examples from a Wikisource

• simple list of by page footnotes that become endnotes when transcluded

https://en.wikisource.org/wiki/A_colonial_autocracy,_New_South_Wales_under_Governor_Macquarie,_1810-1821/Chapter_3

• quoted/excerpts of correspondence, poetry, other works

https://en.wikisource.org/wiki/My_Life_in_Two_Hemispheres/Chapter_15

• example of a small table that is joined from two separate references (use of <ref name=> and <ref follow=>)

https://en.wikisource.org/wiki/Considerations_on_the_state_of_Ireland

• longer list with a table

https://en.wikisource.org/wiki/A_colonial_autocracy,_New_South_Wales_under_Governor_Macquarie,_1810-1821/Chapter_6

I cannot readily find a work with references with complex tables, so that will have to a be a raincheck.

It's probably relevant to point out that the feature is opt-in and opt-out per page as well. They can set a default per wiki (if not specified on the page, then do X), but any editor can override that default on any page.

The ideal arrangement for each wiki is to choose a reasonable default (based on a typical/most common type of page) and then override that default whenever the other behavior is wanted on any individual page. So, for example, the Wikipedias should probably choose to have responsive columns by default, but can and should make individual pages be non-responsive (e.g., an explanatory footnote that contains a table or gallery). The Wikisources might decide to have a single column by default, but can and should make individual pages be responsive (e.g., a project page or a page that has lots of columns of plain text in the original).

Hi, on zhwp there seems to be still some good amount of confusion among almost-techy (bot-capable) users (including sysops, sadly), so I added a paragraph in the document to clarify the process up. Please find some time to review these changes, possibly perform some copyedit, and ideally mark these text for translation. Pretty sad to see people opposing stuff with questions in mind.

I want ask that Could it the tag add two parameters ('class' and 'style') to set custom div's class and style when it have the 'responsive' parameter?

Old tag is a clean output which is only a ol.references. Some designs of consumers, like some wmf's wiki, will add a custom div which sets a custom div's class and style to include the ol.

If the auto columns is on acquiescently, the custom div will make the structure become complex beacause of the two div's nest. There are two ways, One is keep the old tag's style to keep the custom div's class and style, The other is only use new tag's style ,give the custom div up which it will lose the custom div's class and style because the new tag is no the enter to set it more.

If I need the class and style of custom div for ol.references, the auto columns, and NO div's nest, I suggest that parameters 'class' and 'style' should be added when the 'responsive' parameter is on.

In T33597#3100752, @Cwek wrote:

Here it comes.

Old tag is a clean output which is only a ol.references. Some designs of consumers, like some wmf's wiki, will add a custom div which sets a custom div's class and style to include the ol.

Why fear adding another div? Nobody, not even normal CSS/JQuery selectors found in zhwp's MediaWiki:Common.css (all without a strict >), will consider that a problem.

If the auto columns is on acquiescently, the custom div will make the structure become complex beacause of the two div's nest. There are two ways, One is keep the old tag's style to keep the custom div's class and style, The other is only use new tag's style ,give the custom div up which it will lose the custom div's class and style because the new tag is no the enter to set it more.

Again, nesting is not a problem. Nobody will see.

If I need the class and style of custom div for ol.references, the auto columns, and NO div's nest, I suggest that parameters 'class' and 'style' should be added when the 'responsive' parameter is on.

Forwarding the class and style can be a lovely feature to have, but are you sure it belongs to this task?

Figured out this thing would have been easier to explain if I just called it {{reflist|35em}} by default.

Logged https://phabricator.wikimedia.org/T166293 - AutoWikiBrowser does not recognise <references responsive/> and assumes the article needs a {{Reflist}}