VisualEditor/Feedback/Archive/2013/06

Forced markup fixing; pending changes

Copied from w:Wikipedia:VisualEditor/Feedback

In this edit, VisEd added a space and removed some three-quotes from line 133—totally not what I was doing up in line 4. Is this some sort of forced markup fixing? It seems that the bolding in Miniapolis' sig remained the same (i.e. VisEd only removed redundant formatting). Thanks, Ignatzmice•talk 04:36, 30 May 2013 (UTC)

</copy>

With the regular editing interface, if I edit an article with pending changes, alongside the "minor" and "watch" checkboxes is a box to "accept pending revisions" (so as no to have to do it separately five seconds later). It'd be nice if this feature could be integrated into VE.

P.S. So this is Flow? Or what? Rather confusing. The date doesn't show up in the preview; nor does the section title. Do they when I save? Ignatzmice (talk) 03:44, 1 June 2013 (UTC)

Re: your P.S. - This is LiquidThreads v2.0 (from about 3 years ago, I think). Flow is still mostly conceptual, except for the prototype. Quiddity (talk) 07:23, 3 June 2013 (UTC)

I believe that we have fixed and deployed the errant markup-fixing bug you reported; sorry about that.

Integration of non-core features into VisualEditor is generally the responsibility of that tool's authors - I've asked the Platform team, who are nominally responsible for all deployed tools other than active projects, what would be needed to do that for FlaggedRevs. So we don't forget, I've created this as bug 49699. Jdforrester (WMF) (talk) 16:11, 17 June 2013 (UTC)

inter-wiki link

They are not editable in the visual editor. Panpog1 (talk) 02:06, 7 June 2013 (UTC)

Confirmed. Example is [[:fr:|fr]] = fr - this should be an in-text link to the French Wikipedia.

Interwiki links are essentially templates (they abbreviate URLs), and so they are not currently editable (See VisualEditor#Status). Hopefully soon. Quiddity (talk) 05:27, 7 June 2013 (UTC)

Actually, this isn't right; templates are very different, and will be editable very soon (indeed, you can use the experimental template editing code here on MW.org right now). Jdforrester (WMF) (talk) 18:55, 7 June 2013 (UTC)

where is it Panpog1 (talk) 02:04, 12 June 2013 (UTC)

Go to a page with a template in - I've created VisualEditor:Template test as an example - note that editing the block template is currently broken due to a bug, which will be fixed tomorrow (sorry!). Jdforrester (WMF) (talk) 16:28, 12 June 2013 (UTC)

Yes, sorry about this, I've created bug 49316 to make sure we get this done. Jdforrester (WMF) (talk) 18:54, 7 June 2013 (UTC)

So when this all goes live,

is it possible to opt out? Launchballer (talk) 10:29, 8 June 2013 (UTC)

Yup. See en:Wikipedia:VisualEditor/FAQ. Quiddity (talk) 16:33, 8 June 2013 (UTC)

Bánh phở

On the page vi:Bánh phở, clicking the "Sửa" button (for VisualEditor) gives me the content of an old revision of de:Stadtbefestigung Koblenz. (Looks like this one.) Minh Nguyễn (talk, contribs) 22:51, 8 June 2013 (UTC)

Sorry about this; we've found it in a couple of places (it's a cache corruption bug on Parsoid - you're getting the 'right' oldid (11666092) but on the wrong project, so you have the text of https://de.wikipedia.org/w/index.php?title=Stadtbefestigung_Koblenz&oldid=11666092 when you're editing https://vi.wikipedia.org/w/index.php?title=B%C3%A1nh_ph%E1%BB%9F&oldid=11666092 - I think it'll be fixed very soon. Jdforrester (WMF) (talk) 17:22, 10 June 2013 (UTC)

Carry VisualEditor Edits to the 'Edit source' editor for the 'Edit source' onClick event

When I make changes using Visual Editor and I click "Edit source", I would like those changes to be reflected in the wikitext editor. This is a good learning tool, and also helps me avoid losing edits. Ditto in the other direction. ABaso(WMF) (talk) 17:14, 10 June 2013 (UTC)

At the moment they're two totally distinct pieces of software; there is, as I understand it, a plan to have a source editor within the VE (a la wordpress) which would presumably make that possible. Okeyes (WMF) (talk) 16:40, 14 June 2013 (UTC)

This request is tracked on bugzilla:47779. Helder 15:55, 30 June 2013 (UTC)

Notice box onClick

This is a request to have the Leave Feedback button onClick not bring cursor back to top of the page. ABaso(WMF) (talk) 17:15, 10 June 2013 (UTC)

As I understand it that tool is being removed from the beta version, which answers that :). Okeyes (WMF) (talk) 16:41, 14 June 2013 (UTC)

Though this bug was also fixed anyway (the feedback tool is still there, now under the "beta" label). Jdforrester (WMF) (talk) 16:03, 17 June 2013 (UTC)

You can add an intrawiki link, but you can't later edit it

In VE I added a link to a page on another wiki (mw:Schema:ServerSideAccountCreation). That seemed to work fine and the generated wiki text is fine. But on editing the link has the green "You can't edit this" overcoat . The restriction is unexpected. S Page (WMF) (talk) 17:15, 10 June 2013 (UTC)

