Page MenuHomePhabricator

Allow start/end values to be modified after the toolbar has been bootstrapped
Open, Needs TriagePublic

Description

On French wiki we have an enclosing button « <selected text> » (notice the spaces), which is highly used. But because of typographic automatic corrections, the normal spaces get replaced with non-breaking spaces in the generated toolbar. Thus, the button inserts non-breaking spaces instead of the expected normal spaces. This is undesirable and causes us many troubles. The expected behaviour would be to have normal spaces in the wikicode, which get automatically converted to non-breaking spaces when displaying the page (and only at that time).

The attached patch would let adding the following workaround in local script:

mw.hook( 'wikipage.content' ).add( function ( $content ) {
    $content.find( 'a.mw-charinsert-item' ).each( function () {
        var $item = $( this );
        if ( $item.data( 'mw-charinsert-start' ) === '«\xA0' && $item.data( 'mw-charinsert-end' ) === '\xA0»' ) {
            $item.data( 'mw-charinsert-start', '« ' );
            $item.data( 'mw-charinsert-end', ' »' );
        }
    } );
} );

The above code would work whether it's executed before or after the javascript bootstrap of CharInsert. Without the attached patch, the same workaround would be much more complex.

Event Timeline

Change 633345 had a related patch set uploaded (by Gerrit Patch Uploader; owner: Hank Hulet):
[mediawiki/extensions/CharInsert@master] Allow start/end values to be modified after the toolbar has been bootstrapped

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

Change 633345 merged by jenkins-bot:

[mediawiki/extensions/CharInsert@master] Allow start/end values to be modified after the toolbar has been bootstrapped

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

Thanks for merging this old patch.

I have just tried again our frwiki's «  » link. As a reminder, its code is <nowiki>« </nowiki>+<nowiki> »</nowiki> (regular spaces).

As in 2020, the displayed text in the toolbar is «  » (regular spaces automatically converted to nonbreaking spaces).

However there is a difference: whereas in 2020 it was inserting nonbreaking spaces, nowadays it inserts regular spaces. It is great, as it is the desired behavior. Thus the workaround from my first post shouldn't be needed anymore, and in turn the patch isn't needed too (though is has been nice to merge, as it optimizes a bit the bootstrap). I have investigated a bit, but I haven't found what caused the behavior change.

This doesn't feel "robust" (it may change again in the future, no behavior is enforced nor avoided). Basically, the extension generates the links from the output at some stage, rather than from what is input in the wikicode, also adding special handling for spaces in <nowiki> tags, and for &nbsp; / &#160; entities. See CharInsert.php.

On a related note, in our toolbox we have a « &nbsp; » link, to insert the "&nbsp;" string.

The code was initially <charinsert>&nbsp;</charinsert>, but it was broken (maybe it wasn't broken at some previous time):

  • when viewing the MediaWiki:Edittools page, the link was behaving as expected: displayed as « &nbsp; » , and inserting the "&nbsp;" string.
  • but when on an actual edit page, the link was displayed as an non-breaking space (so it was "invisible"), and it was inserting a plain non-breaking space character.

My first attempt at fixing was <charinsert><nowiki>&nbsp;</nowiki></charinsert>, but the behavior stayed exactly the same (working on MediaWiki:Edittools, broken on edit pages).

My second (and successful) attempt at fixing was <charinsert>&amp;nbsp;</charinsert>, which fixed everything: the displayed link, and the text it inserts, both when viewing MediaWiki:Edittools page and on edit pages.