Infrastructure

This seems corrected by this issue https://github.com/WeblateOrg/weblate/issues/4772
Could you comment on the bug if this is not the case? Thanks in advance

Sophie Gautier wrote:

This seems corrected by this issue https://github.com/WeblateOrg/weblate/issues/4772

That issue is about Hebrew quotation marks. Still, I've made a comment about MAQAF there, since Yaron mentioned it in a comment of his own.

Eyal Rozenberg wrote:

Sophie Gautier wrote:

This seems corrected by this issue https://github.com/WeblateOrg/weblate/issues/4772

That issue is about Hebrew quotation marks. Still, I've made a comment about MAQAF there, since Yaron mentioned it in a comment of his own.

Thanks! And I see that Adolfo recommended you to open another issue and gave you a workaround until it's corrected.

Christian Lohmaier wrote in #note-4:

Is this still a problem after the latest updates?

Yes, it's still a problem. I just checked again. See The glossary or just a certain individual strings

This Source-derived design has Hebrew characters. Maybe we could add it to our Weblate while (if at all) upstream considers it. WDYT, Eyal, Cloph?

Thanks for the pointer, Assistant font of course would be more obvious choice if it is indeed meant as an addition to the Source Sans Pro font - updated jsfiddle with the font as additional example: https://jsfiddle.net/pbdja8xf/

For some reason though the font-weight is off compared to Source Sans, weird for a font that is meant to be used as an extension of an existing one. (just add two paragraphs with latin text, one set to font-family: "Source Sans Pro" and the other to font-family: "Assistant" - could also be that the css handed out by the google URL uses the wrong fonts, but both are specified in the returned css as style normal, with a weight of 400, but still pretty different in browser.

As to upstream: Since the font doesn't include Hebrew characters at all, and it is possible to just limit Assistant to Hebrew subset it might be worth adding it to upstream, although that then rises the question: when to stop adding fonts. Easy to argue for Assistant "it is an extension to the font you're already using", but of course other for other code-ranges it won't be that straight forward..
That brings me back to my other initial question: can't we "assume the users' browser would have a default set of fonts (the "sans-serif" alias) that would render their language properly"? Guess the answer is "no"?

Adolfo Jayme Barrientos wrote in #note-7:

This Source-derived design has Hebrew characters. Maybe we could add it to our Weblate while (if at all) upstream considers it. WDYT, Eyal, Cloph?

The MAQAF looks fine. Cantillation marks are missing, but I don't think we need those anywhere in the UI localization.

And - unfortunately, it seems that for now, users' browsers' default fonts can't be assumed to render Hebrew correctly. They can be assumed to render it legibly, though. So it is legitimate to say: "This is a browser problem, not a weblate problem". And I'm not even entirely against that, but then - I would like that someone higher-up in the project make a proper complaint to Mozilla, Google, Microsoft and Opera about this issue (after verifying that the problem is observed with all of their browsers.

The newly installed Weblate now uses a locally-served Source Sans 3 (instead of the old “Source Sans Pro” that is currently served on e.g. Google Fonts). Any comparison with the Assistant font should now be done with “Source Sans 3”, but still I don’t think anybody should expect a perfect down-to-the-pixel match between the two families — that is unreasonable.

The newly installed Weblate now uses a locally-served Source Sans 3

The issue still persists.

Christian Lohmaier wrote in #note-14:

Hebrew now uses the Assistant with the Source font as fallback

I don't know what that means, but the bug as described still persists. Please explain or unresolve it.

Christian Lohmaier wrote in #note-16:

You did signal that the Assistant font renders the characters OK, so that's why I did use it.

I haven't actually checked what font is being used in the textboxes. But - your screenshots doesn't show any Hebrew punctuation marks at all - neither correctly nor incorrectly rendered.

But, wait, now I do see the MAQAF rendered correctly! Not when I select text, and the cursor position is messed up, but still. So, no need to unresolve I guess.

can you check again? the textedit mode wasn't included in the css rule, so that used the old fallbacks, and depending on your system that might have different metrics and cause some offset in cursor placement.
If you still have the problem, please provide a short screen recording demonstrating the problem.

Christian Lohmaier wrote in #note-18:

can you check again? the textedit mode wasn't included in the css rule, so that used the old fallbacks, and depending on your system that might have different metrics and cause some offset in cursor placement.
If you still have the problem, please provide a short screen recording demonstrating the problem.

Seems fine now, also when selecting text. Thank you.