Wiktionary:Grease pit/2007/February

Sorry for the delay. The logo contest finalised and the logo is now ready; the image Image:WiktionaryEn.svg is uploaded to Commons, but needs uploading over the default Wiktionary logo by an admin. The favicon chosen, Image:Wiktfavicon en.svg, is also uploaded; the file appears very small, but is scalable for use in Sister Projects etc. Smurrayinchester 22:22, 15 January 2007 (UTC)

Also, logos for the French, Chinese, Japanese, Hebrew, Russian and Korean Wiktionaries are also ready (see Commons:Category:Wiktionary). Could any speakers of the above languages please inform the above Wiktionaries? The logo has already been set up on the Vietnamese Wiktionary. Smurrayinchester 16:15, 16 January 2007 (UTC)

one: we would have to have a vote here, since this logo is seriously disliked by a number of people, who think the current logo is just fine

two: we would need a new logo that is not a blatant violation of the Hasbro/Spears trademarks Robert Ullmann 15:04, 17 January 2007 (UTC)

Not sure when this changed, about when I was in Rwanda last week ... the definition of the history tab was changed on the wikt, maybe here, maybe by meta. Anyway, it breaks the code in pywikibots. It will raise NoPage on any page get call. To fix, edit wikipedia.py, in function getEditPage, change:

RversionTab = re.compile(r'<li id="ca-history"><a href=".*title=.*&action=history">.*</a></li>')

to

RversionTab = re.compile(r'<li id="ca-history"><a href=.*title=.*&action=history.*</a></li>')

I don't know if this is specific to en.wikt, and I'm not reporting this on SourceForge: their bug procedure is beyond ridiculous. Robert Ullmann 16:51, 16 January 2007 (UTC)

Yes, an extra DIV has been added at the WikiMedia software layer, wrapping the "tab" headings for some reason. Do you syncronize with SVN daily? I'll point the #pywikipediabot channel to this conversation, now. --Connel MacKenzie 07:32, 17 January 2007 (UTC)

Someone asked a while ago (here or BP) if it was possible to generate a list of the oldest red links in the wikt. (It is possible, and not terribly difficult, if one used the entire XML dump with page histories, and a day of compute time. ;-)

I was thinking about this because I flooded Special:Wantedpages with pinyin links a month or so ago, rendering it useless for updating Wiktionary:project-wanted_articles. But it still isn't very useful as there are too many entries with multiple links that aren't good candidates for wanted articles. (Need more English for one thing.)

Occurred to me that while oldest redlinks is hard, listing the 4-5000 redlinks from the oldest articles would be fairly easy: User:Robert Ullmann/Oldest redlinks.

The first 4000 red links occur in the first 1940+ articles ... some of them are good candidates for new entries, some are bad links (e.g. the accordion reference to Mark Twain should be to the 'pedia), some are bad format of one kind or another. But lots of good stuff! Robert Ullmann 15:24, 17 January 2007 (UTC)

elephant flipping ? ! (see elephant) Robert Ullmann 15:55, 17 January 2007 (UTC)

Neat! Well done. --Connel MacKenzie 19:25, 17 January 2007 (UTC)

How about from the least recently edited articles? DAVilla 21:38, 17 January 2007 (UTC)

That's at Special:Ancientpages, isn't it? Or do you mean the redlinks on those pages? --Connel MacKenzie 01:45, 18 January 2007 (UTC)

Since I installed Firefox 2.0 the shortcuts for preview (Alt-p), save (Alt-s), user page (alt-shift-.) etc. no longer work. JS is enabled and works, since for example the edit bar above the edit window is present. This is the case on three separate computers, on both Windows and Linux. Anybody else experience this, what can be done? henne 11:30, 25 December 2006 (UTC)

Alt-SHIFT-p, Alt-SHIFT-s work for me (preview/save) is this what it was before?, and alt-shift-. works ... Firefox 2.0.0.1 Robert Ullmann 18:00, 25 December 2006 (UTC)

Anything identified in Tools, Java Script Console? --Connel MacKenzie 01:52, 26 December 2006 (UTC)

It has the error

Error: Components is not defined
Source file: chrome://fdm_ffext/content/fdm_ffext.js
Line: 67

about 100 times, (it seems to have to do something with Free Download Manager, but his is not installed under Linux, so shouldn’t be the problem) and once the following:

Error: ht has no properties
Source file: http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=-&action=raw&smaxage=0&gen=js
Line: 453

Clicking on the last gives the following line in the source code:

         } else if (ht.match(/^Etymology(?: \d+)?/)) {

I have no idea. Thanks for helping. henne 17:06, 29 December 2006 (UTC)

Thank you! That last error certainly seems to be the culprit. (For future reference, you can clear the JS console, then repeat the error, to see only the relevant error message.) I'll see what I can do to MediaWiki:Monobook.js#Wiktionary-specific tooltips for it now... --Connel MacKenzie 20:04, 30 December 2006 (UTC)

Another problem showed up now:

Warning: Onbekende eigenschap ’spacing’. Declaratie genegeerd.
Source file: http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=fight&diff=prev&oldid=1920557
Line: 0

The first line means: Unknown property ‘spacing’. Declaration ignored.

It still does not work. henne 16:52, 31 December 2006 (UTC)

Well, I fixed the bad template that had the evil "spacing: 0px;" thing. But as that is merely a warning, it wouldn't have had the effect of stopping everything, that you describe. Questions: 1) are you using Monobook skin? 2) Does the behavior change when you log out, (i.e. is it only broken when you log back in?) --Connel MacKenzie 19:23, 1 January 2007 (UTC)

1) Yes, 2) it doesn’t work even when I am logged out. After clearing the Javascript error console, hitting Alt-p gives me no new entry in there. henne 11:25, 8 January 2007 (UTC)

Still no solutions here? henne 14:35, 19 January 2007 (UTC)

Guys, what's up with all this JavaScript mumbo jumbo? All you need is Google. (Also, access keys normally have nothing to do with JavaScript whatsoever.) Go to about:config (write about:config in your URL bar), and change ui.key.contentAccess to 4, and Alt will be the access key again. Jon Harald Søby 09:10, 20 January 2007 (UTC)

Ok, you’re right. Should’ve read Roberts first comment better: you need the SHIFT for those shortcuts. Sorry to have bothered you. But ah well, it isn’t bad that a few minor JS errors have been solved on the way ;-) henne 14:34, 21 January 2007 (UTC)

Under my userpage, I keep several /todo lists. I regenerate most of them after each XML dump. On the surface, they are a useful hitlist of cleanup items. On closer inspection, their static nature makes them hard to use.

