Last modified: 2011-03-13 18:05:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T7121, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5121 - Facilitate bidirectional editing / readability via a trailing escape character (as "\") at the end of line
Facilitate bidirectional editing / readability via a trailing escape characte...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 4357
  Show dependency treegraph
 
Reported: 2006-02-27 19:03 UTC by lɛʁi לערי ריינהארט
Modified: 2011-03-13 18:05 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description lɛʁi לערי ריינהארט 2006-02-27 19:03:36 UTC
Hallo!

List items require to write anything behind a line starting with "*", "#", ":",
etc. in one line.

This can require longer sequences / lines which render in the editor textarea
over many lines.
Beside this long lines are more difficult to handle in 'diff' and they (long
lines) can cause a 'headache' if LTR and RTL characters are mixed.
http://test.wikipedia.org/w/index.php?title=Thai_wordbreak&action=edit requires
scrolling to edit / verify the text.

*request*
Please choose an escape character (as "\") which should be used as final
character in a line in order to facilitate editing. 'diff' should work as before
in "real" lines.

*compatibility issues*
This change should not breake existing page source. "\" is used in Unix but I
assume that there should be anly a few lines ending with Unix style url's.
Another question is if "\" should be used as well to "split" long url's or *not*.
Hope that this request would not create other "complications".

best regards reinhardt [[user:gangleri]]
Comment 1 lɛʁi לערי ריינהארט 2006-04-13 11:45:27 UTC
Changing the summary to focus on *facilitate*.

example:
{{template_foo\
|param_01=bar\
}}

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

Would str_replace( ... ) be sufficient to implement this?
Comment 2 Tim Starling 2006-04-14 08:58:35 UTC
[[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.
Comment 3 lɛʁi לערי ריינהארט 2006-04-14 12:13:58 UTC
*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
Comment 4 Platonides 2006-04-14 21:09:20 UTC
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",
"");
Comment 5 lɛʁi לערי ריינהארט 2006-04-14 23:28:33 UTC
(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
|parameter1=foo
|parameter2=bar
and the called template is using [[{{foo}}]] .

best regards reinhardt [[user:gangleri]]
Comment 6 Niklas Laxström 2009-06-19 13:08:38 UTC
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.
Comment 7 lɛʁi לערי ריינהארט 2009-12-11 00:19:02 UTC
(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]]
Comment 8 Antoine "hashar" Musso (WMF) 2011-01-21 14:25:25 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links