Last modified: 2014-02-12 23:52:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T37911, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35911 - direction in MobileFrontend is always based on the wiki's content language
direction in MobileFrontend is always based on the wiki's content language
Product: MobileFrontend
Classification: Unclassified
stable (Other open bugs)
All All
: Normal normal
: ---
Assigned To: Nobody - You can work on this!
: i18n
Depends on:
Blocks: rtl 35919
  Show dependency treegraph
Reported: 2012-04-12 13:33 UTC by Amir E. Aharoni
Modified: 2014-02-12 23:52 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Amir E. Aharoni 2012-04-12 13:33:32 UTC
The direction of interface messages in MobileFrontent seems to be always based on $wgLanguageCode.

So, for example, if $wgLanguageCode is "en" and you ask for a page with uselang=he, the interface messages will appear as LTR, and that would be wrong. Among other things, the ellipsis at the end of the search label will appear on the right-hand side, even though it's supposed to be on the left-hand side for Hebrew. For comparison, you can easily use and see English content with Hebrew interface.

Since MediaWiki 1.18, core MediaWiki supports good separation between interface language and content language (Bug 6100). The scenario described above is not, by itself, very important, so this bug does not currently have a high priority, but ideally BiDi practices from core MediaWiki should be used as much as possible in MobileFrontend, too.
Comment 1 Max Semenik 2012-04-24 20:44:54 UTC
Amir, does it look OK with,5361 ?
Comment 2 Amir E. Aharoni 2012-04-25 12:48:46 UTC
I didn't review the code in detail, but the problem as described in the opening comment doesn't appear any more in this version.

Note You need to log in before you can comment on or make changes to this bug.