What do people think of the idea of me turning them into additional cleanup categories? Should I consider bot-adding cleanup tags, instead? Or should I just leave them as they are?

--Connel MacKenzie 07:53, 22 January 2007 (UTC)

I apologize for wasting everyone's time with my ignorance, but I keep finding this template: Template:polytonic, and I don't know what it's used for. The template is used only on words in Greek font (and I believe it's only used on Ancient Greek words). It appears to reference some similar templates in other languages, and it generally appears to make the targeted word appear in bold. But I can't for the life of me see any other benefit to it. Can someone help me out? Thanks. Cerealkiller13 20:40, 29 December 2006 (UTC)

If you pull open the page on an edit, you'll see that it also cross links to a whole series of interwiki locations. I'm not sure whether or not it's desirable -- just noting it. --EncycloPetey 07:48, 30 December 2006 (UTC)

The interwiki links are just to the templates on other wikis. (pointless for templates, but eh). What the template does is identify the included text in html/xml as Ancient Greek; this allows browsers to select fonts. In some browsers the user can select their preferred fonts. (In Firefox Tools/options/fonts/advanced) The template doesn't bold the word, but your browser is selecting a bold (or bolder) font. We have a number of these, see Category:Script templates. It also uses a CSS class (polytonic), so you could add something to your monobook.css to change the display if you wanted. Robert Ullmann 12:50, 30 December 2006 (UTC)

And you are correct it is for Ancient Greek, modern Greek should use {{ELchar}} if desired. Robert Ullmann 12:54, 30 December 2006 (UTC)

Does this aid users who might not be able to see the fonts otherwise, or does it simply allow only the users who would be able to read the word without the template to read it in whatever font they desire? Cerealkiller13 19:15, 30 December 2006 (UTC)

With the current browser versions, it will only affect the font selection; in a few cases in IE this is needed to make the characters appear rather than boxes, but I don't think this applies to Greek. With older browsers, these templates (particularily {{unicode}}) were critical to making the text appear. There are still some cases: compare (with unicode template) phah-pho̍k-á and (without) phah-pho̍k-á — in IE the first renders the o and combining ' (but still incorrectly ;-), the second displays a box. In Firefox, either works and renders correctly. Robert Ullmann 20:53, 30 December 2006 (UTC)

I can say from personal experience that IE has converted some Ancient Greek characters to mystery boxes rather than displaying the desired character. This is a problem for any character marked with a spiritus asper or a spiritus lenis, both of which are quite common in Ancient Greek entries. I'd say that given what Robert has said, the template is quite useful and should be used more often, if anything. --EncycloPetey 22:56, 30 December 2006 (UTC)

Thank you very much for your input. However, it seems slightly impractical to me to have every Greek word on Wiktionary encased in this template, and I wonder if there might be a more efficient way of ensuring people see foreign characters. My vision runs something to this effect: Someone writes a page with instructions on how to enable one's browser to accept the characters. We could then create a template which would go at the top of every Greek article and would say, "Having trouble seeing characters in this page? Click here for instructions on how to enable your browser to see them." Sadly, again I must admit that I lack the expertise to write such a page, and so would be dependent on someone else's benevolence for such a task. Is there already such a page? Would anyone be willing to write one if there isn't? What do you think about this idea as opposed to the polytonic template? Cerealkiller13 01:54, 1 January 2007 (UTC)

Ultimately it comes down to who will shoulder the burden. Do we tackle the problem ourselves behind the scenes (as with a hidden template), or do we set the burden on the user (by directing them to do such-and-such). I know in my own case, I often don't have the option of altering browser settings, such as when I'm using a computer from a school or university site. I would therefore prefer to tackle the burden at this end so that users made impotent by their serving institutions may still benefit. --EncycloPetey 02:06, 1 January 2007 (UTC)

Quesiton: How would you sugest we handle Greek words in translation tables? --EncycloPetey 02:07, 1 January 2007 (UTC)

An excellent point which I had not thought of. Yes, it certainly is better to do what we can on this end to ensure users can see stuff. My next question is then what proportion of users will the polytonic template help. Would it allow most users who could not otherwise see the Greek see it, or will the majority still be in the dark? It's my impression that it would only assist a rather small group of users who have Ancient Greek fonts on their computer, but whose browsers do not recognize it without help. Is this incorrect? And I must admit that my solution will certainly not help users see anything on translation tables unless they take the initiative to click on the link to the article on the word itself. Cerealkiller13 20:44, 1 January 2007 (UTC)

No one has any idea as to the answer to my question? Cerealkiller13 06:40, 4 January 2007 (UTC)

To directly answer your question: it is moot, there is no user-side fix short of loading fonts that don't come with Windows. (or telling the users to use Firefox? ;-) It isn't a "small group of users" that have an Ancient Greek font: it comes with Windows, built in, pretty much everyone has the font. The trick is forcing IE to use it, and that's what the template does. Robert Ullmann 08:33, 4 January 2007 (UTC)

Well, I don't agree with the approach, if that's what you are asking. Either all computers will eventually have all the needed fonts, or we'll have downloadable images for them, or something. But server-side fixes shouldn't be usurped by user instructions without a very good reason. --Connel MacKenzie 06:54, 4 January 2007 (UTC)

Agreed, to be sure. But, what I'm asking is, is the polytonic template really fixing things for many people? Because, while I agree that a fix on our side is the best option, I think a user side fix is better than nothing, at least until we can come up with something better. Cerealkiller13 06:59, 4 January 2007 (UTC)

It is only needed for Ancient Greek ("polytonic" after all), but still is needed there. A lot of users will see better rendering, since the IE defaults (without loading anything not out-of-the-box) will otherwise display boxes for the combining characters. Compare ἀποδεικτός (with the template) and ἀποδεικτός (without). Firefox displays the correct character (with the spiritus lenis) if the template is used, and correctly most of the time without. (Sometimes you see alpha with some other diacritic, clearly there is some subtle and sporadic bug ;-) IE displays correctly with the template, and a box without. There is no reason why the browsers can't do the right thing themselves, Firefox does well, while IE is simply broken. It used to be much worse; when the browsers get fixed, we'll drop the template(s). (All of the above results on WinXP, with both IE and Firefox at default options, plus loaded East Asian font support) Translation tables should use polytonic for Ancient Greek translations; nothing is needed for modern Greek. Robert Ullmann 08:21, 4 January 2007 (UTC)

While I get no boxes on my goddamned IE (with or without the template), all I get is a useless little dot above the alpha (or maybe it's a vertical line, it's difficult to tell). But IE makes no distinction between οἰ (without template), οἰ (with template), οἱ (no template) οἱ (template). However, if you're reasonably confident that it does make a difference for a lot of users, I'll start using it. Thanks very much for all your help. Damn Microsoft! Cerealkiller13 08:43, 4 January 2007 (UTC)

