@egardner something you're interested in? 😃

I believe that this is a matter of hard-coding the dir=ltr attribute (or doing the equivalent in CSS) on the actual coordinate input & display elements – the idea is that we don't want the letters/numbers getting shuffled around in lat/lng strings because then they become nonsensical, even when the rest of the text needs to change.

I'll post some screenshots of the updated behavior to get confirmation from RTL-reading folks here.

Change 578582 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Prevent coordinates from being re-arranged in RTL mode

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

Here's the updated coordinate input in Hebrew:

The input fix is achieved with the following CSS:

.wbmi-input-widget__input {
    /* @noflip */
    direction: ltr;
}

And here's the updated ItemWidget (displayed value) in Hebrew:

This is fixed by wrapping the label in a <bdi> tag.

@Mooeypoo does this look correct to you?

Change 578582 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Prevent coordinates from being re-arranged in RTL mode

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

Following up since @Etonkovidova has asked me to look into why it's not working:

I might be missing something here,but I think the <bdi> tag was missed in another place. When I'm looking at the coordinates in view (not edit) -- they're jumbled. The html structure:

<span class="wbmi-qualifier-value--value">34°0'12.550"N, 118°53'40.661"W</span>

There's no bdi tags in there. I see that the patch is adding a direction:ltr to wbmi-input-widget__input which I assume is the form input, and that you're adding bdi tags in php and in the template, but it looks like that value is the one with the wbmi-entity-label class, which is not the one that's having the problem.

As far as I could test in the browser, it unjumbled itself in both of those (or either) --

1. Adding both of these css rules to .wbmi-qualifier-value--value element

unicode-bidi: isolate;
direction: ltr;

2. Adding <bdi> into that wbmi-qualifier-value--value span:

<span class="wbmi-qualifier-value--value"><bdi>34°0'12.550"N, 118°53'40.661"W<bdi></span>

As generalizations go, it looks like #2 would be better, because the first one would make all fields LTR (even those that shouldn't be) while <bdi> will, at least, adhere to the internal directionality of the value. It won't solve all of the value issues but it will likely solve 90% of them.

So I think things are working fine at the level of the ItemWidget. Here's the markup for Item labels as currently deployed on production:

<h4 class="wbmi-entity-label">
    <bdi>48°51'29.2"N, 2°17'41.4"E</bdi>	
</h4>

And here's a screenshot of the UI in Hebrew (from this page):

This looks right to me but would be good to get confirmation.

The Qualifier-level label (i.e. the next level down from Items) does not include a <bdi> tag currently, but I can add one in a follow up patch.

Right now the qualifier-level markup looks like this:

<span class="wbmi-qualifier-value--value">36°18'N, 78°36'W</span>

Here's a screenshot:

Aside from adding a BDI tag to qualifier value read-mode, does everything else here behave correctly?

@egardner - it might be betalabs specific but I still the issue with displaying geo coordinates in RTL.

I was checking in betalabs two properties (as far as I could see there were two relevant properies on Special:List of Properties for geographic coordinates):

• coordinates
• coordinate location

On https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=File:Lion_fountain_statue.png&uselang=he
LTR

		<div class="wbmi-entity-header">
			<div class="wbmi-entity-data">
				<div class="wbmi-entity-title">
					<h4 class="wbmi-entity-label">
						<bdi>
							<a target="_blank" title="d:Special:EntityPage/Q421" href="https://wikidata.beta.wmflabs.org/wiki/Special:EntityPage/Q421" lang="en">0</a><sup class="wb-language-fallback-indicator">אנגלית</sup>
						</bdi>
						
					</h4>
				</div>
			</div>

 <div class="wbmi-item-content-group">
				<div class="oo-ui-widget oo-ui-widget-enabled" aria-disabled="false"><div class="wbmi-qualifier">

		<div class="wbmi-qualifier-value">
			<a target="_blank" title="d:Special:EntityPage/P477" href="https://wikidata.beta.wmflabs.org/wiki/Special:EntityPage/P477" lang="en">coordinates</a><sup class="wb-language-fallback-indicator">אנגלית</sup>

				<span class="wbmi-qualifier-value-separator">: </span>

			<span class="wbmi-qualifier-value--value">34°0'12.550"N, 118°53'40.661"W</span>

			
		</div>
</div></div>

vs production

<div class="wbmi-item-container">

		<div class="wbmi-entity-header">
			<div class="wbmi-entity-data">
				<div class="wbmi-entity-title">
					<h4 class="wbmi-entity-label">
						<bdi>
							48°51'29.2"N, 2°17'41.4"E
						</bdi>
						
					</h4>
				</div>
			</div>

Change 584807 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Wrap Qualifier Values in <bdi> tags for better RTL support

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

That screenshot is showing incorrect behavior at the Qualifier level. Just uploaded a 1-line patch which should address that by simply wrapping the qualifier value in <bdi> tags, like we do for Items. Let's get this on Beta quickly and check the same file again.

Sweet, I think this should fix it. I +2'ed, so it should be available on beta soon to test.

Thanks for the extra care for RTL (and mixed directionalities!) :)

Change 584807 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Wrap Qualifier Values in <bdi> tags for better RTL support

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

(egh, my screenshot didn't work, but--) w00t, it works now!

Just as general clarification, there are a couple of RTL-ui "cases" that came at play here:

• RTL wiki with RTL interface (exmaple: Hebrew wikipedia with Hebrew UI)
• LTR wiki with RTL interface (example: English wikipedia with Hebrew UI -- which is the case I was looking at)

And of course the opposites of each ;)

This might explain why sometimes you may see a different rendering for Hebrew -- it might be that it is the difference between being in a RTL-content wiki vs LTR-content but with RTL-ui wiki.

Moving to be checked in production - wmf.26.