Last modified: 2013-08-02 09:03:22 UTC
visual editor currently is able to edit a whole page. this includes page settings, categories, language links, etc. VE should be split up in components. links should be provided where applicable. an example: editing the languages should be possible on a link at the languages. edit categories should be possible where one sees the categories. as displaying all these links all the time might be a bit too heavyweight, one might think in providing two modes, read (no links to edit) and edit.
Thanks for taking the time to report this! [Resetting severity to enhancement, see http://www.mediawiki.org/wiki/Bugzilla/Fields#Severity ] > VE should be split up in components. What does that mean *exactly*? Could you please describe the problem in this bug report that you would like to solve (so far you provided one potential solution)?
to give some examples what it should do from a user perspective: * one click to remove/add a category (hotcat reimplemented properly) * one click to add/remove languages * one click to add/edit/remove a table (and _only_ the table) * one click to add/edit/remove references * one click to add/edit/remove a template (and _only_ that template) * one click to add/edit/remove a paragraph (and _only_ this paragraph) * one click to add/edit/remove a photo (and _only_ this photo) at the end this is not "the visual editor" anymore, it is small editors for different parts of the wiki page. this is not an enhancement imo because the original architecture is flawed (aka "bug"). the outcome up to now is an elephant. big, heavyweight, slow, difficult to implement, and therefor buggy. it tries to do everything, and does nothing really well.
As I wrote before, this bug report does not describe a problem except for the section "big, heavyweight, slow, difficult to implement" which are slightly subjective terms (not because they might not be true, but because it requires numbers and proof - what did you try to implement, how did you fail, where can I see how you ask for help about it?). Rest assured that developers are working on making VE faster. However it's hard to proof that your proposal would improve things for current browsers, plus if such a large and long-taking amount of work at this development stage would actually provide any gain comparing to speed of browsers improving in the future. Hence I'm going to close this request as WONTFIX as the proposed solution is not something that developers will work on, though the underlying problems that you face might indeed happen for you due to a number of circumstances.
this is a design suggestion. i would be very glad if the VE design team could discuss it, and give some feedback. if you have any other way to make suggestion so they really reach the design team, i am happy if you copy it there.
Please discuss such huge design decision suggestions first with developers on a mailing list, like http://lists.wikimedia.org/pipermail/wikitext-l/ , to break them down into manageable subtasks. Even if this was a valid request, it's pretty unhandable to define when this good be "fixed". I mark your proposed solution again as WONTFIX, as bug reports should be about problems instead. Please leave it like that as the solution proposed here is not planned to be implemented by developers like that.