At IE 6.0.2900... on XP, I get boxes without the template (in your example) and the correct iota-spiritus combinations with the template. Robert Ullmann 08:52, 4 January 2007 (UTC)

Oh. I'm using IE 7.0.5730. And on closer inspection, there may be a difference between the two breathing marks (regardless of the template), but it's incredibly hard to distinguish. Also, I get a box for iota subscript (regardless of the template). You? ὁ ὀ ό ὸ οͅ (with template) ὁ ὀ ό ὸ οͅ (without) Cerealkiller13 09:11, 4 January 2007 (UTC)

Now that's weird. I currently have access only to Safari (the other computer has parts on order), and everything looks fine except the iota subscript displays to the right of the omicron on my screnn unless I'm in the editing window, in which case it displays under the omicron as it should! --EncycloPetey 13:59, 4 January 2007 (UTC)

How odd. Does the template make any difference with this issue? Cerealkiller13 22:54, 4 January 2007 (UTC)

None whatsoever; looks the same with or without the template.. Each kind of Mac I've used to look at Greek does not require any sort of template to see the characters, unlike the various PCs I've used. --EncycloPetey 01:26, 5 January 2007 (UTC)

Addendum: I have a working PC again. Without the template, the omicron with iota subscript appears as a box. With the template, the iota subscript doesn't show, but at least I can see the omicron. --EncycloPetey 18:33, 8 January 2007 (UTC)

May I ask what the OS, browser, and browser version number are? Cerealkiller13 19:44, 8 January 2007 (UTC)

On the PC, the Mac, or both? For the Mac, I use a MacBook laptop running Mac OS X 10.4.8 (8L2127); Safari as the browser. I'll have to check the PC tomorrow, but I use IE for that and a recently updated OS. For the PC, I use Windows XP Professional 2002; IE 6.0 as the browser. --EncycloPetey 00:42, 9 January 2007 (UTC)

<shocked disbelief> The version that doesn't even have tabbed browsing? How is it possibly to "wiki" at all, using IE 6?</get Firefox rant> --Connel MacKenzie 18:12, 24 January 2007 (UTC)

Come to think of it, that's rather disheartening, I'd almost rather the user see a box than the wrong character (even if it is just an iota subscript). Cerealkiller13 20:45, 9 January 2007 (UTC)

Could Wiktionary:Requests for deletion/Others be set up for automatic archiving by Werdnabot? The page is starting to get rather long, and there are resolved issues dating from June and July still on the page. No archive yet exists. --EncycloPetey 17:13, 23 January 2007 (UTC)

I'd rather solidify our WT:RFD archiving procedures a bit more. Perhaps the RFDO archive should be combined with the RFD archive? (Just a thought.) That is, RFDO is separate from RFD for three reasons: #1) reduce volume on RFD, #2) to make sure things (templates/categories especially) are orphaned properly before being deleted, #3) to make sure other namespaces get adequate follow-up a week or two after being deleted. But the archives of activities may not need the same level of separation? As a side-note, RFDO is much smaller (currently) than WT:BP, even though WT:BP is archiving at 14 days right now. So I assume this is not an urgent request? --Connel MacKenzie 16:56, 24 January 2007 (UTC)

I have been discussing how to handle spelling variants with another user. At the moment, there are two approaches currently in use:

1. Have a separate page for each variant spelling, with the full content in each. Advantage: NPOV (especially when used for variants of the color/colour variety). Disadvantage: Duplication of content. This is a bad from a database point of view, as duplication invariably leads to inconsistency - if one page is edited but not the others, the pages fall out of synch and can even end up being contradictory.
2. Have one page with all the content on it, and redirect or cross-refer the pages for all variants to this page. Advantage: No duplication of content, so no possibility of inconsistency arising. Disadvantages: POV; does not work when different spellings have different senses (eg, "program(me)", which is "programme" in Commonwealth English in the senses of TV/radio show, booklet, schedule of events, etc, and "program" in US English, but "program" in both varieties of English in the computing sense).

I think there is a solution that has the advantages of each approach without their disadvantages. I'm not sure if it has been suggested or tried before, but I have thought of it before.

The content of the pages is written as if for all variants and is put into a template which is then used in the page for each variant. As the content is in one place, there is no duplication. As the content is held separately from each page, this is NPOV. Special cases such as "program(me)" are easily handled by labels against the relevant sense:

<number> (computing) (program in all varieties of English) ...

Could this be used to put the Great Wikipedia "colo(u)r" Debate to rest once and for all? — Paul G 08:57, 11 November 2006 (UTC)

I've suggested this at least twice in the last fortnight (although I don't think I called the included page a template) but no one has commented on the suggestion that I've noticed. It seems the obvious solution.

I tried it once but within minutes someone had changed it to an approach that required the user to click through a manual 'redirect'. Moglex 10:52, 11 November 2006 (UTC)

What doesn't work about that approach (in the past exact same experiments) is:

1. Invariably, (and I do mean invariably,) POV removals are made.
2. The commingly prevent the needed, natural branching of the entries. In different regions/continents, some words simply mean different things. Shoe-horning all meanings to the British variety is not the right approach. Allowing American entries to grow, allows them to reflect the American meanings. Allowing Indian entries to grow, allows them to reflect Indian meanings.
3. The "duplication is bad from a database perspective" is a hoojum. The data being represented is different, therefore the data in the database should be different.

Only the parts that truly are common should be template-shared. In color/colour, the terms share some/most translations. For translators, it is easy to miss one or the other, so combining the translation sections makes sense. But perhaps an even better approach would be to further atomize the sharing, so that only common sub-sections of a translation section are shared. I've not seen a WikiMedia way to do so, however, such entries could conceivably be 'bot-synchronized. (For additions, if not for removals.)

There is no silver bullet. Continued proposals to comingle things that truly are not the same is still not going to work. --Connel MacKenzie 18:06, 12 November 2006 (UTC)

Connel, I have been mulling this over for some months since you took the time to explain it to me, and I'm coming to the conclusion that we are giving undue prominence to the the fact that, although there are strong (and perhaps in some cases nationalistic) feelings about the particular regional (even "national standard") spellings of words like color/colour, we are nonetheless making unduly heavy weather of them because we are confusing the issue of regional spelling with that of regional variations of meaning.

