- Agen pengguna: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
About this board
Post your feedback about using the visual editor.
If you have never provided feedback before, you can learn how to do it effectively. If you are reporting a problem directly on this page, please include your web browser, computer operating system, and wiki skin (usually Vector, sometimes Monobook). The feedback tool within the visual editor will include your user agent details instead.
You can use this page to tell the Wikimedia developers your ideas and issues about using the visual editor: this is the only feedback page actively monitored by WMF staff. The Contributors team welcomes your feedback and ideas, especially on user interface decisions and the priorities for adding new features. All comments are read, in any language, but personal replies are not guaranteed: the team will try and go through reports here at least once a week. Need more attention? Report directly in Phabricator. Please note that the Wikimedia Foundation does not provide support for installing VisualEditor on third-party wikis. Please report bugs involving Parsoid at Talk:Parsoid instead.
You may also want to read a guide to optimize the visual editor's experience on your site, which details work necessary on the community side (such as translating or setting up citation systems).
mau menambahkan kategori saya harus masuk kemana ya kak?
Editing merged citiations?
On enwiki, en:WP:CITEBUNDLE recommends a citation style in which multiple citations are merged into a single <ref> tag. This breaks most of the ability of VE to work with these citations. You can still edit them, but just as a blob of text, not as structured data. Is this a known problem?
Abominable ref names
Please see discussion at en:Wikipedia talk:VisualEditor/User guide#Ref names and discuss there.
Insert citation not working in source mode
Fixed June 22.
2017 NWE gets as far as "generating wikitext" but no wikitext is added to editing area.
Works as expected in visual mode.
iOS 12 Safari desktop web.
I'm not a regular NWE user so not sure if this is a new or long-standing behaviour.
Never mind, I found an existing ticket Phab:T255785. Current tags indicate it’s a MW 1.3.5 wmf.38 regression.
Image copy paste broken after 1.32?
Any ideas why VisualEditor throws this exception to Chrome console with 1.33 and later when copy pasting image to editor,
Query.Deferred exception: files.map is not a function TypeError: files.map is not a function at OoUiSelectFileWidget.OO.ui.SelectFileWidget.setValue (https://wiki.local/load.php?debug=false&lang=en&modules=ext.visualEditor.core%7Coojs-ui-core%2Coojs-ui-widgets&skin=vector&version=09ovhn2:1048:538) at mw.ForeignStructuredUpload.BookletLayout.mw.Upload.BookletLayout.setFile (<anonymous>:1050:340) at Array.<anonymous> (<anonymous>:713:254) at mightThrow (https://wiki.local/load.php?debug=false&lang=en&modules=jquery&skin=vector&version=0w5wrgy:48:916) at process (https://wiki.local/load.php?debug=false&lang=en&modules=jquery&skin=vector&version=0w5wrgy:49:589) jQuery.Deferred exception: files.map is not a function TypeError: files.map is not a function at OoUiSelectFileWidget.OO.ui.SelectFileWidget.setValue (https://wiki.local/load.php?debug=false&lang=en&modules=ext.visualEditor.core%7Coojs-ui-core%2Coojs-ui-widgets&skin=vector&version=09ovhn2:1048:538) at mw.ForeignStructuredUpload.BookletLayout.mw.Upload.BookletLayout.setFile (<anonymous>:1050:340) at Array.<anonymous> (<anonymous>:713:254) at mightThrow (https://wiki.local/load.php?debug=false&lang=en&modules=jquery&skin=vector&version=0w5wrgy:48:916) at process (https://wiki.local/load.php?debug=false&lang=en&modules=jquery&skin=vector&version=0w5wrgy:49:589) jQuery.Deferred exception: files.map is not a function TypeError: files.map is not a function at OoUiSelectFileWidget.OO.ui.SelectFileWidget.setValue (https://wiki.local/load.php?debug=false&lang=en&modules=ext.visualEditor.core%7Coojs-ui-core%2Coojs-ui-widgets&skin=vector&version=09ovhn2:1048:538) at mw.ForeignStructuredUpload.BookletLayout.mw.Upload.BookletLayout.setFile (<anonymous>:1050:340) at Array.<anonymous> (<anonymous>:713:254) at mightThrow (https://wiki.local/load.php?debug=false&lang=en&modules=jquery&skin=vector&version=0w5wrgy:48:916) at process (https://wiki.local/load.php?debug=false&lang=en&modules=jquery&skin=vector&version=0w5wrgy:49:589)
What image are you trying to paste? Are you pasting the code for an image that you copied from another wiki page, or an image from another website?
Same behaviour observed in Firefox 72.0.1, after trying to copy an image from a Word document
Same problem on Chrome 79.0.3945.117 (64 bit)
Same problem on version 1.34
Do you realize that you are supposed to use Special:Upload to put images on your wiki, and not just copy/paste?
What os your point? We can achieve the functionality but being less usable is preferred?
Some extensions like ClipUpload actually manages that, we are talking about just one step more, which was working and now does not.
If you are having trouble with Extension:ClipUpload, then you should contact the maintainers of that extension. Extension:VisualEditor has never supported uploading via copy/paste, and supporting copy/paste uploads from the web is actively unwanted by Wikimedia Commons and the Wikipedia communities.
I completely not agree with you.
If something is unwanted, does no seems that it has to be removed from a system.
This feature was working before and now not. Allowing users to do it or to enable it should be a good point.
You say that it was never supported, but it was here and it was a great feature as lots of users like me use wikimedia to store there IT process and then use copy/paste of screenshot.
How could you explain that if it was not supported it was working before and now it throw an error ?
using 1.34 - on line 5803 in oojs-ui-widgets.js, in OO.ui.SelectFileWidget.prototype.setValue, i changed the line files = files.slice(0,1) to files = [files.slice(0,1)] and i'm getting the image upload popup (error was calling .map on a single object not an array). Doesn't quite fix the problem for me, but it's progress (no thumbnail on the upload popup and when i hit upload i get a filename error)
Does VE munge white space?
Does VE munge white space under certain circumstances? I wouldn't mind if VE eats two spaces to make one space inside sentences for example, or chops useless trailing blanks and that sort of thing. But if VE is responsible for the white-space changes in these two edits (and I'm not at all sure that it is), then that's annoying. w:User:Haywalk is trying to make one small change to one line in an Infobox at w:Kingdom of France and tried twice to do so, but the result was 424 bytes changed in 48 lines. Related discussion can be found here. Thanks, Mathglot (talk) 20:49, 15 May 2020 (UTC)
Yes, you're right, that's not Haywalk's fault. The software doesn't "change" something inside a template. Instead, it "removes" the old template and "inserts" a complete new version of the template. When it inserts a template, it follows the directions given in the template's /doc page about how to format it.
It is a bit annoying (especially if the infobox formatting rules get changed), and unfortunately I don't have any reason to hope that it will stop doing this during the foreseeable future.
Oh hi, I didn't see your post until after I posted. Regarding: I don't have any reason to hope that it will stop doing this during the foreseeable future.
You are a liaison, right? Perhaps you you tell them that not-fixing this bug is a disruptive time-sink on the community, and that Foundation-staff time is just going to get wasted dealing with an endless stream of independent duplicate bug reports?
I believe this issue is Phabricator T179259. They did this deliberately. Somehow they think it's a good idea. They made changes to Visual Editor such that it edit wars the format of existing template parameters.
- Complaints have continue to come in in various places for the last two and a half years, and will continue to come in endlessly until this is fixed
- for every report that comes in there surely thousands more editors repeatedly disrupted by it
- editors are blaming and stressing each other over these edits
- it is disrupting our edit filters
This bug is clearly wasting an excessive amount of community time, orders of magnitude more time than it would take to fix, but staff don't want to bother fixing it.
I invite/suggest you post in Phabricator T179259. Perhaps eventually they will realize that explaining they don't want to fix it consumes more of their time than simply fixing it.
P.S. I count a crazy 74 lines changed in this diff, which should have been a 1 line change. More than one and a half times the 48 you reported.
Alsee, thanks for the updated count; that is indeed crazy.
Whatamidoing, we all run into software glitches from time to time. When we do, we report the problem, look for a workaround that will work in the meantime, and execute it, perhaps at the cost of some increased time and/or effort. That is normal and acceptable; nobody expects software to be perfect. But what is the workaround here, for a VE user who isn't familiar with wikitext? I don't see one.
It seems to me that one aspect of this bug (or is it by design?) is that it drafts wikitext editors into involuntary servitude as housekeepers to sweep up after the actions of good-faith VE editors trying to improve the article, who are thwarted by the actions of a tool through no fault of their own, and who are prevented from carrying out a workaround by the tool. To me, this is the greater problem.
I'd rather be working on improving the encyclopedia in some interest area of mine, and no doubt User:Haywalk would, as well; but instead, we're both trying to deal with this now. As Alsee pointed out, it's a drain on numerous editors. #VEwhitespaceMunge Thanks, Mathglot (talk) 19:57, 16 May 2020 (UTC)
The example here shows a template that has been incorrectly configured in the TemplateData to use a fixed number of spaces. TemplateData allows users to keep values and parameters aligned in block templates, it just needs to be configured correctly, see Help:TemplateData#Custom formats.
The TemplateData in question that needs to be fixed: Template:Infobox_country/doc#TemplateData
@ESanders (WMF) your answer has been suggested previously. It is not effective in resolving the issue. There is no value we can place in TemplateData to fix the general problem.
- Put simply: If the VE-user didn't change something, VE shouldn't change it either. A typo fix or other trivial change should result in a 1 line diff, not a 78 line diff.
- Attempting to be formal and precise: VE should apply TemplateData when a template is originally inserted. It should apply TemplateData formatting to an individual field when the user introduces a new field. When the user blanks a field, VE should use TemplateData to decide whether to delete that field or retain it as present&blank. Modified and unmodified existing fields should not be reformatted - it is both unnecessary and a problem.
Why this matters:
- Needlessly massive diffs are burdensome on the editing community. Individual occurrences may "merely" be a nuisance, but in the aggregate they outweigh the cost of fixing it by orders of magnitude.
- Massive diffs with little or no apparent purpose are often reverted. We lose potentially useful content, and reverts are a known primary reason new users quit and never return.
- Editors who are unaware that VE is responsible may blame the VE-user for the disruption. This may cause talk page arguments which is a cost in itself, with the potentially permanent result that the VE user may leave and never return.
- Editors may attempt to reverse the unwanted changes. VE then engages in unrelenting edit warring any time someone comes along and innocently tries to use VE on that template.
- It's a thorn that keeps jabbing us. The above issues often have an undesirable side effect of generating ill-will against VE and/or against the Foundation. You really do want to fix this, if only for this reason.
ESanders, I have to agree with what Alsee says. I try mightily to avoid the blaming in #3, and tried to go out of my way to point out to User:Haywalk that it wasn't their fault. Still, it's a natural, human reaction (#5) to resent the interruption, and the mopping-up effort required, not to mention the back-and-forth required just to deal with it, for example, at this Wikipedia talk page discussion recently irks. Mathglot (talk) 20:20, 21 May 2020 (UTC)
I would also add another bullet to Alsee's "Why this matters", namely:
6. Wikipedia editors are responsible for all their edits.
Even when using a bot, whether user-assisted or operating entirely autonomously, this is so:
- WP:BOTACC: The contributions of a bot account remain the responsibility of its operator... . In particular, the bot operator is responsible for the repair of any damage caused by a bot which operates incorrectly.
- WP:BOTCONFIG: Bot operators... should bear in mind that they retain all responsibility for their bot account's edits.
- WP:AWB (top):
Warning: You take full responsibility for any action you perform using AutoWikiBrowser.
- WP:AWBRULES: You are responsible for every edit made. (emphasis in original).
I'm seeing something related, where VE is now prettifying infoboxes. Not sure if this is a result of a fix to a previous situation described above, or completely new, but in this edit to w:Italian Libya, a user made a simple, one-line change to a value of an Infobox, and as a result, all the equal signs, formerly unjustified, now all nicely line up, with almost every line in the Infobox altered, to ensure their vertical alignment. While some might see this as desirable (that is, the alignment), I don't believe that an editing program doing things "under the hood" that the user did not specify is desirable. For example: terminating a wikilink by using end-brackets where they are required, is highly desirable; and yet, neither the wikicode editor, nor VE (to my knowledge) performs this function. Neither should VE provide spaces to enforce alignment (desirable as it may be) if the editor did not specifically make that change. If this is a TemplateData issue, and not a VE issue, then the change should be made there. Adding previous discussants @Whatamidoing (WMF), Alsee, ESanders (WMF): (if you are watching and don't wish to be re-pinged; please lmk.) Thanks, Mathglot (talk) 22:36, 15 June 2020 (UTC)
This is for the community to decide. If you remove the "display" parameter completely from the template then no whitespace style will be enforced. It seems to me that the community is getting value from this feature due to its widespread usage. If you think the parameter should not be used at all, or used less, then that is a decision the community can make for themselves.
This was a consequence of w:Special:Diff/958036265, which changed the style VE normalizes to to be "nicely lined-up columns" without addressing the actual problem.
Oh dammit, here's another one of these; my watchlist is showing me a +479 byte change to w:Michel Temer, so I ran the Diff, and I can't see what they changed, due to the fact that every line in the Infobox is prettified. This doesn't represent what the user intended, as a reviewing editor, I cannot find what they changed without way more effort than should be needed; it's just a big cock-up. I suspect the user made one tiny change in one line, but this is just ridiculous.
| vicepresident = [[Hamilton Mourão]] to
| vicepresident = ''None''
This is highlighted. What diff system are you using?
W (WMF), thanks!
Pppery, can you please redo your diff? That seems to point to something irrelevant.
Sorry, off-by-one-error in extracting the correct revision ID from a URL.
Back to what it was, per ESanders comment above at 16 June 2020 08:34 AM.
Correction of the article's title
Hi. I'm just getting started in the wiki universe. I found articles which titles need to be corrected in Brazilian Portuguese, but can't find the editing tool for that. Thank you in advance.
ULFAT EXCEPT NEW TECHNOLOGY
When I am using the visual editor lately, I cannot find the align function. It is troublesome to change to source code editing and change it back. Center align is often useful.
If there is a way to do it with the current visual editor, please tell me.
Proposal: add a screenshot to the portal page(s)
Hi everyone. I think the portal page needs a screenshot, and I propose this one (of the VisualEditor being used to change the indentation level of a bulleted list) as the one to use, but I am hoping for better suggestions.
I know what VisualEditor does, and you know what VisualEditor does, but unless I am missing something, there does not currently exist a resource for everyone else which explains (in a picture-is-worth-a-thousand-words kind of way), "OK, but what does it do?"
Just a bit of background on that: I routinely try to pitch MediaWiki as a knowledge management platform for (non-computationally-focused) colleagues in research, and I would like to have something to point to to say "look, you don't have to write in wikitext!" However: VisualEditor has no screenshot, VisualEditor/Portal has no screenshot, and Extension:VisualEditor has no screenshot. There is an explanatory blog post on blog.mediawiki.org, which is referred to by one of the aforementioned, but that's from 2012, and I assume that much has changed since then.
c:Category:VisualEditor_GIFs are also old, but you might find some useful images there, too.
Oh, that's another good one, thanks!
Nice! Before I disappoint myself: this will still be possible for wikitext editors, by switching to VE mode to add the column, then switch back after it's added, right? Mathglot (talk) 21:07, 21 May 2020 (UTC)
Yes, Mathglot [I'd like to indent this reply but can’t], I have done that.
The only limitation is that VE uses one-cell-per-line style for wikitables, so if you’re trying to do a compact one-row-per-line style then you have to work purely in wikitext.
- Agente de utilizador: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36
Ao editar a página, aparece essa mensagem. Mas o conteúdo é pertinente.