Page MenuHomePhabricator

Allow users to change text direction in all text input and textarea boxes
Closed, ResolvedPublic

Description

Author: gangleri

Description:
Dear friends,

What's the problem: The majority of contributors to LTR wiki projects have
problems with the way edits are made in RTL projects.
In a RTL wiki

  • you type "[[" and you see "]]"
  • you type "}}" and you see "{{"
  • you type "</span>" in the last line and you se "<</span"
  • you type "Dear friend!" and you see "!Dear friend"

Beside these characters "|" display differently in the "editor", also all
punctuation characters as .,:;*#"' ... which would inherit RTL properties.

Feature request: It would be a great help for many contributors if the textbox
of the "edit window" could be set independend of the LTR / RTL nature of the
"content language" / selected user interface. Just let the choice to the users
what they prefer.

This should be achieved as follows:
a) as a parameter in [[special:Preferences]]
b) as a setting in monobook.css / monobook.js
Devlopers should decide about priorities if both ways are specified and
comunicate this to the community how it works as soon as the feature is implemented.

I assume that the feature about a *common LTR / RTL nature* should be "relevant"
for all type of objects used as "input mechanisms" also the "Summary" inputbox,
the "Search / Go" inputbox, the "<inputbox>" inputbox etc. (What I mean is that
no parameters / variables should be required for each box.)

I hope this would be a great improuvement / help for contributors who make minor
edits as inserting Interlanguage links, images, correcting or adding alternative
writings (Latin, Russian, ...) or spellings (IPA, ...).

*Finaly* I hope that most browsers would support to have on one hand one kind of
displaying text (LTR / RTL) for the "preview" but would allow in parallel to
chose the "oposite" way to edit the text in the textboxes, inputboxes etc. If
this is not the case please drop a note, mark this report as browser dependend
and open a bug report in the relevant racking system. Thanks in advance.

regards reinhardt [[user:gangleri]]


Version: unspecified
Severity: enhancement
URL: http://he.wikipedia.org/w/index.php?title=project:Sandbox&action=edit

Details

Reference
bz4011

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:57 PM
bzimport set Reference to bz4011.
bzimport added a subscriber: Unknown Object (MLST).

gangleri wrote:

*note* As a workaround it is possible today

  • to use one browser window with an LTR edit sandbox as from :en: or

http://hu.wiktionary.org/w/index.php?title=project:sandbox&action=edit

  • to make there your work and
  • to use copy and paste to another browser window with the destination RTL edit

page.

gangleri wrote:

An alternative usefull also for *anonymous* editors (which can not safe
preferences) would be to add a control object (for example a radio button) that
toggles between RTL / LTR.
It could be beside the "This is a minor edit" / "Watch this page" control boxes.
Default seting should be same as *content language*.
It's configuration should influence the LTR / RTL properties of both the
textinput area and the inputbox of the sumary.
If possible it's value should be preserved between edits at different pages.

gangleri wrote:

special:Emailuser also has a textbox
the feature should be available here as well

zigger wrote:

I've published some work-around bookmarklets for controlling direction at
[[meta:User:Zigger/Bookmarklets]].

gangleri wrote:

*addition*

Maybe this can be implemented together with an paramater ?edit=foo / &edit=foo
where foo is either "ltr" or "rtl".

It would be great if this parameter could be preserved during sessions. See
similar request for ?uselang=xx / &uselang=xx at
Bug 4125: feature request: preserve ?uselang=xx / &uselang=xx during sessions

rotemliss wrote:

You can just toggle the text direction with Ctrl+LeftShift in Internet Explorer,
or Ctrl+Shift+X in Mozilla (maybe you should turn the hidden preference
"bidi.browser.ui" on before you can do that).

  • This bug has been marked as a duplicate of bug 8213 ***