Tracked in bug 49316. (See also below at VisualEditor/Feedback/Archive/2013/06#c-Panpog1-2013-06-07T02:06:00.000Z-inter-wiki_link). Quiddity (talk) 17:16, 10 June 2013 (UTC)

VE garbles display of {{ExtensionInstall }}

When I edited an Extension page with this complicated template, VE shows an empty <pre> area, the "require_once..." code after it, and the closing <source> tag. S Page (WMF) (talk) 17:17, 10 June 2013 (UTC)

Does this still happens on e.g. Extension:Campaigns? Helder 15:45, 30 June 2013 (UTC)

Good news, it seems OK these days! S Page (WMF) (talk) 01:52, 2 July 2013 (UTC)

VE can't handle Template:Extension

If I roll over the {{Extension }} box on Extension:Campaigns I see a jigsaw icon which brings up a template editor, but it's blank. S Page (WMF) (talk) 01:21, 11 June 2013 (UTC)

When I click in that template I don't see any icon until I change the zoom from 100% to e.g. 90% or 110% (and if I keep the new zoom, click outside the template, and then click on the template again, the icon is not shown either - I need to change it again to see the icon, even changing it to 100% is enough).

On the other hand, if I go to

https://www.mediawiki.org/wiki/Extension:Campaigns?debug=1

and click in the content from section "Installation" (generated by Template:ExtensionInstall), I get the following error in the console (on Google Chrome 27.0.1453.110): Uncaught Error: No focused node to edit (from ve.ui.MWTemplateDialog.js). Helder 12:36, 12 June 2013 (UTC)

Yeah, this is a pair of selection bugs we're working on; sorry about this. :-( Hope to get them fixed very soon. Jdforrester (WMF) (talk) 16:36, 12 June 2013 (UTC)

Categories

The way categories are currently edited in VisualEditor is not WYSIWYG at all. Can something like HotCat be added as well?

(Personally, I don't find the "Page Settings" == "Edit categories" intuitive.) Ypnypn (talk) 14:59, 11 June 2013 (UTC)

VisualEditor is not intended to be "WYSIWYG" as a main criterion. :-) If you mean that you'd expect categories to be editable in the place in the skin where they can be edited, that's something we've thought about but is very complicated (how do you show and set hidden categories? what about non-Vector skins - do we just abandon them? etc.).

We're not totally wedded to the name of "Page Settings", though note that it covers categories, language links, "magic word" page settings (REDIRECT, NOTOC, DISPLAYTITLE, etc.) and possibly other things too (one suggestion was to put maintenance templates in here (like "unsourced", "orphaned", "spam-like" or whatever - either wiki-specific ones, or build them into MediaWiki in some way). If you have a better name for this collection of things we'd love your ideas. :-) Jdforrester (WMF) (talk) 15:29, 12 June 2013 (UTC)

It's just that to me, Settings implies user-specific preferences, not metadata. Ypnypn (talk) 19:42, 12 June 2013 (UTC)

Yes, though we have very carefully used the term "preferences" for users rather than "settings", I worry that this distinction may not have been kept clear in other languages. Jdforrester (WMF) (talk) 00:05, 13 June 2013 (UTC)

Ooh sounds cool that we will have an interface to play with magic words :)

Why not call the link "Categories and metadata"? Sure, it's verbose (and a long string - it might fail the German test), but 100% clear. Most users won't understand the term "metadata", but then, most users probably won't need to tweak langlinks, magic words, etc. "Page settings" is quite vague, and the overlap with "preferences" is problematic (MW might be making a clear distinction between the two, but many other software programs/websites/smartphones etc. regrettably do not). This, that and the other (talk) 11:53, 15 June 2013 (UTC)

I like "Categories and metadata". Helder 20:13, 16 June 2013 (UTC)

I think we need to be very careful to avoid putting needlessly-complicated words in front of potential new editors that are likely to scare them away rather than encourage them; "metadata" sounds intimidating, confusing and is not just very unlikely to get users to click the button, but will also add a tone of complexity and technical speciality that will dissuade users from staying.

So, if we can't use "metadata" (and we really, really shouldn't), what else? "Page data"? "Page details"? I also think splitting out the message to name categories differently from other meta-data is the wrong approach - it tries to box people into not setting things like DISPLAYTITLE which are very useful. Just because editing through wikitext makes these very hard to discover doesn't mean we should discourage users from using them in software (that's what community policy and socialisation is for). Jdforrester (WMF) (talk) 15:21, 17 June 2013 (UTC)

For as long as categories are hidden away in the "page settings" dialog, the name of that dialog really should include the word "categories". I think the main reason to invoke this dialog is to add or remove categories. New users who see the "categories" section on the page and want to make changes, as well as experienced users wishing to modify page categories, will not know where to look to make the change unless the word "categories" is prominent.

I think a name like "page data" scares people off just as much as "categories and metadata", because it sounds really "internal". And "page details" sounds to me like some static information. Although I don't really have any better suggestions :( This, that and the other (talk) 02:36, 18 June 2013 (UTC)

"Page settings" would be a fine name (or almost any other name, for that matter) IF hovering or clicking that resulted in a menu of choices (categories, default sort, interlanguage links, etc.) That way, an editor could immediately see what "page settings" involved, and whether he/she wanted to explore further.

Instead, at the moment, to see what is "under" that name, the editor has to click on the link, which opens a dialog box; then the editor can explore further.

It's possible to combine the best of both of these (submenu items, single dialog box) by specifying, in the software, that when someone (say) selects the "Default sort" menu item, the dialog box opens with that item already selected (in the left side side of the dialog box), so that the editor can immediately go to work on that particular aspect of page metadata. So a menu of choices not only informs the editor more quickly what his/her options are, but it also saves a click in cases where the editor doesn't want the top-most option (in this case, categories) handled by the dialog box. John Broughton (talk) 00:59, 17 July 2013 (UTC)

