Last modified: 2014-08-11 10:45:32 UTC
The Hebrew Wikipedia frequently uses the template {{כ}} ( https://he.wikipedia.orgw/wiki/Template:Rlm ), which inserts the ‏ entity. This entity translates to an invisible zero-width control character, the [[right-to-left mark]]. This template works correctly when the article is rendered to the reader, but when the article is being edited in VE, the text behaves as if it's not there. For reference, see https://en.wikipedia.org/wiki/Right-to-left_mark .
See https://he.wikipedia.org/wiki/User:Amire80/ve-rlm for a demostration.
Hint: when disabling inline-block display for the template (e.g removing: .ve-ce-mwTransclusionInlineNode { display: inline-block; } ) it behaves properly.
This is a bit more complicated than removing a css definition. As far as I understand this is what happens -- 1. Parsoid recognizes {{כ}} as a template (expected) and sends it to VE as a transclusion object. 2. VE treats it as transclusion object (as expected) --- but this means that- 3. The content of the transclusion/template is wrapped with transclusion node markup. This means that the RLM code is now wrapped with html markup, which effectively alienates it from the string it is supposed to affect. In most other templates the above behavior is exactly what we want, so this template is an exception. We need to figure out a way to recognize these exceptional templates and then deal with them. But there is another issue - this is going to be a design challenge, too. "RLM" is an invisible character, so when we look at the article itself we have no indication that there is any special notation or character inside a sentence or a word. So, when we let users edit this in VisualEditor, we have to see how we can allow RLM to affect the word (so, it needs to not be encapsulated with html) *but* we also have to make sure a user can see it is there and, hopefully, interact with it. We need to come up with creative ways on how to allow user interaction. What happens, for example, if a user removes the string the RLM was attached to without removing the RLM character itself? The user may not know about it if it is invisible, and it can cause problems in the edit and later edit in that sentence. I think we might want to consider shifting from RLM templates, that provide directionality change in a string, to language annotations, that provide the same thing *plus* language definition. This is what we're moving towards anyways. It provides more information and it lets the user interact with the language definition. I understand that if we do it we will get dirty diffs, but I am not entirely sure how we can deal with RLM properly in the editor -- and is it not in any case preferable to use full-information language annotation instead of a limited-behavior RLM character?
1. I think that adding display:inline-block by the VE (to any transclusion node - and particularly to this template) is a bug, We should consider either removing this css or changing it to inline instead of inline-block 2. Language definition to assign directionality rather than RLM is good approach, but it isn't possible to replace all the RLM uses: A. for normal users it is annoying to meet wiki-text editing HTML code of <span dir="">... B. Sometimes specifying direction/language is overkill and the simple and best solution is to use RLM. Regarding the issue of "invisible template" which the VE users don't know it is there - I think it will be nice (and maybe there is already exist) to add ability to add text that appears only in VE editing mode [either with CSS which tells the content to display:none, and only in VE it appears, or with dedicated parser tag <onlyve>. This solution may be useful for other cases of "invisible templates".
(In reply to comment #4) > 2. Language definition to assign directionality rather than RLM is good > approach, but it isn't possible to replace all the RLM uses: > A. for normal users it is annoying to meet wiki-text editing HTML code of > <span > dir="">... That's why Moriel invested so much time in an easy graphical way to do it :) It's still in the "finishing touches" stage. The trouble is that while bidi isolation replaces most or all of the uses of RLM, it doesn't work in IE. Saw it coming? :) In fact, IE 10 and 11 (!) even show some elements with bidi isolation very incorrectly. Test the following page: https://en.wikipedia.org/wiki/User:Amire80/bidi-isolate > Regarding the issue of "invisible template" which the VE users don't know it > is > there - I think it will be nice (and maybe there is already exist) to add > ability to add text that appears only in VE editing mode [either with CSS > which > tells the content to display:none, and only in VE it appears, or with > dedicated > parser tag <onlyve>. This solution may be useful for other cases of > "invisible > templates". I love this proposal.
At Wikimania Moriel, Roan and I found that the bug, as originally reported, appears to be fixed. I don't know when exactly did the fix happen. Using the {{כ}} template works correctly while editing articles, and the original test page https://he.wikipedia.org/wiki/User:Amire80/ve-rlm shows everything correctly. That said, there are issues with handling this template after it's inserted: * The bubble that shows its name appears in a wrong location. * It's hard to know that it's there while editing in visual mode, because it is zero-width. Showing some kind of a flag there, as it's done with single line breaks, would be a nice idea. Should I close this bug and open separate bugs for these issues?
(In reply to Amir E. Aharoni from comment #6) > At Wikimania Moriel, Roan and I found that the bug, as originally reported, > appears to be fixed. I don't know when exactly did the fix happen. > > Using the {{כ}} template works correctly while editing articles, and the > original test page https://he.wikipedia.org/wiki/User:Amire80/ve-rlm shows > everything correctly. This would probably have been fixed by Ed's work on unwrapping generated content nodes. > That said, there are issues with handling this template after it's inserted: > * The bubble that shows its name appears in a wrong location. Yeah, the context seems to find the nearest thing that actually displays and attaches to that. Probably the same issue as the below. > * It's hard to know that it's there while editing in visual mode, because it > is zero-width. Showing some kind of a flag there, as it's done with single > line breaks, would be a nice idea. That's bug 49806. > Should I close this bug and open separate bugs for these issues? Have done so. Yay.
