Contributing to Dev Wiki

When writing code for your wiki, such as CSS styles, functionality improvements or entirely new tools with JavaScript, or advanced templates using Lua, you might reach a point where you want to share your work with the broader Fandom community and allow other wikis to benefit from your code.

In the past, wikis would copy code from one another and apply it to their own applications. Now, there is a much better option available: contributing your work to the Dev Wiki.

Dev Wiki is not your typical wiki where only administrators can edit code pages. Here, every registered user can contribute their own code, which can then be utilized by wikis and users across Fandom without the need for manual copying. Instead, imports are used to load the code from Dev Wiki, ensuring that everyone always has access to the most up-to-date version.

In order to have your code published on Dev Wiki for everyone to use, you should give your project an easy to recognize and remember name. Some good examples might be DiscordIntegrator - a script that lets you integrate Discord widgets into a wiki, or AntiBigText - a style that reduces font sizes on pages. A good name will help other users find your code when they're looking for a specific solution.

Top header and few first lines of code for "MediaWiki:AntiBigText

After choosing a name for your JavaScript, CSS, or Lua module page, it's time to publish your code on Dev Wiki. Since Dev Wiki allows everyone to edit code pages, you can simply place your project under MediaWiki:<YourProject'sName>.css, MediaWiki:<YourProject'sName>.js or Module:YourProject'sName> name. When writing codes that are intended to be published on Dev Wiki, you might also find its coding conventions handy!

"Custom JavaScript status" box in the right rail of JS pages showing the status of code review - all green and approved!

JavaScript pages on Dev Wiki undergo a review process by the Trust & Safety team to ensure safety before they can be used. Unlike manual code copying, where each wiki requires separate reviews, with Dev Wiki, Dev Wiki's review covers code for universal usage.

Once your code is published and submitted for review, it's time to write a documentation page for your project. Depending on the nature of your project it can ranging from detailed technical descriptions for JavaScript libraries to user-friendly usage guides or a mix of both.

Documentation page for "CustomizeAce" script available at dev

It's always good to take a look at how other project pages are structured and built and use that for your own. Using them as a reference can prevent errors. A WHAM project page is a good example to go by.

The WHAM page demonstrates the inclusion of parameters for other pages. It's part of the internationalization process, an effort to make both code projects themselves and their respective documentation pages accessible and easy to use for users speaking various languages across the globe. Dev Wiki describes this process on its internationalization page.

When internationalizing your code, focus on making the text translatable in your JavaScript. For instance, if you're adding a new option to the "Edit" Dropdown on pages, consider the following example:

(function() {
    'use strict';

    var editDropdown = $('.page-header__actions .wds-list');
    var pageAuthorsLink = $('<li>').append(
    	$('<a>', {
            id: 'ca-credits',
            href: mw.util.getUrl( mw.config.get( 'wgPageName' ), { action: 'credits' } ),
            text: 'Page authors'
        })
    );

    editDropdown.append( pageAuthorsLink );
})();

You can use I18n-js library from Dev Wiki to easily and quickly make your script translatable:

(function() {
    'use strict';

    function main( i18n ) {
        var editDropdown = $('.page-header__actions .wds-list');
        var pageAuthorsLink = $('<li>').append(
            $('<a>', {
                id: 'ca-credits',
                href: mw.util.getUrl( mw.config.get( 'wgPageName' ), { action: 'credits' } ),
                text: i18n.msg( 'editDropdownLabel' ).plain()
            })
        );

        editDropdown.append( pageAuthorsLink );
    }

    importArticle( {
        type: 'script',
        article: 'u:dev:MediaWiki:I18n-js/code.js'
    } );

    mw.hook( 'dev.i18n' ).add( function( i18nlib ) {
        i18nlib.loadMessages( 'pageAuthorsLink' ).then( main );
    } );
})();

Let’s quickly take a look what changed here:

Main code is not located inside a function main with i18n parameter, which is a bridge between your code and the i18n-js library
After the main code ends, there is an importArticle() statement loading I18n-js code. Don’t worry! If there is already i18n-js loaded, it won’t break anything.
Then, a special hook is used to wait until all I18n-js elements are ready to go.
Upon hook being executed, it runs a function loading text from Dev Wiki and launches your main function.

This means text parts of your code will be stored on Dev Wiki separately from the programmatic code in a page following this naming scheme: https://dev.fandom.com/wiki/MediaWiki:Custom-<CodeName>/i18n.json, so in this case – https://dev.fandom.com/wiki/MediaWiki:Custom-pageAuthorsLink/i18n.json, as 'pageAuthorsLink' is what we ask loadMessages() function to load.