Added local fix for hewiki common.css:
.ui-dialog { right: auto; }

(e.g to get rid of the wrong right style rule)

The Vector skin has its own jQuery UI theme, which was updated somewhat recently.

So I guess that it should be something like

.ltr .ui-dialog {
    left: 0;
}
.rtl .ui-dialog {
    right: 0;
}

But the question is where to put it.

• Patching upstream jquery.ui makes sense, but .ltr and .rtl are MediaWiki classes and I'm not sure that they will accept a patch with [dir=ltr] and [dir=rtl] selectors.
• Patching skins/Vector/skinStyles/jquery.ui/jquery.ui.dialog.css seems like a problematic fork, and doesn't apply to other skins.
• Adding another CSS file that fixes issues in other skins is ugly.

@Krinkle, any suggestions?

@Krinkle, any suggestions?

In T86979#984648, @Amire80 wrote:

So I guess that it should be something like

.ltr .ui-dialog {
    left: 0;
}
.rtl .ui-dialog {
    right: 0;
}

But the question is where to put it.

• Patching upstream jquery.ui makes sense, but .ltr and .rtl are MediaWiki classes and I'm not sure that they will accept a patch with [dir=ltr] and [dir=rtl] selectors.
• Patching skins/Vector/skinStyles/jquery.ui/jquery.ui.dialog.css seems like a problematic fork, and doesn't apply to other skins.
• Adding another CSS file that fixes issues in other skins is ugly.

@Krinkle, any suggestions?

@Amire80 You'll have to verify what works best, but I don't think setting right: 0 for RTL will work here. Setting right: 0 for RTL wouldn't do anything because that's what caused this bug in the first place. The stylesheet has left: 0; and CSSJanus flips it to right: 0; in RTL. Then, at run time, jQuery UI adds a top: (something)px rule based on current screen size. Ending up with the dialog stuck to the right edge of the page instead of being centred.

I expect adding @noflip to the left: 0 would solve this bug and is an acceptable solution. While patching upstream libraries should be avoided at all cost, instrumentation like this to prevent it from being interpreted as a CSSJanus instruction is (however unfortunate) common practice. We've added @nofip rules to our copy of jQuery UI in the past already, as well as @embed rules to allow data URI optimisation. Not applying it to this dialog rule was was an oversight.

As for where: Patch the file in MediaWiki core (for fallback of all skins), and the Vector theme specific one. In both cases, be sure to document it in the PATCHES file.

• mediawiki: /resources/lib/jquery.ui/themes/smoothness/PATCHES
• Vector: /skinStyles/jquery.ui/PATCHES

In T86979#1242290, @Krinkle wrote:

Awaiting feedback from I18n about what the desired course of action is.

@Krinkle: How can you await feedback from a tag? Did you mean to CC a team, like Language Engineering, instead?

When you change direction, right will be left and left will be right, so if you have a left value in css, it's absolute and must be a right value instead, and I only seen this behavior in IE, see my trick:

	form.dialog({
		drag: function(event, ui) {
			$(this).parent().css('right', ($(window).innerWidth() - parseInt($(this).parent().css('left')) - $(this).parent().width())+'px');
			$(this).parent().css('left', '');
		},
	})

(Reclassifying since this is not an issue with the ResourceLoader framework itself)

Sure jQuery.ui has lost importance ever since but it's still not unused as I've made aware one of the issue of one of the tools on Wikimedia Commons for RTL languages interface so have applied on Commons "html[dir="rtl"] .ui-dialog { right: auto; }"

In T86979#9869340, @Ebrahim wrote:

Sure jQuery.ui has lost importance ever since but it's still not unused as I've made aware one of the issue of one of the tools on Wikimedia Commons for RTL languages interface so have applied on Commons "html[dir="rtl"] .ui-dialog { right: auto; }"

The inaction on this bug is indeed frustrating, especially given that the fix seems to be very simple (a single line of CSS fixes it locally on hewiki). jQuery.ui may have lost importance, but it's still an integral part of the 2010 wikitext editor (most notably, the "search and replace" dialog uses it). Therefore, the deprecation of this library is not by any means a reason to leave this crucial bug unfixed, at least as long as jQuery dialogs are still heavily used in integral parts of the editing interface.

In T86979#9891979, @Guycn2 wrote:

The inaction on this bug is indeed frustrating, especially given that the fix seems to be very simple (a single line of CSS fixes it locally on hewiki). jQuery.ui may have lost importance, but it's still an integral part of the 2010 wikitext editor (most notably, the "search and replace" dialog uses it). Therefore, the deprecation of this library is not by any means a reason to leave this crucial bug unfixed, at least as long as jQuery dialogs are still heavily used in integral parts of the editing interface.

apology, wrong ticket.