User "Tim Starling" changed the status of MediaWiki.r91518. Old Status: new New Status: fixme
User "Tim Starling" also posted a comment on MediaWiki.r91518. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91518#c22424 Commit summary: (bug 6100; follow-up to r91315) Being bold and removing $wgBetterDirectionality (and dependent wfUILang) in core, as most or all work is finished. Also: * Introduce classes mw-float-end, mw-float-start so we don't have to use inline css depending on wfUILang()/$wgLang (see HistoryPage and SpecialFileDuplicateSearch) * Add direction mark to protection log * Remove specialpageattributes as it is obsoleted by this commit (also fixes bug 28572) * Add two direction marks in wfSpecialList, which makes ltr links on rtl wiki (and vice versa) display nicely as well (only on those special pages however) * Revert r91340 partially: use mw-content-ltr/rtl class anyway in shared.css. Both ways have their [dis]advantages... * Set the direction of input fields by default to the content language direction (except buttons etc.) in shared.css Comment: It looks like all of the special pages are broken, I can't find any special page that is displaying content language text with the correct direction. History pages, log snippets, etc. are all broken. To me it looks to me like only a small fraction of the required work is done. Before we enable this on Wikimedia, it should be in a state where it's unambiguously better than how it was in 1.17. This is definitely better than the situation before r81622. But every content language text snippet apart from the main content area is now backwards, and it's not clear to me whether that's an acceptable tradeoff to get the UI text going in the correct direction. I suggest reinstating $wgBetterDirectionality. _______________________________________________ MediaWiki-CodeReview mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