To add categories should not be intimidating to any users. When viewing pages, these categories are simply shown at bottom of pages in the footer. In the "visual editor", this should be visully editable at the same place (no need to hide this in "page settings" drop down menu, they are directly visible in the bottom of pages

This should use an existing tool that works very well : HotCat, which should be working as well in the visul editor (except that it will not save directly in the actual page, but in the work buffer used by the visual editor, which will immeditely render the new Categories page footer).

Otherwise drop this menu, and activate HotCat instead : the page will be categorized separately from its edit work, and the VisualEditor will not alter the categories, just displayed at the bottom

If you relly want to include this menu for editing categories, place it there in the page footer, not at the top with the odd menu:

- a link under the (translated) term "Categories:" at start of this footer (to add a new category)

- a link under an existing (and editable, not generated internally by templates) category name (to edit it, or remove it) with the same effect as the action link "[+/-]" added by HotCat *after* this category name (HotCat cannot replace the link in page view mode, so it has to insert an dditional link after it)

In visual-edit mode, HotCat would not add "+/-" links, it can

- safely replace the target link (under each displayed category name) normally going (in view mode) to visit the category page, by a javascript link opening a popup menu for: "view category in a new tab", "view category in a new window", "modify category", "remove category".

- insert the link to add a category under the label "Categories:", or still with the "+" link at end of list of categories.

Ideally, we should also be able to edit the category name, along with its sort key parameter. If we edit an existing category but drop the name, the category would be removed, unless there's a non-empty sort key, in which case the empty category name just means the "defaultsort" key for the page. The VisualEditor (HotCat as well when it is used in page view mode..) should warn if there are attempts to place several occurences of the same category name (including the empty category name for the default sort key), but with a distinct sort key parameter. Verdy p (talk) 22:59, 26 October 2013 (UTC)

Let's not mix things with other skins. The VisualEditor hs its own interface, and it should more or less mimic the look and feel seen in the default skin, or in the Monobook skin, where editable categories to include/modify remove in the wiki code of the page will be at bottom of page.

The HotCat extension behavior is perfect (and much more practical to use than the very basic (insufficient) interface currently presented in the VE. I also vote for the integration of HotCat in the VE (or something very similar). Except that this edit will be possible without having to open a menu, and nothing will be saved before saving the whole page visually edited.

This should not be hidden in that menu. Make the categories visible and editable at the bottom of pages.

For now I'll stick with HotCat, or with editing them in the wiki code editor.

----

My opinion is that both editors should be integrated, so that you can switch back and forth between the partially editable preview and the wiki code view during the edition. There would then be later a single "edit" tab on wiki pages (the current working mode would still use the user's preferences, if he only wishes to use the wiki code editor. We should always be able to see at any time every wiki code being modifed by any edit action in the VisualEditor, by just clicking a button.

Also, the editable preview panel (or the wiki code editor) will be scrollable, the interface at top may become a right-side properties pane, fixed on the page and not scrolling (the option buttons will be there in this properties pane.

Still missing as well in the VisualEditor: no support for the very useful characters selector (needed for I18n or for editing IPA and Maths symbols, or some useful punctuations like bullets, rarely present on keyboards). That's another reason why I still prefer not using the VisualEditor by default.

Another reason is that if the VE is your default, there's no way to edit a section in the wiki code editor, only visual editing is present. As long as the two editors are not integrated, we should still have two edit links: "[edit]" and "[edit code]" at end of editable sections, if the VE is enabled in user's preferences.

Lots of template transclusions also offer a specific edit link. Their action uses only the wiki code editor. If both actions "edit" and "editVE" were merged into a single one (with a simple switch to show either the editable preview or the wiki code) it would be simpler. And the "Show preview" button could disappear below the wiki editor (it would just remain a "Save page" button), but the "Save" button could also show the actual rendering without the limitations of the editable preview. Verdy p (talk) 19:30, 20 June 2013 (UTC)

There is bugzilla:52281 about the "veaction" problem. Helder 20:24, 12 October 2013 (UTC)

"(Personally, I don't find the "Page Settings" == "Edit categories" intuitive.)"

+1. I thought VE still couldn't edit categories until I read this thread. Deryck C.^Meta 13:26, 1 December 2013 (UTC)

Which is why I do suggest taking a look at its user guide from time to time to find out what it can do :) Maybe not covered there yet in all languages, but available from the icon with the 3 bars, there's the option to easily switch to wikitext (one-way only for now). Elitre (WMF) (talk) 17:37, 2 December 2013 (UTC)

If you need to check the user guide to use VE, then it's failed in its goal to be easier than wikitext. Ypnypn (talk) 14:08, 9 December 2013 (UTC)

Agreed. I learnt wikitext by trial and error back in the days without consulting the manual. I think we can agree that, in VE, things should be as easy to locate in edit mode as in read mode.

Perhaps there should be a HotCat-like toolbar at the bottom of the VE box? Deryck C.^Meta 22:31, 9 December 2013 (UTC)

Yes, the language is crappy. The categories are not settings. Nnemo (talk) 17:19, 1 June 2014 (UTC)

on wikipedia

VisualEditor doesn't have the media button.Is this intentional? Panpog1 (talk) 02:38, 12 June 2013 (UTC)

What "media button"? There's the "insert media" button (added last week) but we've not yet got the "edit media" float-over button (for setting captions, whether the image is a 'thumb' or 'framed' or 'frameless' or 'inline', etc.) - that should be coming very soon. Jdforrester (WMF) (talk) 15:24, 12 June 2013 (UTC)

insert. sorry.Why isn't it on Wikipedia yet Panpog1 (talk) 23:25, 12 June 2013 (UTC)

Just to update, this was deployed on Wikipedia on the day after your question. :-) Jdforrester (WMF) (talk) 16:17, 17 June 2013 (UTC)

Editor strips out manual anchors

When Anchors have been manually added using <span> they are stripped out by the visual editor (example diff). Ideally they should be converted to {{Anchor }}s. Pointillist (talk) 12:07, 12 June 2013 (UTC)

Hey, sorry about this - we've been dropping empty annotations in general (<b></b> or <span></span>) but we're working on fixing this very soon - see 48605.

On your point about conversion, I think this is the wrong approach for a number of reasons. Firstly, VisualEditor shouldn't convert anything for anyone without them asking us to do it (otherwise we'd be disrupting the wikis). Secondly, though for a very few things we could probably come up with rules that all wikis would like, some rules differ (e.g. is it == Heading == or ==Heading==?; one new line after headings or two?; at the end of a page, should it be references, then external links, then persondata, then categories, then langlinks, or some other order? etc.); VisualEditor has to work for all wikis at once. Finally, converting to use a template would mean that that template must be available on all wikis (including ones not run by Wikimedia), over-writing what might be there already, and worse, must only change in a globally co-ordinated way. I don't think this would be a good idea for anyone. Jdforrester (WMF) (talk) 15:22, 12 June 2013 (UTC)

Sorry, I wrote that too succinctly. I wasn't thinking that VisualEditor should do automatic conversion. I was thinking more in terms of a "global search and replace" that a bot could do across enwiki to find instances of <span id=> inside headings and convert them into {{Anchor }}s at the beginning of the heading. The problem with allowing html elements in source markup is that their purpose isn't clear, which makes it difficult to repurpose the content in another format (e.g. pdf or e-book). It also gives headaches to the VE developers, but I don't need to tell you that! There's a similar issue with comments (e.g. ==Organisation==<!-- Spelled with an "s", please, per the talk page discussion-->). IMO we'd be better off having a template specifically for that purpose, that displays a message during editing but is hidden in the saved article. Pointillist (talk) 16:10, 12 June 2013 (UTC)

Aha, yes, that might be a good idea for a bot to do; I agree that raw HTML in wikitext isn't a great idea, and we'd be very happy if it was replaced, though there are some exceptions to this (e.g., wikitext like <span style="color:red; font-weight:bold; font-family:serif;">Hello</span> is much easier to find a way for users to edit than {{redboldimportanttext|Hello}} - because annotations are editable in-page and extensible, whereas templates are 'special' and work a bit differently - and is more flexible for users than <span {{redboldimportanttextstyle}}>Hello</span>). Jdforrester (WMF) (talk) 16:20, 12 June 2013 (UTC)

For manual styling it makes sense to use spans. But for comments in the source a template might be better: it can be made more visible to editors and it can hold parameters like a link to a policy page or talk page discussion. Actually, it could be quite a good way to kick off a new talk page section, but that's an idea for another day. Pointillist (talk) 16:38, 12 June 2013 (UTC)

It's too easy to delete citations

In the edit source view, reference citations are so big that new editors aren't likely to delete them by mistake (whether they can edit them successfully is another matter). But in the visual editor it is trivially easy to delete a citation without being aware of what has happened. This might be an issue. Could it be made more difficult to delete citations, perhaps by skipping over them when deleting (so that they can only be removed from within the citation template dialog) or by asking for explicit confirmation when the edit is saved? Pointillist (talk) 12:49, 12 June 2013 (UTC)

Interesting... Helder 13:28, 12 June 2013 (UTC)

Surely the visibility of citations in the diff view will solve for that? As you note, in markup they're substantial - and since the VE shows users a before/after wikimarkup view of their change, any deletion of references would be fairly obvious. Okeyes (WMF) (talk) 16:43, 14 June 2013 (UTC)

Unfortunately not: (a) because according to VisualEditor/status#2013-06-13_.28MW_1.22wmf7.29 VE isn't going to show a diff if you click Save, and (b) because in any substantial paragraph the change may only be visible if the user scrolls how the diff, which they aren't like to do. Can you see what I changed in this diff? It isn't immediately obvious, especially as VE has made some changes of its own too. My point about the source was that to delete a reference in markup would require selection of the entire extent of the citation, which is a relatively large amount of test, whereas to delete a citation marker using VE you just have to include [21] (or whatever) in a selection that you delete. That's a much easier thing to do in error. Pointillist (talk) 22:59, 14 June 2013 (UTC)

ULS in Visual Editor

How do I activate ULS in Visual Editor? Jayantanth (talk) 07:01, 13 June 2013 (UTC)

This is not currently possible, unfortunately; a Google Summer of Code student is working on this with the ULS team - see bug 49569 and this github ticket. Jdforrester (WMF) (talk) 16:20, 17 June 2013 (UTC)

Closing settings page triggers editing undo/redo

1. Put the cursor on a unordered list item 2. Click the bulleted list button to remove the bullet and then click it again to readd 3. Click the 'Page settings'. Close the dialog.

Note the button has been triggered again; the bullet is gone. 131.155.27.207 15:49, 13 June 2013 (UTC)

References

I tried adding a reference, but after clicking "Save pages" the dialog went away but the page remained unchanged.

I tried adding a <references /> tag to the page (using the regular editor) in case that was the problem. But when I tried editing the page using VE, it took a long, long, long time to load, even though it was working fine before.

I repeated the above with another page, and the exact same result happened. Ypnypn (talk) 22:03, 13 June 2013 (UTC)

Deleting the <references /> tag made the page load quickly again. Ypnypn (talk) 22:03, 13 June 2013 (UTC)

Sorry about this; this was bug 49668, which we've now fixed and will be deployed here later this week. Jdforrester (WMF) (talk) 15:05, 17 June 2013 (UTC)

Russian Wikipedia

[1][2][3][4] Generous (talk) 15:05, 14 June 2013 (UTC)

Yes, I am really sorry about that - that was bugzilla:49577 which was caused by a mis-configured cacheing layer. Jdforrester (WMF) (talk) 16:19, 18 June 2013 (UTC)

Error Contacting Parsoid Server

Trying to use new Visual Editor I keep getting error contact Parsoid server.

(Editing this post because, a spam bot rewrote the original post) Hutchy68 (talk) 16:02, 14 June 2013 (UTC)

Visual Editor working again, caused by a bug which was dealt with quickly - Bug 49577. Hutchy68 (talk) 13:17, 16 June 2013 (UTC)

I have the same trouble, could you paste your config here to show detail.

maybe I can reference your config,thanks in advanced. 121.14.96.125 02:52, 20 June 2013 (UTC)

My Parsoid configuration is:

// The URL here is supposed to be your MediaWiki installation root
parsoidConfig.setInterwiki( 'localhost', 'http://localhost/w/api.php' );
// Use the PHP preprocessor to expand templates via the MW API (default true)
//parsoidConfig.usePHPPreProcessor = false;
// Use selection serialization (default false)
parsoidConfig.useSelser = true;

Note that my MW installation is in .../www/w/, not in the main root of the Web server.

Hope this helps! Jdforrester (WMF) (talk) 04:14, 20 June 2013 (UTC)

source code?

where the hell is the source code for the page? I want see source code so i can duplicate it. trying to see how the box is put around text but says i can't edit. If you can't figure out how to get it to work don't put it as the default! 198.84.198.205 16:02, 14 June 2013 (UTC)

Bug 49618. Helder 12:23, 15 June 2013 (UTC)

The most important thing is... tables

The only real and serious problem for which everybody would be grateful if it were to be solved, is TABLES. What a surprise to see a VisualEditor which can only half help with handling tables. What a pity. FocalPoint (talk) 19:31, 14 June 2013 (UTC)

We are definitely going to build tools to help with tables, but I think that templates and especially references are more critical for regular editing work than tables, so I prioritised it lower than them. Jdforrester (WMF) (talk) 16:16, 18 June 2013 (UTC)

I disagree - tables are the most used by the basic user in comparison with templates. As Visual Editor is aimed toward that audience, tables really need to be prioritized over templates. Superman57 (talk) 20:51, 2 July 2013 (UTC)

Templates are now implemented, so this advice is a little late. :-)

