Wiktionary:Grease pit/bug reports

Definition from Wiktionary, the free dictionary
Jump to: navigation, search
This is an archive page that has been kept for historical purposes. The conversations on this page are no longer live.

Contents

Use of HTML codes for special characters in links

I was looking at the Most Wanted page and it shows a very ugly entry for (Zoöl (subject)), where the umlauted "o" appears as a question mark in a dark diamond. The writer represented to "ö" by using the HTML "ö" format. I changed a few of these to the Alt 0246 format and the characters were correctly represented. Should we be outlawing the use of HTML codes for special characters in links? We seem to be heading to a broader and more exciting variety of acceptable characters in titles than was ever imagined on Wikipedia. I think that's great! In the course of that, we might as well get rid of dead end options before doing so becomes a huge job. Eclecticology 06:28 Dec 18, 2002 (UTC)

The named-reference->character conversion code is currently hardwired to use an iso8859-1 table. Likewise, the numbered-reference->character conversion code is currently hard-wired to make UTF-8. ;) I'll see about fixing that. --Brion 06:56 Dec 18, 2002 (UTC)

OK, then it shouldn't be a problem if I use the "Alt " format for most 8859-1 characters. Ec

Ug. And for those of us who can remember the standardised entity names but not Alt whatever? (What is that, anyway, Mes$Winduhs?) Does it matter if the entity names map to 8859/1, doesn't Unicode embed 8859/1? Perhaps if it's a problem, the thing that munges wikicode to HTML or XHTML or whatever is fed to the browser, should accept and translate the standard entities itself.


Shakespeare links

New issue: There are now several links from articles marked like Shakespeare (source). That article is a redirect to w:Shakespeare which in turn redirects to w:William Shakespeare. That's where it should end-up. The path getting there is the problem, and the redirect entry in Wiktionary is not accessible for amendment since the trace back to the first redirect in Wiktionary does not show up on the Wikipedia article. -Ec

Workaround: http://wiktionary.wikipedia.org/w/wiki.phtml?title=Shakespeare (source)&redirect=no


Chinese font

Chinese font 睾 is romanized as follows,

YI 4 is wrong,

this is an organ in male body under penis,

it should be romanized as follows,

GAO 3

3Q~

Jacques Pascal Huang

2004/4/8 CST AM 3:05

"jumping" user toolbar?

I don't know if it's just me, but whenever I put my cursor over the user toolbar (the one on the top-right corner of the screen, if the MonoBook skin is used), it (the toolbar) jumps to the left. I find it kind of annoying. :\

I don't have a problem when I use the Classic skin, but for me, Wiktionary looks much better with MonoBook. --Ixfd64 09:06, 14 July 2005 (UTC)

I have this problem too, but I don't complain about quirks I've encountered (e.g. not being able to read the IPA symbols either) since I'm on an Asian computer system. Davilla 15:22, 25 July 2005 (UTC)



Search query

Hello. When I make a search for However. I get this messeage Badly formed search query. I think, such words should be better available by the search engine in a dictionay. -- Youssefsan

"However" is on a stoplist of common words that can't be searched. It seems to me that it would be of benefit to have some way of overriding this for the Wiktionary. At some point we will need to consider them in their own right. Eclecticology 02:56 Jan 13, 2003 (UTC)

The whole system of searching needs to be changed, for 1 we don't need to search for words within articles only the page titles. -fonzy

edited by Andrew Trott

I disagree with fonzy -- in my mind the only purpose for the Search button is to find words which are not page titles (and I have used it many times for that). If we just want page titles, we simply press Go. But yes, we do need to get round the stop list -- which of course Go manages. --Enginear 17:12, 5 October 2006 (UTC)

In the "Search" or "Go" mode, why doesn't Wiktionary offer similar words for searched words not found (similar to spell check)? Many times a user doesn't know the exact spelling, especially of uncommon words (e.g., "plebiscite").

't is query

I've tried to edit 't is (Dutch for it's), but it comes up as "/'t is" (with a slash--could have been a backslash too). I don't know if English has words starting with other characters than letters, but in other languages there are (Dutch: 's morgens, 's middags, 's avonds). AFAIK the glottal stop in South African languages is represented by "!" as in the name of the language !Kung. Can anything be done so everything shows up as it should? D.D. 18:43 Apr 28, 2003 (UTC)

Update: 't is starts with a backslash and !Kung seems to be working fine. But some words in other languages might start with still other characters. D.D. 19:00 Apr 28, 2003 (UTC)

I am assuming the problem is due to how the software works, and that character might be involved with the software, but i am just guessing. - fonzy

Wiki system date query

The mainpage says [[Today]] is [[{{CURRENTDAYNAME}}]], but when I first loaded the page on Friday, Oct 3, 22:54 UTC, it displayed as "Thursday", 2 Oct 2003. Only when I change and preview the page do I get Friday. Is this a bug? The page is probably cached somewhere, just make a minor change and the date will be right for some hours until midnight :-)

Note: The main page also says that the ISO date is 2003-10-2, which is very misleading (as it could be interpreted as the second day of the 10th week), but I guess that {{CURRENTDAY}} cannot be forced to display as 2 digits.





No Bug Reporting Directions

Is this really how you report a bug in the Wiktionary? If so the directions should be more explicit--it's far from obvious. It also doesn't inspire confidence that someone is reading these or acting on them.

Anyway, the bug is that the "quick jump to word beginning with letter" doesn't work. It only shows the first 500 or so words beginning with the specified letter and doesn't have any "next" button. At best it's only marginally useful. At worst, people see these lists and assume they're complete and that the word they're looking for isn't in the dictionary.


Searching for nonexistant word shows bogus $1 in google textbox

If you try to search for "asdf" or something equally bogus, the resulting page has two identical "search google" forms, the first one having $1 instead of the word in the textbox (but the second one has the correct word).

Error message

(This is moved from the beer parlour. Eric119)

I don't really know where to put this, but when I submitted some changes to ironing, I got the following message:


"

From Wiktionary, the free dictionary.

A database query syntax error has occurred. This could be because of an illegal search query (see Searching Wiktionary), or it may indicate a bug in the software. The last attempted database query was:

   UPDATE recentchanges SET rc_this_oldid=63074 WHERE rc_namespace=0 AND rc_title='Ironing' AND rc_timestamp='20040423143040'

