gangleri wrote:

Changing the summary to focus on *facilitate*.

example:
{{template_foo\

}}

should render the same as {{template_foo|param_01=bar}}

Would str_replace( ... ) be sufficient to implement this?

[[Thai wordbreak]] on test.wikipedia.org is a browser test page, demonstrating whether or
not the browser you use to display it has Thai word segmentation capabilities. In Opera
and IE, the text in the edit box breaks at word boundaries, no horizontal scrolling is
required. In Firefox, the text is unbroken, editing requires horizontal scrolling. Adding
line breaks and backslashes would defeat the purpose. The test contrived, it consists of a
Thai passage with spaces and punctuation removed. Adding line breaks and backslashes to
real Thai text is not necessary, see for example

http://th.wikipedia.org/wiki/%E0%B8%AA%E0%B8%B7%E0%B8%9A_%E0%B8%99%E0%B8%B2%E0%B8%84%E0%
B8%B0%E0%B9%80%E0%B8%AA%E0%B8%96%E0%B8%B5%E0%B8%A2%E0%B8%A3

Interaction with lists might be a better example, although note that you can use HTML-
style lists.

gangleri wrote:

*note*
The implementation of this bug will have impacts on SQL searches (most of them
not available) for user Joe.

Example:
The "standard" search for 'hello world' would not find
hello \
world

Would it be enought if it were only 'per edit'?
I mean you write
hello \
world

but it's saved as
hello world

as an 'editor trick', like the ~~~~. It would be easier to implement as it only
hacks the editor, and even that is easy as it would be an str_replace( , "\\\n",
"");

gangleri wrote:

(In reply to comment #4)

Would it be enought if it were only 'per edit'? ...

This would not make much sense. What would you do if you / some body else is
editing the page the next time? All "the logical breakepoints" are gone and you
would not recognize the "logical syntax" (the order of the characters how they
have been typed / are stored in the database / how they are interpreted by the
syntax).

If you want to experience BiDi editing please go to
[[wikt:yi:user:Gangleri/tests/bugzilla]]. Start editing sections, move the
cursor, select somthing and paste it in another position. This is an "easy" one.
Please just make previews.

[[wikt:yi:template:tsayt - divisions]] and [[wikt:yi:template:vokh - divisions]]
contain both RTL and LTR characters. To understand "logical breakepoints" edit
[[wikt:yi:צײַט]].

The scope of this request is to be able to start in a new line *also* at
positions which would break wiki syntax. One of this situations is a syntax like

and the called template is using [[{{foo}}]] .

best regards reinhardt [[user:gangleri]]

The following also seem to work:

• this <!--

--> continues

• this <nowiki>

</nowiki> too

Imho there is no need to add new escaping methods when these do work.

gangleri wrote:

(In reply to comment #6)

The following also seem to work:

• this <!--

--> continues

• this <nowiki>

</nowiki> too

Imho there is no need to add new escaping methods when these do work.

Reopening this bug. The answer three years after the report is not satisfactory. In order to understand the importence of the requirement you need to make some 20,000++ edits with mixed directionality on crapy computers (with outdated operarting systems and browsers).

Why it should not be possible to use a *whatever* unused character to provide this functionality?

The main issue are the characters with directionality neutral which might be displayed oposite to what was keyed in. Please understand that mixed script editing and correction is not the same as looking at a Linux shell ASCII text where you may identify imediately what you are loking for.

Bidirectional support in text areas is quite poor. It is mainly a problem of the operating systems. What I have asked for is a workaround (inside the text are box). Please remind that the most commonly accesible places do not have editors with enhanced BiDirectional support installed. There you may not copy text fom one application to an editor, edit it and copy it back.

Best Regards Reinhardt [[user:Gangleri]]

The trick is to use comment for this purpose as explained in comment 6. We do not want to add another buggy key in the parser.