We have managed without much fuss to comingle the meanings of such words as fanny (see below) and to table in spite of 100% incompatability of US & UK meanings. However color/colour, where 5 or 6 of the total 9 definitions we now have are shared, is seen as a problem. (I believe color#6 is used in UK too.)

I am not suggesting that the whole entries should be combined -- I have been convinced that all separate spellings should have their own page, each eventually with cites using exactly that spelling -- but (if software limitations are not a problem, which I suspect they may be) each common definition should be shared. Translations (glossed to the appropriate definitions) would follow the defs. If that is impracticable at present, then the current situation may be the best we can do.

The downside of splitting the different spellings, ie not getting to know how "the others" use a word, can be dealt with, albeit imperfectly, by glosses or usage notes, as prominent as is appropriate to each case. And I do think that alternative spellings should be subject to CFI in the normal way, def by def (whatever CFI becomes in the future). I think that it should be no more or less difficult to propose frictive in any particular meaning than it should be to propose fricative. However, if (as perhaps in this case I hope) no one loves frictive enough to cite it, then it should be deleted. --Enginear 11:39, 13 November 2006 (UTC)

I can see the logic in what you are saying, but the downside of not comingling is that, for example, if a Canadian and Austrailian each spell widget differently, and the entries are kept separate, then the Canadian will never become aware of the nuances of the Austrailian word and vice versa.

An amusing example of this is when Americans come to the UK and start talking about 'fanny-packs'. A lot of smirking results. In the UK, 'fanny' is a synonym for quite a different part of the anatomy (albeit one which leads to the term being a little more accurate when you consider where they are usually worn).

A banal example, but it does illustrate why it can be a good idea to keep words which people think mean the same thing (and those spelt with only one letter difference between regions would be a prime instance) whould be kept together. Moglex 19:29, 12 November 2006 (UTC)

A belated note to Moglex and those who still wonder why color and colour have to be on separate pages:

It's a "least among evils" compromise. While there are some who believe that color and colour are very similar words that ought to share most of the same information, there are others who believe that they are completely different words, with not only different spellings, but different definitions and etymologies as well. If anyone proposes merging the two entries somehow, they (and the rest of us) must endure howling recurring flamewars explaining how it's out of the question. If the entries remain separate, on the other hand, the worst that happens is that a certain amount of similar information is duplicated, and any changes going forward potentially have to be made in two places. Trying to coalesce the shareable information via template transclusion or other tricks is theoretically possible (and has even been tried at least once), but ends up being too much work for too little gain.

My advice to anyone who wants to absolutely avoid redundantly-specified information and duplication of effort is: check out WiktionaryZ, where that's the focus. (This is advice I ought to follow myself, because I hate redundantly-specified information and duplication of effort.) Notice, buy the way, that the distinct color and colour pages are hardly the only example of redundant information we've got here: for example, the fact that Katze is the German word for cat is specified in two completely separate places -- or four, if you also include de:Katze and de:cat.

Insisting on a computer-science-theoretical minimum set of nonredundant information, noble a goal though that may be, is simply not a priority under the current Wiktionary scheme. It's not supported by the software, and it's not important to a majority of the regular contributors. Duplication of effort is a nuisance, it's true, but we've always got more editors and bots to take care of the drudge work, so we muddle through.

—scs 21:58, 19 November 2006 (UTC)

I can see why, for pragmatic reasons it is not possible to retro-merge the two pages (although I think people who claim that the words are qite different need a bit of a reality check. I don't think any of the current major dictionaries make any overall distinction on that basis, and readers from one spelling block have no trouble with works originating from another, at least on the basis of these particular differences).

There are, however, many places where there is no entry for one version of an 'ise' verb or an 'ize' verb POS. I would like, in those cases to create a page with the missing word that simply contains two lines, one saying 'alternative spelling of xxx' and one including the extant page. The technology is there and it works beautifully. The user goes straight to the information they require and any changes made are effective for both roots.

If anyone in future objects that the words should be different, then the case(s) could be fought one at a time, although judging by the speed with which the one instance of the above scheme I created was zapped there wouldn't be a lot of discussion!

It's not a matter of cluttering up the database (given that it contains all the edit revisions for every page I don't think a few spelling variations are going to cause it problems). It's a matter of giving the user the best service which means they should go directly to the most complete revison of the word they enter. The zapped case I mentioned above ended up as 'alternative spelling of ]' which is most definitely not the way to present the user with a pleasant interface.

Moglex 08:43, 20 November 2006 (UTC)

What specific example are you calling "the zapped case"? Color has the same etymology as colour? Color has the same meaning as colour? Your POV is not lexically oriented. --Connel MacKenzie 19:21, 23 November 2006 (UTC)

Actually, the English variation problem is negligable compared to Asian languages. Take a look at how the same word has to morph across multiple entries:

1. 点钟 (Simplified Chinese characters)
2. 點鐘 (Traditional Chinese characters)
3. diǎnzhōng (Pinyin for Mandarin entry)
4. tiám-cheng (POJ for Min Nan entry)

Note what happens to the example sentences as you look at the different entries. This is a case where the "spelling" and the meaning change. Now, imagine that I wanted to create separate entries for more than one phonetic system (see w:Template:Pinyintable and w:Template:POJtable for the most popular). Furthermore, what if I wanted to add Cantonese or a half a dozen additional Chinese dialects?

The template idea has been tried before. The reason that I have not used it is because it actually creates more work, because I would have to figure out a consistent way to untangle this mess. I'm open to any workable suggestions to this issue, but so far, creating separate entries has solved a lot more problems than it has created.

A-cai 22:25, 13 November 2006 (UTC)

I find it difficult to understand why we should have entries for romanizations, unless they are independently attested. -- Visviva 08:10, 22 January 2007 (UTC)

Mandarin, Min Nan, etc are very frequently written in romanizations in ordinary everyday use. Any common word will appear frequently. It is just easier to write a lot of times, so blogs and emails are very commonly in (e.g.) pinyin. (These cases are not like, say, languages written in Greek or Cyrillic.) Robert Ullmann 20:57, 25 January 2007 (UTC)

I'm fiddling with Werdnabot - the security enhancements for sub-page catches didn't have GP nor BP tagged properly as exceptions. So on tonight's run, it should archive November. I'll hand-edit section zero to then archive December tomorrow night. Then the next day, I'll set this archiving back to "14" days into Wiktionary:Grease pit archive/{{CURRENTYEAR}}/{{CURRENTMONTH}}. --Connel MacKenzie 20:06, 22 January 2007 (UTC)

Done (WT:GP and WT:BP.) This page shouldn't need human intervention anymore, for archiving. --Connel MacKenzie 18:00, 24 January 2007 (UTC)

• For both here and the beer parlour, do people like the new archiving? Is it meeting expectations? Minor improvements desired? Any other general comments? --Connel MacKenzie 04:26, 26 January 2007 (UTC)