from within function "RecentChange::save". MySQL returned error "1205: Lock wait timeout exceeded; Try restarting transaction".

"

(ps. when I hit reload, it worked fine again) Anyone who can 1) tell the right ones or 2) tell me who to tell? (or tell me not to worry..:-)

\Mike 15:43, 23 Apr 2004 (UTC)

wiktionaries and en:-type links

A link like en:Malta used to link to a page on Wikipedia, but now links to the page on Wiktionary. This may be useful for a link like es:Malta to link to the spanish wiktionary's corresponding page, but some articles (I have no idea how many, but I have seen it, e.g. Malta) used an type link (which is now broken) instead of a w:article type link (which still works). Given that an en: type link is not likely to be meaningful on en.wiktionary.org can we get at least this type to point back to Wikipedia? (see also Inter-wiktionary links) —Muke Tever 08:09, 3 May 2004 (UTC)

It seems as we could benefit from some sort of bot to change all links from [[en:link]] to [[w:en:link]]. The latter seems to work. \Mike 09:02, 3 May 2004 (UTC)
Oh, by the way, anyone knows how to make links from the 'pedia to non-en: wiktionaries? Whithout using the complete URL? \Mike
I've not been on Wiktionary since the start of April and back then there were NO other language Wiktionaries. I hadn't realised we couldn't put en: links any more so I've still been putting them. I'll change them now, but ultimately we de need a bot to change en: to w: on the English Wiktionary. Anyone no much about this or have another solution? --Rob 00:31, 23 May 2004 (UTC)

Bug on search failure page

