(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
View Attach Info

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-30) was last changed on 01-Mar-2007 19:05 by MicheleTomaiuolo  

This page was created on 15-Jan-2007 08:39 by ChuckSmith

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 286 added 12 lines
We really, really need someone with Bidi experience to enlighten us. But the arrow is reversed in presentation. The string is ' -> ', and I did not change my link regex in any way to accommodate rtl languages. Bidi is inherently confusing, and this arrow reversal was new to me, but the goal here is not to add to existing confusion.
The examples above were all-Hebrew, but I did some poking around into links with a URL target, which of course needs to be a LTR span because it's in ASCII. Basically, as long as the primary direction is marked as "rtl" (this is an attribute of the top-level [[http://www.w3.org/TR/html401/struct/dirlang.html|html]] tag, and can be overridden through an inheritance mechanism), it looks pretty good. The arrow points to the left, and the URL appears to the left of it, exactly as in the all-Hebrew example.
If the direction in the HTML is left as LTR (as is the case on this wiki), then the all-Hebrew links are still fine, but the mixed-direction ones are a total hash. This is definitely true for both alternates, and imho the hash is equally undecipherable in both cases. But again, I think this is an issue for HTML-based Bidi applications in general, and not something that's within our scope to try to fix. I did note that both Mac TextEdit and (Carbon) Emacs did a much better job in these cases, presumably because they use a heuristic to determine the text direction rather than relying on HTML markup. Thus, messing with this stuff in an editor is a viable option. I //also// observed that ASCII link targets within sentences are exceedingly rare. Link targets within sentences are overwhelmingly Hebrew, and when ASCII link targets occur, they seem to stand alone, for example as a bullet item. I do not know if this tendency is influenced by Bidi glitches, or is a matter of style, but in either case it would seem to keep the incidence of hideously confusing Bidi mixing to a minimum.
Therefore, my assertion that the arrow is less confusing stands.
People who want to experiment with the proposed link syntax are welcome to use the [[http://ghestalt.ghilbert.org/wiki/Sandbox|Ghestalt sandbox]]. You'll have to create an account to get edit permissions (otherwise, I fear, the site would be overrun by [[DiscussionComment.jsp|spam]]), but Creotians are more than welcome.
-- RaphLevien, 2007-01-17
Version Date Modified Size Author Changes ... Change note
30 01-Mar-2007 19:05 35.089 kB MicheleTomaiuolo to previous parenthesis
29 15-Feb-2007 16:25 34.751 kB ChristophSauer to previous | to last apologies accepted
28 14-Feb-2007 20:19 34.656 kB RadomirDopieralski to previous | to last apologies
27 14-Feb-2007 20:15 34.357 kB ChristophSauer to previous | to last refactoring: go ahead but don't call it poor argumentation
26 14-Feb-2007 19:57 34.014 kB RadomirDopieralski to previous | to last refactoring?
25 14-Feb-2007 02:25 33.717 kB RadomirDopieralski to previous | to last proposal not good enough
24 13-Feb-2007 16:55 31.978 kB JaredWilliams to previous | to last Don't like it either & should apply to images too
23 13-Feb-2007 16:49 31.844 kB JaredWilliams to previous | to last Don't like it either
22 13-Feb-2007 13:27 31.332 kB 62.12.165.34 to previous | to last against [[foo -> bar]] and [[bar <- foo]]
21 10-Feb-2007 20:04 31.151 kB RaphLevien to previous | to last argument for arrow, support for radomir ext link
« This page (revision-30) was last changed on 01-Mär-2007 19:05 by MicheleTomaiuolo