In line with the recently concluded vote, and policy at WT:CFI and Wiktionary:Reconstructed terms, I have done some work on the {{proto}} template. (Amid yet another inane argument. Why do PIE/Proto- proponents always have to have such obnoxious POV? Are they trying to convince themselves?)

Takes multiple arguments, formats a phrase of an etymology. See fire for an extreme example.

If you add:

.proto-lang-ref (display:none)

to your .css file, it will suppress display of Proto- language references. Robert Ullmann 17:31, 25 January 2007 (UTC)

In fire, why is there an extra </DIV> in the etymology section? Was a tag not closed in the template, resolved later by MW software in the etymology section?

I've noticed the same POV, but had always assumed it was in response to my brusque manner. Maybe they are upset that their "hard work" (systemic copyright violation) isn't well received? To be fair, it is clear they they each believe themselves to be acting in good faith. Equally clear, is the fact that they are not.

Certainly WT:PREFS will need an item to show PIE information for the people that want to see it. --Connel MacKenzie 22:42, 25 January 2007 (UTC)

I don't see an extra /DIV tag. The template uses one SPAN (well, two counting the embedded Unicode call). Seems to be closed properly.

They all are very insistent that the stuff must have value, when saying *haglaz is the source of hail adds utterly nothing given that the definition of *haglaz is "the imagined word hail came from" ... and saying Hagel and hail maybe came from the same word? of course, that's what cognates are ... sorry, preaching to the choir.

Btw: do you mean systemic or systematic? (both make sense, with different meanings) Robert Ullmann 23:18, 25 January 2007 (UTC)

I still see the extra DIV here. And yes, I meant systemic...the entire system of copying proto forms cannot possibly be from one's own knowledge base; it can only come from sources that are obsolete, or contested, or copyright protected (or contested and copyright protected.) --Connel MacKenzie 00:04, 26 January 2007 (UTC)

I see, in the wikitext itself. Someone added a div to try to display the characters in the etymology in Nov 2005, sometime later the start tag was removed. has nothing to do with this. (I didn't notice it ;-). Robert Ullmann 21:56, 26 January 2007 (UTC)

Whew. OK, thanks for tracking that down. --Connel MacKenzie 03:11, 27 January 2007 (UTC)

Hello,

It seems the vote for Wiktionary:Votes/pl-2006-12/"Change_style_standard_to_use_new_trans-top_style_templates" has passed. There were some questions raised regarding the specifics of the implementation. Are these serious enough they need to be addressed prior to changing the WT:ELE recommendations, or should I just go ahead? We seem to be widely using them already, so it's hard to see that they can be too bad, but I thought I'd throw out a warning just in case. If I haven't heard anything in a couple of days, I'll go ahead and change the policy per the vote. --Jeffqyzt 16:37, 23 January 2007 (UTC)

Is there a way to customize one's monobook so that translations sections are visible by default? --EncycloPetey 16:48, 23 January 2007 (UTC)

Yes. In WT:PREFS, check the box for "Don't hide the "Nav" section by default." See cat or word to test your settings. Re-wording suggestions are welcome. --Connel MacKenzie 17:58, 24 January 2007 (UTC)

Thanks. --EncycloPetey 18:04, 24 January 2007 (UTC)

Check that... It worked for a while, but then cut out. Now the tables are collapsed again. Do I have to reset preferences this way each time I log on? I've tried clearing my cache and resetting prefernces again, but the tables are still collapsed. --EncycloPetey 21:07, 24 January 2007 (UTC)

Until I rewrite the mechanism for the preference cookies, IE truncates them randomly. This problem seems to be increasing in severity and importance. But I'd like to finish the next step of transwiki automation before doing it. Invitation: Anyone else around, feel comfortable editing/refactoring some Javascript? --Connel MacKenzie 23:03, 24 January 2007 (UTC)

Note, I'm not using IE when I experience this problem; I'm using Safari. --EncycloPetey 00:11, 25 January 2007 (UTC)

OK, the "new" cookiejar code is in place. Same behavior? --Connel MacKenzie 09:47, 25 January 2007 (UTC)

Cookies are browser based, so if you start a new browser, the cookies (generally) do not automatically get moved over to the new browser. But once set, you can log out and back in willy-nilly. --Connel MacKenzie 09:53, 25 January 2007 (UTC)

Ugh, now it isn't working for me. After some sleep, work, etc., I'll try and look at it again. --Connel MacKenzie 10:23, 25 January 2007 (UTC)

Regarding wording, how about "Prevent automatic collapse of translations boxes on page load"...or, if it's not specific to the translations, "Prevent automatic collapse of navigation section boxes (e.g. translations boxes) on page load." Or...if you'd prefer something not constructed in the negative: "Leave translation boxes expanded on initial page load/Leave navigation section boxes (e.g. translations boxes) expanded on initial page load." BTW, is there some reason that the WT:PREFS isn't accessible via the my preferences menu (perhaps as an "advanced" tab?) --Jeffqyzt 18:09, 24 January 2007 (UTC)

Thank you. I've considered adding a tab to Special:Preferences, but Brion keeps hinting at a media-wiki extensible thing to provide a framework to project-specific preference extensions, so I've held off. Perhaps I should add a link to WT:PREFS from there, in the meantime?

I believe a link, even if it's later superseded by a full-fledged tab via wiki-extension, would help people find it. Personally, having found Special:Preferences, I would not think to look further for preferences elsewhere. --Jeffqyzt 19:50, 25 January 2007 (UTC)

Yes, it is for all navigation boxes, not just translation sections at this point. I think someone mentioned the possibility of some CSS magic to distinguish the different types, but that seems to have been lost in the shuffle. --Connel MacKenzie 23:03, 24 January 2007 (UTC)

How about ‘Don’t hide translations by default’? I assume this is incorrect, since ‘nav’ is not only used for trans-top etc., but then that should be fixed: it should be possible to see translations but hide derived terms etc. There shouldn’t be too much magic behind that. It is just a question of defining different classes for trans sections and deriv sections etc. And implementing the option for each of them. (But don’t ask me to do it; I know it is theoretically possible, but would have no idea where to start) henne 11:03, 25 January 2007 (UTC)

Having seen no unanswered technical objections, I will go ahead and modify WT:ELE to use {{trans-top}}, etc. specificially. --Jeffqyzt 14:18, 29 January 2007 (UTC)

In <div id="catlinks"> the "Translation to be checked" categories all appear. Should I impement something in MediaWiki:Monobook.js to hide the TTBC categories? Always? When there are more than three? Or should such a mask be a user preference only? --Connel MacKenzie 17:56, 24 January 2007 (UTC)

If it's hidden by default, we're much less likely to get casual or occasional users to clean them up. I suggest that if they're hidden by default, it should be so only for users with named accounts. Anonymous users should always see the TTBC section. If they don't want to see them, they they should create an account. --EncycloPetey 18:06, 24 January 2007 (UTC)

Perhaps this needs more thought, then. Perhaps, instead of hiding them, they (and all other "cleanup/deletion/request" categories) could be split out into something like <div id="catlinks-cleanup">? Yuck. That sort of distinction should be made server-side, I guess. so much for a simple enhancement. I guess an optional user preference will be the way to go, if I do this. --Connel MacKenzie 18:30, 24 January 2007 (UTC)

Another thought on this topic: I routinely invite translators (that I notice in Recentchanges patrolling) to clean up TTBCs...usually with direct links to the categories they are likely to be able to help with. In my experience, the vast majority of those who are specificly invited to help (particularly in ways that only they can,) do help enormously. On the other hand, random anon's are very unlikely to understand that TTBC indicates a cleanup category, at all. I don't think those individuals get any benefit from seeing 41 other languages also listed on the target page, polluting the categories box. Many of these contributors are anon-ips. Also, at present, I have no mechanism for limiting WT:PREFS to users with registered accounts. If I add the preference, anons will be able to use it just as easily as registered users. (Oddly, the same thing is true for "Popups" - on Wikipedia, you need an account, but on Wiktionary, there is no such restriction if you use the properly customized version in WT:PREFS...just click and go; no fuss, no muss.) --Connel MacKenzie 18:32, 27 January 2007 (UTC)

The multitude of Categories (particularly long titled "Translation to be checked" categories) reduces the usefulness of the Cat box. Words which require checking appear under a head to that effect - I doubt whether the casual user would use the Cat box for this purpose. —Saltmarsh 07:06, 26 January 2007 (UTC)

Werdnabot and RoboGMwikt entries in the last few minutes have been given the "unpatrolled" flag, and strangely, it doesn't disappear even after I "mark it as patrolled". --Enginear 15:51, 27 January 2007 (UTC)

They always show as unpatrolled for a little while, until Connel's widget catches up with them. Just ignore them for a while. (And it isn't the bot flag, it is the whitelist that catches them.) Sometimes it doesn't run for a bit. Don't know why they wouldn't get marked when you do it though, works for me. Robert Ullmann 16:02, 27 January 2007 (UTC)

