Test the interface in languages other than English (especially on mobile)

[afercia]

Ideally, a large application like Gutenberg that is meant to be translated and used in several languages should be designed with localization in mind and continuously tested in other languages during development iterations.

I'd like to take this opportunity to suggest to everyone, especially the ones who are not native English speakers, to start testing Gutenberg in their language now, even though the interface is not fully translated yet.

I feel this is an area where, historically, WordPress hasn't always done its best. Of course, most of the development has always been made in English (not arguing that) and testing in other languages has been often an afterthought, if that ever happened. Yes, some additional space is generally reserved to longer strings that may come from other languages, but that's not enough.

This applies to all the interface, on any screen size, but let's consider just the mobile view for now, and just the top toolbar.

What is the minimum display size Gutenberg is optimizing for?

At a 320 pixels viewport, the top toolbar starts being cutted off on the right, even in English (see in the screenshot below: editing a draft):

Other languages typically have longer strings. Actually, English is one of the Western languages with the shorter words. Let's consider, for example, German:

See how there's no space to display the ellipsis button. Notice the word "Saved" is not translated yet. I think it's "Gespeichert"? Anyways, I'm pretty sure it's longer than "Saved" 🙂

Even at a 375 pixels viewport, the toolbar is cutted off on the right:

There are several ways to address these issues, more related to design so I'm not the best person to give suggestions. However, I'd like to mention a few things:

• other languages may have strings even longer than the German ones
• plugins may add UI controls so designing on a "fixed" amount of space maybe is not the best idea in the first place
• hiding UI controls just because there's not enough space is not the best approach, and it's a sign of a problem in the interface itself. For example, how I "Undo" or "Redo" under a 600 pixels viewport?

[afercia]

See the new buttons introduced in #5300 I think they're definitely an improvement, the UI is more clear. However, they take more space. I'd strongly recommend to consider translations in other languages may use longer strings. A couple examples:

German:

Worth considering the buttons labels change depending on various conditions, for example when a user with contributor role creates a new post the publish button becomes "Submit for Review". The translations of this label will very likely be longer:

(any native German speaker willing to translate this ^^ for testing? 🙂 )

/cc @jasmussen

[Soean]

German

Save: Speichern
Saved: Gespeichert
Preview: Vorschau
Submit for Review: Zur Revision vorlegen

[moorscode]

In a general sense, elements need be able to be as big as they need to be. Designing for a certain translation is not a solid basis to rely on.

In this case the bar should be able to grow higher to accommodate the space needed to place all buttons.

Having a fixed menu-button at the right-top is something that might help to maintain functionality at an expected location.

Overflowing the buttons and saved-message allows for a usable state of all the elements.

Suggested functionality:

• Bar should be expanding when buttons need to overflow to new line
• Menu-control should remain "sticky" on the top-right

[moorscode]

In line of the comment above, this issue is a bit too specific in my opinion.

Making it broader; an issue to determine usability of all elements with dynamic length (translatable strings) instead of language-specific tests/checks.

I can imagine a testing method of overriding the translations globally with just random words and seeing which buttons/elements are being obscured or overflowed.

[jasmussen]

I have a solution that I'm pushing in a minute :)

[jasmussen]

In #5329 I believe I've addressed the mobile issues present, and verified it works with at the very least the german translations provided here.

I could not find out how to get into a situation where the big primary button said "Submit for Review". I'm very likely missing something here.

[afercia]

I could not find out how to get into a situation where the big primary button said "Submit for Review".

Login as contributor 🙂

[jasmussen]

Login as contributor 🙂

Thank you, that worked :)

So, this is what that looks like in English, per that branch:

And here's German:

Womp womp.

What I propose we do is to first shepard #5329 through and merge that, as it fixes real issues and mitigates the issues in this ticket. As far as I can tell, it fixes every issue around the editor bar, except for the contributor issue.

I will then open a separate ticket for the "Submit for Review" button, and tackle that separately. I've been meaning to look at the pre-publish and post-publish flow regardless, and this feels to me like a perfect situation for such a flow. Decide you are done -> Get into Publish Flow -> Submit for Review. In such a situation, here's what a contributor would see:

In German, that would give you this pre-publish screen:

Now keep in mind, that fits on an iPhone 5, as it should as that's the smallest width phone we support. But most phones today have way wider screens, so if you're missing some whitespace here, most users would have that.

Thoughts?

[karmatosed]

What I propose we do is to first shepard #5329 through and merge that, as it fixes real issues and mitigates the issues in this ticket. As far as I can tell, it fixes every issue around the editor bar, except for the contributor issue.

Solid +1 from me on that.

[afercia]

I'd recommend to not close this, as it's more a general task that should run from now on and not related just to the header, and not just mobile.
Or maybe open a new one, or include testing in other languages as a task that should run from now on.

[jasmussen]

I'm not personally opposed to reopening this, but think in this phase it would be better to open one or multiple other tickets for specific issues, like for example #5343. We should always test for other languages, and for mobile responsiveness and a slew of other things. Ideally we should have tickets that are specifically actionable. What do you think?

[afercia]

Sure, up to you, My point is more about including testing in other languages in the ongoing tasks. HAving actual working translations would help :)