However, I would strongly disagree with you that ensuring that new users can do proper references is less important to our existing users (and, as importantly, the quality of the projects) than adding rows/columns to tables.

We will definitely be getting on with this in the coming months, of course. Jdforrester (WMF) (talk) 15:35, 3 July 2013 (UTC)

I now see the 'Edit Source' tab, which allows wikitext editing and with the WikiEditor toolbar includes the Insert Table wizard - didn't see that before. I'm happy with that - as long as wikitext editing and table tools are available in some fashion. Superman57 (talk) 22:19, 8 July 2013 (UTC)

There are no plans to remove the old editor. You can 'Edit source' on any page whenever you want. (There's even a request to put into VisualEditor a 'take me to the source code now' button, in case you want to switch mid-edit to deal with something in wikitext markup.)

I personally still want VisualEditor to deal well with tables. The wikitext markup for tables is complicated and messy. Whatamidoing (WMF) (talk) 13:38, 10 July 2013 (UTC)

The request is either bugzilla:47779 or bugzilla:49665 or even bugzilla:50687. Helder 20:06, 12 October 2013 (UTC)

See also VisualEditor/Feedback/Archive/2013/04#c-195.60.68.155-2013-04-12T13:11:00.000Z-Table_editing. Helder 18:27, 3 July 2013 (UTC)

Better Handling of Whole Page Transclusion

First, I know what a mountain there is to climb. I think this project is a tremendous task and it has really come a long way. A bi-directional parser must be a nightmare, wiki markup to html to wiki markup again. Please keep at it! You guys are getting closer and I can't wait until it works seamlessly. It will help many Mediawiki based projects with an editor built for those resistant to learn the simple wiki markup. A common excuse for many not to participate in wiki based projects.

My feedback centers around transclusion. I'm a bit confused by what the handling will be. Transclusion isn't just for templates, it is for subpages and other pages with {{:Transclusion this page}} markup. I don't see any allowances for non template page transclusion interactions. Is the parser looking at {{: ? and how will it handle these pages. I think it is fine to edit the page transclusion in a pop up too. Perhaps a different type of icon mark so an editor knows if it is a template or a page transclusion.

I can edit template transclusions, adjust the parameters, add them but what about {{template|This value}}</wiki>? Parameters with an implied {{{1}}} value or the other based on numerical sequence? How will they work? There really is no set parameter. Perhaps a numerical sequence parameter based on the | separator within the brackets? Thanks [[User:Hutchy68|Hutchy68]] ([[User talk:Hutchy68|talk]]) 20:53, 14 June 2013 (UTC) :{{talkquote|My feedback centers around transclusion. I'm a bit confused by what the handling will be. Transclusion isn't just for templates, it is for subpages and other pages with <code><nowiki>{{:Transclusion this page}} markup. I don't see any allowances for non template page transclusion interactions. Is the parser looking at {{: ? and how will it handle these pages. I think it is fine to edit the page transclusion in a pop up too. Perhaps a different type of icon mark so an editor knows if it is a template or a page transclusion.}}

Parsoid and VisualEditor both support transclusion of pages; the VisualEditor transclusion-insertion search interface will default to the Template: namespace (like {{…}}s do) but if you type in ":User talk:Foo" it will work fine. Expect this code to be available here very soon so you can try it out and tell us. :-)

I can edit template transclusions, adjust the parameters, add them but what about {{template|This value}}? Parameters with an implied {{{1}}} value or the other based on numerical sequence? How will they work? There really is no set parameter. Perhaps a numerical sequence parameter based on the | separator within the brackets? Thanks

For a regular transcluded piece of content, we cannot determine anything that isn't already in the invocation - so parameters are called whatever you called them in the invocation, or auto-numbered if you didn't name them, yes. You will be able to add (arbitrarily-named) parameters and their values. To show this working (in limited mode) right now, go to https://www.mediawiki.org/wiki/Extension:Backup?veaction=edit and select the template that generates the "Installation" section, and click into the puzzle piece - the parameter is auto-numbered.

However, if the content fragment has had "hinting" added to it using the new TemplateData extension, we can give users descriptions, a list of known parameters, and automatically suggest adding sets of parameters together. Jdforrester (WMF) (talk) 21:38, 14 June 2013 (UTC)

[Bug]The VisualEditor unexpectedly deleted infoboxes at top of pages (bug parsing template transclusions).

On French Wikimedia a simple edit (that just added a few words in a paragraph within a section unexpectedly deleted the infobox template transclusion at top of page (there was no change there). The VisualEditor can delete lots of previous contents, and users may not notice it immediately.

I reverted this edit immediately. Evidences show that the VisualEditor does not parse the template transclusions correctly when they span several lines, or more probably if these transclusions contain HTML comments between lines of parameters. This also affects templates for references, that appear in the middle of a paragraph. The VisualEditor also attempts to cleanup unnecessary spaces within named template parameters, throughout the whole edited page (this may be the cause), even if this is not necessary, and we actually did NOT change these parts.

Affected page: . (see http://fr.wikipedia.org/w/index.php?title=Acide_chlorhydrique&diff=prev&oldid=94124322)

Note: if we have an autoconfirmed account, the button to review the changes does NOT show the edits that will be done.

There are similar issues of unexpected deletions when adding a category to a page using the "Page Properties" menu item (in addition the category is added near the top of page, grouped on a single line (most used conventions is to place each category on a separate line, facilitating the visual review of diffs).

Please do not alter the content of template transclusions that you cannot understand for now, not even for cleaning up spaces. Do not delete HTML comments, or if you do, make sure that you won't delete the full code of this transclusion. Verdy p (talk) 14:59, 17 June 2013 (UTC)

Note: to reproduce the bug, you just have to copy the text of the original page :

• Edit it in its history (with the wiki code editor), copy it, don't save.
• Paste your clipboard in your own sandbox page on the same French wiki (also in the wiki code editor), and save your sandbox page.
• Then reedit your sandbox page with the VisualEditor, make a minor change (add a character at end of a paragraph), and save it.
• See the catastrophic result on the whole page when looking at diffs ! Verdy p (talk) 18:55, 20 June 2013 (UTC)

Suggestions for editing templates transclusions

• In my opinion, the visual editor should allow editing template transclusions by presenting editing them in a visual table containing the list of positional parameters and the list of named parameters in two colums (one column for the name, one column for the value. It should also allow viewing the template page by pressing a button opening a scrollable frame (for getting access to its documentation), so that we can add the correct parameters in this editable table, as instructed in the template doc page. This editable table should be done within a popup dialog, because most templates will have a very different layout when rendered, not suitable for editing.
• On the non-mobile version of MediaWiki, this popup could be a frame docked below the menu bar, and not using more than half the screen height. It should be also dockable on the right, for users that have wide screens: the left side shows the visual content of the page, and shows the rendered template as it is edited, the right side is for editing that template, and this docked template transclusion editor can be subdivided in two parts to showing the doc page of that template.
• In addition we should be allowed to select another template name, keeping the parameter list (and if we do that, the doc page shown should reflect this change).
• To select templates, we should be allowed to navigate in the list of categories for the current template (just like with the CatALot extension).
• Similar navigation in categories should be possible as well when adding a cateofy to a page, when we don't know the exact name of the category, we wi still find other relevant categories, instead of beaing presented only a list of categories containing some existing words.
• When editing template transclusions, all whilespaces should be preserved unless we actually edit a field (template name, parameter name, parameter value. This would preserve HTML comments most of the time and would minimize the number of changes in diffs.
• Note also that template parameter names, or or template names way also transclude other templates (or could contain invokations of parserfunctions). These subparts present these fields should be marked as non editable.
• Some whitespaces that are present at start or end of fields for parameter names or values or template names should be preserved (only duplicate SPACE characters may be simplified in the middle of the editable field, and whitespaces characters BEFORE a newline. HTML comments should be kept as much as possible, and should be made accessible in the editor, treated as an editable subelement.
• When template transclusion parameters (or template name) contain another template transclusion, this creates the opportunity of recursive editing. The UI can still be made cleanly, by clicking on this field to open a new tab in this editor. When such a recursive edit is done, the visual rendering on the right side should also give the rendered result of this invokation to show its result, replacing temporarily the rendering of the full page (the full page can still be seen by selecting the first tab automatically created, the second tab being for the 1st level of edited template invokation. We can close the secondary tabs by confirming or cancelling the edit of one level of invokation (this also close tha tabs for its sublevels).
• So in summary: we click the redenred box where the template transclusion appears in the visual page, this adds a row of tabs docked just below the menu bar, and a docked properties pane splitted in two parts : one part for the editable parameters in a table or in a vertical list, another scrollable part for showing the rendered template doc page, and each editable field in the 1st part is just a clickable list of field names, whose value appears in the visual preview (it activates a tab at the top), where actual values are entered visually (we constantly can click on the FULL PAGE tab to view the result in the full page.
• And remember: ALL fields in a template transclusion (tempalte name, parameter name, parameter value) may contain one or more transclusions or invokations of parser functions, each one should have a rendered view accessible from a tab at the top, and viewable in its context ov invokation as if it was clickable element for editing it, or deletable. HTML comments should also be visible or invisible with a checkbox option in the top menu bar, as if they were inline content (i.e. in a subbox). And probably the preview pane should allow showing either the pre-rendered content, or the associated wikicode (if the wikicode is active, the properties pane is disabled or hidden, but tabs remain present at the top; the wikicode or visual rendering mode is a property associated with each open tab).

Similar editing should be possible as well for working with invokations of parser functions (which are mostly like template transclusion because they are just a list of editable subfields), or for inclusions of extension tags (like the search box), except that most parameter names or order are known, and that they don't have their own doc page which is located elsewhere on the Mediawiki.org site. One basic design idea would be that each extension tag or parser function should have a way to register a "hook" for filling a list of properties, some with fixed self-explanatory names subject to translations), specific to the extension (and with status giving their type and mandatory/optional status), some just listed in a defined order without names (or a name equal to an integer number starting by "1"):

• These hooks would handle themselves if they can strip whitespaces, and would also provide some validation for fields editable as plain text, and saying if values may embed other tags, or if it should remain plain-text, or if the value must be one in a list of provided values.
• The VisalEditor would provide the Interface itself in the properties pane, would create the necessary tabs and navigation. The VisualEditor may provide several layouts for editing these properties: either a pane-less mode where data is entered directly in the preview pane, or an edit within a "bubble" pane appearing on top of the page, for basic tags, or the full properties pane docked on the side from the preview pane.
• The hooks will also generate the wiki code, that they will also render themselves (a hook could also generate additional wiki code that won't be saved in the article but which is required to give some meaning to the edited tag or function with an API like "getPreviewCode()". To implement this API, when the inner parameters can embed additional tags edited separately, they will call a part of the API that calls the appropriate "getPreviewCode() recursively in the appriate hooks for their tags. Note that the preview code will often be a bit different from the code that will be saved (it will limit some interactions with it, for example the visual preview of links don't work as links, buttons are inactive, tables don't sort, videos are not played when clicking on them, and a yellowish frame surrounds the element when the mouse hovers them in the preview pane, all of this depending on the type of edit mode best chosen for implementing the tag editor and integrating in the VisualEditor...)
• When saving (or when the preview pane is replaced in edit mode by the wikicode edit mode, these hooks will only generate the editable wiki code containing everything, within unparsed contents for the parameter, i.e. the complete syntax of the tag and all its parameters and contents (in that case the properties pane is hidden or disabled; we have a top button above the wikicode editor that allows switching between the wikicode edit mode and the visual edit mode).
• One of these tag/function extensions would manage the inclusion of images and media ; another would manage the inclusion of reference notes (and the hhok would provide an additional wiki code <hr style="clear:both"/><references/> that will not be saved in the the edited wikicode only in the view pane, but that will be appended in the preview pane that shows the note call in its context where it is inserted in the page); another will manage parser functions (one for each parser functions extension, another will manage template transclusions.
• The hooks will also indicate if they have a documentation page to display below the properties pane, by an API like "getDocumentationURI()" to help understand its usage, and may be links to the applicable policies (so the documentation pane will include a scrollable frame (links on the documenttion page may open a new tab in the browser to avoid complications, if you don't want to use HTML frames).
• All this would finally allow editing complex codes (with lots of "{}" braces) in a much easier way, with less errors: just click one tag in visual mode to access to the subtag and its parameters in a new pane and with its new navigatable visual tab).
• Note that when an extension hook provides flags for editable fields, if one of these flags says that the parameters will have its leaning and trailing whitespaces ignored and stripped by the rendering, the wiki editor should allow using a "pretty-printing" mode using automtic indentation (but a hook may also provide itself an API like "getPrettyCode()" to format this code, or other presentation features like syntax coloring (recursive as well when subtags are embedded, using some code generators for fixing things like indentation levels).
• All these hooks will be optional (the Visual editor will provide a default reasonnable interface, that each extension may override with their hooks to get easier editing mode. For example, the default will not validate the edited values of editable fields. The Visual editor will understand the wiki syntax using braces, colon and pipes by default, and the HTML or XML syntax of tags (with a leading tag name, a list of attribute names, their values, the inner content, and the end-tag marker (possibly abbreviated as "</>" in special tags like "tvar", or unnessary for some HTML5 tags where they are implied like in "li" elements).

Finally the current editing of categories in the "Page properties" menu is really a bad idea (it is also counter-intuitive). It should be done like in CatALot, by editing them at the bottom of the visual page, where they are effectively displayed, like in CatALot. I really suggest the integration of a working mode like CatALot, integrated and adapted in a specific version for the VisualEditor (CatALot should remain a separate extension). Verdy p (talk) 15:00, 17 June 2013 (UTC)

Conclusions about the beta

Before reenabling this beta, PLEASE make sure that all users (uncluding those with autoconfirmed edits) will be able to review the changes in the wiki code. In the past, when submitting the changes, we were presented at least the edited wikicode before confirming it. This presentation of the wikicode when reviewing changes should be kept for now. Verdy p (talk) 15:01, 17 June 2013 (UTC)

[Bug] : characters selector (for internationalization) missing

The useful characters selector (shown above the wiki code editor by clicking a button on its top bar), is definitely missing in the VisualEditor. There's also no support as well for input methods (set using the Universal Language Selector, aka ULS), meaning the many international users can't type the characters they need for their language or for more exact typography (e.g. apostrophes, maths symbols, IPA symbols), typically missing on their keyboards. Using characer name references is not an option for the VisualEditor. Please provide the characters selector, like in the wiki code editor. Verdy p (talk) 15:01, 17 June 2013 (UTC)

Rich editor

The WYSIWYG editor looks great, but it is not a rich editor, where we can paste formatted text from other sources (for example, to easily import some articles from another wiki solution).

Regards! 88.26.246.74 15:02, 17 June 2013 (UTC)

Is this bugzilla:41193? Helder 14:42, 18 June 2013 (UTC)

Yes; we're working on it right now, and hope to have it working (again) very soon. Sorry for the delay. Jdforrester (WMF) (talk) 16:15, 18 June 2013 (UTC)

Text Color

Will there be any way to quickly edit text color, rather than having to place the desired style within a template and require inserting templates everywhere colored text is needed? Thanks! 184.151.127.142 14:36, 19 June 2013 (UTC)

Do you have a specific example (or 2) in mind? Examples (almost) always help!

I know we use colored backgrounds, in many tables. (E.g. en:List of Arizona Cardinals head coaches), but I can't think of any uses of colored text. (Pick examples from en:WP:Featured lists, if possible.)

Note: en:MOS:ACCESS#Color and en:WP:WikiProject Usability/Color both strongly caution against using coloured text. Quiddity (talk) 16:19, 19 June 2013 (UTC)

Here is one example from the Featured Lists page - Transport section, Vancouver Skytrain's page - where forcing white text is required due to the background colors of tables, though it's mostly in related templates. There's also a lesser amount of coloring going on in the Stations section where the line colors are indicated next to the line name by adding a colored emblem. Since it's not the entire cell that's colored, the use of <span style="color:#XXXXXX"></span> is still required to get that effect.

https://en.wikipedia.org/wiki/List_of_Vancouver_SkyTrain_stations

Since I just read that there will be support for cleaning up empty span tags, it seems like VisualEditor already seems able to read those tags' properties.

Thanks,

74.15.154.98 16:48, 28 June 2013 (UTC)

I just noticed the use of color on your own user page. https://en.wikipedia.org/wiki/User:Quiddity which uses full cell coloring, as well. That could definitely be something else to add in VisualEditor in order to cut down on span tags if a color is applied to a cell.

74.15.154.98 16:56, 28 June 2013 (UTC)

This page has a nice use of coloured text. Nnemo (talk) 22:16, 9 February 2014 (UTC)

Font color is a basic addition to any word processor since just after DOS was king. It can be used as an tool to emphasize in place of bold or heading fonts. If used conscientiously and with pattern and can be used to immediately indicate a certain point. For instance in my mediawiki's I have used the red font and the word NOTE: to immediately draw attention to this area on a page. The use of a lighter grey font always meant it was a comment and so on.

I am hoping the folks at MediaWiki do add this feature. It is one I am counting on and hoping for in the future for our wiki's. I have shed my existing wiki WYSIWYG in support of the VisualEditor but do miss this feature badly. Compumatter (talk) 06:07, 16 December 2014 (UTC)

You may want to take a look at Requests for comment/Deprecating inline styles. Helder 20:52, 2 July 2013 (UTC)

Very interesting discussion, however it doesn't seem to change the original request outside of modifying which element of code would be edited in order to allow text color, text bordering, or text background fill. That proposition definitely shows a need for migrating away from div and span tags in favor of style tags with injected CSS, but none of those three options can currently be modified by VisualEditor, nor are any of them planned to be modifiable. However, allowing the modification of style tags could likely allow more than just text color, opening style options up to text size, alignment, and many more. That would be especially powerful if implemented in a future (post beta?) release.

74.15.154.98 11:10, 5 July 2013 (UTC)

Or just move entirely to using templates for styling? E.g. en:template:color. (I'm not uptodate on this at all, just suggesting). Quiddity (talk) 21:20, 5 July 2013 (UTC)

Eww, more templates! ;-) Jdforrester (WMF) (talk) 16:12, 12 July 2013 (UTC)

A quick way to select text and then pick a color from a small color palette would definitely be very useful. This is something we do very often on my local wikisite to highlight things in large tables. 217.210.124.174 22:01, 12 July 2013 (UTC)

I agree. Would be very useful for us local wiki site users that use this great open source wiki for our own projects.

/Daniel 195.60.68.155 15:11, 28 February 2014 (UTC)

Do you use it outside of tables? Inside tables, do you usually change the text color or the background color? Whatamidoing (WMF) (talk) 23:43, 3 March 2014 (UTC)

The best thing would be if it would work both inside and outside of tables. But I guess outside of tables would be most important since I guess there will be someway of coloring background in tables in the near future?

A typical scenario for a local wiki would be to color something in a project page as important with red color, something less important with orange color etc.

/Daniel 195.60.68.156 11:47, 5 November 2014 (UTC)

Well, a bug was filed about this anyway. Elitre (WMF) (talk) 11:51, 5 November 2014 (UTC)

Ctrl Z doesn't work as expected

Also had issues with Ctrl X and Ctrl Y.

Apart from that: Why does Visual Editor enclose all my edits with nowiki tags?? Stefahn (talk) 08:39, 20 June 2013 (UTC)

Sorry about this; this should now be fixed here, and we'll get the code pushed wider tonight.

VisualEditor (actually, Parsoid) is intended to be used by users who have no idea about wikitext, as well as experts. Magically interpreting [[Foo]] as anything other than a nowiki block would fundamentally break the concept. If you don't write wikitext (or wikitext-like things) it won't get nowiki'ed. :-) Jdforrester (WMF) (talk) 01:23, 21 June 2013 (UTC)

Thanks for your feedback.

This means if I want to insert a link (intern or extern) I always have to click on the link symbol? This would be cumbersome... Stefahn (talk) 09:30, 21 June 2013 (UTC)

Autocorrection of wikitext syntax has been suggested as an enhancement: bugzilla:49686. This, that and the other (talk) 01:22, 22 June 2013 (UTC)

VisualEditor/Features/Keyboard shortcuts lists the keyboard shortcuts. You can use Ctrl+K / ⌘ Cmd+K to avoid clicking to create a link. Whatamidoing (WMF) (talk) 15:37, 24 June 2013 (UTC)

Image upload

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Will the new image feature be integrated with the upload feature so you can upload local images easily? This would be very useful for us that uses the mediawiki software as a local wiki. Currently we use the extension msupload to make it smoother to add images for the users. 195.60.68.156 13:47, 20 June 2013 (UTC)

Yes, this is planned, though not in the next couple of months, at least. Jdforrester (WMF) (talk) 00:05, 24 June 2013 (UTC)

Any more news on when this is planned?

BR,

Daniel 195.60.68.156 15:11, 18 December 2013 (UTC)

Hi Daniel,

Apologies for the delay in getting an answer to you. They're still sorting out some of the technical requirement issues with the multimedia team, so it's not been possible to get anything like firm answer. My best estimate at this time ("subject to change without warning" ) is maybe four to six months from now—definitely not before March 2014.

I'm not sure, however, whether it will be available for local/private wikis before or after it becomes available for the WMF wikis. It's possible that private wikis will be the easy case (no need to integrate with Commons or comply with 800 different image policies) and they'll do it first. But they might do it the other way around, in which case what you need might not be available until much later. Whatamidoing (WMF) (talk) 21:18, 2 January 2014 (UTC)

I am also waiting for this to be implemented. We are running a private wiki and only need the ability to upload images privately.

Just thought I'd add this in because we love Visual Editor, other than missing this feature, and of course the ability to create tables.

Is there currently a way to disable the image integration with Commons in a .php file somewhere?

Justin 166.70.115.130 21:08, 28 January 2014 (UTC)

You might also want to keep an eye on 38030 and related bugs. Regards, Elitre (WMF) (talk) 16:30, 3 February 2014 (UTC)

also see https://phabricator.wikimedia.org/T40031 Planetenxin (talk) 09:45, 19 May 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Problem with using shift+

Hi. I have been using the visual editor for a while on ar Wikipedia, it is very nice and smooth for fast edits. However, I am facing a very strange problem when I need to add some Arabic diacritics known as tashkil; when I press shift+diacritic button (like x, e, or z) the letter I pressed starts to repeat itself endlessly, and it can only be stopped by refreshing the page and wasting the work I have did. Any thoughts? aad_Dira (talk) 09:51, 22 June 2013 (UTC)

Hi Abbad. I'll make a bug report for this - sounds annoying. Which browser version and operating system were you using when you had the repeating characters isssue? PEarley (WMF) (talk) 14:55, 24 June 2013 (UTC)

Thank you for making the report. I use Windows 7, and the browser is Chrome version 27.0.1453.116 m aad_Dira (talk) 04:39, 25 June 2013 (UTC)

Thank you for bringing it to our attention. Please let us know about any other problems you find with VE's treatment of Arabic text. PEarley (WMF) (talk) 15:52, 25 June 2013 (UTC)

Bug report is bugzilla:50105 PEarley (WMF) (talk) 15:35, 24 June 2013 (UTC)

VisualEditor Icons on Commons

Hi!

For documentation purposes, it would be good to have the VisualEditor icons available on commons:Category:VisualEditor. Helder 12:36, 24 June 2013 (UTC)

Sure! I'll do this today if I remember (or bug me!). Jdforrester (WMF) (talk) 14:36, 24 June 2013 (UTC)

Which icons are you interested in? The ones for media, references, transclusions, etc. from the VE toolbar? PEarley (WMF) (talk) 14:37, 24 June 2013 (UTC)

Mostly the toolbar buttons. Helder 23:01, 24 June 2013 (UTC)

This is now done - see Commons:Category:VisualEditor icons. Jdforrester (WMF) (talk) 08:15, 30 June 2013 (UTC)

Thank you! Helder 14:16, 30 June 2013 (UTC)

Display "edit | edit source" only when you hover "edit"

Display "edit | edit source" only when you hover "edit".

Atm "edit" turns into "edit | edit source" when you hover the headline which is distracting and annoying on reading, scrolling etc.

Instead it should only be displayed by deafult or when you hover "edit". 93.184.128.25 11:38, 27 June 2013 (UTC)

It is a bit distracting, but I'd argue it's distracting in a good way - reminding readers that they can edit content. PEarley (WMF) (talk) 16:46, 27 June 2013 (UTC)

No, thefore the edit link is visible enough. First of all it is distracting for everyone. 93.184.128.25 09:26, 15 July 2013 (UTC)

This kind of interaction is actually considered bad style, not because it is animated and shows additional links but because it changes the behavior of a known feature. The edit link which goes to a specific type of editing is now changed so it goes to another, but it looks the same. That triggers specific behavior, but the expected result doesn't emerge because the edit link is overlaid another interaction and that interprete the click as opening the VisualEditor.

I'm sure the editor is a nice thing for most users, but it would also be nice it the learned behavior could be supported. I think the simplest would be to turn off the animation and replace "edit" with "Visual editor".

In general I'm not very fund of animations as hover effects, they are distracting and can be very confusing if there are a lot of them. In this case I think they are unnecessary. 89.204.135.231 10:03, 15 July 2013 (UTC)

I agree, it is annoying and confusing. Misibacsi (talk) 04:31, 19 July 2013 (UTC)

i can't type a east asian character

i'm living in Korea and i can't type the Hangul. 61.255.140.81 10:02, 29 June 2013 (UTC) (comment moved into thread by PEarley) PEarley (WMF) (talk) 06:52, 30 June 2013 (UTC)

That isn't good. Could you give us some more detail - are you having trouble with all Hangul characters, or just some? Which browser and operating system were you using? PEarley (WMF) (talk) 06:54, 30 June 2013 (UTC)

I filed a bug report on Bugzilla at https://bugzilla.wikimedia.org/show_bug.cgi?id=50631

I found you are going to deploy the editor to all project until 29 July. I hope the plan could be delayed for Korean Wikipedia.

Can I ask you that you tested all scripts in the beta stage? Can I get the result report? Ryuch (talk) 08:36, 4 July 2013 (UTC)

Hey Ryuch, thanks for filing that. Right now, ko.wikipedia is on the rollout list. BUT - if there continues to be problems with the Hangul character support, I'll make a case for it to be delayed (for instance, zh.wikipedia is not on the rollout because of compatibility issues). I'll inquire about past Korean testing, and reports (I wasn't around before). PEarley (WMF) (talk) 00:32, 5 July 2013 (UTC)