That explains it. I never noticed before. Maybe something to do with accepting the patrolling is running slow too. --Enginear 16:30, 27 January 2007 (UTC)

If I wasn't the only sysop with the WT:PREFS patrolling enhancements turned on, (in the sysop-only section) you'd see them with "(marked)" instead of "(mark)", as you would be whiltelist-marking them. If you do have that turned on, and are experiencing problems with it, I would greately appreciate bug reports here. Sheesh, am I not allowed to sleep, occasionally, with my computer turned off? --Connel MacKenzie 18:16, 27 January 2007 (UTC)

Also, I had requested that Werdnabot not have the bot flag fo a long time. I also did not auto-whitelist it for a long time. I think the various kinks have been worked out of it now (for the Wiktionary-specific changes) that I see no need for that caution anymore, WRT Werdnabot edits. It should now be 'bot-flagged and whitelisted. (Yes, I do normally patrol 'bot edits too. Silly, perhaps...but it helps when one of mine goes nuts...which did happen on two separate occasions last year.) --Connel MacKenzie 18:20, 27 January 2007 (UTC)

How odd. The "master-switch" box had got switched off. Probably me, but certainly not intentional. Also <blush> Lupin popups do now work for me with IE7...a long time since I used this computer. BTW, what does "Patrol in "expert mode" with no alerts" do? --Enginear 18:48, 27 January 2007 (UTC)

A Few things...

1. Yes, I refactored the cookie code used for preferences, so IE truncation problems should not happen anymore. Minor bug reports here are appeciated!
2. "Patrol in expert mode" needs to be reworded. That is the mode where whitelisted entries are "marked" for you (the mode I normally use.) Doing without that flag can give you a whole bunch of alert messages (one for each one being marked) that I should probably just remove - I had been using that mode during debugging.
3. Preference cookies still last for only 30 days, until I can think of a "better" way to do the whole scheme. Now that the cookies have been refactored, changing any one setting should make all of them stay for 30 days. But when they go, they are gone.
4. Honestly, I don't like the whole "cookie" approach to this problem. It should be user-specific, not browser-specific. A curious side effect is that when I test other browsers, I am able to turn different things on and off, particularly as browser-specific bugs are found. And if I use ajax to write the preferences back somehwere, there are two problems: 1) other people could then see your preferences, 2) it would slow things down due to yet another separate http request.

--Connel MacKenzie 22:09, 27 January 2007 (UTC)

At the moment we have a set of templates that gives us the ability to create collapsible tables of translations, which is great, because translations can make a page huge, especially when a word has many meanings. I have seen these templates used for derived and related terms too, but they are a bit unsatisfactory because the opening template ({{trans-top}}) takes an argument, and puts in "Translations" if none is provided. (Previously, it put in the section header, I think. As it now puts in "Translations", these templates should certainly not be used for derived terms). The following is therefore incorrect:

Could someone please create a similar set of templates that do not take an argument (perhaps calling them "der-top", "der-mid" and "der-bottom") that could be used for derived and related terms? I would do this myself, but I'm not confident I could adapt trans-top, etc, correctly. Sometimes the derived terms sections can be as long as the translation sections, or even longer. I am currently working (offline) on the derived terms for time and there will be several hundred more to go in. — Paul G 08:09, 28 January 2007 (UTC)

I encountered {{rel-top}}, {{rel-mid}} and {{rel-bottom}} earlier today. I don't know what the others are called, offhand. User:Williamsayers79 created them on December 6th - perhaps you could ask him for the others...and to list them all in WT:I2T? --Connel MacKenzie 08:51, 28 January 2007 (UTC)

Thanks for those. These still have the headers within them, though, which I think should be omitted as they duplicate the header. The "Show/Hide" link could then be put on the left. — Paul G 10:56, 28 January 2007 (UTC)

Can these be set to accomodate 3 columns? The items listed in Derived & Related terms tend to be shorter than those in Translations, and in some cases are quite numerous. (see 天 for an example, under Mandarin). --EncycloPetey 15:41, 28 January 2007 (UTC)

