Help required to test with QtQuick Controls 2

[Johnny Jazeix]

Hi,

Le mer. 27 avr. 2022 à 23:09, Daniel Shahaf <danielsh at apache.org> a écrit :

> Johnny Jazeix wrote on Wed, Apr 27, 2022 at 21:52:02 +0200:
> > Hi,
> >
> > thanks for testing!
> >
> > Le mer. 27 avr. 2022 à 21:31, Daniel Shahaf <danielsh at apache.org> a
> écrit :
> >
> > > the "X" / "V" graphic is to its right.  That makes sense in LTR
> > > languages, but for RTL languages, where the "X" / "V" graphic of
> > > checkboxes is placed to the _right_ of the checkbox's text, the
> > > placement is misleading.
> > >
> > >
>

I've added note to the task and I have fixed this one and the "About
dialog" too.


> > I've created https://phabricator.kde.org/T15482 to write all the
> > inconsistencies we have for RTL language, can you take a look and add
> other
> > issues?
>
> I have an issue with the identity.k.o registration; I'll follow up on
> that separately.  In the meantime, one more issue:
>
> - In Hebrew at least, the "About" screen aligns the first paragraph to
>   the right (correctly) but the following paragraphs to the left
>   (incorrectly).  The order of letters and words is correct, but it's
>   the left margin that aligns rather than the right one.  Reversed
>   example:
>
>             Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut
>         purus elit, vestibulum ut, placerat ac, adipiscing vitae, felis.
>         Curabitur dictum gravida mauris.  Nam arcu libero, nonummy eget,
>                                     consectetuer id, vulputate a, magna.
>
> > For example, the authors in the help are written: "<name <email.com"
> where
> > we expect "name <email>". What is the correct form in Hebrew for this?
>
> Good question.  I suppose it should render as "name <email>", but in
> logical order, i.e., with name on the right.
>
> The po file writes the angle brackets as U+003C first and U+003E second,
> following rfc822's syntax as much as possible.  However, these two
> characters get mirrored in RTL contexts:
>
> [[[
> % unicode 003c
> U+003C LESS-THAN SIGN
> UTF-8: 3c UTF-16BE: 003c Decimal: < Octal: \074
> <
> Category: Sm (Symbol, Math); East Asian width: Na (narrow)
> Unicode block: 0000..007F; Basic Latin
> Bidi: ON (Other Neutrals)
>
> Character is mirrored
> ]]]
>
> This would be why in your example you get two "<" marks.  The one
> between "name" and "email" [in byte order] is a U+003C rendered
> mirrored, because it's preceded by an RTL character; the one after
> "email" [again in byte order] is a U+003E rendered normally, because
> it's preceded by an LTR character.
>
> I'm not sure how best to fix this.  Normally I'd consider explicit
> Unicode directionality characters (the po file already uses literal
> U+200E, for instance), but this is a pseudo rfc822 context, and I'm not
> sure whether email clients would DTRT with embedded directionality
> characters, should the line be copy-pasted into them (e.g., by
> a translator).  Perhaps we could sidestep the problem entirely by using
> <a href="mailto:…">[translator's name in Hebrew]</a> tags?  Or by moving
> the email addresses to a po comment; they _already_ aren't rendered (as
> of v2.4 on Linux).
>
>
For this one, I still don't have any fix. The mails are displayed but non
clickable (no link in the application is clickable at all because we don't
want children to wander on Internet :)).
They are also not in the .po file because it does not seem to make sense to
translate people names/emails (maybe I'm wrong)? We can reverse the
name/email programmably but there is still the issue.
We added/fixed the display of the email contributor thanks to
https://bugs.kde.org/show_bug.cgi?id=349111 and if I'm not wrong, we
already received contributions/feedbacks thanks to it so it would be nice
to keep it.

Cheers,

Johnny


> Cheers,
>
> Daniel
>
> [1]
> https://en.wikipedia.org/wiki/Bidirectional_text#Table_of_possible_BiDi_character_types
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20220512/e08bebd3/attachment.htm>