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. |
My config -
Steps -
Actual wiki code:
| * Bullet 1 * Bullet 2
Required wiki code:
| * Bullet 1 * Bullet 2
Tom.ngo 15:49, 22 September 2007 (UTC)
Hitting the WikEd preview (the one with the icon and that loads below the edit section) and later the Standard Preview button will force a Return on the previewed page.
That's bad when you edit a page with a Submit form or an
inputbox. When you preview by hitting the preview icon and later hit the standard preview button, it will submit the form and you will be taken to the submit destination page. God bless it only works in Firefox so browsing back won't lose the data ;) Either fix it or remove the standard preview when WikEd is used, cos the WikEd preview feels much better. --
Subfader (
talk)
20:21, 16 March 2008 (UTC)
As my browser (Firefox 2.0.0.14) is loading this diff, it highlights (in red) the newly added text. But as the page finishes loading, the highlighting disappears. Does this happen with anyone else? -- zenohockey ( talk) 21:35, 31 May 2008 (UTC)
Version is 0.9.62g. See this diff. Apparently it's related to this. GregorB ( talk) 19:44, 13 June 2008 (UTC)
My config:
When copying rich text with many paragraphs left-indent, wikEd adds a <blockquote> section.
But <blockquote> needs the <p> mark to break paragraphs. And itallic or bold applies only to the first paragraph instead of the whole section.
The solution would be not to replace <p> marks with <br> marks within <blockquote>.
Another solution would be to use the Poem extension (it adds <br> after each end of line).
To get the left-indent, add this code to poem.php:
// Add a margin-left "style" attribute. if( isset( $attribs['style'] ) ) { $attribs['style'] = 'margin-left: 40px; ' . $attribs['style']; } else { $attribs['style'] = 'margin-left: 40px;'; }
If you put a '' before the <poem> mark (as wikEd acutally does with blockquote), then the whole quote is itallic. For instance:
''<poem> Au clair de la lune, Mon ami Pierrot: Prête-moi ta plume, pour écrire un mot. </poem>
would give:
Au clair de la lune,
Mon ami Pierrot:
Prête-moi ta plume,
pour écrire un mot.
Gabuzo ( talk) 11:16, 22 July 2008 (UTC)
Could you add syntax highlighting for .js & .css pages in edit mode? The code can be found on one of wikipedias common js pages. Thanks, ManishEarth Talk 15:13, 14 August 2008 (UTC)
When will WikEd's find/replace feature support regular expressions? I really need to be able to add new lines in replaces). (And I don't have access to a computer upon which I can load AWB. :( The Transhumanist 19:05, 18 November 2008 (UTC)
My custom settings used for wikEd do not work anymore after the latest wikEd update, even after a hard refresh. Gary King ( talk) 15:08, 17 November 2008 (UTC)
I think I have fixed it and I am in the process of uploading the new version 0.9.67d. It happened only with the ref hide button pushed. Cacycle ( talk) 03:31, 20 November 2008 (UTC)
Hi. I use wikiEd 0.9.67d G with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3. When I click on the edit this page (while editing Kīlauea article) button and then click on Changes button, there are mutliple removed spaces from the beginning of the line between paragraphs and in infobox. In error console are a few tens of errors
and one
-- Tomaxer ( talk) 22:00, 22 November 2008 (UTC)
Today I had time to evaluate the gadget version of wikiEd.
The good news is that it implements highlighting of the embedded citations that make extensively referenced articles very difficult to read in edit mode. I made this suggestion unnoticed last year on an unrelated talk page, so thank you.
The bad news is that wikiEd doesn't solve my fundamental time-wasting problem of constantly reloading a rendered preview so that I can see what I get.
I read the wikiEd help page and the link to What you see is Wiki - Questioning WYSIWYG in the Internet Age (PDF) by Christoph Sauer. He has many good points, but the central notion of deprecating WYSIWYG is not one of them. While formatting may not be durable, it matters locally. It's also an unnecessary dichotomy. WYSIWYG Corel WordPerfect still has the Reveal Codes feature. Why accept less (unless one is a monopoly victim of MS Word)?
The inverse of Reveal Codes is code folding requested above at #Feature request: code folding – but too difficult to implement for wikiEd.
So let's plan beyond wikiEd to the next editing tool – to what I (and many others it appears) really need for "concentrating on the content" in Sauer's words. I need to:
Milo 08:12, 23 November 2008 (UTC)
Hi! I love wikEd, the syntax markup makes it so much easier to edit text, especially with a lot of in-line refs. Unfortunately, I guess my computer is a bit too slow – when editing a big page with wikEd, the whole computer freezes for a long while. Therefore, I normally keep wikEd disabled, and enable it when I need it. However, every now and then, I forget to disable it, open up some big edit and there we go... sometimes I have to kill the browser. It would be so cool if you'd be able to make it scale better for big pages, but until then – would it be possible to have an option to always have wikEd disabled, unless explicitly enabled for a specific edit? Is this already possible? Thank you for this very useful tool. / skagedal ... 19:58, 26 November 2008 (UTC)
Greetings,
I want to use WikEd on a mediawiki installation that I have. I have installaed Gadgets on my wiki, however I am unclear on how to make the code for WikEd availabel on my site that users may select it as a Gadeget in their preferences. Can anyone offer me a little help here with the installation?? -- Shannara Fan ( talk) 02:35, 1 December 2008 (UTC)
I just installed WikEd today, and it seems to work great. I'm only wondering why there are no shortcut keys for the most common functions, such as wikilinks or bold. (At least they're not displayed in the tool tips.) I feel these are so useful for everyone that they should be there by default, especially since it is more ergonomic while your typing than having to navigate (with the touch pad) to the button, and then back to the place you were working at. For that reason, I would also like to have shortcuts for the increase headline and related buttons and for #R, or, come to think of it, for almost all of the in-text buttons. if you feel that not everybody would appreciate it, maybe there is a way I can add shortcuts for myself?
PS: This is strange: Just now I tried alt-shift-o, and it inserted a wikilink. Then I clicked the [T] button, and it selected the whole text (which is not what I would expect from the tooltip), and after that, alt-shift-o does the same. (I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4.) — Sebastian 20:50, 3 December 2008 (UTC)
// define accesskeys for edit buttons (wikEd button number: [key string, JS key code]) var wikEdButtonKey = { 26: ['b', 66], // wikify 32: ['g', 71] // scrolltoedit };
acceskey="
to see the current accesskeys. wikEd uses b, g, and o (the only free ones when I implemented this).
Cacycle (
talk)
17:21, 4 December 2008 (UTC)
I have a date delinking script: User:Lightmouse/monobook.js/script.js. It has the following options:
I would like to turn it into a WikEdit plugin, but it is outside my current skills. Would anyone be willing to help me with the coding? Lightmouse ( talk) 10:12, 4 December 2008 (UTC)
I just ran into an unclosed ref tag, and because the syntax seemed correct, I asked at HD. The edit diff is here. I had thought such an important difference would be obvious thanks to the syntax coloring, but it seems to me that this looks normal. Maybe it's that you're using different shades of bluish-gray to express different things? — Sebastian 04:07, 5 December 2008 (UTC)
Hello, my WikiEd does not seem to be working. I was about to send a warning message user:72.148.61.160 for vandalizing this page, however, the WikEd just seems to stop at "data loaded..." with no message added. What should I do? Prowikipedians ( talk) 03:15, 7 December 2008 (UTC)
Updated Bug Report by Prowikipedians ( talk) 05:47, 7 December 2008 (UTC)
Version: WikiEd 0.9.67d G (November 19th, 2008) Safari Version 3.2.1 (525.27.1) Cleared all cache as a user suggested, but nothing worked. All browsers (Mozilla Firefox, Internet Explorers, Safari) all have shockwave/flash installed. No user scripts installed on my monobook.js page Windows XP (and Ubuntu 8.10) Cannot use the warn/arv/etc buttons. 1) Clicked "warn" on user talk page. 2) Only shows "data loaded..." and freezes there. Nothing. Just freezes there.
Config:
WikED version: 0.9.67d
Browser: Firefox 3.0.4
Addons installed: Adblock, Flashgot, Greasemonkey, Noscript, Stylish
Using Monaco.js, the only script installed is the install for wikED
Problem encountered:
On uploading an image with WikED enabled, if no comment is inserted in the Summary field, WikED automatically sends a single space as the comment. This results in the parentheses appearing in the recent changes, enclosing a single space.
I tested this with 3 image uploads, and produced the following:
Uploaded image and added a comment in the Summary produced: Username uploaded "Image:filename.png" (comment)
Uploaded image with no comment in the Summary produced: Username uploaded "Image:filename.png" ( )
Disabled WikED
Uploaded image with no comment in the Summary produced: Username uploaded "Image:filename.png"
To make things interesting, with WikED enabled, I went into the upload image window, then clicked on "toggle to standard edit window". This produced the expected standard edit window and put a space followed by a carriage return in the window!
I realize that this is a minor thing, but one of the sysops brought it to my attention, so I thought I'd pass it along. The community involved is wiki.ffxiclopedia.org
Thanks! Ffxiclopedia Catrinm ( talk) 04:52, 10 December 2008 (UTC)
Using the gadget version (0.9.67d G). Reproduce open page (like James Bond (character)) with the HTMLarea and syntax highlighting enabled, then disabled syntax highlighting (leave HTMLarea enabled). Click the diff and notice the leading whitespace is gone now. — Dispenser 19:11, 22 December 2008 (UTC)
wgServer + wgArticlePath
? Also the regexes at the end are shorter and might be a good inclusion for the fixes button. —
Dispenser
06:11, 29 December 2008 (UTC)function checkRegexp(text) {
window.status = "No error detected"
try {
if(text == '')
return 0
re = new RegExp(text)
if(''.match(re)){
window.status = "Empty string matches";
return 1
}
if(' \r\n\t'.match(re)){
window.status = "Matches white space";
return 1
}
return 0;
}catch(e){
window.status = "Compiling error"+e;
return 2;
}
}
// Line 133-134, Parser.php
$this->mExtLinkBracketedRegex = '/\[(\b(' . wfUrlProtocols() . ')'.
'[^][<>"\\x00-\\x20\\x7F]+) *([^\]\\x0a\\x0d]*?)\]/S';
If you choose serif (or is it sans?) in your preferences page wikied is still monospace. how can i change the font from monospace?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 latest version from wikipedia pref page
var wikEdFrameCSS = {}; wikEdFrameCSS['.wikEdFrameBody'] = 'background: #FFFFFF; margin: 0px; padding: 0.2em; overflow: -moz-scrollbars-vertical; overflow-x: auto; font-family: monospace;';
On User:Cacycle/wikEd.js, it says: "5. Optional: customize the program by adding user settings to your ''''' page". This should be monobook.js, no? / skagedal talk 15:31, 30 December 2008 (UTC)
xcen > de
I'm using wikEd via Greasemonkey on my local mediawiki. Each time I press the Save Page or Preview button when editing a page somebody inserts automatically a line containing xcen > de on the top of the edited page (the more I press the buttons the more lines will be inserted) Disabling wikEd by disabling greasemonkey, the standard Save or Preview buttons of Mediawiki work as expected: no unwanted lines are inserted ...
What's going on? Who inserts those unwanted lines and why? Probably you will see those lines on top of this page due this behaviour ... ;-)
i am in korean translation. while editing, for example, when i put a mouse on the
[[Image:filename|thumb|150px|explain]]
then popup shows "Imagefilename (ctrl-click)" i think "Image:filename" is right than "Imagefilename" check it please. and it would be nice that HighlightSyntax could be always being updated. -- Ilovesabbath ( talk) 19:48, 8 January 2009 (UTC)
How would I go about changing the colors used to highlight the text? That's a really nice program that you made!
WriterHound ( talk) 03:13, 14 January 2009 (UTC)
There is a bug, probably in the fixing of spaces before puncuation. I'm using the latest version of the program and the latest version of Firefox. When there is an image, it puts a space before ".jpg" or ".gif". It also puts a space before ".html" in external references. Example, see my recent edit to My 60 Memorable Games. Bubba73 (talk), 04:25, 14 January 2009 (UTC)
Hi, I've proposed a script I wrote as a potential Gadget at Wikipedia:Gadget/proposals#Add_the_.22Localize_Comments.22_script. As a Gadget writer, could you check it out when you have time and audit the script, and post your thoughts on whether it should be a Gadget or not? Thanks in advance! Gary King ( talk) 16:54, 16 January 2009 (UTC)
I'm using 0.9.68a on FF3 - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
I don't have any other JS tools in my monobook.js nor using Gadgets.
I've been using wikEd ever since I registered for wikipedia and it's a great tool. Only today did I learn that I could customize it so I read the manual and made a few changes.
Most of the tweaks in my monobook.js worked, but 2 of them didn't:
var wikEdButtonsOnTop = false; var wikEdButtonBarFindHidden = true;
The toolbars are still above the edit box and the find bar isn't hidden.
Is this a bug or am I doing something wrong?
Thanks. This is a really useful tool! -- Armchair info guy ( talk) 02:39, 19 January 2009 (UTC)
Me again. I'm wondering if wikEd can automatically scroll to the preview/changes box when I press either button. I know I can do it with the separate buttons on the tooblar at the right side of the screen, but it'd be more convenient to do so automatically.
Also, it'd be great if the browser focus switches out of the edit box and onto the page when I press preview/changes, so that when I hit spacebar it's a browser page down scroll instead of adding an undesired text space. Probably been dozens of times I've had this happen and then I have to click outside the edit box to change focus.
Thanks again. -- Armchair info guy ( talk) 02:52, 19 January 2009 (UTC)
My 3rd topic in a row. I also added AWB's RegExp button (one of the monobook.js var additions that worked properly, in reference to my first topic). I tried it out and it capitalized every word beginning with "th" - the, them, they, etc. Obviously a bug since most shouldn't be. I assumed it was a bug with RegExp and filed a bug over there but one of them replied that the problem was likely in wikEd.
I have no idea one way or the other. Just reporting it here so you guys can get to the bottom of it. Thanks! -- Armchair info guy ( talk) 04:08, 19 January 2009 (UTC)
Perhaps this isn't a bug and I'm doing something wrong or my system isn't fully supported, but I can't discern that from the documentation.
I'm trying to get copy from Word to MediaWiki with formatting intact. I'm trying an extremely minimal test case: in the Word document are three words, each on their own line. One is normal, one is bold, and one is italic. When I copy/paste into WikiEd, I get the three words with no formatting. When I click the [W] button, the text I just pasted is selected but otherwise nothing happens.
Am I missing a step, is my software combination unsupported, or did I actually find a bug? —Preceding unsigned comment added by 209.240.239.188 ( talk) 17:20, 19 January 2009 (UTC)
I also found formatting - at least the basics that I've tested - are preserved in Safari. I suspect the problem has more to do with FF's handling of the OS X clipboard than anything WikiEd is doing. If you can point me in the right general direction where clipboard handling is in the code (and how to run a local copy instead of sourcing it off wikipedia), I'd be willing to look for a Firefox workaround. —Preceding unsigned comment added by 209.240.239.188 ( talk) 15:29, 20 January 2009 (UTC)
I have a suggestion for a new feature. Could you program wikEd to repair spacing and punctuation placement at references? Some examples below:
It should read:
See: Manual of Style.
This feature could detect certain end of sentence punctuation . ? ! and place it before the reference(s), then remove any extra space(s). It would also remove extra spaces before references in the middle of a sentence; none before and only one space after the reference. One space would be preserved or added as necessary at the end of each reference. Duplicate punctuation at the end of a reference would be removed.
Thank you for your consideration and nice work here. ~ All is One ~ ( talk) 00:52, 20 January 2009 (UTC)
Will this WYSIWYG editor allow for an easy method of creating tables? I'm trying to find an editor for my wiki that will help users create tables easier than the standard wiki markup. Thanks! -- Brandon ( talk) 16:04, 21 January 2009 (UTC)
heading | heading |
---|---|
cell | cell |
cell | cell |
var wikEdShowTableModeButton = true;
on your monobook.js page...
Cacycle (
talk)
14:43, 22 January 2009 (UTC)Config:
WikED version: 0.9.68a
Browser: Firefox 3.0.4
Addons installed: Adblock, Flashgot, Greasemonkey, Noscript, Stylish
Using Monaco.js
Recently, wiki.ffxiclopedia.org installed a new extension "EditEnhancements" from MediaWiki. The expected result is that the "Save", "Preview" etc. buttons now appear on a bar which sits at the bottom of the view area, and scrolls up and down as the view area changes so as to always sit at the bottom of the view area. The Special:Version lists this as: EditEnhancements (Version 1.0) Christian Williams and Maciej Brencz
With WikEd enabled, it doesn't work as expected. The result is that directly below the edit window I only have the "save" button. I have to drop out of full page edit mode to find the preview button which, along with several other bits and pieces, are now in a fixed position further down the page. There is all sorts of unexpected behaviour from this. As one example, on the FFXI site, the space below the "save, preview, changes" buttons is used for a table containing some commonly used wiki markup shortcuts. Closing the preview pane from the WikEd button simply toggles this on and off and doesn't affect the prefiew pane at all! With WikEd enabled, "save" button remains in place while the "preview" and "Changes" buttons are moved to below that table, so I have to hit ctrl-end (end of page) to get to them!
A preview of this can be achieved on this page by editing the text, then scrolling below the edit box. Imagine the "preview" and "Changes" buttons now appear below the line that starts "Once you click the Save button..." and the "Do not copy text from other websites without ...." line has moved down there with them, leaving the "Copy and Paste" table in place. I can provide screenshots if required, just let me know!
Thanks for your attention to this :) Ffxiclopedia Catrinm ( talk) 08:14, 22 January 2009 (UTC)
var wikEdNoRearrange = true;
to your monobook.js page.
Cacycle (
talk)
02:45, 26 January 2009 (UTC)steps to reproduce:
using
Matthias M. ( talk) 18:26, 28 January 2009 (UTC)
Hi, I work on Wikisource fr and I would realy appreciate wikEd to work properly in proofreading mode ( for example). The edit window goes to the bottom of the page instead of next to the image, where the textarea normally stands. With wikEd 0.9.69a, on Firefox 3.0.5. —Preceding unsigned comment added by Aroche ( talk • contribs) 12:52, 31 January 2009 (UTC)
When I use button for fix Unicode in it.wiki, it doesn't works anymore and now appears a window: Uknown function wikEdFixUnicode. Moreover, in some pages some wikEd buttons don't appear. What can be the problem? I don't understand. Script is called here, and these problems started I think not more than few weeks ago. Thank you Lenore ( talk) 14:58, 1 February 2009 (UTC)
Hello, Cacycle. Since some months I have a problem, if i upload an image using your script on the upload page with my firefox.
Always the following lines apear on the upload page, but not until storing of the image.
Vertrauensw.: Händlerzuverl.: Datenschutz: Jugendschutz:
The lines not apear in the editing box, but during the preview (of your script) in the lower part of the page and after the storing. I would be glad, if you could find a solution. Greetings -- Tlustulimu ( talk) 17:04, 2 February 2009 (UTC)
I'm always replacing casual use of the ASCII '-' (hyphen-minus) with the correct typesetting mark, typically em-dash but sometimes em-dash and occasionally the minus character. These show up as different in a proportional font like the normal web page, but all look the same in the edit window!
I think that simply coloring them differently would do the trick. For example, if regular text is black, make the em-dash blue, the en-dash green, and the minus red. To serve as a key of sorts, color-code the "insert" hyperlinks to match.
— Długosz ( talk) 17:42, 12 February 2009 (UTC)
P.S. Some time ago I tried the "fix dashes" button, but it didn't do anything useful. That was years ago, so I'll try it again.
On this page (permanent link to version), the "fix dashes" button does not handle the first paragraph:
The technological singularity is a theoretical future point of unprecedented technological progress -- typically associated with advancements in computer hardware or the ability of machines to improve themselves using artificial intelligence.
It changes this to an EN-dash and leaves the spaces around it. The correct fix is an EM-dash and delete the spaces.
On this page (permanent link to version), select the paragraph:
There has also been speculation that a large tsunami in the Mediterranean Sea caused by the Thera eruption dated ca. 1630-1600 BC geologically…
The fix-dashes button did nothing. I expected it to change the hyphen-minus in the range "1630-1600 BC" to an EN-dash.
On editing this section (permanent link to version), the first paragraph contains a range and the second contains a parentetical thought. I expected the "fix dashes" button to change the first to an EN-dash and the second to EM-dashes without surrounding whitespace. It did nothing.
I tried to load typos in it.wiki from this page, but doesn't work, button doesn't appear. The function in it.wiki is enabled from this page (at the bottom). Thank you for support Lenore ( talk) 19:31, 13 February 2009 (UTC)
When attempting to edit any article, wikEd displays a red "X" icon in the top right corner ("Loading error"). Edit window is empty.
WikEd version is 0.9.73, user agent is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
, JavaScript console message is Uncaught TypeError: Cannot call method 'charCodeAt' of undefined
http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript (line 8591)
, OS is Windows XP SP3. On the same machine Firefox 3.0.6 appears to works fine with wikEd 0.9.73.
GregorB (
talk)
13:03, 17 February 2009 (UTC)
Here's a way to reproduce it (Firefox 3.0.6):
BTW I really like this new feature. I wish there was a way to custom-render the nbsp character entity in a user-friendlier way. Would this be possible? GregorB ( talk) 21:29, 17 February 2009 (UTC)
Hi Cacycle. I saw in Upper Sorbian version wikEd_international_hsb.js that you added the following strings:
and
But those 4 strings have already been part of the file. They are double now. Is it correct? Regards, --
Michalwiki (
talk)
18:55, 23 February 2009 (UTC)
Hi, long time no comment. Kudos! wikEd runs fast under the new Safari beta (so far). Very quick load; will report any anomalies.
- - -
Schweiwikist (
talk)
08:07, 25 February 2009 (UTC)
Apparently it caches the script! Clicking to add this reply, there was zero load-time: all the tools are ready immediately. What a difference. Another thing I wanted to mention is that this is running on a Titanium PBG4 @ 1MHz with only 512MB RAM, and OS X Tiger. Will wikEd move toward supporting the resizeable edit box? ;) - - - Schweiwikist ( talk) 14:36, 25 February 2009 (UTC)
Hi, I can report a small rendering/interface glitch for the current version when running inside Safari 4 public beta (4528.16). This occurred under Leopard (10.5.6 with the security update, of course) on a MacBook (unibody) and also under Tiger (10.4.11 with the current Java version) on a Titanium Powerbook. Specifically, when going into edit mode while wikEd is enabled, or toggling wikEd (master switch by my live clock) while in edit mode, the edit summary text box/interface "drops out" (i.e., hides) until and unless the window is resized (just by a single pixel does it, so it redraws the contents) or fullscreen mode is invoked/uninvoked (producing the same redrawing and unhiding). This doesn't happen in Firefox. - - - Schweiwikist ( talk) 01:30, 28 February 2009 (UTC)
i found an annoying bug with wikiEd, if i edit a page, then i disable the gadget and reenable it, all the changes in the edit field made after this will not be saved or previewed.
here are the exact steps:
the wikiEd version is 0.9.74 G (February 21, 2009) and i'm using Firefox 3.0.6: Mozilla/5.0 (Windows; U; Windows NT 6.0; ro; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729) i have this problem both on english and romanian wikipedia. Dany 123 ( talk) 12:57, 28 February 2009 (UTC)
In diff pages wiked makes links lickable right? But there's a bug for which external links work wrong (see for example this) Lenore ( talk) 19:21, 28 February 2009 (UTC)
I would like to add a text marker to a custom button. How can I achieve this? —Preceding unsigned comment added by 91.50.191.41 ( talk) 12:22, 1 March 2009 (UTC)
It takes many seconds before I can make a simple spelling correction. Disabling. DCDuring ( talk) 17:54, 5 March 2009 (UTC)
Well, Firefox just got incremented to 3.0.7, and your recent update broke. Here's my info:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
The quad-pointers pointer that used-to-appear when hovering over the resize square no longer appears, and now the best way to describe the response is that the resizer is slow and slippery: edit-box refresh is very slow, and once the pointer leaves the grab box (and crosses another interface element), refresh halts. Very weird. Obviously Firefox made some major change under the hood, because it used to work just fine. More info once I test on the other Mac, where we haven't updated Firefox. - - - Schweiwikist ( talk) 19:15, 7 March 2009 (UTC)
UPDATE: Found source for "downgrading" back to FF 3.0.6. Will report results shortly. Schweiwikist ( talk) 19:28, 7 March 2009 (UTC)
UPDATE: Same problem with FF 3.0.6 running, so it's not FF's problem. Apparently this interface bug might have to do with the initial edit box row/column setting in a logged-in user's prefs. Mine are recently set to 20 rows, thanks to your widget. Only enlarging the edit box (down-and/or-right) exhibits this bug. Up and/or left is fine (i.e., into the edit area). Will test ASAP with higher row setting. Schweiwikist ( talk) 19:50, 7 March 2009 (UTC)
UPDATE: Nope, doesn't matter what the user prefs are (sorry, my rows setting was 12, not 20!). Confirming the bug in the resize grip is present under FF. Safari, you get a quad pointer which responds fine in all directions. Schweiwikist ( talk) 19:59, 7 March 2009 (UTC)
Why did you remove the feature that puts the tabs at the top of the page that lets me easily put CSD, AFD, or other tags on the page? That's all I used WikED for, and now it's gone! No warning, no changelogs, no nuthin. Vistro ( talk) 23:42, 7 March 2009 (UTC)
I have some questions and problems with the Fix tools. Why does Fix HTML or Fix All sometimes insert (-- and --) into pages? Also, Fix Caps seems to act on the entire page instead of just the paragraph as the help page describes. Fix Caps and Fix All often break the behavior of templates such as {{infobox}} by capitalizing the parameters. — Ost ( talk) 15:51, 9 March 2009 (UTC)
What is the right way of removing some of the default buttons (to make the page less cluttered and faster to load)? Using a custom wikEdButtonBar is not reliable because the script expects the id of some buttons to exist, and dies if the getElementById call returns null. -- Tgr ( talk) 20:13, 10 March 2009 (UTC)
WikiED, along with other extra editing tools, causes the edit page to lag, at least for me it does.
-Axmann8 (Talk) 22:25, 12 March 2009 (UTC)
(Moved here from User_talk:Cacycle/wikEd_customization)
How can I remove edit buttons (as I do not need them)? Loading of buttons is very very slow.... I use only the syntax-highlight function which is very useful. 88.209.142.83 ( talk) 21:06, 13 March 2009 (UTC)
It seems the problem is gone with one of my Firefox add-ons (I try to narrow it to one add-on with enabling them one-by-one) 88.209.143.46 ( talk) 11:24, 15 March 2009 (UTC)
I enabled all of the add-ons in Firefox and WikEd works well! Maybe you did something beneficial during the last couple of days? 88.209.143.46 ( talk) 11:36, 15 March 2009 (UTC)
Strange things again... For a while all worked well, but today I noticed that WikEd loads again the buttons at every page I open for editing.
I disabled all the Firefox add-ons, then enabled them all, and everything goes well again with WikEd (I suppose: for a while). Maybe yesterday it was OK, I don't remember exactly, so 1 or 2 days passed without this failure.
What can I do now to find the cause? 88.209.147.7 ( talk) 18:38, 17 March 2009 (UTC)
-- JonnyIncognito ( talk) 05:00, 18 March 2009 (UTC)
IE6 throws "Expected identifier, string or number" on WikEd.js line 326 because of the last line of the above object ends with a comma. (That is only allowed for arrays and not for objects according to ECMAScript, though every other browser seems to understand it.) -- Tgr ( talk) 09:20, 26 March 2009 (UTC)
FF3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7), wikEd 0.9.75b G. Steps to reproduce:
A related, more peculiar bug:
-- Tgr ( talk) 09:27, 26 March 2009 (UTC)
I'm using a costum skin on my Wiki and the Button for turning wikEd on and off does not appear. What needs to be in the skin to display the button? -- DaSch ( talk) 22:51, 31 March 2009 (UTC)
I just want to know how to move the enable/disable button up or down the page. It's currently in a non-aesthetic place in the GuMaxDD skin that puts it below the navigation toolbar and above the edit toolbar. —Preceding unsigned comment added by 67.169.137.199 ( talk) 06:51, 1 April 2009 (UTC)
The current Chinese translation of wikEd, User:Shibo77/wikEd international zh.js, is actually in Simplified Chinese. I have made a Traditional Chinese translation for wikEd. Please take a look at User:Quest for Truth/wikEd international zh-hant.js. -- Quest for Truth ( talk) 09:52, 16 April 2009 (UTC)
WikEd is checked in my preferences, but it's not showing up on my navbar as normal. There's no WikEd symbol at all I mean; it's not just the red X. Chrome is version 1.0.154.53, Windows XP, Modern skin. — Levi van Tine ( t – c) 14:11, 17 April 2009 (UTC).
There is extra code that lets the WikEd disabled by default so I can activate it later? HyperBroad ( talk) 20:03, 17 April 2009 (UTC)
Not resolved. I set it in my monobook.js. HyperBroad ( talk) 22:51, 17 April 2009 (UTC)
What I need is a command to leave the wikEd disabled as default so I can activate it by clicking the top of the page when I need it. I always clear the browser cache before closing it. HyperBroad ( talk) 16:32, 18 April 2009 (UTC)
Thanks! HyperBroad ( talk) 18:44, 18 April 2009 (UTC)
Why don't you add suppor for Internet Explorer. I beleive the codes for internet explorer has changed with the onset of IE8, and it is now up to the Standards. -- Tyw7 ( Talk ● Contributions) Leading Innovations >>> 17:46, 19 April 2009 (UTC)
First off all thank you for the great Extension (I use greasemonkey version).
The problem is that the "Toggle between lowercase, uppercase first, and uppercase" doesn't support non-English Alphabet characters, like German "ä,ü,ö" or the whole Cyrillic alphabet(my case). I thought, that it wasn't a big deal and tried to fix it by myself: I replaced all *"a-zA-Z"* strings in the source with *"a-zA-Zа-яА-Я"* and it worked... well halfway (or 2/3way to be precise) - It only works with words, that begins with upper case and if the word begins with a capital letter - it converts it to full-upper case, than to full lower case, but than the cycle breaks. It looks like this: "Арбуз" -> "АРБУЗ" -> "арбуз" -> stays lower case. What should I do?
Thanks. —
85.176.25.24 (
talk)
01:36, 22 April 2009 (UTC)
Using/enabling wiked breaks wikimedia's encrypted connection at Secure Wikipedia. Is there a solution? Smallman12q ( talk) 21:47, 22 April 2009 (UTC)
Source File: http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 3332
~ Itzjustdrama ? C 01:48, 25 April 2009 (UTC)
I don't know if this is a wikEd bug or not, but I occasionally get the quick find feature in Firefox when hitting the ' (straight single quotation mark) button. It comes and goes, but I cannot pinpoint the source or cause, but as far as I can tell it's only happened to me within editing a MediaWiki website with wikEd enable. For instance, I was just editing Wikinews and I kept getting this bug, but reporting here it is fine. I then went back to check Wikinews and it's not happening anymore. Thanks. Calebrw ( talk) 04:53, 27 April 2009 (UTC)
Edit summary hidden in Google Chrome Beta YayaY ( talk) 19:58, 1 May 2009 (UTC)
On http://de.wikipedia.org I recieve the following error using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10.
Fehler: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandEnabled]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame ::
http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript :: anonymous :: line 6223" data: no]
Quelldatei:
http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript
Zeile: 6223
Matthias M. ( talk) 13:28, 2 May 2009 (UTC)
Can WikEd be extended with more formatting options like fonttype and coulor? Columbus56 ( talk) 07:42, 5 May 2009 (UTC)
::Let's say, for example, hypothetically, that a user didn't know HTML... what would be required to change the font to Arial? --
King
Öomie
16:08, 13 August 2009 (UTC)
Can WikEd sort lists?
If not, would you add this incredibly useful feature?
Sorting lists manually is a real pain, and cutting/pasting them into 3rd-party sorters is very inconvenient.
The Transhumanist 18:50, 14 May 2009 (UTC)
The regular expression used in find and replace should always execute in multi-line mode. This would make it more useful. I can't think of any cases where it is useful to restrict ^
to matching only at the very beginning of the page. For example, this would simplify the replace-all of (^|\n)(.+)
→ $1* [[$2]]
to the more straight-forward ^(.+)
→ * [[$1]]
—
GregU (
talk)
05:50, 15 May 2009 (UTC)
What is the size limit for an article’s wikitext above which syntax highlighting doesn’t work? It’s definitely less than 32K, since Standard electrode potential (data page) is only 32,014 bytes, and it doesn’t work even when doing a section edit on the main section. Hgrosser ( talk) 13:32, 19 May 2009 (UTC)
The preceding note was on Firefox Windows, on Safar1 3.1.2 the limit is definitely greater, somewhere between 82 and 109 kilobytes as reported at the top of the preview Hgrosser ( talk) 21:35, 19 May 2009 (UTC)
A wiki I'm on uses special parser extension tags that WED whines about. Solutions?-- Ipatrol ( talk) 19:06, 23 May 2009 (UTC)
The way wikEd highlights the text changed suddenly. What happened? my name inc Ottoman project 00:19, 24 May 2009 (UTC)
This morning it worked fine, but now, after the update, it is different. I am unable to use wikEd in the default monospace font. When I have it enabled, i.e. letting it highlight things, it forces the sans-serif font, but I prefer the monospace. I would like this option. Also, the previous choices to highlight reference text were either gray background or gray words. Now it is gray background or gray words with superscript. I really hate the superscript so I'd rather have just the light colored words. Thanks, Reywas92 Talk 00:23, 24 May 2009 (UTC)
I'm somewhat new to wikiEd, and your page about costomization is very confusing. My concern is about the edit summary and save page region below the edit box. I significantly prefer the dafault Wikipedia format of having the save page/preview/changes buttons directly under the minor edit checkbox, which is directly under the edit summary box. I think that's dumb to have them all separate with the minor edit checkbox below the save page and the edit summary being way on the right. How can I customize to have the standard layout there? Thanks! Reywas92 Talk 00:27, 24 May 2009 (UTC)
Hello Cacycle,
I am a German Wikipedian, we are using directly the code from wikEd.js from your Page as a Gadget. I've seen that you've changed the display of the code in the Textarea. Personally I think the old code was much better, but thats not the main reason I am talking to u. At previously deleted Pages there is shown the deletion log in top of the textarea. With your code update, the deletion log is shown twice. (Compare e.g. [1] with activated Gadget). Could you please have a look at it please. Thank you -- Joschi90 ( talk) 01:00, 24 May 2009 (UTC)
I like it :) Matthewedwards : Chat 05:48, 24 May 2009 (UTC)
window.wikEdProgramVersion = window.wikEdProgramVersion || '0.9.79';
window.wikEdProgramDate = window.wikEdProgramDate || 'May 23, 2009';
Hello, there is a small glitch - one gets a Javascript error in line 845 when starting up in IE7 (tried with Vista). This happens before wikEd has a chance to shut itself down in the unsupported browser mode.
This fixed this for me:
diff -r cb639c56fc30 plwiki/sk/wiked.js
--- a/plwiki/sk/wiked.js Sun May 24 16:38:46 2009 +0200
+++ b/plwiki/sk/wiked.js Sun May 24 16:50:36 2009 +0200
@@ -841,7 +841,7 @@
67: ['g', 71], // scrolltoedit2
72: ['g', 71], // scrolltoedit3
74: ['g', 71], // scrolltoedit4
- 32: ['g', 71], // scrolltoedit, overwrites previous wikEd buttons for same key
+ 32: ['g', 71] // scrolltoedit, overwrites previous wikEd buttons for same key
});
}
« Saper // @talk » 14:53, 24 May 2009 (UTC)
How can I use the old syntax highlighting? The new version have a bug by editing references.-- Video2005 ( talk) 17:34, 24 May 2009 (UTC)
Thanks to WWGB for catching this. I logged in tonight and started doing my disam work. WWGB caught that for whatever reason (Ctrl-click)" is being added to my edits in random places. Here is an example. Anyone else seeing this issue? -- User:Woohookitty Diamming fool! 05:52, 25 May 2009 (UTC)
Mine stopped today. I even have WikiEd on. (I checked) -- Abce2| Access Denied 19:41, 25 May 2009 (UTC)
Likely caused by Chrome it seems. — TheDJ ( talk • contribs) 21:13, 25 May 2009 (UTC)
I too run chrome, same version, all of the same scripts as TallNapoleon plus wikiED. Bizarre. Anyway, I also started a thread on Wikipedia:Village pump (technical) Valley2 city‽ 21:30, 25 May 2009 (UTC)
I run Twinkle, Friendly, Wikied, and reftools. I don't know if this helps, but after I asked for my monobook to be deleted and it got deleted the problem went away. Does that have any connection? -- Abce2| Access Denied 23:49, 25 May 2009 (UTC)
The WikEd extension is really annoying.. it's all screwy. At the same time it's too useful to really disable though, for me at least. Someone should really take a look at it. Disable text formatting while editing in the text box for example, and strip the formatting when pasting. That would help tremendously. Anyway, for my settings and browser and such, see here: Click Rocknroll714 ( talk) 01:23, 26 May 2009 (UTC)
I have found the possible cause and will put the 'new' wikEd (0.9.79c) back online. Chrome/Safari users, please click Shift-Reload to update! Sorry and thanks for the help, Cacycle ( talk) 02:41, 26 May 2009 (UTC)
When I enable, and then disable syntax highlighting, the following is left for my supposedly "unhighlighted" editor view. <font class="Apple-style-span" color="#0000E0">. It's a while since I used WikEd last, so i'm not sure how long this problem exists. — TheDJ ( talk • contribs) 20:23, 25 May 2009 (UTC)
I love Wik-Ed, but I would like to suggest 1 minor improvement. When I copy-paste text from another page, the original formatting is retained in the edit window—a copy-paste of a header appears really big, for example. I can put up with this, although I would rather it were corrected.
The bigger issue is that some copy-pastes (usually of multi-line template code), have dodgy line breaks in. For example, a copy-paste of:
{{Template:Example |1=abc |2=def |3=ghi }}
would come out with an extra line break above it. Deleting this line break causes the formatting to change to the following:
{{Template:Example |1=abc |2=def |3=ghi }}
If I delete that line break, it moves between the |1=abc and the 2=def. With larger chunks of code, this gets rather annoying.
I don't know if this is deliberate, or if it has been addressed before, but I thought I'd suggest it in case it was annoying anyone else. Dendodge T\ C 21:56, 25 May 2009 (UTC)
Just a small problem, when highlighting text that includes an image, pressing either the Fix Caps or Fix all buttons changes File: to the older Image: namespace. While this doesn't break anything, if there's the time it would be nice if this was fixed.
On another note, I prefer the new colouring, it is much clearer and less distracting. QueenCake ( talk) 21:31, 26 May 2009 (UTC)
This appears to be a Mac OS X interaction bug, since I experience the same problem with FireFox 3.0.4 on my Mac. Dnessett ( talk) 15:20, 2 June 2009 (UTC)
Problem identified (probably), but a not solution: This behavior seems to have nothing to do with Mac OS X. It appears to arise because I am using a DELL 30" monitor connected to my Mac (screen resolution = 2560x1600). I think the problem is CSS pixels are not screen pixels (see CSS pixels). The definitions of the Find and Replace combo boxes in wikEd.js use the px dimension, which do not map directly to screen pixels. The problem is the layered Find and Replace Select boxes (defined in wikEd.js as #wikEdFindSelect and #wikEdReplaceSelect) are not aligning properly to the top of the bounding box. They are then pushing the material below them into the edit area. This is seen in this screenshot. I have loaded wikEd locally on my personal wiki and played around with the parameters in WikEd.js, but have not been able to adjust them to get a good placement. To test my theory that this is related to my 30" monitor and not Mac OS X, someone with a 30" monitor connected to a PC should see if they have the same problem. (Note: there is a possibility that the problem has something to do with my graphics card, but I would like to eliminate the 30" monitor hypothesis before going down that alley.) Dnessett ( talk) 01:44, 6 June 2009 (UTC)
Then again, maybe not: I decided to wade through the explanation of CSS reference pixels given in CSS pixels. A CSS reference pixel is about 1/96 inch on a screen display meant for viewing at arms length (~28 inches). The DELL 30" display has a viewable width of ~26.25 inches. At 2560 pixels of width that means it provides 97.5 screen pixels per inch. So, a CSS reference pixel = 97.5 screen pixels per inch * 1/96 inch = 1.01 screen pixels. This is practically identical to a normal display and therefore insufficient to explain the FindSelect and ReplaceSelect field pushdown into the edit area. So, I am back at square one. Dnessett ( talk) 16:21, 6 June 2009 (UTC)
Problem Fixed: This was an extremely difficult problem to identify and fix. That I am not an expert in HTML or CSS is a gross understatement. So, I can only report my findings and hope those with a better understanding of both can elucidate. OK, enough whining. The problem is there is an interaction between class and id styles that leads to improper vertical alignment of the buttons and Find/Replace Select fields in the Find/Replace Button Bar. Some relevant styles specify vertical-alignment of text-bottom, others of text-top and still others 0%. The fix makes the vertical-alignment consistent by specifying vertical-alignment : text-top in the following style definitions - .wikEdButton, .wikEdButtonDummy, .wikEdFindComboInput, .wikEdCombo, .wikEdReplaceComboInput, .wikEdButtonUnchecked, .wikEdButtonChecked, .wikEdSummaryComboInput, .wikEdSummaryText, .wikEdSummarySelect, #wikEdFindText, #wikEdFindSelect, #wikEdReplaceText, and #wikEdReplaceSelect. One problem is I have no way of testing this fix on PCs (I use a Mac for most of my work). While I have a PC, my local test wiki on my Mac is not set up to serve other computers. Rather than going through the trouble of setting up a local network wiki server, I assume wikEd is installed on testwiki. Someone can make the indicated changes there to wikEd.js and test the fix on PCs. If the changes cause problems for PCs, at least the problem is identified and I assume some other approach can fix it for both PCs and Macs. As a side note, it is interesting that both Safari and Firefox on my Mac experienced the same problem. I can only assume that both browsers use a common library that causes the common vertical alignment problem. Dnessett ( talk) 00:02, 11 June 2009 (UTC)
I notice that the Toolbar Hide cookies expire after 30 days. Why not 30 years? I don't want to have to re-hide a toolbar I never use. Thanks. -- Armchair info guy ( talk) 01:33, 1 June 2009 (UTC)
As of recent, the script has been causing my browser(s) to become unresponsive while attempting to edit some articles.
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:8823
This is happening with both Firefox 3.x.x under Windows 7 and with Firefox 3.0.9 under Ubuntu 9.04. wikEd version is 0.9.79c. — C M B J 19:16, 2 June 2009 (UTC)
I tried wikiED and I found that it was too cumbersome (sophisticated?) for me. But I really like the text highlighting feature. Can you make a version, or a customization, that strips out all the buttons and leaves just the text coloring? (In a totally separate matter, is it possible to optionally hide refs so they don't clutter article text?) Thank you in advance.-- HereToHelp ( talk to me) 22:39, 3 June 2009 (UTC)
Infobox insists on first letters of fieldnames to be lowercase. wikEd changes them all to uppercase. Example:
{{Infobox Saint | Name=Saint Paul
is changed by wikEd to: {{Infobox Saint |Name=Saint Paul **which does not work**
John 3:16 becomes John 3:16 **which does not work**
The issue seems to be that the empty parameter "||" which is used for a numbered Bible book like "|1|Corinthians" must be left blank for "||John"
Thanks... Afaprof01 ( talk) 17:16, 6 June 2009 (UTC)
description: when wikiEd is enabled chrome's built in spell check does not underline misspelled words. All other functionality of wikiEd works when enabled. Disabling wikiEd and typing new misspelled words shows them underlined.
steps to reproduce: Edit an entry and type a misspelled word.
attempts to trouble shoot:
Setup:
wikiEd: 0.0.97c G
browser: google chrome 2.0.172.30
script errors: none
browser add-ons: none
user scripts: none
OS: windows vista business SP1
—Preceding
unsigned comment added by
R.Vinson (
talk •
contribs)
23:13, 6 June 2009 (UTC)
If I have this
|
|
wiked formatter gives this
|
|
then, comments (<!-- -->) should not be modified inserting empty lines between them and the rest of the text, because it could lead to malfunctions. Example
|
|
will be modified in this way
|
|
-- 93.47.32.238 ( talk) 21:37, 10 June 2009 (UTC)
How do I disable wikEdFollowLinks? Following links do not work in Firefox on a Mac, so I want to disable the feature. Using wikEdFrameCSS['wikEdFollowLinks'] = false;
did not disable it.
Gary King (
talk)
01:35, 12 June 2009 (UTC)
var wikEdFollowLinks = false;
doesn't do it for me. I still get "ctrl-click" when I hover over links in the textbox.
Gary King (
talk)
02:48, 22 June 2009 (UTC)
Added Cmd-Click for Macs in version 0.9.82. Please could you check if it makes sense and if it works. Thanks, Cacycle ( talk) 03:39, 23 June 2009 (UTC)
wikEd automatically scrolls down to the editbox. However, if a page has an editnotice, this can cause you to miss it.
I propose the implementation of a simple check for <div id="editnotice
I have not closed the tag, as the id attribute ends in several different ways, depending on the namespace. If that string is found anywhere in the page, wikEd should not automatically scroll down to the editbox, as the editnotice should be read.
I have reproduced this on the latest version.
This is a bug with wikEd, and is common to all browsers.
fahadsadah ( talk, contribs) 14:56, 14 May 2009 (UTC)
Moved to botton, as this is still a problem, but now unnoticable.
Hi, I was wondering if it would be possible to make an alteration to how wikEd treats non-textual elements (inline citations, nav- and infoboxes, other templates, etc., maybe even tables) in the edit box. Right now, you color those differently, which helps definitely, but I'm wondering if you could encapsulate them in a show/hide collapsible <div>? It would be very helpful for some workshops for scientists that I've been invited to give.
I floated the idea yesterday at the Village Pump. The basic idea is to replace the "special" texts with a two-state tag like [citation]. By default, everything non-textual (e.g., the ref tags and the citation between) would be hidden within such a tag. But if the editor clicked on a particular [citation] tag, it would show everything within, and could be edited. Once the editing was done, the editor could click that tag again and it'd collapse again.
This approach might make the editbox version of the article more readable (inline citations can be a bear!) and closer to the appearance on the article itself. Do you think it's feasible? We wouldn't need wikEd's other amazing powers (although they'd be a big win), so if you needed to disable something to make this one trick work, it would be OK by us.
I really appreciate your help on this, and I think it could benefit the scientists as they take their first steps into Wikipedia. Please feel to e-mail me, if you think it'd be better. Thanks! Proteins ( talk) 23:04, 25 June 2009 (UTC)
Thanks! I do know the [1] button, but sometimes scientific/mathematical articles are so dense with references, that they still hamper readability despite the smaller text. Some citation templates can take up several lines each. Here's an illustration of what I mean. Another motivation is that many articles begin with an infobox, which occupies the full first screen; if that could be collapsed, so that the editor saw the lead text immediately...
I agree that these scientists can and will pick up wiki-markup quickly; I'm doing my best to put together good teaching materials. :) But at one workshop in particular, we've been allotted only 90 minutes. So I'd really like to "hit the ground running" with them, and not have to explain citation templates and infoboxes immediately. They'll be editing a variety of existing articles, so the problem of dense refs is real. WikEd will be turned on by default on their accounts.
During an earlier lecture to non-editors, I'll also be opening an edit window on a scientific article to demonstrate how Wikipedia works. If the content were readily understandable by them, that would be a huge win.
I appreciate the badly-formatted-wiki-text problem, but I really believe that the advantages of this approach outweigh its risks. The basic goal is to make the editbox article easier to read and navigate by showing simple wiki-markup (such as sections, wikilinks and italics) but hiding advanced wikimarkup (such as references, templates and infoboxes). Is it feasible, do you think? Thanks again for your time and help, Proteins ( talk) 05:49, 26 June 2009 (UTC)
Thank you very much, Cacycle; I'm grateful for your help. I'll work on adapting the CSS schemes and e-mail you with more details on the scientific workshops early next week. Proteins ( talk) 15:52, 27 June 2009 (UTC)
Simply awesome! That's just what I was hoping for. It should really help newcomers to read/navigate the page and to make their first edits. I tested the new feature on several pages and it worked great. I did notice two glitches, which I hope won't be difficult for you to fix. The first was the second long template on Amanita phalloides, {{ mycomorphbox}}; somehow the body of the template wasn't included in the TEMPL placeholder, perhaps because of some non-standard formatting?
The second was the coloring of tables, e.g., this edit section. Once a table is started, the coloring seems to extend for the rest of the article, i.e., it doesn't seem to recognize the table end symbol |}.
Would it be possible to collapse tables in the same way that you've collapsed references and long templates? I think that they're the last major impediment to readability, being unfamiliar in syntax and stretching over many lines.
Your work is exciting, and will be very helpful at these workshops. I have a few more ideas, but I'll send those by e-mail on Monday, if only to give you a breather. :) Thanks again! Proteins ( talk) 13:30, 28 June 2009 (UTC)
wikEd which worked ok on my Win7+FF3.6a1pre doesn't load on Kubuntu9.04+Konqueror (KDE4.2.2). No plug-ins. SkyBon Talk\ Contributions 16:15, 28 June 2009 (UTC)
A superb idea. I thought wikEd more or less had everything, but I was wrong!
Just a small suggestion: when references are hidden, a mouseover displays its content, but hides the templates within. Since templates such as {{ cite web}} are widely used for referencing, perhaps it would make sense to automatically expand the templates within a reference when it's expanded on mouseover.
On a side note: when is 1.0 due? :-) GregorB ( talk) 09:49, 29 June 2009 (UTC)
Hi Cacycle,
Great work on wikEd! I have a few more suggestions for your consideration, which might be helpful. The first one is the most important for the workshops, but also the most work. I'm grateful for whatever you can do, and leave all of these suggestions to your discretion whether they'd improve wikEd or not. Thanks, Proteins ( talk) 18:35, 29 June 2009 (UTC)
Perhaps you could add a special button that requests the PMID, launches an XML request and inserts the resulting full reference into the Wikipedia page?
:<math alt=""> Add formula here. </math>
Clicking one button is faster than typing it out, and I believe the format is standard.
Again, thanks for your help, Proteins ( talk) 18:35, 29 June 2009 (UTC)
If I have something like this
{{Stub
| arg
|}}
(last argument missing) button returns an error
{{Stub
| arg
|}
}
probably because |} is treated like a table element. Can you fix? -- 93.47.34.59 ( talk) 21:52, 29 June 2009 (UTC)
wikEd remembers whether I have wikEd enabled or not and then applies that the next time I open an edit page. That's good, but I'd like to instead force it to be disabled by default because it slows down the loading of pages, especially long ones, too much. How do I disable it by default instead of having it remember whether or not it was previously disabled? Gary King ( talk) 04:07, 30 June 2009 (UTC)
var wikEdDisabledPreset = false;
does not work for me. wikEd is still enabled based on whether or not it was enabled the last time I was in an edit window.
Gary King (
talk)
15:54, 30 June 2009 (UTC)
true
then it does indeed disable wikEd, but there is no way to reactivate it when I need it because none of the buttons created by wikEd appear, so this does not help.
Gary King (
talk)
15:57, 30 June 2009 (UTC)
Using wikEd 0.9.83a and Firefox 3.0.11, when I try to edit Rsync and expand the {{ Infobox software}} within, the latest_release_date parameter appears empty, but it isn't, it is populated with {{ release date}}, which is only visible once wikEd is turned off. GregorB ( talk) 08:48, 1 July 2009 (UTC)
Reference/template unhiding is apparently broken in Firefox 3.5 (wikEd 0.9.83a, WinXP SP3); mouseover does nothing. GregorB ( talk) 15:21, 1 July 2009 (UTC)
I recommend U+3000 IDEOGRAPHIC SPACE to be highlighted: it is occasionally treated as wide variant of U+0020 SPACE and therefore is forbidden on ja Wikimedia projects.
Regular square with dotted lines may be desirable for highlighting image (note that it is wide character --- as Chinese ideographs [kanzi] are wide). -- Hatukanezumi ( talk) 16:42, 1 July 2009 (UTC)
See title. Please change: (...) Please see edit window. — M C 10| Sign here! 23:00, 1 July 2009 (UTC)
{{
edit protected}}
template. — Martin (
MSGJ ·
talk)
06:13, 2 July 2009 (UTC)
Content hidden with Template:Hidden begin isn't working in wikEd's preview. The template isn't broken - it works in articles, and in WP's "Preview". I'm using FF 3.0.1 and the version wikEd supplied by "my preferences."
For example, "{{hidden begin|title=my title}}hidden content{{hidden end}}" displays as
my title [show]
with WP Preview (where "[show]" is clickable), but as
my title hidden content
with wikEd. — eitc h 21:22, 8 July 2009 (UTC)
Safari 4. page. Whenever I have WikEd enabled, suddenly i see the protected page warning twice after wikEd has loaded. — TheDJ ( talk • contribs) 18:37, 12 July 2009 (UTC)
Hi. The link for site-wide installation under "Installation" is not working. You have typed _ in stead of - between "site" and "wide". I'm not able to edit the page so I'm telling you. -- 79.160.203.21 ( talk) 06:25, 15 July 2009 (UTC)
Hi, I installed wikiEd just now as a gadget through the Wikipedia preferences, and while it's unfortunate that ref (un)hiding is broken on Firefox, wikEd looks like a great idea. A bug: It seems that wikEd breaks URLs with ampersands in them (at least, URLs in refs). In Firefox, it turns each ampersand into � (that's Unicode 0002 "START OF TEXT") and in Safari it turns them into "%02" (same thing?). While strictly speaking ampersands in URLs must be encoded, in practice everyone uses ampersands and it's really ungainly to encode all of them. (And in any case, it's unlikely that existing links on a page have their ampersands encoded.) Is this a known bug? Regards, Shreevatsa ( talk) 13:19, 16 July 2009 (UTC)
Sure. I should have been clearer: the bug is that when you click on the URL from within the wikEd textarea, it takes you to the wrong place. Here's a detailed description:
Hope you can reproduce this, Shreevatsa ( talk) 14:30, 20 July 2009 (UTC)
PS: Do you know if the "ref hiding" is broken in Safari too? Turning it on seems to hide {{ quote}} content too (in both Firefox and Safari), which is usually part of the article proper and need not be hidden. Regards, Shreevatsa ( talk) 16:02, 20 July 2009 (UTC)
Every time I click on "Toggle REF and template hiding" or "Toggle between classic text area and wikEd", the font size in the edit area grows. The only solution is to reload the page after clicking one of those buttons.
wikEd 0.9.84b G, Safari 4.0, Mac OS X 10.5.7, No user scripts -- UncleDouggie ( talk) 07:24, 20 July 2009 (UTC)
It's working now with wikEd 0.9.85c! UncleDouggie ( talk) 06:42, 21 July 2009 (UTC)
When I mouse over a reference or template it is automatically expanded. I'd prefer it if it only expanded when I click on it, because sometimes I accidentally hover over one and then it expands, and it's hard to make it collapse again because it doesn't always notice that I moused over it again. I usually have move the cursor a few times over it for it to recognize it. Gary King ( talk) 21:53, 21 July 2009 (UTC)
I just discovered wikEd and it seems great so far, but I'm missing one function: besides the normal 'create article link' button, there should be one that autoinserts the "|" character between the double brackets, and maybe some empty spaces before it, so creating alternate text for links would be speedier. I know I should learn the alt-code for "|", but I always copy it instead from somewhere, and I bet many others do this too.
Also, why don't common functions, like boldening, italicizing, have keyboard shortcuts? Poisonborz ( talk) 00:00, 25 July 2009 (UTC)
Hello, I'm using WikiEd (0.9.84b) with greasemonkey (firefox 3.5) on the french wikipedia, and I was wondering if this is possible to have the icon images stored locally, to speed up the load time.
Thanks for your work. MickaëlG ( talk) 20:16, 4 August 2009 (UTC)
I've just recently re-enabled wikEdDiff after having it disabled for about a year. The button doesn't show up in diffs though, even after I've hard refreshed. Gary King ( talk) 16:03, 7 August 2009 (UTC)
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. |
My config -
Steps -
Actual wiki code:
| * Bullet 1 * Bullet 2
Required wiki code:
| * Bullet 1 * Bullet 2
Tom.ngo 15:49, 22 September 2007 (UTC)
Hitting the WikEd preview (the one with the icon and that loads below the edit section) and later the Standard Preview button will force a Return on the previewed page.
That's bad when you edit a page with a Submit form or an
inputbox. When you preview by hitting the preview icon and later hit the standard preview button, it will submit the form and you will be taken to the submit destination page. God bless it only works in Firefox so browsing back won't lose the data ;) Either fix it or remove the standard preview when WikEd is used, cos the WikEd preview feels much better. --
Subfader (
talk)
20:21, 16 March 2008 (UTC)
As my browser (Firefox 2.0.0.14) is loading this diff, it highlights (in red) the newly added text. But as the page finishes loading, the highlighting disappears. Does this happen with anyone else? -- zenohockey ( talk) 21:35, 31 May 2008 (UTC)
Version is 0.9.62g. See this diff. Apparently it's related to this. GregorB ( talk) 19:44, 13 June 2008 (UTC)
My config:
When copying rich text with many paragraphs left-indent, wikEd adds a <blockquote> section.
But <blockquote> needs the <p> mark to break paragraphs. And itallic or bold applies only to the first paragraph instead of the whole section.
The solution would be not to replace <p> marks with <br> marks within <blockquote>.
Another solution would be to use the Poem extension (it adds <br> after each end of line).
To get the left-indent, add this code to poem.php:
// Add a margin-left "style" attribute. if( isset( $attribs['style'] ) ) { $attribs['style'] = 'margin-left: 40px; ' . $attribs['style']; } else { $attribs['style'] = 'margin-left: 40px;'; }
If you put a '' before the <poem> mark (as wikEd acutally does with blockquote), then the whole quote is itallic. For instance:
''<poem> Au clair de la lune, Mon ami Pierrot: Prête-moi ta plume, pour écrire un mot. </poem>
would give:
Au clair de la lune,
Mon ami Pierrot:
Prête-moi ta plume,
pour écrire un mot.
Gabuzo ( talk) 11:16, 22 July 2008 (UTC)
Could you add syntax highlighting for .js & .css pages in edit mode? The code can be found on one of wikipedias common js pages. Thanks, ManishEarth Talk 15:13, 14 August 2008 (UTC)
When will WikEd's find/replace feature support regular expressions? I really need to be able to add new lines in replaces). (And I don't have access to a computer upon which I can load AWB. :( The Transhumanist 19:05, 18 November 2008 (UTC)
My custom settings used for wikEd do not work anymore after the latest wikEd update, even after a hard refresh. Gary King ( talk) 15:08, 17 November 2008 (UTC)
I think I have fixed it and I am in the process of uploading the new version 0.9.67d. It happened only with the ref hide button pushed. Cacycle ( talk) 03:31, 20 November 2008 (UTC)
Hi. I use wikiEd 0.9.67d G with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3. When I click on the edit this page (while editing Kīlauea article) button and then click on Changes button, there are mutliple removed spaces from the beginning of the line between paragraphs and in infobox. In error console are a few tens of errors
and one
-- Tomaxer ( talk) 22:00, 22 November 2008 (UTC)
Today I had time to evaluate the gadget version of wikiEd.
The good news is that it implements highlighting of the embedded citations that make extensively referenced articles very difficult to read in edit mode. I made this suggestion unnoticed last year on an unrelated talk page, so thank you.
The bad news is that wikiEd doesn't solve my fundamental time-wasting problem of constantly reloading a rendered preview so that I can see what I get.
I read the wikiEd help page and the link to What you see is Wiki - Questioning WYSIWYG in the Internet Age (PDF) by Christoph Sauer. He has many good points, but the central notion of deprecating WYSIWYG is not one of them. While formatting may not be durable, it matters locally. It's also an unnecessary dichotomy. WYSIWYG Corel WordPerfect still has the Reveal Codes feature. Why accept less (unless one is a monopoly victim of MS Word)?
The inverse of Reveal Codes is code folding requested above at #Feature request: code folding – but too difficult to implement for wikiEd.
So let's plan beyond wikiEd to the next editing tool – to what I (and many others it appears) really need for "concentrating on the content" in Sauer's words. I need to:
Milo 08:12, 23 November 2008 (UTC)
Hi! I love wikEd, the syntax markup makes it so much easier to edit text, especially with a lot of in-line refs. Unfortunately, I guess my computer is a bit too slow – when editing a big page with wikEd, the whole computer freezes for a long while. Therefore, I normally keep wikEd disabled, and enable it when I need it. However, every now and then, I forget to disable it, open up some big edit and there we go... sometimes I have to kill the browser. It would be so cool if you'd be able to make it scale better for big pages, but until then – would it be possible to have an option to always have wikEd disabled, unless explicitly enabled for a specific edit? Is this already possible? Thank you for this very useful tool. / skagedal ... 19:58, 26 November 2008 (UTC)
Greetings,
I want to use WikEd on a mediawiki installation that I have. I have installaed Gadgets on my wiki, however I am unclear on how to make the code for WikEd availabel on my site that users may select it as a Gadeget in their preferences. Can anyone offer me a little help here with the installation?? -- Shannara Fan ( talk) 02:35, 1 December 2008 (UTC)
I just installed WikEd today, and it seems to work great. I'm only wondering why there are no shortcut keys for the most common functions, such as wikilinks or bold. (At least they're not displayed in the tool tips.) I feel these are so useful for everyone that they should be there by default, especially since it is more ergonomic while your typing than having to navigate (with the touch pad) to the button, and then back to the place you were working at. For that reason, I would also like to have shortcuts for the increase headline and related buttons and for #R, or, come to think of it, for almost all of the in-text buttons. if you feel that not everybody would appreciate it, maybe there is a way I can add shortcuts for myself?
PS: This is strange: Just now I tried alt-shift-o, and it inserted a wikilink. Then I clicked the [T] button, and it selected the whole text (which is not what I would expect from the tooltip), and after that, alt-shift-o does the same. (I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4.) — Sebastian 20:50, 3 December 2008 (UTC)
// define accesskeys for edit buttons (wikEd button number: [key string, JS key code]) var wikEdButtonKey = { 26: ['b', 66], // wikify 32: ['g', 71] // scrolltoedit };
acceskey="
to see the current accesskeys. wikEd uses b, g, and o (the only free ones when I implemented this).
Cacycle (
talk)
17:21, 4 December 2008 (UTC)
I have a date delinking script: User:Lightmouse/monobook.js/script.js. It has the following options:
I would like to turn it into a WikEdit plugin, but it is outside my current skills. Would anyone be willing to help me with the coding? Lightmouse ( talk) 10:12, 4 December 2008 (UTC)
I just ran into an unclosed ref tag, and because the syntax seemed correct, I asked at HD. The edit diff is here. I had thought such an important difference would be obvious thanks to the syntax coloring, but it seems to me that this looks normal. Maybe it's that you're using different shades of bluish-gray to express different things? — Sebastian 04:07, 5 December 2008 (UTC)
Hello, my WikiEd does not seem to be working. I was about to send a warning message user:72.148.61.160 for vandalizing this page, however, the WikEd just seems to stop at "data loaded..." with no message added. What should I do? Prowikipedians ( talk) 03:15, 7 December 2008 (UTC)
Updated Bug Report by Prowikipedians ( talk) 05:47, 7 December 2008 (UTC)
Version: WikiEd 0.9.67d G (November 19th, 2008) Safari Version 3.2.1 (525.27.1) Cleared all cache as a user suggested, but nothing worked. All browsers (Mozilla Firefox, Internet Explorers, Safari) all have shockwave/flash installed. No user scripts installed on my monobook.js page Windows XP (and Ubuntu 8.10) Cannot use the warn/arv/etc buttons. 1) Clicked "warn" on user talk page. 2) Only shows "data loaded..." and freezes there. Nothing. Just freezes there.
Config:
WikED version: 0.9.67d
Browser: Firefox 3.0.4
Addons installed: Adblock, Flashgot, Greasemonkey, Noscript, Stylish
Using Monaco.js, the only script installed is the install for wikED
Problem encountered:
On uploading an image with WikED enabled, if no comment is inserted in the Summary field, WikED automatically sends a single space as the comment. This results in the parentheses appearing in the recent changes, enclosing a single space.
I tested this with 3 image uploads, and produced the following:
Uploaded image and added a comment in the Summary produced: Username uploaded "Image:filename.png" (comment)
Uploaded image with no comment in the Summary produced: Username uploaded "Image:filename.png" ( )
Disabled WikED
Uploaded image with no comment in the Summary produced: Username uploaded "Image:filename.png"
To make things interesting, with WikED enabled, I went into the upload image window, then clicked on "toggle to standard edit window". This produced the expected standard edit window and put a space followed by a carriage return in the window!
I realize that this is a minor thing, but one of the sysops brought it to my attention, so I thought I'd pass it along. The community involved is wiki.ffxiclopedia.org
Thanks! Ffxiclopedia Catrinm ( talk) 04:52, 10 December 2008 (UTC)
Using the gadget version (0.9.67d G). Reproduce open page (like James Bond (character)) with the HTMLarea and syntax highlighting enabled, then disabled syntax highlighting (leave HTMLarea enabled). Click the diff and notice the leading whitespace is gone now. — Dispenser 19:11, 22 December 2008 (UTC)
wgServer + wgArticlePath
? Also the regexes at the end are shorter and might be a good inclusion for the fixes button. —
Dispenser
06:11, 29 December 2008 (UTC)function checkRegexp(text) {
window.status = "No error detected"
try {
if(text == '')
return 0
re = new RegExp(text)
if(''.match(re)){
window.status = "Empty string matches";
return 1
}
if(' \r\n\t'.match(re)){
window.status = "Matches white space";
return 1
}
return 0;
}catch(e){
window.status = "Compiling error"+e;
return 2;
}
}
// Line 133-134, Parser.php
$this->mExtLinkBracketedRegex = '/\[(\b(' . wfUrlProtocols() . ')'.
'[^][<>"\\x00-\\x20\\x7F]+) *([^\]\\x0a\\x0d]*?)\]/S';
If you choose serif (or is it sans?) in your preferences page wikied is still monospace. how can i change the font from monospace?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 latest version from wikipedia pref page
var wikEdFrameCSS = {}; wikEdFrameCSS['.wikEdFrameBody'] = 'background: #FFFFFF; margin: 0px; padding: 0.2em; overflow: -moz-scrollbars-vertical; overflow-x: auto; font-family: monospace;';
On User:Cacycle/wikEd.js, it says: "5. Optional: customize the program by adding user settings to your ''''' page". This should be monobook.js, no? / skagedal talk 15:31, 30 December 2008 (UTC)
xcen > de
I'm using wikEd via Greasemonkey on my local mediawiki. Each time I press the Save Page or Preview button when editing a page somebody inserts automatically a line containing xcen > de on the top of the edited page (the more I press the buttons the more lines will be inserted) Disabling wikEd by disabling greasemonkey, the standard Save or Preview buttons of Mediawiki work as expected: no unwanted lines are inserted ...
What's going on? Who inserts those unwanted lines and why? Probably you will see those lines on top of this page due this behaviour ... ;-)
i am in korean translation. while editing, for example, when i put a mouse on the
[[Image:filename|thumb|150px|explain]]
then popup shows "Imagefilename (ctrl-click)" i think "Image:filename" is right than "Imagefilename" check it please. and it would be nice that HighlightSyntax could be always being updated. -- Ilovesabbath ( talk) 19:48, 8 January 2009 (UTC)
How would I go about changing the colors used to highlight the text? That's a really nice program that you made!
WriterHound ( talk) 03:13, 14 January 2009 (UTC)
There is a bug, probably in the fixing of spaces before puncuation. I'm using the latest version of the program and the latest version of Firefox. When there is an image, it puts a space before ".jpg" or ".gif". It also puts a space before ".html" in external references. Example, see my recent edit to My 60 Memorable Games. Bubba73 (talk), 04:25, 14 January 2009 (UTC)
Hi, I've proposed a script I wrote as a potential Gadget at Wikipedia:Gadget/proposals#Add_the_.22Localize_Comments.22_script. As a Gadget writer, could you check it out when you have time and audit the script, and post your thoughts on whether it should be a Gadget or not? Thanks in advance! Gary King ( talk) 16:54, 16 January 2009 (UTC)
I'm using 0.9.68a on FF3 - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
I don't have any other JS tools in my monobook.js nor using Gadgets.
I've been using wikEd ever since I registered for wikipedia and it's a great tool. Only today did I learn that I could customize it so I read the manual and made a few changes.
Most of the tweaks in my monobook.js worked, but 2 of them didn't:
var wikEdButtonsOnTop = false; var wikEdButtonBarFindHidden = true;
The toolbars are still above the edit box and the find bar isn't hidden.
Is this a bug or am I doing something wrong?
Thanks. This is a really useful tool! -- Armchair info guy ( talk) 02:39, 19 January 2009 (UTC)
Me again. I'm wondering if wikEd can automatically scroll to the preview/changes box when I press either button. I know I can do it with the separate buttons on the tooblar at the right side of the screen, but it'd be more convenient to do so automatically.
Also, it'd be great if the browser focus switches out of the edit box and onto the page when I press preview/changes, so that when I hit spacebar it's a browser page down scroll instead of adding an undesired text space. Probably been dozens of times I've had this happen and then I have to click outside the edit box to change focus.
Thanks again. -- Armchair info guy ( talk) 02:52, 19 January 2009 (UTC)
My 3rd topic in a row. I also added AWB's RegExp button (one of the monobook.js var additions that worked properly, in reference to my first topic). I tried it out and it capitalized every word beginning with "th" - the, them, they, etc. Obviously a bug since most shouldn't be. I assumed it was a bug with RegExp and filed a bug over there but one of them replied that the problem was likely in wikEd.
I have no idea one way or the other. Just reporting it here so you guys can get to the bottom of it. Thanks! -- Armchair info guy ( talk) 04:08, 19 January 2009 (UTC)
Perhaps this isn't a bug and I'm doing something wrong or my system isn't fully supported, but I can't discern that from the documentation.
I'm trying to get copy from Word to MediaWiki with formatting intact. I'm trying an extremely minimal test case: in the Word document are three words, each on their own line. One is normal, one is bold, and one is italic. When I copy/paste into WikiEd, I get the three words with no formatting. When I click the [W] button, the text I just pasted is selected but otherwise nothing happens.
Am I missing a step, is my software combination unsupported, or did I actually find a bug? —Preceding unsigned comment added by 209.240.239.188 ( talk) 17:20, 19 January 2009 (UTC)
I also found formatting - at least the basics that I've tested - are preserved in Safari. I suspect the problem has more to do with FF's handling of the OS X clipboard than anything WikiEd is doing. If you can point me in the right general direction where clipboard handling is in the code (and how to run a local copy instead of sourcing it off wikipedia), I'd be willing to look for a Firefox workaround. —Preceding unsigned comment added by 209.240.239.188 ( talk) 15:29, 20 January 2009 (UTC)
I have a suggestion for a new feature. Could you program wikEd to repair spacing and punctuation placement at references? Some examples below:
It should read:
See: Manual of Style.
This feature could detect certain end of sentence punctuation . ? ! and place it before the reference(s), then remove any extra space(s). It would also remove extra spaces before references in the middle of a sentence; none before and only one space after the reference. One space would be preserved or added as necessary at the end of each reference. Duplicate punctuation at the end of a reference would be removed.
Thank you for your consideration and nice work here. ~ All is One ~ ( talk) 00:52, 20 January 2009 (UTC)
Will this WYSIWYG editor allow for an easy method of creating tables? I'm trying to find an editor for my wiki that will help users create tables easier than the standard wiki markup. Thanks! -- Brandon ( talk) 16:04, 21 January 2009 (UTC)
heading | heading |
---|---|
cell | cell |
cell | cell |
var wikEdShowTableModeButton = true;
on your monobook.js page...
Cacycle (
talk)
14:43, 22 January 2009 (UTC)Config:
WikED version: 0.9.68a
Browser: Firefox 3.0.4
Addons installed: Adblock, Flashgot, Greasemonkey, Noscript, Stylish
Using Monaco.js
Recently, wiki.ffxiclopedia.org installed a new extension "EditEnhancements" from MediaWiki. The expected result is that the "Save", "Preview" etc. buttons now appear on a bar which sits at the bottom of the view area, and scrolls up and down as the view area changes so as to always sit at the bottom of the view area. The Special:Version lists this as: EditEnhancements (Version 1.0) Christian Williams and Maciej Brencz
With WikEd enabled, it doesn't work as expected. The result is that directly below the edit window I only have the "save" button. I have to drop out of full page edit mode to find the preview button which, along with several other bits and pieces, are now in a fixed position further down the page. There is all sorts of unexpected behaviour from this. As one example, on the FFXI site, the space below the "save, preview, changes" buttons is used for a table containing some commonly used wiki markup shortcuts. Closing the preview pane from the WikEd button simply toggles this on and off and doesn't affect the prefiew pane at all! With WikEd enabled, "save" button remains in place while the "preview" and "Changes" buttons are moved to below that table, so I have to hit ctrl-end (end of page) to get to them!
A preview of this can be achieved on this page by editing the text, then scrolling below the edit box. Imagine the "preview" and "Changes" buttons now appear below the line that starts "Once you click the Save button..." and the "Do not copy text from other websites without ...." line has moved down there with them, leaving the "Copy and Paste" table in place. I can provide screenshots if required, just let me know!
Thanks for your attention to this :) Ffxiclopedia Catrinm ( talk) 08:14, 22 January 2009 (UTC)
var wikEdNoRearrange = true;
to your monobook.js page.
Cacycle (
talk)
02:45, 26 January 2009 (UTC)steps to reproduce:
using
Matthias M. ( talk) 18:26, 28 January 2009 (UTC)
Hi, I work on Wikisource fr and I would realy appreciate wikEd to work properly in proofreading mode ( for example). The edit window goes to the bottom of the page instead of next to the image, where the textarea normally stands. With wikEd 0.9.69a, on Firefox 3.0.5. —Preceding unsigned comment added by Aroche ( talk • contribs) 12:52, 31 January 2009 (UTC)
When I use button for fix Unicode in it.wiki, it doesn't works anymore and now appears a window: Uknown function wikEdFixUnicode. Moreover, in some pages some wikEd buttons don't appear. What can be the problem? I don't understand. Script is called here, and these problems started I think not more than few weeks ago. Thank you Lenore ( talk) 14:58, 1 February 2009 (UTC)
Hello, Cacycle. Since some months I have a problem, if i upload an image using your script on the upload page with my firefox.
Always the following lines apear on the upload page, but not until storing of the image.
Vertrauensw.: Händlerzuverl.: Datenschutz: Jugendschutz:
The lines not apear in the editing box, but during the preview (of your script) in the lower part of the page and after the storing. I would be glad, if you could find a solution. Greetings -- Tlustulimu ( talk) 17:04, 2 February 2009 (UTC)
I'm always replacing casual use of the ASCII '-' (hyphen-minus) with the correct typesetting mark, typically em-dash but sometimes em-dash and occasionally the minus character. These show up as different in a proportional font like the normal web page, but all look the same in the edit window!
I think that simply coloring them differently would do the trick. For example, if regular text is black, make the em-dash blue, the en-dash green, and the minus red. To serve as a key of sorts, color-code the "insert" hyperlinks to match.
— Długosz ( talk) 17:42, 12 February 2009 (UTC)
P.S. Some time ago I tried the "fix dashes" button, but it didn't do anything useful. That was years ago, so I'll try it again.
On this page (permanent link to version), the "fix dashes" button does not handle the first paragraph:
The technological singularity is a theoretical future point of unprecedented technological progress -- typically associated with advancements in computer hardware or the ability of machines to improve themselves using artificial intelligence.
It changes this to an EN-dash and leaves the spaces around it. The correct fix is an EM-dash and delete the spaces.
On this page (permanent link to version), select the paragraph:
There has also been speculation that a large tsunami in the Mediterranean Sea caused by the Thera eruption dated ca. 1630-1600 BC geologically…
The fix-dashes button did nothing. I expected it to change the hyphen-minus in the range "1630-1600 BC" to an EN-dash.
On editing this section (permanent link to version), the first paragraph contains a range and the second contains a parentetical thought. I expected the "fix dashes" button to change the first to an EN-dash and the second to EM-dashes without surrounding whitespace. It did nothing.
I tried to load typos in it.wiki from this page, but doesn't work, button doesn't appear. The function in it.wiki is enabled from this page (at the bottom). Thank you for support Lenore ( talk) 19:31, 13 February 2009 (UTC)
When attempting to edit any article, wikEd displays a red "X" icon in the top right corner ("Loading error"). Edit window is empty.
WikEd version is 0.9.73, user agent is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
, JavaScript console message is Uncaught TypeError: Cannot call method 'charCodeAt' of undefined
http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript (line 8591)
, OS is Windows XP SP3. On the same machine Firefox 3.0.6 appears to works fine with wikEd 0.9.73.
GregorB (
talk)
13:03, 17 February 2009 (UTC)
Here's a way to reproduce it (Firefox 3.0.6):
BTW I really like this new feature. I wish there was a way to custom-render the nbsp character entity in a user-friendlier way. Would this be possible? GregorB ( talk) 21:29, 17 February 2009 (UTC)
Hi Cacycle. I saw in Upper Sorbian version wikEd_international_hsb.js that you added the following strings:
and
But those 4 strings have already been part of the file. They are double now. Is it correct? Regards, --
Michalwiki (
talk)
18:55, 23 February 2009 (UTC)
Hi, long time no comment. Kudos! wikEd runs fast under the new Safari beta (so far). Very quick load; will report any anomalies.
- - -
Schweiwikist (
talk)
08:07, 25 February 2009 (UTC)
Apparently it caches the script! Clicking to add this reply, there was zero load-time: all the tools are ready immediately. What a difference. Another thing I wanted to mention is that this is running on a Titanium PBG4 @ 1MHz with only 512MB RAM, and OS X Tiger. Will wikEd move toward supporting the resizeable edit box? ;) - - - Schweiwikist ( talk) 14:36, 25 February 2009 (UTC)
Hi, I can report a small rendering/interface glitch for the current version when running inside Safari 4 public beta (4528.16). This occurred under Leopard (10.5.6 with the security update, of course) on a MacBook (unibody) and also under Tiger (10.4.11 with the current Java version) on a Titanium Powerbook. Specifically, when going into edit mode while wikEd is enabled, or toggling wikEd (master switch by my live clock) while in edit mode, the edit summary text box/interface "drops out" (i.e., hides) until and unless the window is resized (just by a single pixel does it, so it redraws the contents) or fullscreen mode is invoked/uninvoked (producing the same redrawing and unhiding). This doesn't happen in Firefox. - - - Schweiwikist ( talk) 01:30, 28 February 2009 (UTC)
i found an annoying bug with wikiEd, if i edit a page, then i disable the gadget and reenable it, all the changes in the edit field made after this will not be saved or previewed.
here are the exact steps:
the wikiEd version is 0.9.74 G (February 21, 2009) and i'm using Firefox 3.0.6: Mozilla/5.0 (Windows; U; Windows NT 6.0; ro; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729) i have this problem both on english and romanian wikipedia. Dany 123 ( talk) 12:57, 28 February 2009 (UTC)
In diff pages wiked makes links lickable right? But there's a bug for which external links work wrong (see for example this) Lenore ( talk) 19:21, 28 February 2009 (UTC)
I would like to add a text marker to a custom button. How can I achieve this? —Preceding unsigned comment added by 91.50.191.41 ( talk) 12:22, 1 March 2009 (UTC)
It takes many seconds before I can make a simple spelling correction. Disabling. DCDuring ( talk) 17:54, 5 March 2009 (UTC)
Well, Firefox just got incremented to 3.0.7, and your recent update broke. Here's my info:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
The quad-pointers pointer that used-to-appear when hovering over the resize square no longer appears, and now the best way to describe the response is that the resizer is slow and slippery: edit-box refresh is very slow, and once the pointer leaves the grab box (and crosses another interface element), refresh halts. Very weird. Obviously Firefox made some major change under the hood, because it used to work just fine. More info once I test on the other Mac, where we haven't updated Firefox. - - - Schweiwikist ( talk) 19:15, 7 March 2009 (UTC)
UPDATE: Found source for "downgrading" back to FF 3.0.6. Will report results shortly. Schweiwikist ( talk) 19:28, 7 March 2009 (UTC)
UPDATE: Same problem with FF 3.0.6 running, so it's not FF's problem. Apparently this interface bug might have to do with the initial edit box row/column setting in a logged-in user's prefs. Mine are recently set to 20 rows, thanks to your widget. Only enlarging the edit box (down-and/or-right) exhibits this bug. Up and/or left is fine (i.e., into the edit area). Will test ASAP with higher row setting. Schweiwikist ( talk) 19:50, 7 March 2009 (UTC)
UPDATE: Nope, doesn't matter what the user prefs are (sorry, my rows setting was 12, not 20!). Confirming the bug in the resize grip is present under FF. Safari, you get a quad pointer which responds fine in all directions. Schweiwikist ( talk) 19:59, 7 March 2009 (UTC)
Why did you remove the feature that puts the tabs at the top of the page that lets me easily put CSD, AFD, or other tags on the page? That's all I used WikED for, and now it's gone! No warning, no changelogs, no nuthin. Vistro ( talk) 23:42, 7 March 2009 (UTC)
I have some questions and problems with the Fix tools. Why does Fix HTML or Fix All sometimes insert (-- and --) into pages? Also, Fix Caps seems to act on the entire page instead of just the paragraph as the help page describes. Fix Caps and Fix All often break the behavior of templates such as {{infobox}} by capitalizing the parameters. — Ost ( talk) 15:51, 9 March 2009 (UTC)
What is the right way of removing some of the default buttons (to make the page less cluttered and faster to load)? Using a custom wikEdButtonBar is not reliable because the script expects the id of some buttons to exist, and dies if the getElementById call returns null. -- Tgr ( talk) 20:13, 10 March 2009 (UTC)
WikiED, along with other extra editing tools, causes the edit page to lag, at least for me it does.
-Axmann8 (Talk) 22:25, 12 March 2009 (UTC)
(Moved here from User_talk:Cacycle/wikEd_customization)
How can I remove edit buttons (as I do not need them)? Loading of buttons is very very slow.... I use only the syntax-highlight function which is very useful. 88.209.142.83 ( talk) 21:06, 13 March 2009 (UTC)
It seems the problem is gone with one of my Firefox add-ons (I try to narrow it to one add-on with enabling them one-by-one) 88.209.143.46 ( talk) 11:24, 15 March 2009 (UTC)
I enabled all of the add-ons in Firefox and WikEd works well! Maybe you did something beneficial during the last couple of days? 88.209.143.46 ( talk) 11:36, 15 March 2009 (UTC)
Strange things again... For a while all worked well, but today I noticed that WikEd loads again the buttons at every page I open for editing.
I disabled all the Firefox add-ons, then enabled them all, and everything goes well again with WikEd (I suppose: for a while). Maybe yesterday it was OK, I don't remember exactly, so 1 or 2 days passed without this failure.
What can I do now to find the cause? 88.209.147.7 ( talk) 18:38, 17 March 2009 (UTC)
-- JonnyIncognito ( talk) 05:00, 18 March 2009 (UTC)
IE6 throws "Expected identifier, string or number" on WikEd.js line 326 because of the last line of the above object ends with a comma. (That is only allowed for arrays and not for objects according to ECMAScript, though every other browser seems to understand it.) -- Tgr ( talk) 09:20, 26 March 2009 (UTC)
FF3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7), wikEd 0.9.75b G. Steps to reproduce:
A related, more peculiar bug:
-- Tgr ( talk) 09:27, 26 March 2009 (UTC)
I'm using a costum skin on my Wiki and the Button for turning wikEd on and off does not appear. What needs to be in the skin to display the button? -- DaSch ( talk) 22:51, 31 March 2009 (UTC)
I just want to know how to move the enable/disable button up or down the page. It's currently in a non-aesthetic place in the GuMaxDD skin that puts it below the navigation toolbar and above the edit toolbar. —Preceding unsigned comment added by 67.169.137.199 ( talk) 06:51, 1 April 2009 (UTC)
The current Chinese translation of wikEd, User:Shibo77/wikEd international zh.js, is actually in Simplified Chinese. I have made a Traditional Chinese translation for wikEd. Please take a look at User:Quest for Truth/wikEd international zh-hant.js. -- Quest for Truth ( talk) 09:52, 16 April 2009 (UTC)
WikEd is checked in my preferences, but it's not showing up on my navbar as normal. There's no WikEd symbol at all I mean; it's not just the red X. Chrome is version 1.0.154.53, Windows XP, Modern skin. — Levi van Tine ( t – c) 14:11, 17 April 2009 (UTC).
There is extra code that lets the WikEd disabled by default so I can activate it later? HyperBroad ( talk) 20:03, 17 April 2009 (UTC)
Not resolved. I set it in my monobook.js. HyperBroad ( talk) 22:51, 17 April 2009 (UTC)
What I need is a command to leave the wikEd disabled as default so I can activate it by clicking the top of the page when I need it. I always clear the browser cache before closing it. HyperBroad ( talk) 16:32, 18 April 2009 (UTC)
Thanks! HyperBroad ( talk) 18:44, 18 April 2009 (UTC)
Why don't you add suppor for Internet Explorer. I beleive the codes for internet explorer has changed with the onset of IE8, and it is now up to the Standards. -- Tyw7 ( Talk ● Contributions) Leading Innovations >>> 17:46, 19 April 2009 (UTC)
First off all thank you for the great Extension (I use greasemonkey version).
The problem is that the "Toggle between lowercase, uppercase first, and uppercase" doesn't support non-English Alphabet characters, like German "ä,ü,ö" or the whole Cyrillic alphabet(my case). I thought, that it wasn't a big deal and tried to fix it by myself: I replaced all *"a-zA-Z"* strings in the source with *"a-zA-Zа-яА-Я"* and it worked... well halfway (or 2/3way to be precise) - It only works with words, that begins with upper case and if the word begins with a capital letter - it converts it to full-upper case, than to full lower case, but than the cycle breaks. It looks like this: "Арбуз" -> "АРБУЗ" -> "арбуз" -> stays lower case. What should I do?
Thanks. —
85.176.25.24 (
talk)
01:36, 22 April 2009 (UTC)
Using/enabling wiked breaks wikimedia's encrypted connection at Secure Wikipedia. Is there a solution? Smallman12q ( talk) 21:47, 22 April 2009 (UTC)
Source File: http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 3332
~ Itzjustdrama ? C 01:48, 25 April 2009 (UTC)
I don't know if this is a wikEd bug or not, but I occasionally get the quick find feature in Firefox when hitting the ' (straight single quotation mark) button. It comes and goes, but I cannot pinpoint the source or cause, but as far as I can tell it's only happened to me within editing a MediaWiki website with wikEd enable. For instance, I was just editing Wikinews and I kept getting this bug, but reporting here it is fine. I then went back to check Wikinews and it's not happening anymore. Thanks. Calebrw ( talk) 04:53, 27 April 2009 (UTC)
Edit summary hidden in Google Chrome Beta YayaY ( talk) 19:58, 1 May 2009 (UTC)
On http://de.wikipedia.org I recieve the following error using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10.
Fehler: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandEnabled]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame ::
http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript :: anonymous :: line 6223" data: no]
Quelldatei:
http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript
Zeile: 6223
Matthias M. ( talk) 13:28, 2 May 2009 (UTC)
Can WikEd be extended with more formatting options like fonttype and coulor? Columbus56 ( talk) 07:42, 5 May 2009 (UTC)
::Let's say, for example, hypothetically, that a user didn't know HTML... what would be required to change the font to Arial? --
King
Öomie
16:08, 13 August 2009 (UTC)
Can WikEd sort lists?
If not, would you add this incredibly useful feature?
Sorting lists manually is a real pain, and cutting/pasting them into 3rd-party sorters is very inconvenient.
The Transhumanist 18:50, 14 May 2009 (UTC)
The regular expression used in find and replace should always execute in multi-line mode. This would make it more useful. I can't think of any cases where it is useful to restrict ^
to matching only at the very beginning of the page. For example, this would simplify the replace-all of (^|\n)(.+)
→ $1* [[$2]]
to the more straight-forward ^(.+)
→ * [[$1]]
—
GregU (
talk)
05:50, 15 May 2009 (UTC)
What is the size limit for an article’s wikitext above which syntax highlighting doesn’t work? It’s definitely less than 32K, since Standard electrode potential (data page) is only 32,014 bytes, and it doesn’t work even when doing a section edit on the main section. Hgrosser ( talk) 13:32, 19 May 2009 (UTC)
The preceding note was on Firefox Windows, on Safar1 3.1.2 the limit is definitely greater, somewhere between 82 and 109 kilobytes as reported at the top of the preview Hgrosser ( talk) 21:35, 19 May 2009 (UTC)
A wiki I'm on uses special parser extension tags that WED whines about. Solutions?-- Ipatrol ( talk) 19:06, 23 May 2009 (UTC)
The way wikEd highlights the text changed suddenly. What happened? my name inc Ottoman project 00:19, 24 May 2009 (UTC)
This morning it worked fine, but now, after the update, it is different. I am unable to use wikEd in the default monospace font. When I have it enabled, i.e. letting it highlight things, it forces the sans-serif font, but I prefer the monospace. I would like this option. Also, the previous choices to highlight reference text were either gray background or gray words. Now it is gray background or gray words with superscript. I really hate the superscript so I'd rather have just the light colored words. Thanks, Reywas92 Talk 00:23, 24 May 2009 (UTC)
I'm somewhat new to wikiEd, and your page about costomization is very confusing. My concern is about the edit summary and save page region below the edit box. I significantly prefer the dafault Wikipedia format of having the save page/preview/changes buttons directly under the minor edit checkbox, which is directly under the edit summary box. I think that's dumb to have them all separate with the minor edit checkbox below the save page and the edit summary being way on the right. How can I customize to have the standard layout there? Thanks! Reywas92 Talk 00:27, 24 May 2009 (UTC)
Hello Cacycle,
I am a German Wikipedian, we are using directly the code from wikEd.js from your Page as a Gadget. I've seen that you've changed the display of the code in the Textarea. Personally I think the old code was much better, but thats not the main reason I am talking to u. At previously deleted Pages there is shown the deletion log in top of the textarea. With your code update, the deletion log is shown twice. (Compare e.g. [1] with activated Gadget). Could you please have a look at it please. Thank you -- Joschi90 ( talk) 01:00, 24 May 2009 (UTC)
I like it :) Matthewedwards : Chat 05:48, 24 May 2009 (UTC)
window.wikEdProgramVersion = window.wikEdProgramVersion || '0.9.79';
window.wikEdProgramDate = window.wikEdProgramDate || 'May 23, 2009';
Hello, there is a small glitch - one gets a Javascript error in line 845 when starting up in IE7 (tried with Vista). This happens before wikEd has a chance to shut itself down in the unsupported browser mode.
This fixed this for me:
diff -r cb639c56fc30 plwiki/sk/wiked.js
--- a/plwiki/sk/wiked.js Sun May 24 16:38:46 2009 +0200
+++ b/plwiki/sk/wiked.js Sun May 24 16:50:36 2009 +0200
@@ -841,7 +841,7 @@
67: ['g', 71], // scrolltoedit2
72: ['g', 71], // scrolltoedit3
74: ['g', 71], // scrolltoedit4
- 32: ['g', 71], // scrolltoedit, overwrites previous wikEd buttons for same key
+ 32: ['g', 71] // scrolltoedit, overwrites previous wikEd buttons for same key
});
}
« Saper // @talk » 14:53, 24 May 2009 (UTC)
How can I use the old syntax highlighting? The new version have a bug by editing references.-- Video2005 ( talk) 17:34, 24 May 2009 (UTC)
Thanks to WWGB for catching this. I logged in tonight and started doing my disam work. WWGB caught that for whatever reason (Ctrl-click)" is being added to my edits in random places. Here is an example. Anyone else seeing this issue? -- User:Woohookitty Diamming fool! 05:52, 25 May 2009 (UTC)
Mine stopped today. I even have WikiEd on. (I checked) -- Abce2| Access Denied 19:41, 25 May 2009 (UTC)
Likely caused by Chrome it seems. — TheDJ ( talk • contribs) 21:13, 25 May 2009 (UTC)
I too run chrome, same version, all of the same scripts as TallNapoleon plus wikiED. Bizarre. Anyway, I also started a thread on Wikipedia:Village pump (technical) Valley2 city‽ 21:30, 25 May 2009 (UTC)
I run Twinkle, Friendly, Wikied, and reftools. I don't know if this helps, but after I asked for my monobook to be deleted and it got deleted the problem went away. Does that have any connection? -- Abce2| Access Denied 23:49, 25 May 2009 (UTC)
The WikEd extension is really annoying.. it's all screwy. At the same time it's too useful to really disable though, for me at least. Someone should really take a look at it. Disable text formatting while editing in the text box for example, and strip the formatting when pasting. That would help tremendously. Anyway, for my settings and browser and such, see here: Click Rocknroll714 ( talk) 01:23, 26 May 2009 (UTC)
I have found the possible cause and will put the 'new' wikEd (0.9.79c) back online. Chrome/Safari users, please click Shift-Reload to update! Sorry and thanks for the help, Cacycle ( talk) 02:41, 26 May 2009 (UTC)
When I enable, and then disable syntax highlighting, the following is left for my supposedly "unhighlighted" editor view. <font class="Apple-style-span" color="#0000E0">. It's a while since I used WikEd last, so i'm not sure how long this problem exists. — TheDJ ( talk • contribs) 20:23, 25 May 2009 (UTC)
I love Wik-Ed, but I would like to suggest 1 minor improvement. When I copy-paste text from another page, the original formatting is retained in the edit window—a copy-paste of a header appears really big, for example. I can put up with this, although I would rather it were corrected.
The bigger issue is that some copy-pastes (usually of multi-line template code), have dodgy line breaks in. For example, a copy-paste of:
{{Template:Example |1=abc |2=def |3=ghi }}
would come out with an extra line break above it. Deleting this line break causes the formatting to change to the following:
{{Template:Example |1=abc |2=def |3=ghi }}
If I delete that line break, it moves between the |1=abc and the 2=def. With larger chunks of code, this gets rather annoying.
I don't know if this is deliberate, or if it has been addressed before, but I thought I'd suggest it in case it was annoying anyone else. Dendodge T\ C 21:56, 25 May 2009 (UTC)
Just a small problem, when highlighting text that includes an image, pressing either the Fix Caps or Fix all buttons changes File: to the older Image: namespace. While this doesn't break anything, if there's the time it would be nice if this was fixed.
On another note, I prefer the new colouring, it is much clearer and less distracting. QueenCake ( talk) 21:31, 26 May 2009 (UTC)
This appears to be a Mac OS X interaction bug, since I experience the same problem with FireFox 3.0.4 on my Mac. Dnessett ( talk) 15:20, 2 June 2009 (UTC)
Problem identified (probably), but a not solution: This behavior seems to have nothing to do with Mac OS X. It appears to arise because I am using a DELL 30" monitor connected to my Mac (screen resolution = 2560x1600). I think the problem is CSS pixels are not screen pixels (see CSS pixels). The definitions of the Find and Replace combo boxes in wikEd.js use the px dimension, which do not map directly to screen pixels. The problem is the layered Find and Replace Select boxes (defined in wikEd.js as #wikEdFindSelect and #wikEdReplaceSelect) are not aligning properly to the top of the bounding box. They are then pushing the material below them into the edit area. This is seen in this screenshot. I have loaded wikEd locally on my personal wiki and played around with the parameters in WikEd.js, but have not been able to adjust them to get a good placement. To test my theory that this is related to my 30" monitor and not Mac OS X, someone with a 30" monitor connected to a PC should see if they have the same problem. (Note: there is a possibility that the problem has something to do with my graphics card, but I would like to eliminate the 30" monitor hypothesis before going down that alley.) Dnessett ( talk) 01:44, 6 June 2009 (UTC)
Then again, maybe not: I decided to wade through the explanation of CSS reference pixels given in CSS pixels. A CSS reference pixel is about 1/96 inch on a screen display meant for viewing at arms length (~28 inches). The DELL 30" display has a viewable width of ~26.25 inches. At 2560 pixels of width that means it provides 97.5 screen pixels per inch. So, a CSS reference pixel = 97.5 screen pixels per inch * 1/96 inch = 1.01 screen pixels. This is practically identical to a normal display and therefore insufficient to explain the FindSelect and ReplaceSelect field pushdown into the edit area. So, I am back at square one. Dnessett ( talk) 16:21, 6 June 2009 (UTC)
Problem Fixed: This was an extremely difficult problem to identify and fix. That I am not an expert in HTML or CSS is a gross understatement. So, I can only report my findings and hope those with a better understanding of both can elucidate. OK, enough whining. The problem is there is an interaction between class and id styles that leads to improper vertical alignment of the buttons and Find/Replace Select fields in the Find/Replace Button Bar. Some relevant styles specify vertical-alignment of text-bottom, others of text-top and still others 0%. The fix makes the vertical-alignment consistent by specifying vertical-alignment : text-top in the following style definitions - .wikEdButton, .wikEdButtonDummy, .wikEdFindComboInput, .wikEdCombo, .wikEdReplaceComboInput, .wikEdButtonUnchecked, .wikEdButtonChecked, .wikEdSummaryComboInput, .wikEdSummaryText, .wikEdSummarySelect, #wikEdFindText, #wikEdFindSelect, #wikEdReplaceText, and #wikEdReplaceSelect. One problem is I have no way of testing this fix on PCs (I use a Mac for most of my work). While I have a PC, my local test wiki on my Mac is not set up to serve other computers. Rather than going through the trouble of setting up a local network wiki server, I assume wikEd is installed on testwiki. Someone can make the indicated changes there to wikEd.js and test the fix on PCs. If the changes cause problems for PCs, at least the problem is identified and I assume some other approach can fix it for both PCs and Macs. As a side note, it is interesting that both Safari and Firefox on my Mac experienced the same problem. I can only assume that both browsers use a common library that causes the common vertical alignment problem. Dnessett ( talk) 00:02, 11 June 2009 (UTC)
I notice that the Toolbar Hide cookies expire after 30 days. Why not 30 years? I don't want to have to re-hide a toolbar I never use. Thanks. -- Armchair info guy ( talk) 01:33, 1 June 2009 (UTC)
As of recent, the script has been causing my browser(s) to become unresponsive while attempting to edit some articles.
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://en.wikipedia.org/?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:8823
This is happening with both Firefox 3.x.x under Windows 7 and with Firefox 3.0.9 under Ubuntu 9.04. wikEd version is 0.9.79c. — C M B J 19:16, 2 June 2009 (UTC)
I tried wikiED and I found that it was too cumbersome (sophisticated?) for me. But I really like the text highlighting feature. Can you make a version, or a customization, that strips out all the buttons and leaves just the text coloring? (In a totally separate matter, is it possible to optionally hide refs so they don't clutter article text?) Thank you in advance.-- HereToHelp ( talk to me) 22:39, 3 June 2009 (UTC)
Infobox insists on first letters of fieldnames to be lowercase. wikEd changes them all to uppercase. Example:
{{Infobox Saint | Name=Saint Paul
is changed by wikEd to: {{Infobox Saint |Name=Saint Paul **which does not work**
John 3:16 becomes John 3:16 **which does not work**
The issue seems to be that the empty parameter "||" which is used for a numbered Bible book like "|1|Corinthians" must be left blank for "||John"
Thanks... Afaprof01 ( talk) 17:16, 6 June 2009 (UTC)
description: when wikiEd is enabled chrome's built in spell check does not underline misspelled words. All other functionality of wikiEd works when enabled. Disabling wikiEd and typing new misspelled words shows them underlined.
steps to reproduce: Edit an entry and type a misspelled word.
attempts to trouble shoot:
Setup:
wikiEd: 0.0.97c G
browser: google chrome 2.0.172.30
script errors: none
browser add-ons: none
user scripts: none
OS: windows vista business SP1
—Preceding
unsigned comment added by
R.Vinson (
talk •
contribs)
23:13, 6 June 2009 (UTC)
If I have this
|
|
wiked formatter gives this
|
|
then, comments (<!-- -->) should not be modified inserting empty lines between them and the rest of the text, because it could lead to malfunctions. Example
|
|
will be modified in this way
|
|
-- 93.47.32.238 ( talk) 21:37, 10 June 2009 (UTC)
How do I disable wikEdFollowLinks? Following links do not work in Firefox on a Mac, so I want to disable the feature. Using wikEdFrameCSS['wikEdFollowLinks'] = false;
did not disable it.
Gary King (
talk)
01:35, 12 June 2009 (UTC)
var wikEdFollowLinks = false;
doesn't do it for me. I still get "ctrl-click" when I hover over links in the textbox.
Gary King (
talk)
02:48, 22 June 2009 (UTC)
Added Cmd-Click for Macs in version 0.9.82. Please could you check if it makes sense and if it works. Thanks, Cacycle ( talk) 03:39, 23 June 2009 (UTC)
wikEd automatically scrolls down to the editbox. However, if a page has an editnotice, this can cause you to miss it.
I propose the implementation of a simple check for <div id="editnotice
I have not closed the tag, as the id attribute ends in several different ways, depending on the namespace. If that string is found anywhere in the page, wikEd should not automatically scroll down to the editbox, as the editnotice should be read.
I have reproduced this on the latest version.
This is a bug with wikEd, and is common to all browsers.
fahadsadah ( talk, contribs) 14:56, 14 May 2009 (UTC)
Moved to botton, as this is still a problem, but now unnoticable.
Hi, I was wondering if it would be possible to make an alteration to how wikEd treats non-textual elements (inline citations, nav- and infoboxes, other templates, etc., maybe even tables) in the edit box. Right now, you color those differently, which helps definitely, but I'm wondering if you could encapsulate them in a show/hide collapsible <div>? It would be very helpful for some workshops for scientists that I've been invited to give.
I floated the idea yesterday at the Village Pump. The basic idea is to replace the "special" texts with a two-state tag like [citation]. By default, everything non-textual (e.g., the ref tags and the citation between) would be hidden within such a tag. But if the editor clicked on a particular [citation] tag, it would show everything within, and could be edited. Once the editing was done, the editor could click that tag again and it'd collapse again.
This approach might make the editbox version of the article more readable (inline citations can be a bear!) and closer to the appearance on the article itself. Do you think it's feasible? We wouldn't need wikEd's other amazing powers (although they'd be a big win), so if you needed to disable something to make this one trick work, it would be OK by us.
I really appreciate your help on this, and I think it could benefit the scientists as they take their first steps into Wikipedia. Please feel to e-mail me, if you think it'd be better. Thanks! Proteins ( talk) 23:04, 25 June 2009 (UTC)
Thanks! I do know the [1] button, but sometimes scientific/mathematical articles are so dense with references, that they still hamper readability despite the smaller text. Some citation templates can take up several lines each. Here's an illustration of what I mean. Another motivation is that many articles begin with an infobox, which occupies the full first screen; if that could be collapsed, so that the editor saw the lead text immediately...
I agree that these scientists can and will pick up wiki-markup quickly; I'm doing my best to put together good teaching materials. :) But at one workshop in particular, we've been allotted only 90 minutes. So I'd really like to "hit the ground running" with them, and not have to explain citation templates and infoboxes immediately. They'll be editing a variety of existing articles, so the problem of dense refs is real. WikEd will be turned on by default on their accounts.
During an earlier lecture to non-editors, I'll also be opening an edit window on a scientific article to demonstrate how Wikipedia works. If the content were readily understandable by them, that would be a huge win.
I appreciate the badly-formatted-wiki-text problem, but I really believe that the advantages of this approach outweigh its risks. The basic goal is to make the editbox article easier to read and navigate by showing simple wiki-markup (such as sections, wikilinks and italics) but hiding advanced wikimarkup (such as references, templates and infoboxes). Is it feasible, do you think? Thanks again for your time and help, Proteins ( talk) 05:49, 26 June 2009 (UTC)
Thank you very much, Cacycle; I'm grateful for your help. I'll work on adapting the CSS schemes and e-mail you with more details on the scientific workshops early next week. Proteins ( talk) 15:52, 27 June 2009 (UTC)
Simply awesome! That's just what I was hoping for. It should really help newcomers to read/navigate the page and to make their first edits. I tested the new feature on several pages and it worked great. I did notice two glitches, which I hope won't be difficult for you to fix. The first was the second long template on Amanita phalloides, {{ mycomorphbox}}; somehow the body of the template wasn't included in the TEMPL placeholder, perhaps because of some non-standard formatting?
The second was the coloring of tables, e.g., this edit section. Once a table is started, the coloring seems to extend for the rest of the article, i.e., it doesn't seem to recognize the table end symbol |}.
Would it be possible to collapse tables in the same way that you've collapsed references and long templates? I think that they're the last major impediment to readability, being unfamiliar in syntax and stretching over many lines.
Your work is exciting, and will be very helpful at these workshops. I have a few more ideas, but I'll send those by e-mail on Monday, if only to give you a breather. :) Thanks again! Proteins ( talk) 13:30, 28 June 2009 (UTC)
wikEd which worked ok on my Win7+FF3.6a1pre doesn't load on Kubuntu9.04+Konqueror (KDE4.2.2). No plug-ins. SkyBon Talk\ Contributions 16:15, 28 June 2009 (UTC)
A superb idea. I thought wikEd more or less had everything, but I was wrong!
Just a small suggestion: when references are hidden, a mouseover displays its content, but hides the templates within. Since templates such as {{ cite web}} are widely used for referencing, perhaps it would make sense to automatically expand the templates within a reference when it's expanded on mouseover.
On a side note: when is 1.0 due? :-) GregorB ( talk) 09:49, 29 June 2009 (UTC)
Hi Cacycle,
Great work on wikEd! I have a few more suggestions for your consideration, which might be helpful. The first one is the most important for the workshops, but also the most work. I'm grateful for whatever you can do, and leave all of these suggestions to your discretion whether they'd improve wikEd or not. Thanks, Proteins ( talk) 18:35, 29 June 2009 (UTC)
Perhaps you could add a special button that requests the PMID, launches an XML request and inserts the resulting full reference into the Wikipedia page?
:<math alt=""> Add formula here. </math>
Clicking one button is faster than typing it out, and I believe the format is standard.
Again, thanks for your help, Proteins ( talk) 18:35, 29 June 2009 (UTC)
If I have something like this
{{Stub
| arg
|}}
(last argument missing) button returns an error
{{Stub
| arg
|}
}
probably because |} is treated like a table element. Can you fix? -- 93.47.34.59 ( talk) 21:52, 29 June 2009 (UTC)
wikEd remembers whether I have wikEd enabled or not and then applies that the next time I open an edit page. That's good, but I'd like to instead force it to be disabled by default because it slows down the loading of pages, especially long ones, too much. How do I disable it by default instead of having it remember whether or not it was previously disabled? Gary King ( talk) 04:07, 30 June 2009 (UTC)
var wikEdDisabledPreset = false;
does not work for me. wikEd is still enabled based on whether or not it was enabled the last time I was in an edit window.
Gary King (
talk)
15:54, 30 June 2009 (UTC)
true
then it does indeed disable wikEd, but there is no way to reactivate it when I need it because none of the buttons created by wikEd appear, so this does not help.
Gary King (
talk)
15:57, 30 June 2009 (UTC)
Using wikEd 0.9.83a and Firefox 3.0.11, when I try to edit Rsync and expand the {{ Infobox software}} within, the latest_release_date parameter appears empty, but it isn't, it is populated with {{ release date}}, which is only visible once wikEd is turned off. GregorB ( talk) 08:48, 1 July 2009 (UTC)
Reference/template unhiding is apparently broken in Firefox 3.5 (wikEd 0.9.83a, WinXP SP3); mouseover does nothing. GregorB ( talk) 15:21, 1 July 2009 (UTC)
I recommend U+3000 IDEOGRAPHIC SPACE to be highlighted: it is occasionally treated as wide variant of U+0020 SPACE and therefore is forbidden on ja Wikimedia projects.
Regular square with dotted lines may be desirable for highlighting image (note that it is wide character --- as Chinese ideographs [kanzi] are wide). -- Hatukanezumi ( talk) 16:42, 1 July 2009 (UTC)
See title. Please change: (...) Please see edit window. — M C 10| Sign here! 23:00, 1 July 2009 (UTC)
{{
edit protected}}
template. — Martin (
MSGJ ·
talk)
06:13, 2 July 2009 (UTC)
Content hidden with Template:Hidden begin isn't working in wikEd's preview. The template isn't broken - it works in articles, and in WP's "Preview". I'm using FF 3.0.1 and the version wikEd supplied by "my preferences."
For example, "{{hidden begin|title=my title}}hidden content{{hidden end}}" displays as
my title [show]
with WP Preview (where "[show]" is clickable), but as
my title hidden content
with wikEd. — eitc h 21:22, 8 July 2009 (UTC)
Safari 4. page. Whenever I have WikEd enabled, suddenly i see the protected page warning twice after wikEd has loaded. — TheDJ ( talk • contribs) 18:37, 12 July 2009 (UTC)
Hi. The link for site-wide installation under "Installation" is not working. You have typed _ in stead of - between "site" and "wide". I'm not able to edit the page so I'm telling you. -- 79.160.203.21 ( talk) 06:25, 15 July 2009 (UTC)
Hi, I installed wikiEd just now as a gadget through the Wikipedia preferences, and while it's unfortunate that ref (un)hiding is broken on Firefox, wikEd looks like a great idea. A bug: It seems that wikEd breaks URLs with ampersands in them (at least, URLs in refs). In Firefox, it turns each ampersand into � (that's Unicode 0002 "START OF TEXT") and in Safari it turns them into "%02" (same thing?). While strictly speaking ampersands in URLs must be encoded, in practice everyone uses ampersands and it's really ungainly to encode all of them. (And in any case, it's unlikely that existing links on a page have their ampersands encoded.) Is this a known bug? Regards, Shreevatsa ( talk) 13:19, 16 July 2009 (UTC)
Sure. I should have been clearer: the bug is that when you click on the URL from within the wikEd textarea, it takes you to the wrong place. Here's a detailed description:
Hope you can reproduce this, Shreevatsa ( talk) 14:30, 20 July 2009 (UTC)
PS: Do you know if the "ref hiding" is broken in Safari too? Turning it on seems to hide {{ quote}} content too (in both Firefox and Safari), which is usually part of the article proper and need not be hidden. Regards, Shreevatsa ( talk) 16:02, 20 July 2009 (UTC)
Every time I click on "Toggle REF and template hiding" or "Toggle between classic text area and wikEd", the font size in the edit area grows. The only solution is to reload the page after clicking one of those buttons.
wikEd 0.9.84b G, Safari 4.0, Mac OS X 10.5.7, No user scripts -- UncleDouggie ( talk) 07:24, 20 July 2009 (UTC)
It's working now with wikEd 0.9.85c! UncleDouggie ( talk) 06:42, 21 July 2009 (UTC)
When I mouse over a reference or template it is automatically expanded. I'd prefer it if it only expanded when I click on it, because sometimes I accidentally hover over one and then it expands, and it's hard to make it collapse again because it doesn't always notice that I moused over it again. I usually have move the cursor a few times over it for it to recognize it. Gary King ( talk) 21:53, 21 July 2009 (UTC)
I just discovered wikEd and it seems great so far, but I'm missing one function: besides the normal 'create article link' button, there should be one that autoinserts the "|" character between the double brackets, and maybe some empty spaces before it, so creating alternate text for links would be speedier. I know I should learn the alt-code for "|", but I always copy it instead from somewhere, and I bet many others do this too.
Also, why don't common functions, like boldening, italicizing, have keyboard shortcuts? Poisonborz ( talk) 00:00, 25 July 2009 (UTC)
Hello, I'm using WikiEd (0.9.84b) with greasemonkey (firefox 3.5) on the french wikipedia, and I was wondering if this is possible to have the icon images stored locally, to speed up the load time.
Thanks for your work. MickaëlG ( talk) 20:16, 4 August 2009 (UTC)
I've just recently re-enabled wikEdDiff after having it disabled for about a year. The button doesn't show up in diffs though, even after I've hard refreshed. Gary King ( talk) 16:03, 7 August 2009 (UTC)