This might not be the best time to bring this up. But here goes, anyhow. On Wikipedia, more and more "References" sections are using the multi-column format. I have a very big problem with Wikipedia's implementation of that. (Their screwy CSS ends up throwing JS errors by being formed so badly, just to work around yet-another-IE-bug.) I'd like other's thoughts on revamping all of our top/mid/bot things, to #1) eliminate "mid"s, #2) use spans and clever JS to insert the browser-specific column-count thing, #3) never have to worry about manual column balancing again. Comments? --Connel MacKenzie 21:14, 28 January 2007 (UTC)

I'd be very happy not to have to balance columns manually. --EncycloPetey 21:46, 28 January 2007 (UTC)

OK, the outstanding issues I see are:

1. Naming conventions (top/bottom or top/bot)
2. Number of columns parameter
3. Preference distinction for section-hiding types
4. Figuring out an acceptable Javascript mechanism for -moz-column-count vs. -column-count

Bot-changing all the templates from {{top}} to {{trans-top}} is trivial, in NS:0, since the only times "top" is used for something other than translation, is already an error. Changing all {{top2}} to {{rel-top}} is not trivial (they are not all related terms.) Bot-removing all {{mid}} is trivial. Getting WT:VOTE approval for all of it, is not trivial (but might be covered under the previous vote?)

So, what next? Or rather, where to begin? --Connel MacKenzie 00:50, 29 January 2007 (UTC)

Is there an easy way of renaming a category without having to update all the pages in the category? For example "English three letter words" should be "English three-letter words"; not a big deal, but if we were to change it, fixing all the pages in the category would take for ever. — Paul G 08:09, 28 January 2007 (UTC)

python category.py -rename "English three letter words" "English three-letter words" works for me. But yes, that does (automatically) edit each entry separately. That's why I suggested a "Category renaming requests" page on WT:BP last year. (The side benefit being that everyone could comment on whether or not the category move was correct, or not, before a random 'bot operator came along and just did it.) --Connel MacKenzie 08:56, 28 January 2007 (UTC)

Also of note: you can download pywikipediabot from sf.net yourself, if so inclined! --Connel MacKenzie 08:58, 28 January 2007 (UTC)

Paul, Did you d/l it? Or are you waiting for me to run it? I'd rather have an offical Wiktionary:Requests for category moves page, you see...as I am certain there are many more requests, and a one-day sanity-check on each request would help enormously. --Connel MacKenzie 21:21, 28 January 2007 (UTC)

Strange things happen when you use {{en-noun}} twice shortly after another. Can anybody clear me up on this? See it’s talk page. henne 19:35, 29 January 2007 (UTC)

Not that it explains this, but in the particular case on the talk page, those entries should be broken out into different etymology sections, which would resolve the problem. If they're not, you should be using something like {{en-noun|di|ce|pl2=dies}} --Jeffqyzt 20:39, 29 January 2007 (UTC)

This is a nasty bug in WM software's parser.php. I've offered a work-around on that talk page (but I detest that work-around.) --Connel MacKenzie 08:23, 30 January 2007 (UTC)

Several discussions have been raised about {{countable}}/{{uncountable}} that seem to have been lost in the shuffle, so I'm about to be bold.

1. I'm going to change the templates to say C and U
   • <span title="Countable - a count noun">]</span>
   • <span title="Uncountable - a mass noun">]</span>
2. I'll chance MediaWiki:Common.css to have:

   .countable1, {display: inline}

   .countable2, .countable3 {display: none}

3. I'm going to add a WT:PREFS to 'Expand "countable" and "uncountable"' and 'Expand instead to "count noun" and "mass noun"' and 'Hide the "C" and "U" entirely'
4. Change {{en-noun}} to call these templates, instead of directly wikifying them.
5. Perhaps add other WT:PREFS to rename them to other things if needed (please leave suggestions here...have I missed other common options for these?)

Ping me on my talk page ASAP if there is some reason not to proceed. --Connel MacKenzie 05:07, 27 January 2007 (UTC)

Number 1 is a bad idea! Remember that we now have a {{context}} template that merges parenthetical context tags together. A C or U could look very veird in these situations. --EncycloPetey 05:11, 27 January 2007 (UTC)

Well, I'll hold off...OK. But expanding out "uncountable" or "countable" is weirder IMHO. We might look...you know...like other dictionaries, if we had just U or C. --Connel MacKenzie 05:27, 27 January 2007 (UTC)

I just imagine entries beginning with (U, vulgar) or (C, computer programming). --EncycloPetey 05:29, 27 January 2007 (UTC)

Yes, precisely. That certainly seems cleaner and more consistent with other dictionaries. --Connel MacKenzie 05:33, 27 January 2007 (UTC)

As in "You vulgar" and "C is for computer"? We might look like other dictionaries if we also didn't expand inflections. DAVilla 04:48, 28 January 2007 (UTC)

"Vulgar" is neither hyperlinked, not hint-texted, while "U" is both. "Computer is neither hyperlinked, nor hint-texted, while "C" is both. As to looking like other dictionaries; yes there are good arguments for and against each aspect. Inflections themselves obviously are a very different kettle of fish, particularly when most of the time, people look up the inflected form (that they just used or are about to use) first. Traditional dictionaries (e.g. dictionary.com) then try to mislead readers by presenting them with a different word form, yet no where indicating the word the person started with. (-ing, -ied, -ified, etc.) On the other hand, "mass noun" vs. "count noun" information is most often irrelevant or painfully obvious (especially when uncountable) and clutters entries needlessly. Perhaps there is good reason that many traditional dictionaries don't show the distinction at all, let alone emphasize it as having great lexical importance. --Connel MacKenzie 09:21, 30 January 2007 (UTC)

Well, I did not imagine any controversy on this. I'll move this to WT:VOTE to decide which should be the default. I should probably ask DAVilla what the best vote type is though...to choose among: 1) Nothing, 2) U/C, 3) uncountable/countable, 4) mass noun/count noun. --Connel MacKenzie 05:39, 27 January 2007 (UTC)

A secondary concern is the issue that started all this in the first place: {{en-noun}}. I suppose the question remains (particularly for {{en-noun|-}} forms) if en-noun should use the same mechanism. Considering the painfully obvious selection above was not so obvious, that should probably be debated as well. --Connel MacKenzie 05:47, 27 January 2007 (UTC)

Probably. I know some of the regular users and admins are very particular when it comes to abbreviating terms in the inflection line. I'm a bit more flexible in that regard, and personally wouldn't mind seeing C and U used for {{en-noun}}. --EncycloPetey

Well then, that adds to my confusion. You would like to see U/C on inflection lines, but not on defintion lines within the context tags? --Connel MacKenzie 18:23, 27 January 2007 (UTC)

