Keyboard shortcuts direction

Dev Translations
1

Hi,
I ran into the translation of the keyboard shortcuts (g h is home,etc.).

Two issues I’d like to cover:

  1. Is there an option to translate the key bindings?
  2. In RTL they it looks different than LTR since it’s two characters in LTR and then RTL, so the user might think the key bindings are h g instead of g h, is there a way to make is more comprehensive for Hebrew/Arabic/Farsi etc.?

EDIT: The text there is Z + Shift instead of Shift + Z for example.

Thank you!

3 Likes
2

No, there isn’t. The shortcuts were carefully selected so they do not clash with any browser shortcuts. And we mostly use shortcuts similar to other popular web apps like Gmail.

This is what I’m seeing when I switch to Hebrew:
image

Would replacing the comma with an arrow help? You could change that on Transifex.
בית h ← g

2 Likes
3

Nahh its not printing it right for Hebrew and I imagine Arabic as well. It gets super confusing when you move English around like this, it is unexpected, we never flip English.

It should be:

GH בית

I assume Arabic is the same problem @Osama ? Maybe you can take sorting this out

4 Likes
6

image

image

I got the correct order by applying direction: ltr; to the rows, but to me this doesn’t seem like the right fix here. I looked at the translation files and I noticed this:

https://github.com/discourse/discourse/blob/d1860536bc4b1e3beb67bc132adb1f22a8554c4a/config/locales/client.ar.yml#L2456-L2459

In the translation file the order is correct, but when direction: rtl; is applied the order is flipped and it appears as if RTL was never applied.

So unless I’m misunderstanding something here, this seems to be a translation error? I could special-case the keyboard shortcuts but I worry there might be other places with similar problems.

4 Likes
7

Hmmm this is a tricky pickle. We could pull <b>g</b>, <b>h</b> out of the translation I guess to make this less confusing. But then there is a giant amount of new translations to do.

I guess if he, ar and fr_IR all made the same mistake already we might as well just special case this.

3 Likes
8

Persian and Urdu have the same problem as well. I’m going to apply LTR on the keyboard shortcuts for now, and see if there are other places with the same problem.

5 Likes
9

The technical correct solution would be to use the <bdi> HTML tag, but browser support is really bad. :frowning:

בית <bdi><b>g</b>, <b>h</b></bdi>

In Chrome it looks like this:
image

The following produces the same result and should be supported in all browsers:

בית <span dir="ltr"><b>g</b>, <b>h</b></span>
4 Likes
10


maybe this will help?

15

Doesn’t change the fact that it doesn’t work so well on other browsers :slight_smile:

16

We are going to sort this out, discussing with @gerhard and @Osama what the best fix is.

Probably going to just break the translation into 2 pieces (English and non-English) so the value no longer has <b>g</b>, <b>h</b> in it. The reason this will take a tiny bit is cause we want to use the transifex API to correct all the already translated stuff so we don’t force translators to work through all keyboard shortcuts again.

4 Likes
17

My general approach is that if the keys cannot be translated anyways they should not be nominated for translation, except for the Shift+X case where “Shift” key name might be different in other languages.

1 Like
18

This was fixed a while ago.

We have now translations for modifier keys in client.en.yml which you can translate via Transifex.

4 Likes