When you perform a failed lookup on a word ("parbroil" for instance) the results page ( http://en.wiktionary.org/w/wiki.phtml ) lists both search boxes as Google (wikipedia has one Google and one Yahoo search box.) Additionally, the default text in the top box shows up as "$1", likely a scripting error as it should be the failed search term (same behavior as the second search box, which works correctly on this page.)

YAGSP (Yet Another Google Search Problem)

The Google site-search searches in http://wikipedia.org/. That should be updated to http://en.wikipedia.org/.

I suppose that depends on whether you want to search all lang's or just english? \Mike


Bug in Greek page titles with Χ χ Φ φ Ψ ψ Π π

Okay, so I clicked a link to χάλιξ (chalix), and the resulting page informs me I am Editing &Ch1;άλι&x1;... similar problems with Ἄλφα...

Heck. Apparently it does this for all Greek letters whose names end in -i: Χ χ chi, Φ φ phi, Ψ ψ psi, and Π π pi — something somewhere is turning it into a 1 when it makes page titles.

—I just checked and the URLs work properly (I can link to Μηχανή and get the right page), it's just whatever converts the Greek into entities for the displayed title does this. —Muke Tever 03:56, 8 Jun 2004 (UTC)


Bugs on et:Wiktionary

et:Wiktionary has a lot of bugs. The article counter has stopped on 46. There is no way to see which articles there are in the Wiktionary. No special page functions, nor all pages, nor new pages. Andres 19:48, 20 Jun 2004 (UTC)

Works for me. -- Tim Starling 02:03, 28 Jun 2004 (UTC)

Bug on sv.wiktionary

As I understand it, the random page should not direct the user to articles in the Wiktionary name space, as it does on sv:. Anyone knows anything about it? \Mike 08:56, 23 Jun 2004 (UTC)

That's because there were a whole heap of pages in the Wiktionary pseudo-namespace, which were apparently recreated after the namespace was changes. The following pages were recovered:

-- Tim Starling 02:03, 28 Jun 2004 (UTC)

The swedish wiktionary has some problems with identifying Å as capital å. The same goes for Ä/ä and Ö/ö. This allows us to create two different pages - one where first letter is capitalized, one were it is not, providing the first letter is å,ä or ö. Is this something that will be corrected as we get UTF-8, or is there something else around? \Mike 01:07, 22 Sep 2004 (UTC)

bugs on la.wiktionary

When I created a new talk page to an existing article (linear) I found that the page says:

Wiktionary does not yet have an entry for Linear.

I think it ought to be ... for Talk:Linear, i.e. to add the namespace. Not a major issue, though.\Mike 14:40, 11 Aug 2004 (UTC)


Save Page => Preview

Every so often, you hit the "Save Page" button, or press alt-S, and you get the Preview page instead of the page being saved. You might then have to try half a dozen times until it works. SemperBlotto 28 June 2005 13:53 (UTC)

georeactor

I posted a scientifically precise long definition of "georeactor" as well as a precise summary. An hour or two later, I discovered that the long definition had disappeared and only a different, and INCORRECT summary definition was in its place. What is happening here? J. M. Herndon mherndon@san.rr.com

Not a software bug, I've noted this on the (anonymous) user's talk. --Wytukaze 22:59, 15 July 2005 (UTC)

Server error for "Index of language indexes"

Clicking on the "Index of language indexes" on the Main page gives an error message:

Warning: strpos(): Empty delimiter. in /usr/local/apache/common-local/php-1.5/includes/Parser.php on line 1065

Nurg 22:50, 22 July 2005 (UTC)

That's a temporary problem with the Wikimedia apaches, and can happen on any page. It should be fixed soon enough. --Wytukaze 23:20, 22 July 2005 (UTC)

Position of '[edit]' links

When I view the colon page the [edit] links do not line up correctly. For example if I click "Derived terms [edit]" it opens the editor on "See also". Is it me or does the same happen to others?

Nick1nildram, that seems to happen sometimes when there is a template on the same line as a header (somewhere on the page), or if the header marks (the '=') are not properly aligned. \Mike 11:17, 20 August 2005 (UTC)

template:Rfd

Why has the {{Rfd}} template stop working on pages such as roundheels? -- Nick1nildram 19:35, 20 August 2005 (UTC)

new word templates for multiple word searches

The availability of templates is wonderful! There's a small bug for multiple word searches though. Spaces should be replaced with underscores for links to function. Possibly other character substitutions should be performed as well. Davilla 16:29, 31 August 2005 (UTC)

It should, yes, but this appears to be currently impossible in wikimarkup. See bugzilla:839. (In earlier versions of the software—i.e. before about a week ago—this was possible because Mediawiki:Nogomatch (which produces the links with the templates) used to allow HTML where this is not a problem, but HTML is now disallowed on it. —Muke Tever 20:53, 31 August 2005 (UTC)

Double Redirects not listed properly

Special:DoubleRedirects initially shows no entries. Changing 50 to 500 shows numbers 1 to 180. Next 500 shows numbers 501 to 529. Whats up? (numbers may vary as the entries get cleaned up) SemperBlotto 16:57, 31 August 2005 (UTC)

Magic caches. The whole list is cached, but it is 'smart' enough to know when its entries are no longer applicable and thus removes them from the cache. However it is apparently not smart enough to properly renumber what remains. (It shows 1 to 180 numbered thus because the numbering is done with an HTML auto-numbered list; presumably the internal enumeration, if any, is different.) —Muke Tever 20:42, 31 August 2005 (UTC)

incorrect statement of "Wiktionary does not yet have an entry for X"

If a page has no talk page, as in Talk:statistician as of this minute, the page has a header saying that "Wiktionary does not yet have an entry for statistician" when it should say "Wiktionary does not yet have a talk page for statistician", since the former sentence is incorrect. This is nit-picking, but it can't be hard to fix. Hogghogg 17:39, 16 October 2005 (UTC)

Actually it can, because the same messages (Mediawiki:Noarticletext if you're viewing the page, Mediawiki:Newarticletext if you're editing the page) is used, regardless of what namespace it is. Better would be a more generalized message such as "Wiktionary does not yet have a page by this title." —Muke Tever 20:20, 16 October 2005 (UTC)
If one writes "Wiktionary does not yet have a {{NAMESPACE}} page for {{PAGENAME}}.", that ought to do the trick. Jon Harald Søby 10:53, 24 December 2005 (UTC)

Bug in display of category entries when passed a parameter

There is a subtle bug in the display of category entries. If an entry is passed as in "category:potato|foo" on page "bar", the entry is alphabetized as "foo", but is still displayed as "bar". The bug is that the category page display uses whatever you give it after the "|" for alphabetizing the list, but ignores that passed parameter when displaying the entry. It should show the entry as "foo" alphabetized under "foo". This behavior is important in the Wikipedia in order to properly alphabetize names, but is less important here in the Wiktionary, so as such is a low priority bug. Brholden 00:29, 2 November 2005 (UTC)

Dear Sir,

An error message comes up which states "404 Page not found". Can you download this dictionary to Palm OS 5 handheld? How much memory do you need to download it? I just looooooove this dictionary.

Best, David

Polish not possible

I've noticed some shortcomings in the availability of certain character sets. In particular, Russian e-umlaut is not available in the Cyrillic character set, and a-ogonek, and e-ogonek are not available as Polish characters. These letters are essential for these languages, so why aren't they available from the edit pages? --EncycloPetey 10:51, 24 December 2005 (UTC)

Arabic script

In Special:Recentchanges, the Arabic entries come on the right. I know that Arabic is written left-to-right, as in the following:


(diff) (hist) . . Wiktionary:Arabic index; 21:30 . . Jackbrown (Talk) (suggested reorganization of Arabic/English dictionary)
(diff) (hist) . . gadolinium; 21:29 . . Hyark (Talk) (→External links - cat fi:chem elem)
(diff) (hist) . . N رأس; 21:28 . . 196.218.4.51 (Talk)
(diff) (hist) . . Hall; 21:28 . . Uncle G (Talk) (Category:English proper nouns)
(diff) (hist) . . User:Vildricianus; 21:27 . . Vildricianus (Talk) (→Current Mission)

--Wonderfool 21:38, 5 January 2006 (UTC)

Add <meta name="keywords" content="word, define word"> to each definition

Both Yahoo! and Google support "define word" as a special query which returns their local dictionary definitions. I noticed that Wiktionary articles are not returned for these special defintion queries. If "define word" was added to the meta keywords for the page, this would increase the chances that the Wiktionary article would be returned for these "define" queries.

Add <meta name="description" content="first defintion" to each definition

When I did the query word wikipedia on Yahoo! and Google, I noticed that the page descriptions for the wiktionary articles were pretty weak. You might consider creating a defintion template that incorporates the pimary defintion in the description for each entry.

For instance, juggernaut might have the default description:

Noun: juggernaut, The term juggernaut is used to describe any literal or metaphorical force regarded as unstoppable; that will crush all in its path.

In the title, add "juggernaut: definition from Wiktionary, the free dictionary"

What links here not working

For templates especially, using What links here is not finding all pages that link.

--Connel MacKenzie T C 07:11, 11 February 2006 (UTC)

no edit tab

illegal does not allow edit. Something's wrong with the page, and it must be screwing up the parsing. That or some funny HTML is stopping the rendering on my machine. No way to tell what's going on in the page code. 59.112.41.146 10:47, 23 February 2006 (UTC)

Works OK for me - I have cleaned it up. SemperBlotto 10:56, 23 February 2006 (UTC)

Strange. There was the start of a comment tag showing that no longer appears in the history. Possibly some sort of database corruption, who knows? Davilla 17:53, 23 February 2006 (UTC)

not a bug report as much as a question

preface: I am not accustomed to capitalizing anything I don't absolutely have to over at pedia, so maybe just have to get used to that here. now, for entry titles I understand why there is a distinction. but everytime I type special:whatever or wiktionary:bug reports the word after the colon has to be capped?? could this be changed? is there an advantage to keeping it how it workz currently? let me know. thankz, LingLangLung 02:26, 5 March 2006 (UTC)

It used to be the same over here as it is over there, it is because *pedia is not first letter case sensitive (w:Word == w:word) but we recently changed this (and every) wiktionary to be case sensitive (Word =/= word) for a variety of reasons. It is handy to note that while you do have to capitalize everything that requires it, we have many shortcut pages (WT:BP = Wiktionary:Beer_parlour, also WT:A for admins) so you can still be a little lazy with the typing ;) Happy editing, - TheDaveRoss
dude. w:SA is a frikkin double yo. LingLangLung 08:35, 6 March 2006 (UTC)
Indeed. Likewise w:sa (in deference to w:SA.) --Connel MacKenzie T C 23:34, 22 April 2006 (UTC)
It's because the first-letter decapitalization is a feature intended for a few languages (chiefly Klingon) where upper and lower case letters have different meanings entirely (Klingon |q| is pronounced /qʰ/, an aspirated uvular stop, and |Q| is /q͡χ/, an uvular affricate). In these languages the distinction in letters is needed in all namespaces, so there was no option to limit it to the main namespace. This feature was not built or intended for Wiktionary, where it is ill-suited. —Muke Tever 23:01, 22 April 2006 (UTC)

Confirmation clears edit summary

When submitting external links to an edited page, I get a confirmation notice with an image of text to type. On this intermediate page the edit summary is reset and has to be re-entered.

(Also + tab at top of this page would be nice, in addition to Make a Report link.)

∂ανίΠα 21:19, 13 June 2006 (UTC)

+-tab should be there now. \Mike 12:39, 9 August 2006 (UTC)

Memory of username

I would consider it odd enough that "Remember this user" is not checked when logging in, as though it remembers me, but doesn't remember that it remembers me. However, it's questionable that this checkbox even does anything. When logging in under a new user name, and not checking the checkbox, it subsequently remembers the new username anyways. In other words, the function is applied regardless. Davilla 17:14, 18 June 2006 (UTC)

I haven't tried checking for this site, but "Remember this user" is usually intended to mean "Do not require me (or anyone else using this computer) to sign in or use a password in future, but allow automatic login as this user", rather than the sense you are implying: "Enter the last used user name as default, to save unnecessary keystokes for those (the majority) who do not have multiple personalities." (And I do hope you get DAVbetter soon) ;-p ... O no, I think it's catching — εηĝίпær, no, ENGinear, no...try very hard...think straight...repeat to myself, "I am not a cipher, I am an Enginear, I am not..." 01:41, 1 July 2006 (UTC)
The checkbox is unchecked by default, for people logging in in public places (cybercafes, libraries, etc.) in case they close their broswer (or their cafe-time runs out and their browser closes,) before they log out. --Connel MacKenzie 19:25, 11 July 2006 (UTC)
I understand how it works now. It's a little troubling that it would remember the username though, even if it doesn't automatically log in, when the box is unchecked. It's also somewhat annoying that it doesn't automatically check the box if it had been checked last time. Essentially all-or-nothing makes more sense to me. Right now the checkbox only applies to the critical stuff. Username, always remembered, and whether the checkbox was checked, always forgotten, are not tied to it. But this isn't the bug I thought it was. DAVilla 05:29, 25 September 2006 (UTC)
But, it is your browser that is filling them in. Because you told it to, at some point. Or am I completely misunderstanding what you are reporting? --Connel MacKenzie 05:32, 25 September 2006 (UTC)
Really? Damn it I hate Windows. No, I think you're right. My new roommate speaks Chinese, so I'll ask to go over the security settings, which I can't read on this machine. DAVilla 05:36, 25 September 2006 (UTC)

Word of the Day Archive

It seems that regardless of which month is being viewed it has March up the top next to the days (although the days change with the month requests). —This comment was unsigned.

This is being fixed by bot, as I type this. --Connel MacKenzie 02:31, 5 January 2007 (UTC)

Feature request: link all words

Wiktionary! Why isn't every single word in the definition a link back to it's Wiktionary definition by default? That would make Wiktionary unbeatable dictionary source and also if the links turned red that didn't exist would show what words are missing. Paul D.

Firefox has that feature built in, and several alternates exsist to doubleclick a word on any website and look up that word here. But Wiktionary prefers to put emphasis only on key terms, as appropriate. Auto-linking all words prevents proper linking of multi-word terms (e.g. kick the bucket) which would be a horrible loss. --Connel MacKenzie 19:20, 11 July 2006 (UTC)
Okay but 1. Not everybody uses Firefox 2. word groupings could be maintained as needed so that if your kick the bucket gets maintained with brackets around the whole then it's a unit. Otherwise it's good to link to each word independently so you can understand what kick the bucket literally means.
Linking every word also puts a very large load in the servers which as we know constantly need updating as more and more people use Wikipedia and friends. Every linked word means a database lookup. Linking just relevant words is a lot less stressful for the servers. Also, many of us don't want every word linked - it's just too distracting. Now what should be possible is for somebody to use the ToolServer to make some kind of tool that shows pages with every word linked, preferably looking at an offline database rather than the main one. It would be a very useful tool but there would be some difficulties including correct parsing to avoid re-linking words that are already linked as a group, and handling apostrophes and hyphens, both of which are sometimes part of a word and sometimes punctuation. Another concern is that Wiktionary is for all languages and quite a few major languages such as Chinese, Japanese, and Thai do not put spaces between words so that any automatic treatment is not really possible and would produce garbage results. — Hippietrail 17:41, 13 July 2006 (UTC)
Your general demeanor is troubling. First there should be little or no load on the servers. Every linked word does NOT necessarily mean a database lookup. The URL is known only by the word (http://en.wiktionary.org/wiki/word). You must be joking about "many of us don't want every word linked". Because many of US do want every word linked. Normally when going to a dictionary to find something that is defined with words you also don't understand will result in more lookups. Distracting? lol that's funny. Entries still will get parsed so that corrections can be made for apostrophes and hyphens; there's no difference between that and kick the bucket Chinese & Japanese -- sorry about ya. This works for the majority of languages. Anyone who has learned a foreign language knows how beneficitial this feature would be. —This unsigned comment was added by 12.135.52.82 (talkcontribs) 2006-07-14 13:31:03.
Anon, your specific demeanor is troubling. Hippietrail is right about the server load. Each page save would require significant database load in order for the server to determine which words should be blue-linked and which red-linked. Did you even bother to look at a URL for red-links before posting above? If not, look at the link for this. Hippietrail is not joking when he says that many of us don't want every word linked. Editors here generally make good decisions about which words to link, as Connel explained above. Note also that only lemmata get full definitions here, so having the software automatically link everything would force the reader to click through the inflected form to get to the entry with meaning. Your anyone who has learned a foreign language knows how beneficitial this feature would be... is not only wrong, but rude. Rod (A. Smith) 04:45, 16 July 2006 (UTC)
Anon1 is right. If all words are entries then they are all blue; meaning no database lookup.
This is a pretty good idea. The problem discussed is only to red/blue the words. What if the color stayed black? It wouldn't be "distracting", wouldn't require a database lookup but may or may not have an entry. Just a thought.
Hey, why not? I still think phrases should be linked as they are, but otherwise any unlinked word could very easily be linked in black, with no server load at all. DAVilla 05:11, 25 September 2006 (UTC)
As a WT:PREF, yes, I could see that. Once they load a page, every word not already linked could get one, from a small Javascript bookmarklet. If we wanted to get really fancy, they could each be spell-checked and given a red background (if not wikified, and kicked out by the spell check.) Or course, the toolserver would melt. (30,000 anon users x 3 pages x 200 words would be a lot of redundant spell checking, for just one day.) --Connel MacKenzie 09:57, 29 January 2007 (UTC)

wikipedia.org blocked in Yahoo Messenger

I can't seem to get wikipedia links to work in Yahoo Messenger with BT Communicator (BETA) MyYahoo Module (7.5.0.1).

Don't know how to contact Yahoo about this.

Has anyone else noticed this? —This unsigned comment was added by 84.13.34.183 (talkcontribs) 2006-07-19 11:47:47.

Are you having trouble clicking through links or creating them? If you're having trouble clicking through them, what happens when you try? Rod (A. Smith) 06:37, 21 July 2006 (UTC)

{{en-noun}} cosmetic problem

Dates on headers in word of the day archive...

Dates on headers in word of the day archive for future dates all show today's date, not the day corresponding to that word being posted as word of the day. For example, looking at the archive for November 2006, every word has a posting date of Novemeber 6, as it's today. Not true though surely? In fact not only on future dates, but past months also. —This unsigned comment was added by 80.177.121.117 (talk).

This is a feature of the {{wotd}} template. It prevents us from having to type each full date manually. It is also why the day of the month displays above each entry in regular text. --Versageek 16:16, 6 November 2006 (UTC)
A possible remedy would be to change the last parameter to be just the date, instead of the page edit link, then 'bot change all the entries. The template could then display the comparison date format in the display portion (which would probably be reported as another bug here) yet still work for the current edit links.
The other 'fix' would be to add a display-date parameter, and 'bot-fill the entries. This however, seems pretty yucky for all future WOTD entries. --Connel MacKenzie 19:15, 20 November 2006 (UTC)
This is being bot-fixed as I type this. --Connel MacKenzie 02:32, 5 January 2007 (UTC)

Erroneous 'doesn't have a page' message for capitalised word at the start of a line.

Actually, the message is literally correct since the search in case sensitive, but surely this feature needs to be addressed as it makes the whole project look very Mickey Mouse.

I tried to work around the problem on a definition I added a few das ago by creating a page for the capitalised word and just including the non capitalised one. It worked beautifully but within a minute or so it had been deleted leaving an ugly red ling that looked very amateurish.

Sometimes it's possible to recast the sentence without making it look too gruesome but it's a pain and I've noticed not everyone bothers. Moglex 09:51, 16 November 2006 (UTC)

  • The simplest solution is to "pipe" the word - e.g. [[simplicity|Simplicity]] gives Simplicity SemperBlotto 09:55, 16 November 2006 (UTC)
Great. That'll work for new ones, thanks. As for the ones already lying around, I feel a robot coming on. —This unsigned comment was added by Moglex (talkcontribs).
I tried 'botting this a couple ways, but none have been satisfactory. I think a cleanup list will be the way to go. But I'm not sure how the cleanup list will be refreshed; once something has been struck from the list, it probably shouldn't be re-added after the next XML dump.
That is to say, most of the resultant redlinks are valid (e.g. German nouns pointing to capitalized varient, where a lower case entry exists but the German noun has not yet been entered.)
Additional suggestions for a viable approach are appreciated. --Connel MacKenzie 19:11, 20 November 2006 (UTC)
Ideally the parser would capitalize the first unparenthesized character of the resultant text within an enumerated item list. (The stuff in parens we already have a great deal of control over.) Talk about fixing a solution though! Good luck changing your mind on that style. DAVilla 17:53, 27 December 2006 (UTC)
Actually, this is so common it might be better to just incorporate it as [[word|]], which is currently equivalent to [[word]]. DAVilla 03:42, 28 December 2006 (UTC)


page cuts off

At Template talk:context I get only <script type="text/javascript" src="/w/index.php?title=-&a in the left-hand corner. The HTML code likewise cuts off at that point. Temporary problem? DAVilla 17:48, 27 December 2006 (UTC)

Worksfineforme. Did you try the normal stuff, e.g. logout, view page, log back in, view again? Restart browser, reboot, etc? --Connel MacKenzie 03:19, 28 December 2006 (UTC)
But why should only that page have problems, and reloading do nothing? Very well, it's back. DAVilla 03:25, 28 December 2006 (UTC)
Actually, when I've seen errors like that, it is usually due to a tag not being closed properly somewhere in the various Javascript snippets. Does the behavior change when you log out? --Connel MacKenzie 19:55, 2 January 2007 (UTC)

script error in tooltips because of poor handling of innerHTML

/* Wiktionary-specific tooltips*/
...
function headingToolTips() {
...
   // level 3, 4, and 5 headings depend on their content
   var h345 = new Array('h3', 'h4', 'h5');

   for (var j = 0; j < h345.length ; j++) {

     var allh345s = document.getElementById('bodyContent').getElementsByTagName(h345[j]);

     if (allh345s != -1) {
       for (var i = 0; i < allh345s.length; i++) {

         // part of speech
         var ht = allh345s[i].innerHTML.replace(/^(?:\d+(?:\.\d+)* )?(.*)/, "$1");
         if (ht.search(/editsection/) != -1) {
           ht = ht.split('')[1];
           ht = ht.split('')[0];
         }

I'm using: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)

when I load: http://en.wiktionary.org/wiki/ageless I get an exception. What follows is what happens when I let the script debugger walk through, first using my own variants of the above, and then executing the actual code:

ht = allh345s[i].innerHTML.replace(/^(?:\d+(?:\.\d+)* )?(.*)/, "$1");

"<SPAN class=editsection>[<A title=\"Edit section: Etymology\" href=\"/w/index.php?title=ageless&action=edit&section=2\">edit</A>]</SPAN> <SPAN class=mw-headline>Etymology</SPAN>"

ht.search(/editsection/)

12

ht.search('<span class="mw-headline">')

-1

ht = allh345s[i].innerHTML.replace(/^(?:\d+(?:\.\d+)* )?(.*)/, "$1");

"<SPAN class=editsection>[<A title=\"Edit section: Etymology\" href=\"/w/index.php?title=ageless&action=edit&section=2\">edit</A>]</SPAN> <SPAN class=mw-headline>Etymology</SPAN>"

(ht.search(/editsection/) != -1)

true

ht = ht.split('<span class="mw-headline">')[1];

undefined

ht = ht.split('</span>')[0];

'ht' is null or not an object


--
The problem is that the code is assuming SPAN will be lowercase as part of innerHTML. it shouldn't do that. It could use /<span class="mw-headline">/i and /<\/span>/i instead. or it could be removed.

—This comment was unsigned.

Interesting that the double quotes are stripped off, as well as "span" being converted to "SPAN". --Connel MacKenzie 03:47, 28 December 2006 (UTC)
OTOH, there is no excuse for using innerHTML. I'll try to remember to fix this soon. --Connel MacKenzie 09:46, 29 January 2007 (UTC)

Logins, don't

I'm running Firefox (latest version), on linux. Cookies are enabled. I login as 'fastluck' and am told that I have logged in successfully. Then I attempt to edit my preferences to change my email address (or edit a page--doesn't matter). Next, I am sent to a page that tells me I need to log in. This continues until I give up.

Try logging out first, and then log in again. —Stephen 04:12, 20 January 2007 (UTC)

Stephen,

Thanks. I had already tried that and it didn't change anything.

John

In the Special:Preferences [misc] section, there is a "Disable page caching" item, that may be confounding your login. If I recall correctly, that item is worded opposite the behavior, so try toggling the setting. Also check your FF cache settings, and restart your browser after you log out. I have not experienced the problem you report in a very long time now (on FF, IE, Netscape, Konqueror, lynx, w3c, etc.) --Connel MacKenzie 09:42, 29 January 2007 (UTC)


I'm having a problem with logging in. I've tried using Opera9 and IE7. On both browsers, wiktionary tells me I need to have cookies enabled. I thought I did, but still cannot log in. What kind of cookies are Wiktionary looking for? I don't have any cookie problems with the wikipedia sites. --67.135.143.106 19:40, 5 March 2007 (UTC)

The same exact software is used to perform the logins at both places. You may have exemptions for *.wikipedia.org but not *.wiktionary.org (*.wikibooks.org, *.wikinews.org, etc.) --Connel MacKenzie 19:43, 5 March 2007 (UTC)
Thanks. I haven't figured it out. But its something in my ZoneAlarm. --Wiciwich 19:54, 5 March 2007 (UTC)

Results problem

When doing a special search for "far idiom" I find that I cannot get beyond the third page of the results, even though there's supposed to be quite a few more entries (147 of them) -- it stops first item of the third page -- perhaps there's some invalid character in the text of that item?

Enovickas 17:01, 26 January 2007 (UTC)

No, there is nothing wrong with the item. This occurs with many such searches, where it claims to have found more pages than it actually displays. I don’t know the technical reasons for this, but it seems to be nothing more than a counting inconsistency. Perhaps it is counting the number of occurrences rather than the number of pages, and it appears more than once on some pages. —Stephen 17:11, 27 January 2007 (UTC)
In Special:Preferences [search] tab, you can select all namespaces to be checked. The Lucene search doesn't know a user's preference when it counts the potential matches, so if you have the default three namespaces selected (only) it will consistently give misleading results. --Connel MacKenzie 09:44, 29 January 2007 (UTC)

Two web page suggestions

1. At http://wikipedia.org/ - the header tag says the charset is UTF-8 but there is a lot of stuff on the page (repeated on many other pages) that all of my UTF-8 browsers and editors show as question marks. (While still rendering correctly some of the Arabic and Chinese)

UTF-8 is an encoding scheme. It enables your browsers to figure out what character is intended. If you don't have those fonts loaded on your computer, (Control panel: Regional and Language Settings) you will see question marks or boxes. I'm not sure how Firefox works around that limitation, but it seems to do a great job of rendering characters that other browsers do not. --Connel MacKenzie 04:56, 17 March 2007 (UTC)

2. On the search page, where there are numerous checkboxes for areas to search - I recommend putting a non-breaking space between the check box and its item. Also for any spaces within item names. Leave a 'normal' space between items. This will prevent a check box on the end of a line with its label at the beginning of the next line.

That is a good suggestion, however, that text is auto-generated by the MediaWiki software, so fixing that will take a while, probably after someone files a bug report on bugzilla. --Connel MacKenzie 04:56, 17 March 2007 (UTC)

—This comment was unsigned.

Please sign your posts with ~~~~. Thanks. --Connel MacKenzie 04:56, 17 March 2007 (UTC)

Missing Devnagari Characters

Hi. I was trying to correct the spellings of Hindi words typed in Devnagari script and to my great surprise many alphabets are missing. Most of the half letters cannot be typed. Characters for "Ksha", "shra", "tra" etc simply do not exist! What can be done about it? Msddn 17:08, 26 April 2007 (UTC)

Please supply the characters that are missing at MediaWiki talk:Edittools#Devanāgarī and one of us will try to get them in, soon. --Connel MacKenzie 17:22, 26 April 2007 (UTC)
The words that you have corrected were already spelled correctly. It seems that you do not possess the appropriate fonts for viewing Unicode characters. I suggest you obtain one. Half letters can be typed by the use of hala.nt, which is the appropriate way. To spell ksha you will have to type . --Dijan 19:25, 26 April 2007 (UTC)
You probably have a font that does not allow for the correct display of characters by the use of the hala.nt and instead it assigns a unit to each half letter and ligature as well. Please obtain a font, such as Xdvng.ttf for Devanagari, that is able to correct this error. --Dijan 19:28, 26 April 2007 (UTC)

http://hu.wiktionary.org/wiki/User:hu-hr/e  ???

Hello, Please help me. I was using this link/adress for some of my translations, but now I can't: http://hu.wiktionary.org/wiki/User:hu-hr/e . is this some where else? Would you give me the new adress? Thank you! Sylvia

You might want to try an admin at the hu Wiktionary, who would be able to see the history of the deleted page. DAVilla 14:38, 3 May 2007 (UTC)


werewolf

It could be just my machine, or my work's network, but every time I go to werewolf I get this error: Appliance Error (internal_error)


An unrecoverable error was encountered: "" This problem is unexpected. Please use the contact information below to obtain assistance.

For assistance, contact your network support team.

Any thoughts? sewnmouthsecret 21:09, 8 October 2007 (UTC)

{{worksforme}} - try calling your ISP? --Connel MacKenzie 21:12, 8 October 2007 (UTC)
Hmm. I'll try at home and see if it works there; if so I'll leave it be. Thanks for checkin. sewnmouthsecret 21:13, 8 October 2007 (UTC)

what it says on the tin

Unable to revert to previous version as it seems to have no history now. DAVilla 07:01, 3 December 2007 (UTC)

Never mind. DAVilla 07:03, 3 December 2007 (UTC)

claim

I assume it is a bug. I can only see the top half of the page, but I can see the full editing script. I cant see any sort of nowiki in the edit page. - Algrif 17:23, 3 January 2008 (UTC)

OK found it. missing trans-bottom. - Algrif 17:27, 3 January 2008 (UTC)

free-form, free form and freeform

There are 2 definitions of the same term in these page. Cumeo89 18:25, 8 February 2008 (UTC)

See my changes. If you find such instances in the future, you are welcome to edit.
This isn't really a "bug report" since it doesn't concern the software. DAVilla 18:39, 8 February 2008 (UTC)

Transclusions on protected pages

Unprotected pages that are transcluded on protected pages and would normally show edit tabs do not, despite the subpage itself being editable if the user is knowledgeable enough to find it. DAVilla 02:03, 11 February 2008 (UTC)

If the page is that important (like the Main page) then "cascading protection" can be switched on which stops the subpages from being editable. Or are you saying something else, in which case could you give a link? Conrad.Irwin 23:32, 12 February 2008 (UTC)
What I said is true of Wiktionary:Votes, which does not have cascading protection turned on. You have to log out to see that nothing on the page is editable, although Wiktionary:Votes/2008-01/IPA for English r for instance is. DAVilla 04:25, 15 February 2008 (UTC)
Wiktionary:Votes is semi-protected, which is why it is not editable by anonymous users. Special:Log shows that it was protected for "edit=autoconfirmed" by Connel in September 2006. Mike Dillon 06:02, 15 February 2008 (UTC)

Error message

I have a couple of times the last half hour or so gotten the message "Error, Setup.php must be included from the file scope, after DefaultSettings.php" instead of the actual page. As in, a blank page with this as it's only text. It's infrequent, and irregular, so I can't really pinpoint what's been happening. It's occurred both when searching and clicking on existing links. Anyone knows what's going on? \Mike 11:16, 13 February 2008 (UTC)

Something weird

Something is wrong with the database or software. Look at this last change to Template:patrol box. It's just a single letter. But while the old revision can't find the misspelled name in the Template space, the current revision is looking for "patrol box/disply" in the Main namespace. I think it may have something to do with the fact that I overrode a redirect at Template:patrol box/display which was pointing to a page different from the one I was moving there. For a time, the revision history of that page said there was only one deleted edit, but later it was corrected to four. DAVilla 04:21, 15 February 2008 (UTC)

Never mind, the problem was here. I never knew what would happen if a template referenced itself. How strange. DAVilla 16:35, 15 February 2008 (UTC)
Historic note: When templates were first turned on, the vandals of the day set to building recursive (and later, circular) template references which caused over five minutes of disruption. Imagine not being able to save an edit for five minutes! The horror! --Connel MacKenzie 06:23, 19 February 2008 (UTC)


Feature request: link all words

Wiktionary! Why isn't every single word in the definition a link back to it's Wiktionary definition by default? That would make Wiktionary unbeatable dictionary source and also if the links turned red that didn't exist would show what words are missing. Paul D.

Firefox has that feature built in, and several alternates exsist to doubleclick a word on any website and look up that word here. But Wiktionary prefers to put emphasis only on key terms, as appropriate. Auto-linking all words prevents proper linking of multi-word terms (e.g. kick the bucket) which would be a horrible loss. --Connel MacKenzie 19:20, 11 July 2006 (UTC)
Okay but 1. Not everybody uses Firefox 2. word groupings could be maintained as needed so that if your kick the bucket gets maintained with brackets around the whole then it's a unit. Otherwise it's good to link to each word independently so you can understand what kick the bucket literally means.
Linking every word also puts a very large load in the servers which as we know constantly need updating as more and more people use Wikipedia and friends. Every linked word means a database lookup. Linking just relevant words is a lot less stressful for the servers. Also, many of us don't want every word linked - it's just too distracting. Now what should be possible is for somebody to use the ToolServer to make some kind of tool that shows pages with every word linked, preferably looking at an offline database rather than the main one. It would be a very useful tool but there would be some difficulties including correct parsing to avoid re-linking words that are already linked as a group, and handling apostrophes and hyphens, both of which are sometimes part of a word and sometimes punctuation. Another concern is that Wiktionary is for all languages and quite a few major languages such as Chinese, Japanese, and Thai do not put spaces between words so that any automatic treatment is not really possible and would produce garbage results. — Hippietrail 17:41, 13 July 2006 (UTC)
Your general demeanor is troubling. First there should be little or no load on the servers. Every linked word does NOT necessarily mean a database lookup. The URL is known only by the word (http://en.wiktionary.org/wiki/word). You must be joking about "many of us don't want every word linked". Because many of US do want every word linked. Normally when going to a dictionary to find something that is defined with words you also don't understand will result in more lookups. Distracting? lol that's funny. Entries still will get parsed so that corrections can be made for apostrophes and hyphens; there's no difference between that and kick the bucket Chinese & Japanese -- sorry about ya. This works for the majority of languages. Anyone who has learned a foreign language knows how beneficitial this feature would be. —This unsigned comment was added by 12.135.52.82 (talkcontribs) 2006-07-14 13:31:03.
Anon, your specific demeanor is troubling. Hippietrail is right about the server load. Each page save would require significant database load in order for the server to determine which words should be blue-linked and which red-linked. Did you even bother to look at a URL for red-links before posting above? If not, look at the link for this. Hippietrail is not joking when he says that many of us don't want every word linked. Editors here generally make good decisions about which words to link, as Connel explained above. Note also that only lemmata get full definitions here, so having the software automatically link everything would force the reader to click through the inflected form to get to the entry with meaning. Your anyone who has learned a foreign language knows how beneficitial this feature would be... is not only wrong, but rude. Rod (A. Smith) 04:45, 16 July 2006 (UTC)
Anon1 is right. If all words are entries then they are all blue; meaning no database lookup.
This is a pretty good idea. The problem discussed is only to red/blue the words. What if the color stayed black? It wouldn't be "distracting", wouldn't require a database lookup but may or may not have an entry. Just a thought.
Hey, why not? I still think phrases should be linked as they are, but otherwise any unlinked word could very easily be linked in black, with no server load at all. DAVilla 05:11, 25 September 2006 (UTC)
As a WT:PREF, yes, I could see that. Once they load a page, every word not already linked could get one, from a small Javascript bookmarklet. If we wanted to get really fancy, they could each be spell-checked and given a red background (if not wikified, and kicked out by the spell check.) Or course, the toolserver would melt. (30,000 anon users x 3 pages x 200 words would be a lot of redundant spell checking, for just one day.) --Connel MacKenzie 09:57, 29 January 2007 (UTC)
We could use the feedback system to gauge how many users would actually like it. As a dictionary we have a slightly different aim than an encyclopedia, but Wikipedia decided against the "Allwiki" idea (see w:Wikipedia:Build the web). --Bequw¢τ 15:27, 22 February 2008 (UTC)

Wiktionary does not yet have an entry for NAMESPACE:Article

See https://bugzilla.wikimedia.org/show_bug.cgi?id=13636 Jidanni 22:51, 6 April 2008 (UTC)

Resolved (to my satisfaction anyway). Conrad.Irwin 23:00, 6 April 2008 (UTC)

cusor

Is it possible to default the cursor to the search box? I have no technical knowledge, just want to be able to access the dictionaries more easily.

We would like to make that happen as well, although there are certain technical restrictions with the system that we use. See this thread for more info. --Bequw¢τ 16:02, 15 April 2008 (UTC)

Weird edit

I recently unified my accounts on Wikipedia. I first visited Wiktionary a few days ago and just made an edit. Then I checked my contributions and found it lists an edit I didn't make. Did someone own this account before I came here? Fisdof9 04:25, 5 June 2008 (UTC)

They are probably edits that were transwikied from another Wikimedia site. Mike Dillon 04:39, 5 June 2008 (UTC)

Error at gride

At the entry gride, the gerund is given as "grideing" and the past tense is "grideed" (instead of "griding" and "grided". What are we going to do about these words that drop the E? 75.58.19.21 04:22, 9 July 2008 (UTC)

Fixed. Just put in the proper forms. —Stephen 11:55, 9 July 2008 (UTC)

Internet Explorer 7 search-box

Not sure if this is a bug exactly. For users of Internet Explorer 7, the search box at the top right of the toolbar allows for adding an array of different search providers. In order to do so, you must first go to the home page of the search provider you wish to add, and type the word "TEST" (in all capitals, without the surrounding quotes) into the search box & click "ENTER". You then copy the link from your address bar of the resulting page, and paste it into the "Find Search Providers" form for I.E. Doing so adds the chosen search provider to the drop-down list on your toolbar. I have a number of different providers, of all different types. Wiktionary was one I definitely wanted to add, however, Internet Explorer wouldn't recognize it (an error message pops up saying "the search results URL must contain the word test- please check the URL, etc, etc"). I tried several times, still getting the same error message (despite the fact that the search results URL did contain the word test! Here is the URL: http://en.wiktionary.org/wiki/test

Maybe because the word TEST, although in all caps in the query, was not in all caps in the results page URL. It would be great to have Wiktionary in my search providers list, but for some reason it will not go through.

—This comment was unsigned.

Did you try pressing "Search", instead of "Go?" -Atelaes λάλει ἐμοί 23:50, 4 August 2008 (UTC)
I see the problem. If you type "TEST" in the search-box and click "Go", it sends you to <http://en.wiktionary.org/wiki/Special:Search?search=TEST&go=Go>. Since we don't have an entry for TEST, but do have one for test, that page redirects you to our entry for test: <http://en.wiktionary.org/wiki/test>. You then gave that URL to Internet Explorer, and as you've guessed, it couldn't process that URL, because it contained test instead of TEST. Since this is probably a common problem, I think it might be worth it to us to create an entry for TEST, perhaps with an {{only in}}-type message. —RuakhTALK 16:04, 5 August 2008 (UTC)
You realize you answered your own question? Just change "test" to "TEST" in the URL you are entering in the IE box. However a better URL to enter would be http://en.wiktionary.org/wiki/Special:Search/TEST That, of course, doesn't help anyone who doesn't happen to read this ... you might use Firefox, Wiktionary search is built-in. We should create a TEST page I think. Robert Ullmann 16:24, 5 August 2008 (UTC)
Added TEST, I think it will help. (If someone actually reads it, they will do even better!) Robert Ullmann 16:34, 5 August 2008 (UTC)
Very strange. I use IE7, but I don't remember ever using that search box. I've just had a look and I've got Google as default + Wiktionary (en) - where did that come from? SemperBlotto 16:27, 5 August 2008 (UTC)
There was some widget or code floating around that would add the wikt to IE, before IE7 added the present configuration option. Presumably you must have tried it? Robert Ullmann 16:34, 5 August 2008 (UTC)

Error in Appendix List

I have found a small but annoying problem inthe appendix list. When I try to scroll through the list of appendices, I find that the next page has only one entry-which, strangely begins with the letter G. Mathmagic 00:40, 20 August 2008 (UTC)

WT:WOTDN

Could someone take a look at WOTDN. I'm not sure what is causing the prob. I tried to correct it, but made it worse, so undid. -- ALGRIF talk 14:10, 26 November 2008 (UTC)

Fixed. Two relevant aspects of wikisyntax:
  1. that anything from <!-- to --> is taken to be a comment, and is ignored, almost without exception, meaning that editors can see it when editing a page, but it has no effect on processing; and
  2. that a line that starts with whitespace is taken to be "preformatted", meaning that it's displayed somewhat like plain-text;
together conspired to create weirdness.
RuakhTALK 03:13, 27 November 2008 (UTC)

Auto Log Off On Edit Selection

Whenever I select to edit a file for the first time while logged on that day, I automattically get logged off, much to my chagrin. --Dictionman 22:32, 16 December 2008 (UTC)