Yes. On the inflection line, I would like to see word forms in full, but grammatical information abbreviated when possible, since such information appears in a clear context. Besides, I don't want to see the word forms cluttered with additional information when it can be avoided. However, for the beginning of a definition line, I would rather not see grammatical information abbreviated since it is mixed with other information, putting it out of context and mixing it with categorical information. --EncycloPetey 04:54, 28 January 2007 (UTC)

You actually think of context tags as separate from grammatic indicators, when both are qualifying a definition? That is, the characters \n, \n and \t change the context of the definitions we're talking about? I'm sorry, but I cannot agree. Limiting the definition qualifiers to the inflection line is always misleading, as it provides too much separation from the definition(s) being qualified.

This unsigned comment makes little sense to me. It does not seem to follow from the preceding discussion. I said that 'when grammatical information appears in the inflection line I would prefer it be abbreviated, but when grammatical information appears in-line in front of the definition I would rather it not be abbreviated. My reasoning is that grammatical information appearing in the inflection line is appearing in the context of grammatical information, and only grammatical information, so its context is clear and abbreviations are easily done. But grammatical information appearing at the outset of a definition line may be mixed with topical tags, so the context (and thus the meaning) of the abbreviation is more difficult to determine. Therefore, abbreviations are more likely to confuse a user in those situations. --EncycloPetey 01:19, 31 January 2007 (UTC)

February (plural Februarys)

1. {substub} (template turned off to clean out category)

• Add verifiable references here to show where you found the word in use.

Note that the "tutorial" text for the "basic entry" looks like an older revision of the "noun" popup. Is this button pointing to the right information? --Jeffqyzt 16:02, 29 January 2007 (UTC)

Thank you. Yes, there are several of the "preload" templates that have fallen out of date. The basic entry is supposed to be a noun entry without the =References= section, but is the one preload template that doesn't have a bot-entry equivalent.

Following the basic assusmption that the "noun" preloads are correct, the components are:

MediaWiki:Noexactmatch

Special:Prefixindex/Template:new en

For the button, the three are: {{new en noun}}, {{new en noun intro}} and {{new en noun bot}}.

I would appreciate help filling out the "intro" texts of the rest of the preload buttons (which need to be linked in from "Noexactmatch" as they are created.) Whenever the {{{1}}} form is seen, the preload template has then therefore been used as both a "preload button" and a bot "subst fill" mechanism. Dvortygirl was kind enough to point out to me the shortcomings of combining those two functions...so I started splitting the preloads (e.g. new en noun/new en noun bot) but was unable to finish them all before higher priority items arose.

Note also that include/noinclude/includeonly mechanisms do not work in preload contexts. So I don't exactly know how to mark {{new en noun}} and {{new en noun bot}} as needing to be synchronized.

Perhaps a page, such as Wiktionary:Index to reload templates (Like WT:I2T?) would help organize these? It is obvious (now) that you all deserve a better explanation of the mechanisms being used for this successful experiment. (In terms of the popularity it has among newcomers.)

--Connel MacKenzie 17:11, 29 January 2007 (UTC)

Might be less of a problem now. What'daya think, should I do the WT:I2RT thing? --Connel MacKenzie 08:58, 30 January 2007 (UTC)

Hrm...is it a reload, or a preload (hence WT:I2PT? In any case, if you create an index, what would it contain that's not already in Special:Prefixindex/Template:new en? Pre-fill templates for other languages (do we have any?) Might be worth having a shortcut though...is there some reason (seeing as these are templates, albeit somewhat differently used than normal) that these shouldn't just get a sub-header under WT:I2T itself? Oh wait, they're mentioned there already, with a pointer to Category:Article creation templates, and it looks like we do have other languages (at least German.) I wouldn't create yet another index page; the problem is more one of finding the index (Index of indices, anyone?) :-) --Jeffqyzt 20:17, 30 January 2007 (UTC)

Why is there an empty section under "a" in Category:Section stub? SemperBlotto 12:28, 30 January 2007 (UTC)

I don't see an empty section. --EncycloPetey 01:11, 31 January 2007 (UTC)

Well, I can still see it - after "Wiktionary:Index to templates" and before "ch-". Also "what links here" from {{substub}} shows what looks like a null article. Could that be it? SemperBlotto 09:23, 2 February 2007 (UTC)

Are you seeing ad- after the a? (then there is c, with entry ch-) Robert Ullmann 10:54, 2 February 2007 (UTC)

We could use a plugin for Wiktionary. It will be extremely productive, and also we would have a lot more entries and edits. If there is one, please tell us where to get it at. Thanks. --Bookinvestor 20:22, 31 January 2007 (UTC)

I'm copying this to the Grease pit where it will get a wider (and more technically biased) audience. --Enginear 21:14, 31 January 2007 (UTC)

Hmmm. There's a bookmarklet somewhere. Maybe at Wiktionary:Bookmarklets? Well, I'd better add it there now. --Connel MacKenzie 10:43, 2 February 2007 (UTC)

OK, WT:BOOK is all set now. --Connel MacKenzie 10:57, 2 February 2007 (UTC)

Is there a way to force extra whitespace in Wiktionary? &nbsp; usually works in html but is not consistant here! —Saltmarsh 08:53, 5 February 2007 (UTC)

You can use <br>. Atelaes 08:56, 5 February 2007 (UTC)

Sorry - I should have said - horizontal whitespace! —Saltmarsh 09:24, 5 February 2007 (UTC)

It seems the behavior changes every time someone edits parser.php. But alternating " " and "&nbsp;" does have an effect...just slighter than I'm used to. --Connel MacKenzie 03:14, 6 February 2007 (UTC)

At Wikipedia it's very easy to enter IPA. You just choose the character from the list under the edit box. It doesn't exist here. I often find myself going and opening an edit box in Wikipedia, entering the characters I'm after and cutting-and-pasting them here. Odd that Wiktionary, which makes greater use of the IPA, would not have this when Wikipedia does. Can it be added? Jimp 09:25, 5 February 2007 (UTC)

Huh? Sure we do: under the edit box you'll see a drop down pick (that probably says Templates or Latin/Roman by default). Pick IPA ... Robert Ullmann 11:21, 5 February 2007 (UTC)

Oh. Thanks. In fact this style is better than the Wikipedia one ... as long as you're not too thick to figure it out. Jimp 14:43, 5 February 2007 (UTC)

Hey, their is something seriously wrong with the rfv page I cant get to it, this problem should be addressed immediately. Randy6767 22:46, 5 February 2007 (UTC)

Try following this link. If it doesn't work, could you describe exactly what happens? Atelaes 23:02, 5 February 2007 (UTC)

Everything is fine now, thanks. Randy6767 01:39, 6 February 2007 (UTC)

The sortcut WT:RFV works too, by the way. --Connel MacKenzie 03:16, 6 February 2007 (UTC)