Please create apt preconditions for varying amounts of text in internationalisations

[uli-on]

In #70 you mention that you want to add fields that contain descriptions. We've had a short exchange of words over in Crowdin where I mentioned that certain languages use longer and more words than default English, more precisely it's been the label filtering options, where now the German translation is shrunk in font size to an estimated 70% in order to fit in. Another one I saw is a string that has been updated recently in Crowdin: I'm holding my breath for "No reminder is set up for this note" or the like, where the verb was cut off in German, German verbs sitting at the end of sentences very often while being essential for understanding.

I'll post whenever I find such things, but German certainly is not the only language that's not as terse/short as English is. So generally creating optimal preconditions seems a good thing in respect of any language.

The measures I'd like to propose include auto-growing/-shrinking buttons and fields while alignment for surrounding/preceding/following fields is maintained.

Also, activating hyphenation seems a means of choice for using the available space better. As far as I can judge (I'm not a developer, I simply observe) hyphenation seems possible now (at least with my Webview 102). In Noto words sometimes are cut at any point when they're too long to fit (here: buttons), instead of using the orthographically correct break points and a hyphen.

[alialbaali]

Okay, I see what you mean. Feel free to translate the words as they are without shrinking them, and I'll handle how they are displayed.

[alialbaali]

Do you currently have places where it should show text in multiline or hyphened?

[uli-on]

Multiline is not set for above mentioned "no reminder is currently set", and hyphenation would be great for almost all buttons that are stored inside a drawer. Also the selection terms for label filter modus suffered from not being treated in any such way. Should I find more I will post. Currently out in nature.

[uli-on]

This is such a subtlety that I think opening a separate issue is too much. Speaking of the sliding selection indicator for label filters (above): I recently saw there's too little padding-left/right on the indicator itself while in landscape format. Also, and only held in landscape format: English buttons build a lump in the middle (while German ones seem to occupy one third of the width, which looks way nicer).

[alialbaali]

For label filtering buttons in landscape mode, it is fixed now. Meaning, they will expand to fill all the available width. For portrait mode, there are three options:

1. Wrap the text, which is how currently it's done.
2. Make them scrollable, like the following screenshot:
   
3. Make them a dialog like Sorting Type, Sorting Order, etc...

[alialbaali]

Multiline for reminder text has already been set. One thing is left, which is hyphenation in dialogs. My question is, is it really preferred over line break?

[uli-on]

For portrait mode [...]

If in option 1 hyphenation is not possible, then option 3 would be the most elegant one.

hyphenation in dialogs. My question is, is it really preferred over line break?

If "Line break" means break in the middle of words, then hyphenation please, and no more orthographic faults by line breaks, no more single letters cut off at word ends wrapped onto a new line. Else, if it means wrap at blanks only, then don't pull your hair out, I'm fine with that.

[uli-on]

Oh, "jump through hoops" was what I actually meant, not the hair pull thing.

[uli-on]

For label filtering buttons in [...] portrait mode

We could try out a fourth option: the soft hyphen entity (&shy). I would massage some into a string that I know is broken in two at the wrong point. It just needed you to pull the translation from Crowdin for the next minor update (or a try-out apk). What do you think?

[alialbaali]

If "Line break" means break in the middle of words, then hyphenation please, and no more orthographic faults by line breaks, no more single letters cut off at word ends wrapped onto a new line. Else, if it means wrap at blanks only, then don't pull your hair out, I'm fine with that.

No, it wouldn't break in the middle of the word. If the word doesn't fit the space, the whole word will move to the next line, like how currently it is being done.

We could try out a fourth option: the soft hyphen entity (&shy). I would massage some into a string that I know is broken in two at the wrong point. It just needed you to pull the translation from Crowdin for the next minor update (or a try-out apk). What do you think?

You mean translators handle that? If so, then there's a problem with that, which is screen sizes differs from each other. Meaning, what could look good in one screen, it wouldn't on the other, e.g. In tablet there's so much space, breaking the word and adding a hyphen, would make the word multiline even when it shouldn't.

[uli-on]

would make the word multiline even when it shouldn't.

A ­ entity is invisible as long as the word fits the line, it's not a hard coded word break. It is just a proposal to the browser and becomes visible only when the proposal to break a word at a certain point is needed and used by the browser. The only thing I'm not sure of yet and why I wanted to try it out on one single term and in a test apk (or a minor release) is, it might remain visible as the string ­ itself.

[uli-on]

Do you perhaps have an opportunity to test that ­ entity in an emulator, without pulling translations and producing an apk?

[uli-on]

Also, if 'shy' worked, it wouldn't have to be used of necessity (while doing no harm to nothing if not used), it would just offer an additional method to optimise text rendering in situations where space is severely limited.

[alialbaali]

I have tried, but it doesn't work. Check the image:

[uli-on]

Thanks, that's nice. Two things, why it did not work, probably:
1 Looks like you've left out the closing semicolon
2 Browsers might use it only when it sits amidst letters like here:
qwertz­uiopl­kjhgf­dsayx­cvbnm

Ready for copying, that little monster. Will you, please?

[alialbaali]

Of course. I tried both of them, and none has worked. Check the image below:

[uli-on]

Rats! Thanks anyway.

[alialbaali]

I'm thinking of making sorting, grouping and their orders dialogs as buttons like Label Filtering Type. What do you think?

[uli-on]

Usability-side an improvement to have the options visible without further clicking. No question!

But how do you see the housing of the amounts of text? E. g. German:

Manuell * Erstellungsdatum * Änderungsdatum * Alphabetisch

In two rows? Below each other? Is the sliding indicator possible still?

Can you easily imitate that without coding to show a preview?

[alialbaali]

They would be horizontally scrollable just like here #93 (comment).

[uli-on]

I'm not avert to having it that way. Only objection is that there should be some kind of indicator for "there's some more to see" for these cases that one option is fully visible while the next one is fully covered with the box's edge. If these semi transparent gradients for imitating the shadow of an edge weren't that butt ugly. Are there other possibilities?

[uli-on]

In order to avoid the solution of animating the options marquee-like: Maybe a semi-transparent filled triangle whenever the content exceeds the available space?

[alialbaali]

In order to avoid the solution of animating the options marquee-like: Maybe a semi-transparent filled triangle whenever the content exceeds the available space?

Good point. I'll start working on it.

[alialbaali]

Well, I think it looks messy:

[uli-on]

Two possibilities:

• What about darkening the current #f7f7f7 of each selector's background a little more while at the same time lightening the black indicator for a substantial amount to something around #777.
• If technically possible: The now full height indicator might be reduced to a thinner bar with rounded ends that slides on the bottom edge of the gray background rail, that way also serving as a separator between all the different elements.

Also, you might try a constant padding around text labels. That would also visually calm the "haystack" effect.

[uli-on]

Ah, now with this flattened hierarchy you can also group together "Sorting type and order" and "Grouping type and order", maybe with an integrating, consistent background colour like the f7f7f7 and some more distance between groups. That would also straighten out, calm and make relations clearer.

[alialbaali]

[uli-on]

That's better, in fact, quicker to grasp, more clean/calm. I'd really prefer the variant with the grouped selectors, though with the proposed background colour their relation isn't visible enough, cause the darker colours sitting on top have much stronger contrast. Hence it needed a slightly darker gray. The grouping's visibility might also be facilitated by slightly enlarging their distance.

OK. Then I projected my thoughts into using this gadget and thought about

• where would the indicator be at the end of a selection with excess width
• how would the selection itself have to react upon such a situation, so that the user understands the situation and the indicator remains visible.

The result was, optimally the indicator needed to be fixed, cause two moving parts are too wobbly to use, counterintuitive.

And: A fixed indicator can sit in the middle, which will be even tidier, and using it seems more familiar.

[alialbaali]

• If there's no excess width, then text would wrap.

TBH, I think I prefer dialogs over those two. However, I'll tweak it a bit to show currently selected sorting/grouping.

[uli-on]

OK, and what do you think of Sorting Type and Sorting Order combined in one drawer? That would ease using them and avoid accidental misuse by mixing up the two secondary selectors.