thanks for the bug!

I'm a bit leary of --force-ui-direction=rtl because it seems to be showing you a half-baked RTL UI.

using LANGUAGE={ar,he} on Linux is giving me better / more sane results.

also, punctuation should be flipped in RTL (so, on the left), so the periods are where I would expect.

I know it's a pain to flip your system language on Mac, but it's the only way I've gotten reliable results in the past :(

please re-open if you're sure there's issues and maybe show me locally with a full system language flip from settings?

Deleted: 2016-11-28-205019_1067x831_scrot.png 44.5 KB

	2016-11-28-205019_1067x831_scrot.png 44.5 KB View Download

Deleted: 2016-11-28-205048_924x557_scrot.png 41.9 KB

	2016-11-28-205048_924x557_scrot.png 41.9 KB View Download

It is extremely easy to change the system language on the Mac.

Re: the punctuation, I was thinking that because it's a full English sentence within an RTL paragraph that LTR punctuation conventions would apply but apparently not. However, as you can see from the screenshot, the parens around the system version are still incorrect.

Deleted: Screen Shot 2016-11-29 at 9.15.22 לפ׳.png 90.2 KB

	Screen Shot 2016-11-29 at 9.15.22 לפ׳.png 90.2 KB View Download

yep, this certainly seems like a bug if you've swapped language fully.  out of curiosity, is this string the same on beta/stable?

dpapad@: has this translation changed lately?  maybe the page isn't fully translated yet?

@dschuyler: Is it possible that the "i18n{}" templating mechanism is messing up the version string? Printing the string in JS seems fine (see attachement).

Deleted: version_rtl.png 60.9 KB

	version_rtl.png 60.9 KB View Download

dpapad@: no, not likely

#4
The string is confusing the text layout engine (separate from i18n or loadTimeData). 

Since this is not a real sentence and instead a set of data about the version; I'll suggest setting dir="ltr" on this <span> so that it is *not* reinterpreted by the system laying out the text. Forcing the dir on the specific element will cause the text layout system to not change the layout of the text.

It may also help to align the text to the far left or right, depending on the actual dir. That way the unaltered string will be on the far left or the far right as appropriate.

(Whoops it's a <div> not a <span>).

@dschuyler: Thanks for the suggestion. In fact that is what the old about page already does (see https://cs.chromium.org/chromium/src/chrome/browser/resources/help/help_content.html?l=18&dr=C).

I'll go ahead and make the same change for MD Settings.

So, adding dir="ltr" fixes the string itself, but messes up the alignment (see screenshot). Note that the old page already suffers from the alignment bug.

Deleted: dir_ltr.png 85.0 KB

	dir_ltr.png 85.0 KB View Download

Sorry, I think didn't explain this well enough, "It may also help to align the text to the far left or right, depending on the actual dir. That way the unaltered string will be on the far left or the far right as appropriate."

Using a css like
.foo-class[dir=ltr] { ... }
.foo-class[dir=rtl] { ... }

and wrapping the current div with something like:

<div class="foo-class">
<div class="..." dir="ltr"> ... </div>
</div>

Then foo-class would shift the text to the far right or left.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a2a00b738abb8301a46a6bb92c150d1fe1155e2c

commit a2a00b738abb8301a46a6bb92c150d1fe1155e2c
Author: dpapad <dpapad@chromium.org>
Date: Sat Dec 03 03:31:32 2016

Fix browser version string in RTL mode.

BUG= 669256 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2540023002
Cr-Commit-Position: refs/heads/master@{#436156}

[modify] https://crrev.com/a2a00b738abb8301a46a6bb92c150d1fe1155e2c/chrome/app/settings_strings.grdp
[modify] https://crrev.com/a2a00b738abb8301a46a6bb92c150d1fe1155e2c/chrome/browser/resources/help/help_content.html
[modify] https://crrev.com/a2a00b738abb8301a46a6bb92c150d1fe1155e2c/chrome/browser/ui/webui/settings/about_handler.cc

I believe this is fixed now. Please re-open if not the case.

Seems like it's still broken in the latest Canary?

Deleted: Screen Shot 2016-12-07 at 4.19.52 אח׳.png 23.7 KB

	Screen Shot 2016-12-07 at 4.19.52 אח׳.png 23.7 KB View Download

this is a pickle.

I would guess that there are no further code changes required by developers, and that when the translators actually finish the new translations (the SLA for that is only by *stable*), it should be fixed.

so basically, canary might be "broken" for a while, but it's likely only waiting on a translation (but it's not guaranteed the translation will have the correct directionality in each component of the translation).

Hm, this is not what I am getting on Linux see attachment.

Deleted: rtl_version_linux.png 9.3 KB

	rtl_version_linux.png 9.3 KB View Download

I believe remaining items on this bug are a duplicate of issue 849869.