This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
On this website : http://fr.nvcwiki.com wikEd can be activated via gadgets preferences, but doesn't work properly.
With Firefox one can only have the right part of wikEd but not functionnal. And with Camino or Safari the edit window is to small to be visible except when set to full screen.
Thanks for reporting this. I could replicated this and will fix it as soon as I find some time. Cacycle (talk) 06:46, 10 September 2010 (UTC)
Works under 0.9.125 GM. Cacycle (talk) 15:35, 6 May 2014 (UTC)
Text highlighter on view source page?
Would it be possible to implement the font/text highlighter on the view source page? (without the toolbars of course). — Train2104 (talk • contribs • count) 19:25, 12 September 2010 (UTC)
What is the "view source" page? Cacycle (talk) 21:36, 12 September 2010 (UTC)
The one a user gets when they try to edit a page and they don't have permission to . — Train2104 (talk • contribs • count) 21:46, 12 September 2010 (UTC)
Sure, I will add it as soon as I find some time. Thanks for the suggestion - Cacycle (talk) 22:06, 12 September 2010 (UTC)
Works under 0.9.125 GM. Cacycle (talk) 15:35, 6 May 2014 (UTC)
UploadForm.js not working when wikEd is enabled
Is there any way to switch of wikEd for selected articles? I have a problem with running the UploadForm-Script when the wikEd Option is active. I tried disabling loading wikEd.js (which does work wrt. wikEd not showing up), but the new upload form is still not applied. When switching off wikEd (user preferences), the new upload form is correctly applied. Thanks --StefanSchulzDe (talk) 18:30, 27 April 2010 (UTC)
How do I install UploadForm-Script? I don't think it loads when I try this and I cannot find any installation instructions. Cacycle (talk) 20:33, 28 April 2010 (UTC)
The script is loaded via the MediaWiki:Common.js script. Has some pre-requisits though, as can be seen, and I am not sure whether it can be applied via User-Scripts. I assume there is a reason, why WikEd is not available in commons. --StefanSchulzDe (talk) 17:56, 2 May 2010 (UTC)
wikEd is overwriting user customization (I give also an solution)
Hello, Cacycle! That's a very good and powerful Gadget! I have one problem/suggestion about accesskeys. You wrote "it overwrites the MediaWiki shortcuts", that's pretty fine. But You also overwrite user customization with that:
I'd like to attach 'u' to Underline button, 'i' to Italic button and 'b' to Bold button but the 'b' key seems not to work. It's attached to Wikify, I think that's because You add user customization and then set accesskeys for wikify, textify and scrolltoedit. Maybe You should reverse it?
(...)wikEd.InitButtonKey=function(){wikEd.InitObject({26:['b',66],// wikify(...)32:['g',71]// scrolltoedit, overwrites previous wikEd buttons for same key},wikEd.config.buttonKey);};
P.S. Don't You think about archiving some sections here? q;) Vinne2 (talk) 18:57, 13 August 2011 (UTC)
Is it possible to selectively disable the autoscroll feature that causes the page to jump down to the edit box when loaded? I saw the previous discussion that this behavior is disabled when there's an edit notice, but I really would rather it not happen at all. I use Friendly and Twinkle, and often find myself opening a non-existent talk page to welcome or warn someone. However, wikEd jumps down to the edit box, causing the tabs to go off-screen, and I have to manually scroll back up to use my other tools. Since my browser is big enough to see the whole edit box anyway, the scrolling is more annoying than useful for me. --Darkwind (talk) 05:37, 16 April 2010 (UTC)
I will work on this as soon as I find the time after the upcoming major change to version 0.9.91. Cacycle (talk) 20:28, 20 April 2010 (UTC)
Please try to use the following customization options: wikEdConfig.scrollToEdit = false; and wikEdConfig.focusEdit = false; Cacycle (talk) 17:08, 6 May 2014 (UTC)
Fail on bold italic text
Hello,
Some of us on frwiki have problems with wikEd when editing a page with bold italic text.
wikEd 0.9.97a
Firefox 3.6.13 on Ubuntu 10.10 (for me, but it looks it's not related)
Plenty of addons (not related either)
Plenty of other gadgets (including popups — but I don't think this is related either)
Not related to userscripts (same behaviour with or without)
monobook for me (don't know for the others) and no beta interface
parseObj.tree[openNodeIndex].tag = tag; // openNodeIndex is null, the previous value of tag is “bold”
This is called by line 11147:
wikEd.HighlightTreeRedefine(parseObj.secondlastOpenNodeFiltered, 'bold', 0, 3, parseObj); // just after case “'boldItalic':”
This is called by line 13316:
wikEd.HighlightSyntax(obj);
With obj.whole == true and obj.html == // the whole page
If you can't reproduce, please let me know at fr:User talk:Arkanosis, I'd be happy to help.
Best regards — Arkanosis✉ 15:44, 8 February 2011 (UTC)
Oops. I can reproduce it and will check into it. Thanks for reporting. Cacycle (talk) 08:18, 9 February 2011 (UTC)
Works in 0.9.125. Cacycle (talk) 17:08, 6 May 2014 (UTC)
Making scripts compatible with wikEd
I have installed WikEd on my wiki with the "intgrated to wikifarm" installation. I have some problem with the WikiEditor extension, when activated wiked's editing frame isn't visible. It work when you activate the fullscreen mode but the modification aren't applied.
I have a mediawiki 1.16 and the WikiEditor (Version 0.2.0) extension installed with UsabilityInitiative (Version 0.1.1)
I want to do "Making scripts compatible with wikEd" installation but I don't get how it has to be done and where to paste the code --Tsouchon (talk) 13:41, 18 March 2011 (UTC)
This sounds like an incompatibility, perhaps with WikiEditor. What happens if you disable that extension? Please could you also fill out a bug report form (from the top of this page)? Do you see the wikEd logo on top of the page and does it give an error message on hovering? The "Making scripts compatible with wikEd" section is for authors of simple scripts, not for users. Cacycle (talk) 16:02, 18 March 2011 (UTC)
I have this problem too. MW version is 1.16.2. When WikiEd is on I cannot edit pages and sometimes I also get a "WikiEd Error" (WikiEd icon has a red X on it). For some reason here everything is OK... --Tharbad (talk) 19:03, 19 March 2011 (UTC)
I got the same problem too, my MW version is 1.16.2. These two editor just work fine in zh.wikipedia.org(1.17) but not in my wiki. here is a Screenshot of the broken editor http://easycaptures.com/fs/uploaded/387/0939602272.png
PS: the small icon in right-top show as normal（There are no red X on it.）--晒太阳的冰 (talk) 04:44, 29 March 2011 (UTC)
Scroll down to the middle of the text in the edit window
Click on [T]
This causes wikEd to jump to the end of the text, instead of staying in the same position, as it does in 3.6.16 and Chrome 10
Somewhat annoying when using [T] in big articles, otherwise not a big deal. GregorB (talk) 11:18, 26 March 2011 (UTC)
This is relatively annoying, though I wouldn't imagine it's as important to fix as other things. Still, it would be convenient if the cursor was in the same position after the function completes. —danhash (talk) 18:09, 30 January 2012 (UTC)
The problem seems to be gone in Firefox 21... GregorB (talk) 11:27, 25 May 2013 (UTC)
Bug in diff.js
Hi. I found a bug in your diff.js: Look at this diff (don't care about the text, this was the example I found the bug in, and I didn't look for an English example). There is a move shown, which looks like only the comma and the space was moved. If you look at the HTML source, you can see that the deleted "also" and the inserted "wenn man" are in the moved block too, which is kind of strange. But even if you accept this to be a move, it is wrong still, since the following "einfach" should belong to the moved block too. I hope you are able to find the bug in your diff.js. --Schnark (talk) 07:29, 11 April 2011 (UTC)
In certain cases, the results are counterintuitive, especially for many close minor changes of common words and when block moves are involved. I would not call this a bug. Cacycle (talk) 17:07, 8 May 2011 (UTC)
The diff suggests that the word "einfach" wasn't changed. But it was changed: It was moved from the point where the yellow arrow shows a move to the place where it is shown in the diff. But it is not highlighted yellow as it should. The span with the class wDiffHtmlBlock should end after the word, not before it.
It should be possible to restore both the old and the new text from the diff, by omitting either the inserted or deleted blocks and by putting moved blocks either where they were or where they are now. But in this case you can only get the new text correctly in this way, the old text can't be restored from this diff. --Schnark (talk) 09:34, 10 May 2011 (UTC)
It is even possible to hide vandalism: [1] If you only look at the text marked as changed you won't notice the vandalism that occured. --Schnark (talk) 07:44, 12 May 2011 (UTC)
Screenshots to show the bug: "Vandalism is" should be yellow. --Schnark (talk) 08:31, 17 June 2011 (UTC)
What it looks like
What it should look like
Edit window size
I'd like to customize the size of the edit window in my browser and I'm a wiked user. Is there a customization bit for that, or will I need to do something special? — V = IR(Talk • Contribs) 14:08, 19 April 2011 (UTC)
To do that, you can drag the grip handle at bottom right of the edit window. -Pgan002 (talk) 03:39, 26 April 2011 (UTC)
You can chose the textarea size in your wiki preferences, wikEd keeps the default size. You can also use the fullscreen mode which is a persisting setting. Cacycle (talk) 07:03, 6 May 2011 (UTC)
Is it possible to calculate the text area height depending on the window height? it seems this should be already happening in
wikEd.SetEditArea(), but for me it always comes up a standard height. -Pgan002 (talk) 01:25, 24 December 2011 (UTC)
Full-screen mode is great! But it should resize area dynamically if the window gets resized, or if the Find bar is shown or hidden (for example in Firefox) or a notification bar appears (in Firefox). Is that achievable? I noticed that the width does change dynamically.
JS errors in IE 8
After enabling the wikEd gadget on Portuguese Wikipedia and going to a page like pt:Idempotência using Internet Explorer 8.0.6001.18702 I get the following errors in the console:
Error: Type mismatch
javascript&smaxage=21600&maxage=86400, line 15568 character 3
domElement.detachEvent('on' + eventType, domElement[eventType + eventHandler]);
and
Error: Object doesn't support this property or method
javascript&smaxage=21600&maxage=86400, line 15547 character 4
domElement['wikEd' + eventType + eventHandler](eventRootElement.event);
Could this be fixed? Helder 20:46, 9 May 2011 (UTC)
minor bug considering new lines and highlighting
New lines created at the beginning of the document will already possess the highlighting of the following lines, no matter what you write there. It's distracting me slightly.
It's reproducible. For instance, open the page [2], go to the start of the document, press enter two times and start writing. The text will adopt the highlighting of the following lines, no matter the content. --Aetas volat. (talk) 13:30, 30 May 2011 (UTC)
Supplement: It's not just highlighting, but formatting in general. --Aetas volat. (talk) 16:03, 30 May 2011 (UTC)
Preview doesn't work properly in Safari
In Safari 5.1 under Mac OS 10.7, clicking on the same-page preview button (the magnifying glass) results in a generated preview where templates are not expanded, but instead appear in their source code form. Firefox works properly.
Hgrosser (talk) 03:41, 1 September 2011 (UTC)
Tabbing
Did something change with the tabbing? For some mysterious reason, tabbing out of the edit textarea to the edit summary now fails to select the content of the edit summary (instead inserting the cursor at the beginning of the input), which is the behavior behavior anywhere that I know in computing. Circéus (talk) 16:48, 14 October 2011 (UTC)
Ref hiding bug
In this edit I used the "[REF] and [TEMPL] hiding" feature to make the text easier to edit, but it removed the </ref> tag at the end. —danhash (talk) 18:35, 31 October 2011 (UTC)
Could not reproduce this under wikEd 0.9.119c. Cacycle (talk) 16:36, 7 October 2013 (UTC)
Plain pasted text?
Sorry if this isn't the right page to ask this on, but is there a way to force any text that's pasted into wikED to be plain text? It's really annoying when I copy things in from other sites and it keeps the font style, sometimes even the page's formatting gets through and screws up the whole page. I hate having to copy text through Notepad in order to change it to plaintext. Thanks very much for the assistance and keep up the work! I love this extension! 76.172.107.173 (talk) 17:52, 30 January 2012 (UTC)
Check out this thread which addresses the issue. The short answer is to use Ctrl-Shift-V to paste instead of Ctrl-V, or to right-click and select "Paste as plain text" in supported browsers. —danhash (talk) 18:05, 30 January 2012 (UTC)
I am actually working on this. Unfortuntely, Ctrl-Shift-V does not work in most cases. Cacycle (talk) 00:09, 4 February 2012 (UTC)
instant preview not working
0.9.102
Firefox 11
all addons disabled apart from wikEd/greasemonkey
default skin
no other scripts
Windows XP sp3
Whenever I try to use the "preview" function of wikEd to show a live preview of an article without reloading the page, the preview doesn't appear. All that appeasr is a text box containing "..."
Clicking the preview button again adds an additional blank line to the text box
It is a browser bug, please see Firefox bug 721750 and feel free to help/comment. Cacycle (talk) 20:50, 17 July 2012 (UTC)
Thanks, however, as I previously mentioned, the bug appears in Safari & Chrome as well. Toggle wikEd text area off in any of the 3 browsers, and my edit-area text highlighting is my preferred color. Fresh link below shows (Chrome) that the highlighting is “boxed in” after a select-all or drag-select:
I had an idea recently, and I was wondering how hard it would be to have a button in wikiEd that would display tables as actual tables, so that people could edit the entries easily without having to sort through the jumble of code. Is such a thing even possible? ~Adjwilley(talk) 19:16, 17 July 2012 (UTC)
Great suggestion. This is actually possible and most of the code has already been written (you can see it in the source). It is just that I am really busy IRL at the moment. Cacycle (talk) 20:53, 17 July 2012 (UTC)
Wow! That's exciting to hear. If I had any experience programming I would offer to dive in and help, but unfortunately I'm no programmer. Good luck with whatever you've got going on :-) ~Adjwilley(talk) 21:18, 17 July 2012 (UTC)
A few additional details (not sure if they'll help, but can't hurt): If I load you talk page with the wikEd text area turned off (as I normally do), it comes up fine. When I try to turn on the wikEd text area, the mouse cursor changes to the "busy" symbol and won't change back, and this error is produced:
Timestamp: 8/16/2012 11:56:04 AM
Error: TypeError: parseObj.tree[openNodeIndex] is undefined
If I click on the wikEd text area button again, the mouse cursor goes back to normal and the edit box is now blank. Loading your talk page with the wikEd text area turned on produces a blank edit box and the same error. I get no other errors in my error console. I'm on Firefox 14.0.1, Windows Vista, Vector skin, wikEd 0.9.104a G (August 6, 2012). jcgoble3 (talk) 16:01, 16 August 2012 (UTC)
Installation problem
Can't seem to install with a User script. Have tried both Complete_version and Ultra-simple_version with refreshing and even reloading the browser. Using Firefox 16.0.1 and Firefox 17. Does common.js prevent use in monoboook.js perhaps? However it works fine with the gadget, but the gadget doesn't appear to support Fix typos which was my mean purpose of installing the gadget. Regards, Sun Creator(talk) 23:54, 13 October 2012 (UTC)
Your message is to cryptic to understand or perhaps the documentation is outdated. After having followed the installation instructions my monobook.js page has no '/ start of user configurable variables' section. What am I doing wrong? Regards, Sun Creator(talk) 00:27, 6 January 2013 (UTC)
wikEd & Narayam compatibility
Hi Cacycle, I am an admin on gu.wiki where I recently installed this gadget. I am localising it there as well. I am facing an issue with its compatibility with Narayam. When WikEd is enabled, narayam doesn't work, saying that input language is only English. Once WikEd is disabled Narayam starts working. Before I file a bug, thought to check with you whether you are aware of this issue? Or is it because I missed something while installing?-- DhavalTalk 08:46, 5 January 2013 (UTC)
I am not aware of this, please post a detailed bug report (see top of page) so that I can replicate your problems. Thanks, Cacycle (talk) 19:14, 6 January 2013 (UTC)
Wikidata Template German
Hey I use the gedaget on Wikidata. if there is a Template highlited I can click it and it opens a new tab but instead of "Template:..." it opens "Vorlage:..." this would be correct on the German wikipedia but as I am using Wikidata (yes in German language) it should still be "Template:..." there. --Sk!d (talk) 00:23, 16 January 2013 (UTC)
Fixed in version 0.9.118a (May 19, 2013), now the customization settings in wikEdConfig.text take precedence over loaded translations. Simply add the following code to common.js to the wikidata:MediaWiki:Gadget-wikEd.js page. Cacycle (talk) 13:27, 19 May 2013 (UTC)
Hi, someone asked me a question about automatic replacement of this html code : obj.plain = obj.plain.replace(/ | |\xa0/g, ' ');
Is it possible to disable this replacement in personnel common.js ? Thanks Leag (talk) 08:03, 5 February 2013 (UTC)
No, that is not possible as non-breaking space as a character (but not as a character entity) is not supported by wikEd. Cacycle (talk) 10:48, 20 May 2013 (UTC)
Problem description: I am editing a user talk page with WikEd enabled. After clicking preview and editing it a few times, I click save. Then I realize that it added my edits to Main Page rather than the user's page.
Steps to reproduce:
Enable WikEd on Wikinews.
Create a new user talk page.
Add "{{subst:Welcome}}" to it, click WikEd's preview, click save.
You will get a message that you have tried to edit the Main page.
It depends on the previewed <input name="title"> that hijacks the save command to a new page title.
Given that in your project it's matter of a frequently saved template, while waiting a fix in wikEd, you can apply this temporary patch in n:MediaWiki:Gadget-wikied.js :
// patch for the title-trapdoor// on saving after a live-preview of an <input name="title">$('#wpSave').click(function(){$('#wikEdLocalPrevWrapper').remove();});
I cannot replicate this problem, neither using wikEd as a gadget nor under Greasemonkey. Has this already been fixed somewhere else? Maybe this has been caused by Gadget-Feedbackhack.js? Do you still see this with all other gadgets disabled? BTW, it is wikEd, not wikiEd... Cacycle (talk) 14:55, 7 April 2013 (UTC)
OK, I can see it now and are working on it... Cacycle (talk) 21:26, 7 April 2013 (UTC)
Has been fixed a while ago in 0.9.114c (April 21, 2013). Cacycle (talk) 19:41, 11 May 2013 (UTC)
Inline links to Wikidata items
Some of the Wikipedias (and all of them soon) allow you to pull information from Wikidata. A common example is for the population of a country or city so that updating the value in Wikidata will update it for all of the articles and languages that use that information. There is concern about how easy it is to get from a Wikipedia article to the item in Wikidata. It would be great if wikEd could link to Wikidata items like it does for Commons media items. The basic idea would be to turn any into a link to the Wikidata item with the title of the article. More details are here. http://blog.wikimedia.de/2013/03/27/you-can-have-all-the-data/ My JavaScript is a bit dusty, but I could help out. Wakebrdkid (talk) 19:28, 29 March 2013 (UTC)
Added to version 0.9.113. Thanks for suggesting this. Cacycle (talk) 21:36, 6 April 2013 (UTC)
Signature button / custom buttons / Common.js
Hi. After installing wikEd recentlly I noticed the standard "sig" button on the wiki I use stopped working. So, I decided to disable the standard toolbar and make a custom wikEd button. I copied the custom buttons example as per User:Cacycle/wikEd_customization#Custom_buttons however no buttons appear and I get the following in the error console:
Timestamp: 30/03/2013 2:12:38 PM
Warning: Expected 'important' but found 'ie'. Expected ';' or '}' to terminate declaration but found 'ie'. Declaration dropped.
Source File: http://en.pathofexilewiki.com/wiki/User:Nightblade/common.js
Line: 13
Timestamp: 30/03/2013 2:12:38 PM
Warning: Expected 'important' but found 'ie'. Expected ';' or '}' to terminate declaration but found 'ie'. Declaration dropped.
Source File: http://en.pathofexilewiki.com/wiki/User:Nightblade/common.js
Line: 13
Timestamp: 30/03/2013 2:12:38 PM
Warning: Expected 'important' but found 'ie'. Expected ';' or '}' to terminate declaration but found 'ie'. Declaration dropped.
Source File: http://en.pathofexilewiki.com/wiki/User:Nightblade/common.js
Line: 13
I guess this is two or three bug-reports in one. Sorry about that! -- Niightblade (talk) 03:20, 30 March 2013 (UTC)
Please use the updated example under User:Cacycle/wikEd_customization#Custom_buttons instead. Also, in order to use custom functions (such as the button handlers) under Greasemonkey, you have to add the function code to the wikEd Greasemonkey code bundle. Cacycle (talk) 20:59, 5 April 2013 (UTC)
Everything is working perfectly now thanks! I moved to the non-GS version too. One last thing: Why no signature button on the wikEd bars? -- Niightblade (talk) 02:43, 6 April 2013 (UTC)
wikEd bug report (improper whitespace added)
Date: 2013-04-15 13:31:39 UTC
wikEd version: 0.9.113 G (April 06, 2013)
Browser: Mozilla/5.0 (Windows NT 6.0; rv:20.0) Gecko/20100101 Firefox/20.0 (Win32)
<ref>{{cite journal |doi=10.1016/j.•neurobiolaging.2009.04.012 |title=The N-methyl-d-aspartate receptor modulator GLYX-13 enhances learning and memory, in young adult and learning impaired aging rats |year=2011 |last1=Burgdorf |first1=Jeffrey |last2=Zhang |first2=Xiao-lei |last3=Weiss |first3=Craig |last4=Matthews |first4=Elizabeth |last5=Disterhoft |first5=John F. |last6=Stanton |first6=Patric K. |last7=Moskal |first7=Joseph R. |journal=Neurobiology of Aging |volume=32 |issue=4 |pages=698–706 |pmid=19446371 |pmc=3035742}}</ref>
Hi Technical 13, this is not a real bug, please see User:Cacycle/wikEd_help#Fix_buttons. After using the fix buttons, always check the changes with the button for unexpected collateral damage. Always use the smallest possible selection. Keep in mind that the applied rules are very simple. Only the Unicode character fixing is completely safe. Cacycle (talk) 21:25, 21 April 2013 (UTC)
Improper space inserted in front of references
Date: 2013-04-16 07:17:17 UTC
wikEd version: 0.9.113 G (April 06, 2013) 0.9.116 G (April 26, 2013)
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1 (Win32)
Problem description: When inserting a reference with a Cite form, it inserts an extra space in front of the reference, which is incorrect according to the MOS.
Steps to reproduce:
Position cursor at desired insertion point (e.g. after the period at the end of a sentence).
Click the "Cite" option at the top of the edit form, revealing a new row with a Templates dropdown listbox, "Named references" link, and "Error check" link.
Choose "cite web" from the listbox, fill out the resulting form, and click its Insert button.
The reference is inserted, but with a leading space, violating WP:MOS.
I could swear I have seen this bug reported in the past, but am unable to find it, and so am reporting it again, since it still occurs (and is polluting WP some). —[AlanM1(talk)]— 07:36, 16 April 2013 (UTC)
(edited) —[AlanM1(talk)]— 19:46, 6 May 2013 (UTC)
LaTeX code parser activation upon refresh of post preview
Reason for Addition for Bug Queue:
Users requesting help on the mathematics reference desk need to be able to properly preview their posts before they finish submitting them.
Problem Description:
wikEd's article-previewing functionality does not call MathJax upon its activation even though the normal Wikipedia editor, which appears during an edit page's initial loading sequence, does, thereby allowing MathJax to parse any LaTeX code embedded in the page which one is currently editing only when the article's editing form first loads but not when the edit preview is refreshed from wikEd.
Error Console Entries:
None applicable to website code (all apply to installed extensions and disappear when I disable extensions through Safari's master switch in 'Preferences → Extensions')
Steps Necessary to Reproduce this Problem:
Check your preferences to make sure that the following options are enabled:
Preferences → Appearance → Math → ⊙ MathJax (experimental; best for most browsers)
Preferences → Gadgets → Editing → ☑ wikEd, a full-featured integrated text editor for Firefox, Safari, and Google Chrome. Please read the help page for usage instructions.
Begin editing an article or section.
Add some LaTeX markup to this article or section if none already exists.
Refresh the edit preview without saving your edits by clicking 'Preview.'
Any embedded LaTeX will not render correctly.
Possible Leads:
BugzillaBug 35478: Remove support for WikEd and ajaxPreview from ext.math.mathjax.enabler.js
I will work on this for the next release in a few days. In the meanwhile, simply push the standard preview button with math in the text one in order to load MathJax. Cacycle (talk) 21:25, 22 April 2013 (UTC)
Thank you so very much!!! I look forward to being able to use MathJax with wikEd once again and will check back every once in a while to make sure I catch your update to wikEd when you notify wikEd's userbase of it via the script's history page.
Okay, I take it back: you haven't completely fixed the problem; it still occurs when I try to refresh a preview for a section I'm just starting on the mathematics reference desk. I'll submit a new bug report…ugh, why doesn't everything just work like it's supposed to? — RandomDSdevel (talk) 16:33, 26 April 2013 (UTC)
Fixed in 0.9.117. Cacycle (talk) 19:31, 11 May 2013 (UTC)
Need help with whitespace issue
I need your help in order to fix the whitespace issue extensively discussed above (wikEd adds too much whitespace, Extra spaces, Improper space inserted in front of references). The bug consists of the addition of empty lines into submitted text after pushing the Save page or Preview buttons. Examples from above include text containing wikicode lists. The bug seems to happen only under OS X, but unfortunately, I do not have access to an OS X system to figure this out on my own.
Do you see the issue in the preview area after pushing the Show preview below button ()?
Do you see it with wikEd disabled ( button above edit area inactive)?
Do you see it with highlighting disabled ( button inactive)?
Do you see it with [REF] and [TEMPL] hiding on as well as off ( active as well as inactive)?
Do you see the issue when not pasting text
Please could you create a minimal test case that contains the minimum amount of text and unnecessary wikicode?
Has anybody experienced this issue under Windows first-hand?
Please email me the following debugging information (only working with wikEd version 0.9.114c):
Hi Technical 13, your bug is not related to this, please check my upcoming comments above. Cacycle (talk) 21:20, 21 April 2013 (UTC)
Because of a bug I had to revert to last stable version (0.9.113). Therefore, the debug info function is temporarily disabled. I will fix this asap. Cacycle (talk) 19:52, 21 April 2013 (UTC)
Debugging mode works again in 0.9.114c. Please update with Shift-Reload and submit your bug reports. Cacycle (talk) 18:37, 23 April 2013 (UTC)
OK, I think I have found the bug! It is a bit difficult to fix, please give me some time. Cacycle (talk) 21:32, 24 April 2013 (UTC)
I think I have fixed it, please update to version 0.9.116 and report back. Thanks, Cacycle (talk) 23:05, 26 April 2013 (UTC)
I'm going to cautiously say it looks like it's fixed. Thanks a lot! As I'm sure you noticed, this has been bothering me for several months, almost a year. -- tariqabjotu 07:57, 28 April 2013 (UTC)
I typed this line and then attempted to insert a ref with the cursor position just after this period -->. Not only did it add a space after the period, but it inserted the reference at the top of the buffer (instead of after the period and new space), in front of the section header (i.e. "<ref>blah...</ref>== Need help with whitespace issue =="). Version=0.9.116 G (April 26, 2013). —[AlanM1(talk)]— 19:43, 6 May 2013 (UTC)
LaTeX code parser activation upon refresh of post preview
Reason for Addition for Bug Queue:
Users requesting help on the mathematics reference desk need to be able to properly preview their posts before they finish submitting them.
Problem Description:
wikEd's article-previewing functionality does not call MathJax upon its activation. The normal Wikipedia editor, which appears during a normal edit page's initial loading sequence, does; this would normally allow MathJax to parse any LaTeX code embedded in the article which one is currently editing upon first loading this article's edit page, but the normal Wikipedia source code editor doesn't have anything to preview when a user creates a new section.
Error Console Entries:
None applicable to website code (all apply to installed extensions and disappear when I disable extensions through Safari's master switch in 'Preferences → Extensions')
Steps Necessary to Reproduce this Problem:
Check your preferences to make sure that the following options are enabled:
Preferences → Appearance → Math → '⊙ MathJax (experimental; best for most browsers)'
Preferences → Gadgets → Editing → '☑ wikEd, a full-featured integrated text editor for Firefox, Safari, and Google Chrome. Please read the help page for usage instructions.'
Create a new article or section.
Add some LaTeX markup to this article or section.
Refresh the edit preview without saving your edits by clicking 'Preview.'
Any embedded LaTeX will not render correctly.
Possible Leads: None
— RandomDSdevel (talk) 17:36, 26 April 2013 (UTC)
It works for me under wikEd 0.9.116 (Firefox under Windows). BTW, for an automatic and concise bug report summary, please see the top of this page Cacycle (talk) 23:12, 26 April 2013 (UTC)
Sorry for not getting back to you right away, but I haven't been able to get to my computer over the past few days. Anyway, I can confidently state in response to your second sentence that I've tried to figure out the keyboard shortcut that you mentioned a couple of times in the past without success. Although I should really submit a second bug report for this, I thinks that I can safely summarize what might go into such a report by saying that that this might be a problem for me because I use a Mac. On such computers, Control - clicking (along with its Mouse Keys equivalents of either Function - Ctrl - 5 on the row of number keys above the main section of the keyboard, or Ctrl - 5 on the numeric keypad, or Function - Ctrl - i, which are respectively available via the keyboard after you activate these said Mouse Keys – either via System Preferences's Universal Accesspreference pane or by rapidly pressing down the ⌥ Option key five times – –depending on whether the type in use is a large desktop keyboard, a small desktop keyboard, or a laptop keyboard) is associated in OS X with the trigger that opens contextual menus. Similarly, holding down the ⇧ Shift key or the ⌘ Command key while clicking the primary (left) mouse button after selecting a single item allows users to select continuous and non-contiguous multiple selections, respectively. As you can now see, Mac users such as myself are in a bit of a pickle when it comes to the use of keyboard shortcuts here on Wikipedia. Sometimes ⇧ Shift - {key press|Option}} works, though, and Wikipedia's instructions for using keyboard shortcuts tell those of us using Safari 4 or higher to use Control - ⌥ Option to activate them, so I'll try that next. I think that my previous filibuster, though, is enough of the tangent which it pursued, and I should really be discussing your first point with you. I'll purge both my local and server caches to see what happens, and then I'll report the results back to you.
Okay, let me make a long story short by saying that none of your or Wikipedia's keyboard-mouse shortcut doo-hickeys work in my browwer when applied to the bug report button, but, again, that's for another bug report (oh, the irony!) Anyhow, I should probably also elaborate on your reply's first point by stating that the 'Preview' button should call MathJax whenever it's pressed…except that it doesn't! Oh, what am I going to do?
MathJax fixed in 0.9.117. Cacycle (talk) 19:25, 11 May 2013 (UTC)
Actually, that doesn't seem to be the case for me, Cacycle. I emptied the cache in my copy of Safari 5.0.6 and also purged the mathematics reference desk's server cache and didn't get any results from MathJax when I plopped the text that I wanted to see rendered into the wikEd text box. Going over to Safari's error console only provided me with a warning about how the generic picture of a person to the left of my username does not express the correct MIME type (it is 'image/svg+xml' but should, according to Safari5.0.6, simply be 'image,' but this is most likely a consequence of the fact that my browser doesn't renderpages with the latest version of WebKit –I really need to help my Dad finish migrating all six of the accounts on our family's computer to Mountain Lion, don't I? Moving along, I then decided to have Mac OS X 10.5.8 Leopard's version of Activity Monitor sample the pieces of Safari that were in my machine's memory because of how few were the results that Safari gave me. Doing so when I clicked the 'New section' tab at the top of the mathematics reference desk resulted in this text file, which I have made available for your inspection through my Google Drive. Similarly, the application produced this other text file, which I have also made available to you through that service, when I had it profile Safari while wikEd attempted to preview the results that my input text would generate. I will therefore probably have to switch over to using texvc until you can notify me that this bug has been fixed, but at this point I'm starting to wonder if there's a problem with either the extension or Live Preview, which doesn't really work anyway. I guess it's time to disable that and find out, eh?
UPDATE: Yup, it was the live-previewing functionality (ugh…) — RandomDSdevel (talk) 17:16, 15 May 2013 (UTC)
New MathJax hook
He Cacycle, just would like to let you know that I added a $jquery method to the MediaWiki version of MathJax (so not Nageh's version), that can be used to postprocess DOM fragments with MathJax. It can be used like: $('#wikiPreview').renderTex(); Therefore this version now also no longer has the hack to trigger it from the preview mode of wikEd. It is not yet live, and will probably take a few weeks before it does go live. Also under development right now is a new hooks system to trigger these type of events automatically after a page has loaded bugzilla:30713. That means that in the future, you can trigger a new 'wikipage ready' event from wikEd and it will execute all the registered postprocessing hooks. So do expect some breakages on this front in the coming months and let us mediawiki devs know if something goes terribly wrong somewhere :D —TheDJ (talk • contribs) 08:26, 2 May 2013 (UTC)
It's about time that you guys figured this out! I reported this bug for Cacycle to fix only to have it break again! No wonder things got so messed up…oh, well; I guess you guys can just ping me when every thing's hunky-dory.
Hi DJ, thanks for the note. I had already added that to the next version of wikEd. Please wait a few days until it gets online. Cacycle (talk) 20:58, 5 May 2013 (UTC)
Hello, Cacycle. You have new messages at Wikipedia:Help desk. Message added 22:08, 5 May 2013 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.
Um, sorry to intrude again, but…Cacycle, I have a problem with waiting for this to be fixed, just as I have mentioned at the bottom of the linked/talkbacked section.
Not directly a talkback, but please add a comment. ;-) mabdul 22:21, 4 May 2013 (UTC)
Sorry for being too late... I do not think that such a library makes much sense as the existing tools are too specialized and different in their intended purposes. Developers can always check the workings and functionality of the existing code and have to adopt that to their own project. Cacycle (talk) 19:22, 11 May 2013 (UTC)
Feature request: display redlinks in red
Long time, no see. (Though I see/use "Ed" every time I log on to Wikipedia).
I spend a lot of time stripping redlinks from lists.
To do this, I have a viewing copy of the page I'm editing with WikEd open in another window, so I can see which items are red.
It would sure help if WikEd identified these by showing them in red directly in its editor window.
I look forward to your reply. The Transhumanist 02:47, 19 May 2013 (UTC)
I have added redlinking to wikEd 0.9.122a, thanks for the suggestion. 00:15, 15 December 2013 (UTC)
It is simply awesome. Works great. Thank you! The Transhumanist 03:24, 9 February 2014 (UTC)
wikEd bug report (May 21)
Date: 2013-05-21 18:28:11 UTC
wikEd version: 0.9.118b G (May 20, 2013)
Browser: Mozilla/5.0 (Windows NT 6.0; rv:21.0) Gecko/20100101 Firefox/21.0 (Win32)
Problem description: links to expand collapsed sections in #wikEdClonedWarnings duplicated editnotices reloads the page (sends to #top at least) and sections refuse to expand. The section at the top of the page will expand, but is useless due to its distance from the editbox. Perhaps the script that creates the #wikEdClonedWarnings duplicated editnotice could also .remove() the section on the top of the page eliminating this problem? Technical 13 (talk) 18:41, 21 May 2013 (UTC)
Please give me links to such articles. Cacycle (talk) 20:07, 21 May 2013 (UTC)
I have a collapsed section on my talk page editnotice. It also occurs with the reviewer tools section on WT:AfC pages. I can try to get a screen capture too if you need. Technical 13 (talk) 20:28, 21 May 2013 (UTC)
I do neither see a simple fix for that nor any problems caused by the current behavior. Sorry, Cacycle (talk) 19:21, 23 May 2013 (UTC)
If you don't mind me asking, what is the code that you use to duplicate the notices in the first place? I'm trying to recreate "just" that piece in my vector skin so that I can create a patch/workaround that should work and test it. Technical 13 (talk) 18:29, 24 May 2013 (UTC)
Where is the discussion archives search?
Is there an "archive search" field on this page that I'm not seeing for some reason? Or am I on the wrong page? I was going to search for the latest info about running this with an Opera browser on Ubuntu Linux. Thanks! —Grollτech (talk) 20:56, 18 June 2013 (UTC)
All discussions have been archived, please see the top of this page for the archived pages. Opera before version 15 is not compatible with wikEd. Since version 15, wikEd works just fine under Opera, unfortunately, they have not yet released a linux version above 15. Cacycle (talk) 16:14, 7 October 2013 (UTC)
I added a search box to make searching easier. --Elvey (talk) 15:47, 6 May 2014 (UTC)
Bug report: Double pasting
I noticed just today (so I imagine this is new) when I paste something within the edit box on a new line, the item gets pasted twice. An example of this is here and here. I copy the first line (using CMND+C), and paste it to the last line (using CMND+V), and I get the same text repeated twice. This seems to only occur in certain conditions as noted below:
This occurs regardless whether the item is copied from a source in the edit box or outside the edit box.
When the source text is unitalicized, this bug seems to occur if and only if it's pasted to a new line on its own.
When the source text is italicized, this bug seems to occur regardless of whether it's pasted to a new line or on a line with something else already. That behavior also exists regardless of whether you actually copy the single quotes that cause the italicization or not.
In other words, when I copy the word twice right here, I get "twicetwice". If I copy the word twice right here, I just get "twice". However, if I copy and paste the second, unitalicized instance of twice onto a new line, I get:
"twicetwice"
There are also a few other situations where the issue occurs, but I can't isolate the common factor. For example, if you look at Template:In the news and copy "Brétigny-sur-Orge derailment aftermath" (from the template embedded within the source of the page) and paste it either someplace there or someplace here, even if its on the same line as something else, you get "Brétigny-sur-Orge derailment aftermathBrétigny-sur-Orge derailment aftermath".
Anyway, that should give you an idea of what the problem is. As you request, here's some details about my computer and browsing:
WikEd version: 0.9.119g
Browser ID: Chrome v. 28.0.1500.71
User scripts: Prose size
Gadgets: Reference tooltips, Popups, GoogleTrans
Skin: Vector
Operating System: Mac OS 10.8.3
Let me know if you need more information. Thanks. -- tariqabjotu 15:59, 14 July 2013 (UTC)
This started happening to me today, shortly after I noticed that WikEd was coming and going on the page (appears and disappears with "Preview"). Firefox 22.0, Windows WP, Skin Modern. Scripts - Reflinks and DYK Check in toolbox. — Maile (talk) 21:50, 14 July 2013 (UTC)
The issue of wikEd coming and going was due to system problems with gadgets in general; there was lots of talk about this on Village Pump, with some editors blaming VisualEditor. Actually, this was one thing VE did not mess up. Christhe spelleryack 01:19, 15 July 2013 (UTC)
I clicked the Gadgets box that removes VisualEditor from the interface. I still get the coming and going, so I guess that confirms what you are saying about it not being VisualEditor. — Maile (talk) 11:17, 15 July 2013 (UTC)
Oops, sorry for that. I have reverted to the last good version for now until I have figured this out. I do not see the problem under Firefox, so it might be Chrome related. Cacycle (talk) 06:26, 15 July 2013 (UTC)
As of this morning, I'm still getting the double pasting. — Maile (talk) 11:37, 15 July 2013 (UTC)
OK, I have fixed this Chrome-only bug in version 0.9.119a. Pasted text is now automatically [T]extified. For the formatted text, please push the undo button once. Cacycle (talk) 20:51, 17 July 2013 (UTC)
Then you only did a Chrome-only fix. Because I still get the double pasting in Firefox 22.0. I'll just unclick WikEd in the Gadgets and do without it. I'm still having issues I posted months ago that never got resolved. Too much trouble for me. — Maile (talk) 21:01, 17 July 2013 (UTC)
I am sorry to hear that. Have you updated (Shift-Reload) and use version 0.9.119b? Would you mind pasting a bug report here (See top of this page)? Thanks, Cacycle (talk) 07:04, 18 July 2013 (UTC)
Haven't done a bug report, yet, but please refer to Issues_remaining from January, and also what is posted below by Schweiwikist. I think the issues are related. Also, in regards to "issues remaining", how I've gotten around it in a rather clunky and time-consuming manner is to do a tap-tap-tap on the space bar, manually inserting spaces, then backspace into the (on my computer) gray area where the extra spaces are, and then doing in insert into that space. Quite time consuming. So, add that to what is happening now, and I'm not sure WikEd is much of a tool for my use. — Maile (talk) 16:25, 18 July 2013 (UTC)
Hi there!
I’m getting the same behavior, by doing the following (it’s okay in Chrome) under Firefox 22 (Snow Leopard/Monobook—can’t figure out how to bring up the bug report form for you). Ready?
1. Open up a new user sandbox for editing.
2. Select only the template code {{User sandbox}}. It’s blue-black highlighted. But note that it was already wikEd highlighted.
3. copy or cut the selected text in the usual way (menu item or keystroke)
4. now move the insertion point to the end of the page code, i.e., at the end of: <!-- EDIT BELOW THIS LINE -->|
5. type a return to start a new line of code.
6. now Paste the copied or cut text snippet. the code {{User sandbox}} appears ONCE. So far so good.
7. Now Select All and DELETE all the code.
8. Now Paste again. This is when the double-paste occurs, with the extra paste wikEd-highlightEd.
At least this is a reproducable recipe where one way the bug doesn’t appear and the other way it does.
I first noticed this buglet when I was prepping my CE Cal pages for speedy-deletion, deleting all the page code and then pasting in {{Db-g7}}. Hope this helps.
----Schweiwikist (talk) 16:07, 18 July 2013 (UTC)
Oh, replacing the whole text or pasting into an empty area makes problems. I have reverted to the last good version for now. Please update by Shift-Reload. Cacycle (talk) 21:25, 21 July 2013 (UTC)
I thought maybe I had a keyboard bounce problem of some kind. I had the problem occasionally with Win7/Ffox20 in the last week or so – maybe 3 days ago the last time. It seemed to happen most often when insert-pasting a single-line template row at the top of the buffer. —[AlanM1(talk)]— 02:15, 25 July 2013 (UTC)
This has been fixed in the current wikEd 0.9.119c. Cacycle (talk) 12:53, 7 October 2013 (UTC)
WikEd gone for two days
As I posted on Village Pump yesterday, I had re-checked WikEd in my Preferences, intending to run some tests so I could input a Bug report above. And, yes, I've bypassed my cache several times. Firefox 22.0, Windows XP. My Error Console shows nothing. WikEd does not appear in my edit window. Not today, not yesterday. Anybody know what is going on with this? — Maile (talk) 11:55, 20 July 2013 (UTC)
Based on what you said above, I just did a Shift+Reload. I still don't have WikEd on my browser. Three days now. — Maile (talk) 21:29, 21 July 2013 (UTC)
if you see a tiny icon that looks like so: to the right of "Log out" at the top of the page, try to click it. peace - קיפודנחש (aka kipod) (talk) 23:22, 24 July 2013 (UTC)
Well, for goodness sakes! That took care of it. I never knew about that. Thanks for posting. — Maile (talk) 23:37, 24 July 2013 (UTC)
The first method in this section does not work : I always have wikEdUseWikEd set (really, by window.wikEdUseWikEd = wikEd.useWikEd) to undefined. I used
This is working. I think it is simpler (it can be shorted into window.wikEd && window.wikEd.useWikEd), but there is a problem for the 'compatibility for older customizations' because you never update this value when it changes. — LtrlG☎, 23:06, 30 July 2013 (UTC)
Thanks for bringing this up, I have updated that page and have added updating of wikEdUseWikEd to the code in version 0.9.119d. Cacycle (talk) 16:27, 7 October 2013 (UTC)
Bracket matching
It would be very nice to have bracket matching (especially for parser functions brackets).
I found this thread and tried the linked script but it didn't work.
Would it be much work to add bracket matching to wikEd?
Thanks. Britpoper (talk) 17:42, 9 August 2013 (UTC)
wikEd's syntax highlighting already marks wrong brackets for wikicode. It is actually not possible to have a general bracket matching because excluded passages (e.g. comments, strings, regular expressions...) will differ between target languages. Cacycle (talk) 12:49, 7 October 2013 (UTC)
Wikidata links to items and properties
Would it be possible to add two buttons to the toolbar. The first symbol adds brackets to an internal link. On Wikidata most people use a template to link to items and properties, which displays the number and the label for the link. The two links look like this {{q|123}} for an item and {{p|123}} for a property The two buttons should convert "Q123" into "{{Q|123}}" and "P123" into "{{P|123}}". Thanks a lot and keep up the excellent work. --Tobias1984 (talk) 07:23, 30 August 2013 (UTC)
Steps to reproduce: Having wikEd loaded on pages that are taken over by mw:Extension:CodeEditor has undesired results. The error console messages above are caused by toggling wikEd off and on and syntax highlighting off and on and CodeEditor off and on. The consensus on IRC and Bugzilla seems to be that wikEd shouldn't load on any page that CodeEditor loads on (.js .css and Module:) Technical 13 (talk) 19:05, 8 September 2013 (UTC)
Thanks, I have made wikEd compatible with CodeEditor in wikEd 0.9.119c. As long as the CodeEditor is turned off during page load, both can actually co-exist - just disable one before enabling the other. To turn off the CodeEditor during page load, un-click its [/*] button and reload or, alternatively, turn the CodeEditor off and click the wikEd logo (with an error message) on top of the page to activate wikEd. Also, I have fixed the JSON error.
Thanks! I have updated all links to the German translation to your translation. Cacycle (talk) 20:38, 15 October 2013 (UTC)
use locally wikicode Image tag
Is it possible that "Add Image" button use "language specific wiki code" instead of "Image"? and use locally "thumb" keyword? שמוליק (talk) 22:18, 31 October 2013 (UTC)
As far as I an tell, wikEd's Image button adds translated code. I have also tested this with the wikEd gadget on the Hebrew Wikipedia and it works for me. Please could you give some more details (e.g. by filling out a bug report - simply Ctrl-push the )? Thanks, Cacycle (talk) 14:09, 20 November 2013 (UTC)
Wiked personalization
Hello,
I want to personalize WikEd to do just syntaxhighlight. My script is here. I deleted WikEd toolbar but the problem is that when I click to save button my changes are not saved. Can you please help to detect the cause?. Thanks. Rabah201130 (talk) 14:24, 1 November 2013 (UTC)
I have foud the problem. Rabah201130 (talk) 13:21, 2 November 2013 (UTC)
You may want to try Dot's syntax highlighter instead. It only colors the background, but it does it in real time, while you are typing. --V111P (talk) 00:10, 3 November 2013 (UTC)
Whitespace stripped when copy-pasting in Firefox
Happens in Firefox 25, here's how to reproduce it:
Press Ctrl-A, Ctrl-C, Ctrl-V (select all, copy, paste)
The contents of the article should be the same as before, but a click on the Changes button shows that repeated whitespace (e.g. in the infobox) has been stripped
This works fine in Chrome 30.0.1599.101, i.e. the text remains unchanged. My guess is that this is a bug in Firefox 25, I don't remember encountering the same problem in the earlier versions. GregorB (talk) 21:15, 9 November 2013 (UTC)
Sadly, unchanged in Firefox 25.0.1. GregorB (talk) 00:32, 16 November 2013 (UTC)
I have fixed this in wikEd 0.9.121. Thanks for reporting. Cacycle (talk) 13:49, 20 November 2013 (UTC)
Works fine in 0.9.121 G, thanks! GregorB (talk) 17:17, 20 November 2013 (UTC)
Resolved bug
Hi,
It seems that the bug 587461 is resolved. So maybe we could retire it from the list. NB: it seems that we can't vote for the Webkit's bug (nor for the Chromium's bug?). Automatik (talk) 20:10, 5 December 2013 (UTC)
It seems to have landed in Firefox 26, when I checked with Firefox 24 or 25, I think it was still buggy. Thanks for bringing this up, I will remove it from the header box. On the Chromium bug tracker you have to be logged in and it is called "starring" instead of "voting". Cacycle (talk) 16:38, 16 December 2013 (UTC)
Updated Traditional Chinese translation
Hi, I noticed the Traditional Chinese translation hasn't seen an update in a while, so I've put up an updated one at User:Liflon/wikEd_international_zh-hant.js. Thanks. Liflon 14:20, 14 December 2013 (UTC)
Cool, thanks a lot! I have updated the documentation and the program (wikEd 0.9.122a). Cacycle (talk) 00:12, 15 December 2013 (UTC)
"Replace all" is case-insensitive and ignores the case-sensitive button
Fixed in 0.9.122c, please update with Shift-Reload. Thanks, for reporting, Cacycle (talk) 16:26, 16 December 2013 (UTC)
wikEd for Ukrainian (and Russian language)
I installed "wikEd" to the browser Mozilla Firefox v.27 (by dint of "Greasespot"), editing articles in Ukrainian (and Russian) Wikipedia. But I work so hard - English interface. Help me please. I am from city Kiev (Ukraine). Regards --Krupski Oleg (talk) 22:46, 22 December 2013 (UTC)
Unfortunately, we do not yet have an Ukrainian translation. Please see User:Cacycle/wikEd_international for how to create one - maybe you know somebody who could do that? Cacycle (talk) 18:20, 1 January 2014 (UTC)
WikEd in French
I use wikED on wikipedia and wikibooks in french. All the words are underlined in red and when I right click, English words are available for correction. How to configure Wiked for spelling on French. Thank you in advance. Gtaf (talk) 02:10, 5 January 2014 (UTC)
Hi Gtaf, spell checking is done by the browser itself, not by wikEd or a web page. You might have to install a French-specific dictionary add-on. Good luck, Cacycle (talk) 19:14, 6 January 2014 (UTC)
Thanks Cacycle. It's changed.
Hello Cacycle, Gtaf has smiled at you! Smiles promote WikiLove and hopefully this one has made your day better. Spread the WikiLove by smiling at someone else, whether it be someone you have had disagreements with in the past or a good friend. Go on, smile! Cheers, and happy editing! Smile at others by adding {{subst:Smile}} to their talk page with a friendly message.
I am offering a prize for a fix to WikEd. Have posted the issue here [3]. The problem occur with google chrome latest version. Unable to copy and paste colors across with Firefox. Let me know if you are interested. Else will offer to a wider community. Great program by the way. Doc James(talk · contribs ·email) (if I write on your page reply on mine) 11:58, 30 January 2014 (UTC)
Another issue is that WikEd does not work well with the cite tool in the top of the edit box. An extra space occurs after you insert a citation. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:09, 30 January 2014 (UTC)
Any word on this yet? Doc James (talk · contribs · email) (if I write on your page reply on mine) 18:02, 24 February 2014 (UTC)
This is actually an already known bug in Chrome, please see Chrome bug 318925. It is not specific to wikEd, it also affects CodeEditor and VisualEditor. Please feel free to comment on their bug tracker or "star" that bug. Cacycle (talk) 14:59, 3 March 2014 (UTC)
So how to fix it? I am offering a $200 award. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:19, 5 March 2014 (UTC)
WikEd conflicts with code editor
Note: Ctrl-click on the wikEd logo does not seem to do anything in this case.
wikEd version - enabled via Preferences, so assumed to be latest
Browser: Pentadactyl hg6978 (created 2013/12/20 00:00:04) running on: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0
OS: Linux Mint 13 Maya, Linux 3.2.0-23-generic i686 GNU/Linux
Skin: Vector default, custom CSS disabled
No custom JS
I have a lot of gadgets enabled. If there are any specific ones that might cause this interference, I can try disabling them.
This is actually a problem with the signaling mechanism of CodeEditor, please see bug 62250. Please see the bug report below for more details. Cacycle (talk) 10:16, 5 March 2014 (UTC)
wikEd bug report: Edit box doesn't appear on CSS pages
Date: 2014-02-04 20:22:16 UTC
wikEd version: 0.9.122c G (December 16, 2013)
Browser: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36 (Win32)
Browser: Mozilla/5.0 (Windows NT 6.1; rv:26.0) Gecko/20100101 Firefox/26.0 (Win32)
Browser: Mozilla/5.0 (Windows NT 6.2; rv:26.0) Gecko/20100101 Firefox/26.0 (Win32)
Error console: Nothing of note. (event.returnValue is deprecated. Please use the standard event.preventDefault() instead.)
Problem description: I have no edit text box on my custom CSS pages. It appears briefly as the page loads, but then disappears. This is not just a Chrome problem, as I also tried in Firefox 26. I also was sure to disable adblock.
Oddly enough, the problem goes away after I activate the JS preview and then Ctrl-F5 on the page. (Ctrl-F5 alone does not fix the problem.)
Steps to reproduce: Open a custom CSS page while WikEd is enabled.
I confirm the problem. Also when we modify .js pages and pages in module name space. Hunsu (talk) 11:20, 8 February 2014 (UTC)
Cacycle might know but did not yet make use of: There is a rather new wgPageContentModel which tells that a page is css or javascript. Iff it is wikitext wikEd should start working, otherwise quit. See (in German) de:Wikipedia:Technik/MediaWiki #Content Model. Greetings --PerfektesChaos (talk) 20:37, 11 February 2014 (UTC)
This is actually a problem with the signaling mechanism of CodeEditor, please see bug 62250. wikEd already uses wgPageContentModel, but in the absence of a conflicting editor, wikEd can handle css and js pages just fine. Cacycle (talk) 10:14, 5 March 2014 (UTC)
How does WikEd detect redlinks?
Thank you for adding the redlink display feature. It is very helpful. Damn nice addition to WikEd functionality.
By the way, I'm working on a script in which I need to detect redlinks.
How do you do it in WikEd?
I look forward to your reply. The Transhumanist 03:50, 9 February 2014 (UTC)
You may take a look at the functions wikEd.LinkInfoCall and wikEd.LinkInfoHandler. Hunsu (talk) 10:44, 9 February 2014 (UTC)
Yep. These functions collect all links and make an AJAX API call. Cacycle (talk) 09:15, 5 March 2014 (UTC)
wikiEd conflicts with new WikiEditor interface
Debug info
Date: 2014-02-22 14:26:12 UTC
wikEd version: 0.9.122c G (December 16, 2013)
Browser: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Win32)
Error console: ____ (Firefox: Tools → Web Developer → Error console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
Problem description: ____ (Please be as specific as possible about what is wrong, including when it happens, what happens, what is broken, and what still works)
Steps to reproduce: ____ (Please include what happens at each step. Your problems cannot be fixed without reproducing them first!)
Current WikiEditor interface without wikiEd
Please see the actual wikiEd footer. You see that it conflicts with already existing layout, I mean breaking the copywarn text and chopping the background gray panel. This layout conflict is uncomfortable to me (and some others). Here's a mockup how it should look. What do you think about it? --Rezonansowy (talk • contribs) 14:51, 22 February 2014 (UTC)
@Cacycle: You're the main dev, could take a look a this please? --Rezonansowy (talk • contribs) 11:21, 24 February 2014 (UTC)
Error console: [Exception... "The operation is insecure." code: "18" nsresult: "0x80530012 (SecurityError)" location: "<unknown>"]
Problem description: When switching to Edit mode, the textarea is empty, the editor toolbar doesn't appear and the WikEd icon (upper right corner) is covered with a red cross. The Title icon's attribute contains Loading error - wikEd 0.9.122c GM (December 16, 2013) Click to disable
Steps to reproduce: With Firefox Aurora 29.0a2 (2014-02-22), any MediaWiki edition page. This problem doesn't appear with Chromium (ver. 32.0.1700.107) on the same machine. — Preceding unsigned comment added by Benoitb (talk • contribs) 14:38, 25 February 2014 (UTC)
This has been fixed in wikEd version 0.9.123. Thanks for reporting. Cacycle (talk) 19:56, 4 March 2014 (UTC)
There are links to 13 archives near the top of this page. But another archive would be good, I agree. this shows that Cacycle has been manually archiving the page and adding an index. Anyone could set up automatic archiving by one of the common bots and add a search field, as has been requested in a thread above, provided they're familiar with the auto-archivers. I could give it a shot, but it would take me a while to figure out how to get right (so that the old and new archives were compatible...). Any volunteers? Any objection, Cacycle? --Elvey (talk) 23:37, 27 March 2014 (UTC)
Since this page doubles as a bug tracking system, I prefer to archive the fixed issues manually from time to time and to keep the open issues here. Cacycle (talk) 21:36, 28 March 2014 (UTC)
Ok. I'm going to add a search field; feel free to improve/revert...--Elvey (talk) 06:14, 1 April 2014 (UTC)
I added a search box to make searching easier. --Elvey (talk) 15:47, 6 May 2014 (UTC)
What it looks like
What it should look like
fullscreen mode which is a persisting setting. Cacycle (talk) 07:03, 6 May 2011 (UTC)
button for unexpected collateral damage. Always use the smallest possible selection. Keep in mind that the applied rules are very simple. Only the Unicode character fixing is completely safe. Cacycle (talk) 21:25, 21 April 2013 (UTC)
)?
button above edit area inactive)?
button inactive)?![[REF, TEMPL]](//upload.wikimedia.org/wikipedia/commons/0/0b/WikEd_ref_hide.png)
active as well as inactive)?
![[REF, TEMPL]](/wiki/File:WikEd_ref_hide.png){kind=small}
to the right of "Log out" at the top of the page, try to click it. peace - קיפודנחש (aka kipod) (talk) 23:22, 24 July 2013 (UTC)
adds translated code. I have also tested this with the wikEd gadget on the Hebrew Wikipedia and it works for me. Please could you give some more details (e.g. by filling out a bug report - simply Ctrl-push the 
Resolved
