Hello, you have come here looking for the meaning of the word User talk:Vildricianus/Archive2. In DICTIOUS you will not only get to know all the dictionary meanings for the word User talk:Vildricianus/Archive2, but we will also tell you about its etymology, its characteristics and you will know how to say User talk:Vildricianus/Archive2 in singular and plural. Everything you need to know about the word User talk:Vildricianus/Archive2 you have here. The definition of the word User talk:Vildricianus/Archive2 will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofUser talk:Vildricianus/Archive2, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
This is an archive page that has been kept for historical purposes. The conversations on this page are no longer live.
Sorry, I have a migraine headache right now and cannot comprehend what you are saying. Perhaps it would be better to change the comments in "welcomeip" and not bother subst:ing this template ever. What course do you recommend? --Connel MacKenzieTC22:37, 1 April 2006 (UTC)Reply
Quotation templates
Latest comment: 18 years ago4 comments2 people in discussion
This looks good, and it makes my own minor formatting inconsistencies more obvious. Since this list will be a growing one, my one concern is in whether there is any way to automate the list to reflect the addition of new templates. Eclecticology21:02, 2 April 2006 (UTC)Reply
Automation: certainly, by means of a category. That would however not show the contents of the templates, and for now I'd like to keep the manual list until we are using these templates on a slightly larger scale and until we have more of them. Somewhere in the near future, I'll have the possibility to add more quotations in a consistent and less time-consuming manner than is now the case. — Vildricianus21:09, 2 April 2006 (UTC)Reply
Latest comment: 18 years ago10 comments2 people in discussion
These templates are not supposed to be coloured, AFAIK. Only top and mid, because of their purpose in the translation section. There are also top2 and mid2, which have the same code as top and mid, except then that they're not coloured. — Vildricianus13:14, 3 April 2006 (UTC)Reply
I'll check out what links there. I don't believe I'm doing any damage by adding the colour, but I'll sample and see.--Richardb13:24, 3 April 2006 (UTC)Reply
Checked out quite a few. All look fine, better with the same colour for 3 column tables as for 2 column tables. So, please leave the change in. Thanks --Richardb13:34, 3 April 2006 (UTC)Reply
No, these columns are/will be heavily used in =Derived/Related terms= sections, which should not be coloured in order to mark the difference with the =Translations=. This is because either you're interested in translations or you're not, so the colour makes it easy to either skip or focus on this section. Now there's another point of focus in the articles. Perhaps you can create new three-column templates with colours. — Vildricianus13:44, 3 April 2006 (UTC)Reply
OK. I can create some others. But, I hate creating more templates than necessary. How about we use a different colour Pale), instead of no colour ?--Richardb13:51, 3 April 2006 (UTC)Reply
Agreed, no more templates than is necessary. I'm at the moment trying to organize this stuff as WT:I2T is insufficient. A different colour than yellow is indeed another option. I let you proceed with that. Perhaps you can use #F8F8FF as they do on de.wiktionary. — Vildricianus14:05, 3 April 2006 (UTC)Reply
I've already added a note to Template:top - "Note: It is intended that this colour background is used to indicate the translation tables in an entry, for quick and easy indetification of those tables. Please avoid using this colour, and hence this template, for other tables.". And I'll proceed with changing the colour for the top3, mid3 templates.--Richardb 14:08, 3 April 2006 (UTC) - Done--Richardb14:16, 3 April 2006 (UTC)Reply
I noticed the message; I wonder why I actually hadn't done that before. The new colour looks OK. Could you perhaps also change top2, top4, mid2, mid4? Thanks. — Vildricianus14:19, 3 April 2006 (UTC)Reply
Congratulations! I think you've set a speed record for the time from nomination until the time of appointment. I think that goes a long way towards showing how much your efforts here are appreciated. --Connel MacKenzieTC17:03, 4 April 2006 (UTC)Reply
Alright, but is there any reason in particular? I used to see them a lot more, but I'd been away from the English Wiktionary for awhile, so I don't know about any changes in policy here. – Minh Nguyễn (talk, blog) 05:25, 5 April 2006 (UTC)Reply
Yes there is, mainly in order to facilitate sorting languages by alphabetical order and to not needlessly complicate things for newbie contributors who don't know all these codes. — Vildricianus07:56, 5 April 2006 (UTC)Reply
Oh, I figured tools like this were created to eliminate the problem of sorting the language codes. This tool understands lines that begin like *{{vi}}: . I just figured that using the template would make it easier to find all the words that have Vietnamese translations here, in case that ever becomes necessary. On some other Wiktionaries, such as the Vietnamese and Dutch editions, templates are used for every part of an entry (including the entry headings) for this reason. – Minh Nguyễn (talk, blog) 06:13, 6 April 2006 (UTC)Reply
Enclosing headers into templates eliminates the "edit section" option (try this). All these codes and templates make it very confusing for people who are not used to it. We're trying to remain as user-friendly as possible. And I don't think it's necessary to find all entries that have Vietnamese translations, is it? — Vildricianus07:28, 6 April 2006 (UTC)Reply
Huh. I never noticed that edit section issue – probably because the Vietnamese templates use __NOEDITSECTION__. :^) It'd be nice if the templated headings worked better though; that way people wouldn't have to manually add categories such as "English nouns" to entries all the time.
Having a way to easily find all the Vietnamese translations would make it much easier for Vietnamese speakers to find words that need entries, since there's no way you'd be able to find them all the redlinked Vietnamese words at Special:Wantedpages. In fact, quickly skimming through the 1,000-entry list, I couldn't find any. I suppose it's still possible to Google for the term, though. A user at the Vietnamese Wiktionary converted all the headings and stuff to templates in an effort to assist the WiktionaryZ project.
The thing with headers in templates is that you'll end up editing the template instead of the page where the template is included. Note also that the part of speech categories are no more to be added for English words.
About finding Vietnamese: well, I suppose the best way to go about this is to cruise through Category:1000 English basic words and add translations where necessary. And then create the Vietnamese entries. I guess the 1000 basic words more or less correspond in each language. — Vildricianus09:45, 8 April 2006 (UTC)Reply
About the section edit links: I suppose it does make sense, considering how they're used in w:Template:Current events when transcluded to w:Current events. It'd be a pain to have to hunt down the particular sections of that template to edit; then again, the page is still a pain because all the edit section links get pushed to the bottom, due to the floating sidebar there. Anyhow, you might be interested in Bug 2795 and Bug 4034 at MediaZilla. – Minh Nguyễn (talk, blog) 10:39, 8 April 2006 (UTC)Reply
CheatBot
Latest comment: 18 years ago7 comments2 people in discussion
What are you planning to do against the many redirects from plural to singular that are in place? I've deleted some of them, but it seems there are quite a number of them. — Vildricianus15:44, 5 April 2006 (UTC)Reply
Um, I created this page User talk:Connel MacKenzie/redirects a long time ago. I made it through the plurals redirecting to singular; perhaps some have been reenetered since?
I didn't make it through the other sections, as I was going to manually replace those plural entries I'd deleted first. (Actually, I'm not sure where I left off.)
The 'bot specifically does not override any existing entry, not even a redirect.
What is this new magic you've discovered/invented?
Hehe, I dropped .allpagesredirect { text-decoration: line-through } in my monobook.css which strikes out redirects in Allpages. — Vildricianus07:45, 7 April 2006 (UTC)Reply
Ah, so that's standard - I thought it was just for phrases and composite words. I'll fix mine up, though I'm frankly curious as to the need for it, since it mimics the article title. Cheers! bd2412T20:33, 5 April 2006 (UTC)Reply
Yes, some peculiarities seem to reappear time and again in questions – this is one of them. It's partly a relic from the time before case-sensivity, but is still retained because that's the line where inflected forms, gender etc. will appear. Cheers. — Vildricianus20:39, 5 April 2006 (UTC)Reply
enwreathe
Latest comment: 18 years ago1 comment1 person in discussion
Your "tiny create" was flagged by the #vandalism-en-wt RC monitoring bot, so I looked at the article because I'm really, really bored. --Rory09607:52, 6 April 2006 (UTC)Reply
More talk for you
Latest comment: 18 years ago3 comments2 people in discussion
Latest comment: 18 years ago1 comment1 person in discussion
What do you think your deletion of all of my images has accomplished? I was using those to verify my entries. Does it make you feel important?--Primetime P.S. I take back my apology I gave a while back.
Latest comment: 18 years ago2 comments2 people in discussion
What should we do about this? Isn't there a way to run a bot against this? Or shall we leave them in place until your inflection bots make them work again? — Vildricianus15:16, 7 April 2006 (UTC)Reply
Latest comment: 18 years ago6 comments2 people in discussion
Good day. Some comments on your use of the AWB. It moved some categories to the bottom of a page, whilst they belonged at the end of the section, e.g. at far. Usually, we have them ordered in their appropriate language section here. Also, what kind of Unicode fixes are those? Beware that we sometimes use different apostrophes than the normal ASCII ones. Cheers. — Vildricianus14:41, 10 April 2006 (UTC)Reply
Vild, that isn't quite right, according to this (nor according to the previous discussions I recall on the topic.) A category applies to an entire page, not a section, so to make them easier to find/correct, they are supposed to be at the end (right before interwikis.)
The only reason we haven't pursued these corrections in the past, is because we did not have a tool available that would do it. I am delighted that I can scratch this off my "monobook.js" todo list, now that a better solution exists. --Connel MacKenzieTC16:33, 10 April 2006 (UTC)Reply
That's something we might want to change then. Suppose an entry with multiple language sections: now I want to edit the Dutch part, so I section-edit. However, I don't want to re-edit the entire page or the last section to track down the Dutch POS category; I'd rather have it in the Dutch section. Reasonable, not? — Vildricianus16:48, 10 April 2006 (UTC)Reply
Reasonable yes, but Eclecticology wanted them at the bottom only. <conjecture> At the time, he may have been more concerned about categories within templates, but I think those concerns have been overcome by events. (Note: even though categories within templates is still a thorny issue; their popularity and ease of use has outweighed the initial arguments against them.) </conjecture> --Connel MacKenzieTC16:59, 10 April 2006 (UTC)Reply
You can certainly make the suggestion on WT:BP. I don't see a big problem with having them correctly at the bottom, especially now that there is a tool (and a willing volunteer) to help standardize the entries in this manner. --Connel MacKenzieTC17:07, 10 April 2006 (UTC)Reply
WOTD
Latest comment: 18 years ago6 comments2 people in discussion
I am trying to be cautious when editing this Main Page template. I created {{lurl}} long before I knew of the magic word's existence. I do not think that template serves any better in this situation. And not having a passed-in page name is a bug, IMNSHO. --Connel MacKenzieTC17:22, 10 April 2006 (UTC)Reply
Wow. Having broken magic words is almost worse than not having them at all. I think to work around MediaWiki's but, we should have {{furle}} which simply does {{fullurle:{{{1}}}}} so that the parameter defaulting doesn't mess up the parameter passing. Of course, without further testing, this may not work either. --Connel MacKenzieTC17:46, 10 April 2006 (UTC)Reply
All this makes me wonder if Brion's refusal to fix the bugs the Gangleri reported is intentional. Is there a security violation somehow, in having this stuff just work? --Connel MacKenzieTC17:48, 10 April 2006 (UTC)Reply
I have the links working for 4/1, 4/10, and 4/11 currently. I'd like to reengineer the entire process to 1) not contain spaces or commas, 2) not cover more than one month. Until that is further discussed, I don't see much point in continuing messing with the individual templates. Future entries have a working edit link (for one day, anyhow.) But I'd like the whole thing overhauled before too long. --Connel MacKenzieTC19:19, 10 April 2006 (UTC)Reply
Latest comment: 18 years ago1 comment1 person in discussion
This entry is up for WOTD later this month, but there's some concern about the etymology. I've pulled some information from the 1913Woordenboek der Nederlandsche Taal (vol. IX), and entered it onto the Talk:mallemaroking page. However, the text predates the Dutch spelling reforms and my Dutch isn't that strong to begin with. Would you please have a go at translating it? Thanks. --EncycloPetey21:25, 11 April 2006 (UTC)Reply
Thanks for the welcome!
Latest comment: 18 years ago5 comments2 people in discussion
I checked the old version in Firefox, and I see what you mean by "spacious" now! I've made another version with widths defined in ems, not by percentages — User:Alerante/Scratch. Is this good? æle✆16:36, 14 April 2006 (UTC)Reply
Yes, that's decent, thanks. You can replace the old one with it, but I don't know how long it'll stand. AFAIK, the Gutenberg rankings will shortly be reordered and will perhaps get a new template. As long as you don't change the pages themselves (a bot will have to be able to remove them again), you're free to do with it as you please. Cheers! — Vildricianus17:02, 14 April 2006 (UTC)Reply
Mirrors
Latest comment: 18 years ago2 comments2 people in discussion
Erm, not quite. It was never deleted. But it was linked without the lowercase pipe syntax (and the linking I encountered was old.) We never should have decapitalized - it is still causing problems today. And as more are entered, I think those problems will continue to increase. --Connel MacKenzieTC20:19, 12 April 2006 (UTC)Reply
Most recent todo4
Latest comment: 18 years ago4 comments2 people in discussion
I added a bunch more exceptions last night. I think for future runs though, I'll ignore anything that isn't a heading level line. That should work better than trying to maintain a list of exceptions. On the other hand, I did find things that incorrectly has __TOC__ or __NOTOC__ as a result of doing this "wrong." So I dunno. Is a separate "correct" list in order? --Connel MacKenzieTC20:12, 12 April 2006 (UTC)Reply
Well, some of the results had nothing to do with headers but still deserved some cleanup. Any list with cleanupable entries is fine ;-) — Vildricianus20:15, 12 April 2006 (UTC)Reply
... for the immediate help on the wiktionary pronunciation request I put in for 'stab' 30 minuutes ago. You are very fast! Also for the 'are you serious' query to me on the pronunciation I am also looking for on the (widely used in Economics textbooks) 'Slutsky', which I trust I answered adequately by just pushing the recreate button. I am new to Wiktionary -- these are my first two edits. (By the way, the request for the pronunciation of 'stab' was made by a colleaque of mine, a PhD grad student in Economics who speaks English as a second language.)
Thanks again! —This unsigned comment was added by 129.82.19.60 (talk • contribs) 19:29, 12 April 2006.
More clutter to your popular talk page, as per usual by me
Latest comment: 18 years ago3 comments2 people in discussion
Do you think a link-correcting bot would be feasible: correcting links to uppercase pages where it should be to the lowercase? You know what I mean, installing pipelinks and such. ] --> ]. Just a random thought of mine. — Vildricianus21:09, 12 April 2006 (UTC)Reply
Have you downloaded the Wikipedia bot framework yet? In conjunction with the latest XML dump, you can run replace.py for each of these you find. I suppose I could generate a list of words currently linked with first characters uppercase, redlinked, where the lower case entry exists. Unfortunately, I don't know python well enough to have it figure that out. It would have to run through the whole XML dump once for each term? There must be a better way. Then again, it is a small enough concern right now. This one should remain shelved for a while. --Connel MacKenzieTC21:16, 12 April 2006 (UTC)Reply
Yes, of course, but I was thinking what further cleanup could be arranged when the main tasks are done, say, in about ten years from now, right? :-) Yes, my todo list is large enough right now. And no, I know nought about bots or python or what have you, unfortunately. Cheers! — Vildricianus21:24, 12 April 2006 (UTC)Reply
Template documentation
Latest comment: 18 years ago3 comments2 people in discussion
Thanks for the info regarding template documentation. I'll move the docs I started, but probably not before Monday, when I get back to my regular computer. Rodasmith22:12, 14 April 2006 (UTC)Reply
Sorry to cut across what you are doing, but equally well I'm committed to trying to get some policies roganised, and to get you lot thinking a bit more organised. before Beer PArlour becomes completely unmanageable.--Richardb09:50, 15 April 2006 (UTC)Reply
Really there are two aspects. THe policy, and the work to try to keep translations common. As written, the policy can stand regardless of the success of Connel's idea for the latter.--Richardb10:03, 15 April 2006 (UTC)Reply
Richard, I'd like to propose a policy, that you never do that! Every time you remove stuff, you compromise the integrity of the archive. At the very least, copy it to the archive first, then retain the link. If all of our archived conversations are corrupted in the manner you performed above, it makes it harder to find relevant prior discussion.
Every time Ncik or Ec ask me for a link, I search. (Denial of the existence of previous conversations seems to be both of their MOs.) Their pretending things have not been discussed before is very frustrating, but it is greatly compounded by only the most relevant content being stripped away, lost forever!
What you've done to the Beer Parlour is vandalism. Don't ever do that! You didn't even leave a link! I mean, holy shit, you didn't even leave a link! If you compromise the integrity of a simple archive, then you compromise the integrity of all of Wiktionary.
Hehe, I knew your reply was going to be like this. I had told Richard to make sure it got archived correctly, but I got a weird, seemingly irrelevant reply. Don't worry, it'll get in there exactly as it was before today's removal. (I'm dishwashing BP archiving). — Vildricianus19:47, 15 April 2006 (UTC)Reply
I thought the solution I proposed was a viable solution too. Instead of garnering useful comments though, the concept seems to have been ignored. The last time I saw the conversation, Hippietrail had a counter-proposal to use a similar template trick, to fully reinstate the POV schism. So I don't know...maybe Wiktionarians will continue to insist on keeping it AFU.
Then again, maybe Hippietrail was mired in the technical details of the template, and wasn't considering the NPOV vs. POV issue at all. Hard to guess. I'm pretty discouraged with the whole situation right now.
No problem either, the issue is left cold for hardly a week now. Give it some time, it's a quite radical change (or perhaps not, whatever), and it'll need some time to settle. When I'm done with the webster pages, I'm going to tackle some of the (currently) low-profile entries like rancour/rancor, rigour/rigor and so forth, with your system, then move up towards some more complex stuff. — Vildricianus19:47, 15 April 2006 (UTC)Reply
FWIW, the relevant Wikipedia pages are useful on this topic now. A year ago was about the last time I checked, and they seemed useless then...I guess these pages have undergone tremendous reworking in that time. We used to have a policy specifically prohibiting traversing such lists to assert one POV spelling over the other, but it seems Ncik and others have gone ahead with the UKisms despite that policy. It seems that the main page w:American and British English differences was traversed, filling entries in here, in order of appearance on that page. It certainly looks to me like a certain amount of UKism impropriety. --Connel MacKenzieTC09:08, 3 May 2006 (UTC)Reply
Thanks, added to list of things to consider. Please note further things you find on my talk page, as the following months, I won't have the time to check all pages. Cheers. —Vildricianus18:48, 3 May 2006 (UTC)Reply
But, as to stripping archives etc. I try to do the best I can in taking the pages and pages of stuff out of BP to put into some sensible spot, so that when someone new to the discussion can find out what has gone before relatively easily. Sorry if I stuffed up a bit. But, boy, can I ask you to try setting up project and discussion pages earlier for this in-depth stuff. Point is, people should not have to look everywhere for the past discussion, or keep their own index. It should not be splattered all over Beer Parlour archives. It should be in one logical place, where any one can find it easily. I'll promise to be more careful. But, can you try to be a bit more organised in this one respect. Please.--Richardb09:31, 21 April 2006 (UTC)Reply
And it will be easier to counter any denial of previous conversation. It is all too easy for someone to subtly delete a little bit of inconvenient stuff out of Beer PArlour (which is so fast changing, and few people check the history of) without anyone noticing (which I feel sure has happened occasionally). Harder in a specific project page, where the history is probably more closely checked.--Richardb09:35, 21 April 2006 (UTC)Reply
Latest comment: 18 years ago1 comment1 person in discussion
Is there any way to search Wiktionary User Pages for folks who have identified themselves to have specific expertise in specific fields? I'm wondering as it would be helpful to have someone with a background in Economics review the "Slutsky" page and the 'rfv' you put on it.
I don't know anyone with a specific economic background here. You may want to try at Wikipedia, where I think the term belongs. I think you'll need to provide evidence from printed sources in order to get it verified here. We try not to include material that is purely encyclopedic. — Vildricianus08:48, 16 April 2006 (UTC)Reply
Latest comment: 18 years ago8 comments4 people in discussion
Hi,
I got a mail from the above mentioned user that he'd been blocked. Claiming you blocked him altho he did usefull work, do you want me to forward his mail to you? (I can't really help the guy, I just develop software :)) 81.243.70.13113:07, 17 April 2006 (UTC) (try me on nl-wikipedia or en-wikipedia as henna)Reply
Thanks. Yes I do, but I find that the interface has become a bit too spacious for my 800x600 resolution. I'll stick with the 3.3 for now. Cheers. — Vildricianus13:44, 17 April 2006 (UTC)Reply
I have unblocked this IP address. The page Wiktionary:Why Wiktionary is not so great is a valid page that has been linked from Wiktionary:Why Wiktionary is so great for nearly a year. The comments that he put on the page may have been erroneous or newbie-ish, but I see nothing malicious or vandalistic about them. Some previous comments on that page were suspect but they came from other users. The page is being unprotected blank, and the notice removed. Eclecticology00:39, 18 April 2006 (UTC)Reply
Thanks, I had already unblocked him. I found that page highly suspect, also given the previous edits to it. Thanks for the explanation. — Vildricianus12:34, 18 April 2006 (UTC)Reply
spamming
Latest comment: 18 years ago1 comment1 person in discussion
Sinds wanneer is het beleefd wijzen op de tamelijk beledigende en discriminerende aard van een aantal Engelse uitdrukkingen spamming? nl:Gebruiker:Jcwf
This is the English Wiktionary, talk goes in English.
Latest comment: 18 years ago4 comments2 people in discussion
Hey, I'm a sysop at Commons as well as a volunteer for Wikimedia Foundation and was reviewing some of your recent admin actions. Was curious why you deleted the US spelling of tranquility (See deletion log). Does Wiktionary have a policy on not accepting any commonly used US spellings? Bastique — talk to me22:48, 17 April 2006 (UTC)Reply
It was a redirect to the other spelling variant, which is not acceptable indeed. All versions get a complete entry here, regardless of which standard they belong to. Usually I don't delete existing redirects without replacing them with a proper entry, but this one was created recently while I was watching RC and I forgot about it. — Vildricianus12:52, 18 April 2006 (UTC)Reply
Nothing serious. It's always something I do when we receive a user complaint that they've been blocked unfairly with a sysop with whom I'm unfamiliar, to see if there is a pattern of administrative abuse.
Interesting one, indeed. Seems to be correct, apart from snee being a noun, meaning "a cut". Could it be then that the snick is also from the noun steek, instead of from the verb? Or perhaps both are from verbs? — Vildricianus14:36, 18 April 2006 (UTC)Reply
Formatting of devanagari character entries
Latest comment: 18 years ago1 comment1 person in discussion
I don't have the Beer parlour in my watch list. Some people don't have anything in their watchlist here, and merely read the Beer parlour. I still think this should be kept there for a while to draw attention. Once more specific things are to be discussed, it can be moved (which is, according to me, how the majority of BP-discussions should be treated - alas, this only happens in rare instances). — Vildricianus17:15, 20 April 2006 (UTC)Reply
I don't use my watchlist for anything anymore. After a couple thousand entries, it isn't usable. I do know that comments made on that talk page of discussion pages here usually go unnoticed for months. I think talk:WT:BP, talk:WT:TR, talk:WT:RFV, etc. should redirect to the main respective discussion page to avoid that problem. --Connel MacKenzieTC18:24, 20 April 2006 (UTC)Reply
Perhaps we can make them usable again by including all of them on some "main talk page" - a single page to read all comments on (similar to the proposed "main Beer parlour page"). — Vildricianus18:29, 20 April 2006 (UTC)Reply
Thanks
Latest comment: 18 years ago2 comments2 people in discussion
Thank you, Vildricianus for welcoming me to the Wiktionary project.
Be warned! You are now officially on my English Wiktionary support list, though i'll try to bother you only when i find no alternative.
I'm currently working on compiling a useful list of Wiktionary links on my User page.
May you raise upright children and never suffer from severe ear ache,
Hehe, thanks. I've seen your list, good job. There's much to do here on the organizational front, and I understand it's not easy for newcomers to find their way through the maze. It's good to see your interest in all this. If you find mistakes or incomplete pages, be bold in updating them! Enjoy your time here. — Vildricianus10:58, 21 April 2006 (UTC)Reply
Organizing
Latest comment: 18 years ago2 comments2 people in discussion
Good job working out these policies, we do need them. Yet, a stupid comment of mine: could you perhaps make the titles of Wiktionary: pages a bit shorter? Eg. Wiktionary:Disambiguation in layout - Policy Think Tank could easily do without the " - Policy Think Tank". This may sound like a trivial matter, but I get confused by these long titles, especially by the dashes in them. (I also often fail to find them back because of this reason.) Cheers. — Vildricianus11:15, 21 April 2006 (UTC)Reply
Disambiguation in layout is the name of the Policy. Policy is a necessary tag to differenetiate it from any odd page. We coulddrop te Think Tank bit. Feel free, but I'm off to bed!--Richardb12:19, 21 April 2006 (UTC)Reply
Wow!
Latest comment: 18 years ago1 comment1 person in discussion
Latest comment: 18 years ago5 comments2 people in discussion
Thanks for the welcome. I've been editing Wikipedia and Commons for a few months, so I'm still learning my way around. I made a "test" edit to the Wiktionary, here: whirligig, so that I might follow up with a question. Is it appropriate to provide simple illustrations for Wiktionary articles such as the one I provided in my test? I am a photographer, and I've been loading my photos into the Commons bit by bit, and I thought it might be nice to make the most of them. Personally, I think an illustrated dictionary would be nice. However, I'm keen to follow policy and practice. Please let me know. Rklawton20:15, 21 April 2006 (UTC)Reply
Wiktionary:Pictures seems to have answered my question. If you would like to add to the the information it provided, please feel free to do so. As per above, I'm uploading my images to the Commons and just want to make good use of them. Cheers. Rklawton20:22, 21 April 2006 (UTC)Reply
Up to now, I don't think anyone has set adding illustrations as one of their goals. Personally, I would encourage it (I even think it's great to see someone finally doing this), and I think the majority of Wiktionarians would agree, but if you're going to add a lot, prepare to stir up some discussion! Enjoy your time here. — Vildricianus20:27, 21 April 2006 (UTC)Reply
I've added a few more photos to test the waters. If you have time, could you check them out and let me know if I'm making any mistakes? It's easier for me to fix a dozen edits than a hundred. I've got the relevant articles linked on my user page. Thanks! Rklawton04:52, 23 April 2006 (UTC)Reply
Nice set of pics, I must say. I see no big problems, actually. The left alignment (pigeon and chapel) won't work I think, but apart from that, it's nice. Layout is, after all, always changing here, so in those instances where it overlaps other boxes, a small tweak can fix. Cheers. — Vildricianus15:07, 23 April 2006 (UTC)Reply
How old are you
Latest comment: 18 years ago4 comments2 people in discussion
Hmm. Not sure. I removed my translation, because you're right that "сколько у вас лет?" sounds more natural. Darn. I thought I had that one. Rodasmith21:21, 21 April 2006 (UTC)Reply
Latest comment: 18 years ago3 comments2 people in discussion
Does Wiktionary support phonetic searches for folks who can't spel? If not, would it be useful to add redirects for common misspellings to the correct spelling? Personally, I'd rather hold out for phonetic searches because that requires the labor of only one programmer. Variations of the Soundex function would work well for this. Cheers! Rklawton00:32, 22 April 2006 (UTC)Reply
The English Wiktionary does not permit redirects for misspellings. The SOUNDEX lookup feature is something I'm fond of, but the MediaWiki developers either are not, or haven't had the time to implement it yet. Note also that SOUNDEX is best used only for English terms, while here on Wiktionary we include all languages.
The MediaWiki engine was recently enhanced to use a Lucene search (when pressing the button instead of .) Beyond that, there has not been much activity since it was last discussed. The proposal from several months ago, was to tag all Wiktionary entries with their SOUNDEX hash, so that the search function could simply search on the SOUNDEX value if no match was found. The 'bot required to do that (to every entry here) is no small effort, nor is the Javascript coding to finagle the secondary searching. So, no resources have been directed toward that effort at this time.
Very interesting, thanks! Also, would you e-mail me the names (or even code) for the multi-lingual tools? Can you tell me more about them? This is one of my areas of interest. I do a lot of data-work in English and have done so in Spanish and Italian in the past. Rklawton04:50, 23 April 2006 (UTC)Reply
wikpedia
Latest comment: 18 years ago3 comments2 people in discussion
Wildrick Steele
There is a need to use the talk page for this article to verify or refute the alleged malicious nature of this site.
Since you did not check out a Wiktionary Project Page before deleting it and then blocking my access I am posting this note to you so that you can join the discussion in the Tea Room under the topic of Escape and become fully aware and informed of the need to use the talk page in order to allow the REDIREDT in the article proper to be maintained for the time being.
There may also be other information which you are not aware of in order to be fully informed so as to prevent the status of the Wikimedia Foundation with the State of Florida from coming to an untimely end.
We do not discuss websites on our talk pages. And I do follow your posting spree in the Tea room, but would rather not spend my time commenting there. Nor do I have any questions for you. — Vildricianus15:49, 22 April 2006 (UTC)Reply
Your refusal to cooperate has been duly noted in addition to your relationship with Connel.
I am against this in principle. The templates:new_en_* should bear the brunt of the Ncik formatting wars. Obfuscating my activities to be exactly in the format *I* prefer would probably be viewed negatively. (Note that for 'bot activities, I don't have the same flexibility, as the subst: iterations are not possible; all the inflection transformations must be done beforehand.) --Connel MacKenzieTC19:27, 22 April 2006 (UTC)Reply
I was referring to the BP topic and my talk page; Richard had archived a conversation that was still semi-active and far from concluded. You replied to my response. --Connel MacKenzieTC03:07, 26 April 2006 (UTC)Reply
In the UK, they are called sweets, while in the US, they are called candy. The term "sweets" is sometimes used in the US to refer to all desserts collectively, while in the UK I think this refers to what we in the US call hard candy. Actually, candy in the US also refers to chocolate bars, while sweets can mean anything containing sugar, including ice cream. The term "sweets" in the US is very rare. --Connel MacKenzieTC06:42, 28 April 2006 (UTC)Reply
In Australia, we use the term lolly (countable) for candy. Sweets, or much less commonly just sweet means dessert. You will hear sweets used as a synonym for lollies but this will sound a bit British to many people. Candy sounds both very American and like the name of a stripper or hooker in a movie and we wouldn't use it. Even cotton candy goes by another name here. You might hear candy cane at Christmas time. — Hippietrail16:05, 28 April 2006 (UTC)Reply
Bot changes
Latest comment: 18 years ago2 comments2 people in discussion
Latest comment: 18 years ago3 comments2 people in discussion
Hi I think these things are great but on this XP machine with Explorer at least, the hide/show button is superimposed right over the edit button. You might want to try to find a way to fix that. — Hippietrail20:47, 24 April 2006 (UTC)Reply
Latest comment: 18 years ago5 comments2 people in discussion
I've been too busy again — do you think what I've done at foam#translations is useful? IIRC, you've been experimenting with the hide/show thingy as well, right? Anyway, it's useful in the first two BP sections. Cheers. — Vildricianus20:32, 24 April 2006 (UTC)Reply
Yes, I helped Shibo copy his experiment here from zh:. The response on WT:BP was, as you can expect, stunningly inconclusive.
When I first loaded foam just now, the translations/verb's and marks on the right were on top of each other. Now they aren't, but I didn't think I changed anything related to that section. --Connel MacKenzieTC23:53, 24 April 2006 (UTC)Reply
Hmmm. On WT:BP the show/hide makes the total d/l speed slower (since all monobook.js and .css get loaded with every page.) Wasn't one theory about the BP's current state of affairs that the load time should be reduced? --Connel MacKenzieTC07:48, 25 April 2006 (UTC)Reply
Latest comment: 18 years ago2 comments2 people in discussion
Hey Wild Rick of One Anus. Just to say that we greatly appreciate you busting your guts out on here. You're doing an awesome proactive job (with your help, and others, soon maybe I'll even use this site as an actual reference site as opposed to for procrastinating). However, maybe you would benefit from a holiday, this much time on any unpaid project can't be healthy for you. If you fancy coming to Wales for a 2-day boating trip in June then let me know! I may pop in and say hi on our IRC channel in a few weeks time. --Dangherous18:30, 25 April 2006 (UTC)Reply
Hi Dang; thanks a lot. So you finally figured out the logic behind my username :-). I'm afraid I won't have any time in June, there will be some exams going on that time (let's hope you won't see me here too much then). Nevertheless, sojourning in Wales is indeed on my todo list, how did you find that out? See you then! — Vildricianus18:40, 25 April 2006 (UTC)Reply
"Character encoding" templates
Latest comment: 18 years ago2 comments2 people in discussion
Hi there. Was it you who made these templates? Nice work but I have a bit of bad news. They actually have nothing to do with encodings )-: What they do is set a font that works for a certain script (also known as writing system. The idea is a good one but the name is sadly wrong and misleading. I think out of "Font templates" and "Script templates" that the latter is most fitting and accurate. I can imagine font template could also be used for other things.
You mean the category? No prob, changing the name takes 0.5 seconds :-) The template categorizing I've been doing is still preliminary work and probably needs more refining. The FOOchar templates are now in Category:Script templates and the ones that set fonts or font size in a subcategory. — Vildricianus08:25, 26 April 2006 (UTC)Reply
Welcome
Latest comment: 18 years ago1 comment1 person in discussion
Thanks for the welcome at my IP address; sometimes I'm lazy and/or impatient and make edits without logging in first. But I'm Badagnani00:55, 26 April 2006 (UTC)Reply
Hi, and thanks for the welcome.
Latest comment: 18 years ago1 comment1 person in discussion
Hi. I just came back here and read your message to me. Thanks for the formal welcome. By the way, I am the anonymous user with the IP 70.249.61.170, in case you wondered.
Sorry to take so long. I don't come here a lot, mostly just Wikipedia, but I do visit sometimes. Last time I was here, I searched that word, noticed that it's past tense wasn't in, and figured "Hey, why not?" and stuck in the definition.
Latest comment: 18 years ago5 comments2 people in discussion
Right, this reminds me of it. I'm going to take it on right now, so what do you think? There's going to be 366 pages, but it'd be a bit silly to make all new ones while there are some months of them already done. Can I start moving the existing pages of the format ] to ], adapting all links? That's phase 1 then. Following is the semi-protection of all 366 pages, while you or anyone can move the past WOTDs to archives. How does that sound? — Vildricianus11:35, 26 April 2006 (UTC)Reply
Make the proposal on the WOTD Talk Page. There's some on-going discussion there. I'm not particularly concerned about the mechanism specifics, as long as the day-to-day operations run smoothly. Just make sure the next day will come up automatically. --EncycloPetey11:37, 26 April 2006 (UTC)Reply
Sorry, but I don't know enough about the coding to spot a bug. We'll have to wait until the change-over tomorrow to see if it works. Connel might be able to spot a bug, though. --EncycloPetey11:49, 26 April 2006 (UTC)Reply
Your deletion of "Wikpedia" from the Protologism Project Page
Latest comment: 18 years ago2 comments1 person in discussion
I've warned you about deleting entries from Project Pages or the pages themselves. If you were 35 years old or older I might consider your antics to qualify as those of a Thought Police but since you are only 20 years old and have only become a sysop in the current month of April I consider your antics up to this point to be those of merely an irresponsible child who enjoys playing with new power and learning its bounds. To date your antics have resulted in a copy of the Wikipedia Foundation bylaws being mailed to me by the Pinellas County Legislative Delegation. This will inform you that regardless of whether your childish rookie sysop vandalism persists a full examination of the Wikimedia Foundation bylaws will be made and the resulting findings provided to the Delegation in due course. I suggest you not risk violating those bylaws by practicing further sysop vandalism.
If you must respond anonymously by leaving derogatory messages on my user page instead of here please be so kind as to leave them on my user talk page...
Latest comment: 18 years ago2 comments1 person in discussion
Could you give some feedback on today's moving and changing of mine? I've split out the WOTD pages into archives and recyclable pages (to be protected). I guess the majority of links and tricks are fixed, but there'll probably be something I've overlooked. There's also a host of redirects but I've waited to delete these. Do you have an idea to keep an overview on these "recycled pages"? — Vildricianus15:20, 26 April 2006 (UTC)Reply
Latest comment: 18 years ago3 comments2 people in discussion
Hi there. The dictionary link there is an unknown dictionary. I explained that Aryanpour is the most famous English-Persian dictionary. I don't understand why you insist on having a dictionary which has probably a low quality. Second, the word Farsi has been banned by academy of persian language and literature. The word is not used in academia. --Mehran Kashi20:19, 26 April 2006 (UTC)Reply
You should probably address this issue, if you feel it is one, in the Tea room, where more people can see it. Various regular contributors here have different views on that, but I can't recall a discussion on that. — Vildricianus20:23, 26 April 2006 (UTC)Reply
OK. I will. Thanks. I could not find any previous disscusion in the archives. I doubt there exist any controversies on this issue and my proposal for a standard dictionary (instead of an unknown one). But I will write something in the tea room tommorrow morning. Good night and thanks again. --User:Mehran Kashi20:33, 26 April 2006 (UTC)Reply
Archaic
Latest comment: 18 years ago3 comments2 people in discussion
I didn't know where to look for those templates, so thanks for the pointer to that category. I did happen to know about {{archaic}}, so I used {{subst:archaic}}. Should I not have used subst? Rodasmith21:15, 26 April 2006 (UTC)Reply
No. Actually, I can't think of any main namespace template that is subst:'ed here. BTW the category is new since yesterday :-) — Vildricianus21:17, 26 April 2006 (UTC)Reply
Latest comment: 18 years ago3 comments2 people in discussion
Hi there. Can you tell me if overmoed is a word in Dutch? And if so, what does it mean – and if not, how would you interpret the word if you saw it? The reason I ask is that there is a famous word in Old English (ofermōd) which no one is entirely sure how to translate (it is only attested once). I know German Übermut means ‘high spirits’, and I was curious about what the Dutch equivalent might be. Thanks! Widsith17:01, 27 April 2006 (UTC)Reply
Absolutely; it means "overconfidence", more or less the same as the German noun. I'd say that it's a contraction of over and moed ("courage"), but seeing that there's this OE cognate makes it more interesting. — Vildricianus17:09, 27 April 2006 (UTC)Reply
Wonderful! Thanks a lot. Mōd certainly could mean ‘confidence’ in OE, but it could mean a lot of other things as well! (It's the ancestor of English mood.) Widsith17:50, 27 April 2006 (UTC)Reply
FAQ help
Latest comment: 18 years ago3 comments2 people in discussion
Hi and thanks for answering my question on Connel's talk page!
From time to time things come up which some of us here deal with, but not the majority. Like the CSS and Javascript customisations, and also like the script templates - which can also use CSS.
Probably best is if you know about these topics, add them and then point me to them to check for you. If you don't know what I'm talking about I'll try to find talk pages for you or describe them myself so you can FAQ-ize them and again I'll check them. My brain is too chaotic to patiently sit and write documentation and stuff myself (-:
Hmm, yes, it seems you're a bit chaotic: I posted on your talk page, not Connel's :-). I don't fully understand your post here, but it's getting late, so I'll reread it tomorrow. Cheers. — Vildricianus21:50, 27 April 2006 (UTC)Reply
Oh well sorry. Too many long bus trips, lugging heavy backpacks, and granitas de café (-: Also, feel free to email me if that's more convenient. You can do that via my talk page. — Hippietrail01:46, 28 April 2006 (UTC)Reply
Months and Days
Latest comment: 18 years ago5 comments2 people in discussion
Hi, Vildricianus. Would you mind having a look at the Appendices for Appendix:Months of the Year and Appendix:Days of the Week and be sure that both pages include the appropriate NL entries? Also, some of these basic entries may be missing from Wiktionary. Kappa has already helped to created the Korean ones, and I'll be looking for others to help in additional languages. Thanks for whatever help you can provide. --EncycloPetey09:31, 29 April 2006 (UTC)Reply
I'd already noticed it; nice pages. Would you mind me putting them in some visual table? Days of the week are ok. I'll add the Dutch months when I'm back. Cheers. — Vildricianus09:42, 29 April 2006 (UTC)Reply
Latest comment: 17 years ago239 comments12 people in discussion
Preamble and discussion
Hi again Connel.
I wanted to start a non-Beer-parlour thread on the subject of normalizing articles. I used to do it, stopped for a while, started again, and am now trying to stop again. I think you and Stephen also do this so for now I just wanted to discuss it amongst us before taking it to everybody on the Beer parlour. Please invite other contributors you know who normalize though.
We can bring it to the BP by just {{including}} this page there. But you may first want to move it out of your user talk page space. —Vildricianus | t | 09:33, 7 May 2006 (UTC)Reply
No way, no how. This is gigantic. My initial brain-storming list was a start, but about a quarter of them (or more?) have been contested. What I wish to present to WT:BP is the concise list of non-controversial terms only. As people see the positive effects each of these changes gradually has, we can add the contested or controversial topics to WT:BP separately, one per week. The ones I've struck out must not go any further at this time. But as this working-list settles down, I think we'll have a dozen items to present to the community, with explanation. That is probably too much for most people to grok all at once. Right now, we're still getting new, fresh viewpoints on things that seemed absolutely sound. Let's try to keep it small for a few more hours, then present only a tiny list of the things that we know are OK with everyone. --Connel MacKenzieTC11:04, 7 May 2006 (UTC)Reply
By normalization I mean making minor changes to formatting which usually make no or little difference to how a user sees the page, but does make them conform more to what each of us thinks of as best when editing a page.
Issues such as where to put blank lines and how many, whether to put spaces inside the == ==, or after asterisks in lists.
A few months ago I modified some of the stuff I had been doing for ages to bring it more into line with what I saw you were doing, but I seem to notice now some other things that Stephen and I might be doing differently, which has made me think we should check with each other about what such changes we've been making and agree with each other, then take what we come up with to the Beer parlour, altering the instructional pages on formatting if need be.
Well, I started with a list of twelve names, then realized I'd forgotten about another two dozen people. Rather than have anyone feel left out, I'll skip naming names. I'm sure all are welcome to chime in, and some probably will, here.
Because these activities always turn out to be more controversial than imagined, it might be considered improper to have a back room meeting. OTOH, this is not exactly behind closed doors. Furthermore, practically discussing these things in a small group first may wheddle out some of the more bone-headed things.
Where to start is also difficult. I'm not as consistent as I probably should be. Some of it is from semi-automatic changes from my monobook, others are specific requests (over time.)
I also consider the 3rd level headings consolidation efforts to be part of normalization. Those consolidation efforts (that Polyglot started) give en.wikt: a consistent look and feel, that significantly adds to usability. --Connel MacKenzieTC19:03, 2 May 2006 (UTC)Reply
Hi Connel. Would it be a good idea, for each proposal, to link to a pair of example words showing the yes/no usages. Just so we are certain that we understand what we are talking about? SemperBlotto08:20, 7 May 2006 (UTC)Reply
The list
1. No whitespace before first language heading
1. I agree. I've always done this. But note that disambiguation see also goes before here, and many times the wikipedia link - but the latter suffers from much variance. — Hippietrail16:32, 30 April 2006 (UTC)Reply
I agree. The 'pedia link should not go before the language header, as it may not apply to all languages on the page. Widsith10:36, 7 May 2006 (UTC)Reply
For section editing purposes, this functions as a separate section before the first section edit possibility. --EncycloPetey17:38, 7 May 2006 (UTC) (POV on your part. Note that just because something is called "incorrect" doesn't mean it shouldn't be done. In the Netherlands, coffee with cream is termed "koffieverkeerd", which literally translates as "coffee wrong", but that doesn't stop me.)Reply
2. No whitespace after a headerheading start, nor before a header end (i.e. between the == and the actual text.)
2. Do you mean between the == and the actual heading name? (I prefer "heading" to "header" by the way though I sometimes use the latter term due to programming habits) — Hippietrail16:32, 30 April 2006 (UTC)Reply
Realize that this one is actually, in part, determined by software. When you use the "+" tab to add a new section to a talk page, it prompts you for the heading, and when it constructs the == line for you, it does use those spaces. So, strictly speaking, for maximum consistency, we should either declare the spaces to be correct, or change the software to match our recommendation. (But I'm tossing this out as food for thought, not as a serious suggestion that the software needs to be changed.) –scs14:07, 5 June 2006 (UTC)Reply
I am unsure whether any discussion of this page is still actual, but I disagree here. As I mentioned on Connel’s talk page, it makes navigating easier if the spaces are there. H. (talk) 14:10, 12 March 2007 (UTC)Reply
3. No spaces or tabs after a header
3. Agree. I remove these often. Note that spaces at the end are usually due to copying and pasting from some other software. This is a very minor point for me. — Hippietrail16:32, 30 April 2006 (UTC)Reply
I agree we have to work around this bug: However, it is our duty to report it. I was looking to see if it's already reported earlier but that machine crashed. If anybody else can do that better than me, please do. — Hippietrail21:10, 2 May 2006 (UTC)Reply
4. No comments after header, on the same line as the header (breaks section editing!)
4. Is there a better place for such comments? I have done this from time to time when I've thought it appropriate. My lost parser could handle this. — Hippietrail16:32, 30 April 2006 (UTC)Reply
Again, as Vild points out below (and I expounded on above) this breaks section editing numbering...so clicking on the link on the right side of the page edits the subsequent section instead. --Connel MacKenzieTC23:41, 30 April 2006 (UTC)Reply
On #4: it seems to be quite important that there is nothing on the same line as the heading since this confuses the numbering of sections (you end up editing different sections than those which you intended to if there are comments after any header). —Vildricianus18:27, 30 April 2006 (UTC)Reply
4. No comments after header, on the same line as the header (breaks section editing!)
Do you mean for the "final" list (whatever that is) or that I should abandon the numbering concept within this page? I separated them originally for no reason whatsoever, but on reflection, they each have different reasons for being problematic. {Shrug}. --Connel MacKenzieTC16:42, 6 May 2006 (UTC)Reply
5. No templates after header, on the same line as the header (breaks section editing!)
5. I've also done this. My reasoning was that I wasn't sure that putting a category or a comment (as above) on its own line may introduce an extra blank line on some browsers. — Hippietrail16:32, 30 April 2006 (UTC)Reply
So it was you removing them? Ah ha! :-) . Well, I think that having the language heading stand out in the edit section is pretty important. (Gah, did I just say "heading" and not "header"? I'm messing up my own conventions now.) Also, AFAIK, this was the convention used by a clear majority of users, when I was learning Wikt: layout style.
6. No blank line after any header except for all level two language headings
7. Templates generally prohibited in headings and translation sections (notable exceptions: {{acronym}}, {{abbreviation}}, {{initialism}}.)
7. what about ((Acronym)) and ((Initialism))? Are these exceptions or should we stop this practice. Personally I've been doing this since it seemed standard but I never liked it. — Hippietrail16:32, 30 April 2006 (UTC)Reply
I've waffled a few times about this - I think I started this practice way back when. User:Dmh was doing is category/template experiments at the time; I took these to this "extreme" but I've never seen a viable alternative. --Connel MacKenzieTC23:41, 30 April 2006 (UTC)Reply
Even if the categories are "solved" (e.g. the 4th parent category becomes a separate super-category, but no longer a parent relationship to the other three categories) the template(s) would still need to add two (or more) categories to each entry. Using AWB, it is conceivable to subst: the template and zap the category to the bottom of the page. But AWB is not permitted to do that on en.wikt: just yet. Is it Vild? --Connel MacKenzieTC19:28, 2 May 2006 (UTC)Reply
So you advoicate removing the templates like {{temp|m}}, {{temp|f}}, {{temp|n}}, {{temp|c}}, {{temp|pl}}, etc from all the translation sections? I would agree with that. --EncycloPetey14:06, 7 May 2006 (UTC)Reply
For clarity: leave out the and translation sections part. At first, I didn't get that either, actually, until I realized this was about the {{lang}} templates ({{sv}}, {{nl}} etc). It was, right? Perhaps that deserves a separate section, although most of the work restricted to a dozen more templates to be subst:ed. —Vildricianus | t | 19:06, 7 May 2006 (UTC)Reply
7. Templates generally prohibited in headings and translation sections (notable exceptions: {{acronym}}, {{abbreviation}}, {{initialism}}.)
8. Wikification of non-"top 40" languages (as per HT's/SGB's final lists - I could care less.)
8. Stephen and I, and perhaps others have been discussing a more common sense approach than "top 40". The reasoning is that exotic languages remain exotic to the majority of users (readers) even if a fan of such language adds thousands of entries, and a well-known language with few articles still doesn't need to be looked up often. A sub-point is that I always wikify exotic language names also in the level-2 heading for the exact same reason. I know others don't do this and it may be that some undo this. — Hippietrail16:32, 30 April 2006 (UTC)Reply
As Vild comments below, I think you guys have a decent handle on these. I am mostly ambivalent about the final list. (I have my own POV, of course, but for this I can mostly ignore it.) --Connel MacKenzieTC23:41, 30 April 2006 (UTC)Reply
I really don't like the disparity. I understand it's nice to have a handy link to the entry describing a language you've never heard of; I understand such a link is distracting and unnecessary for a language everybody's heard of, but still, it seems odd to me to have wikilinks in headers at all, and just wrong to have this split scheme where sometimes the language header is a link and sometimes it isn't. I wish there were some completely different way to provide the convenience link to the language name, one that didn't have this disparity problem at all. –scs14:17, 5 June 2006 (UTC)Reply
10. I feel strong agreement here and have always done it. I have a pet peeve against "compressed" articles - those which use few or no blank lines. I find them unreadable. — Hippietrail16:32, 30 April 2006 (UTC)Reply
I agree - like Hippietrail says, entries with no blank lines between sections are difficult to read and edit. — Paul G07:21, 7 May 2006 (UTC)Reply
Disagree. I've tended to compress the initial sections (language, etymology, pronunciation) together, except when these sections are more than a line or two. I also disagree for a variety of foreign language situations. We have a current discussion (I forget where, at the moment) concerning the best place to put categorization tags for foreign languages. One favored suggestion is to place them immediately following the language header, which is the one I favor. I see no reason to have an additional blank line after that, though this is a special case. --EncycloPetey14:23, 7 May 2006 (UTC)Reply
This formatting guideline/recommendation has nothing to do with where the categories go. I said in the category-relevant sections that my opinion about category placement is just too controversial for this conversation. So, it is my opinion that in the case where those categories are "in the relevant section" that there would still be a blank line. e.g.
The blank lines here are what are being discussed, not whether to shuffle the categories to the bottom of the page. For foreign language entries, the white space is perhaps more important, as English-only editors have such great difficulty understanding what is there. --Connel MacKenzieTC17:42, 7 May 2006 (UTC)Reply
Note: finding "compressed" entries is a good way of identifying contributions from new Wiktionarians, that may need some gentle guidance. --Connel MacKenzieTC16:44, 6 May 2006 (UTC)Reply
11. One blank line after "inflection line" (originally for Polyglot, now this has grown on me.)
11. I always used to do this but grudginly gave it up and practised the opposite when I saw that was what you were doing. I would vote strongly in favour of keeping the headword/inflection/romanization line attached to the heading above it and with a blank line below it. — Hippietrail16:32, 30 April 2006 (UTC)Reply
I strongly disagree on this one. It results in compression, and the visual impact of this would be completely unacceptable in print, and I think it's unacceptable in a webpage as well. As a general rule, pages benefit visually from a little whitespace artfully applied to margins, between paragraphs, and before headers. Putting just a single blank line before ---- has the same effect as putting no blank line. I feel strongly that there should be two blank lines before each ----. —Stephen09:16, 2 May 2006 (UTC)Reply
I've never heard an explanation for this before, so I always thought it was a mistake. Now that I understand it is not a mistake, I'll try to look a few more before forming an opinion on it. --Connel MacKenzieTC13:38, 2 May 2006 (UTC)Reply
Solved this quite conveniently by adapting monobook.css. Perhaps this is a good candidate for adoption in MediaWiki:Monobook.css:
This is important. Everybody needs ---- in edit mode. Non-monobook users need it always. Am I right in saying most monobook users would prefer it hidden in view mode? If so we can move a version of this code into the standard monobook CSS. But can anybody think of a way to hide the actual line, but still add extra space? This aspect of this topic is beyond normalization and should probably be taken to the Beer parlour. — Hippietrail21:29, 2 May 2006 (UTC)Reply
I've only ever put a blank line before the ----. If it makes a difference (and I didn't know that it did) I'll put one before as well. — Paul G07:21, 7 May 2006 (UTC)Reply
On #14: I find that the Wiki layout renders too little space before and after horizontal dividing lines, which two blank lines may solve. But customizing the top and bottom margin in CSS might be a better solution. —Vildricianus18:27, 30 April 2006 (UTC)Reply
But what about the cases where categories are not placed at the end of the page? This is an on-going discussion, but the issue is that people editing only a single language on pages with multiple language headers need access to the categories for editing. One proposed solution (which I favor) is that for non-English categories, the category tags would be placed immediately following the language header. In this case, I would not favor including a blank line before the categories. --EncycloPetey14:23, 7 May 2006 (UTC)Reply
Gah. Excellent point. This was written with the assumption that categories were moving to the bottom of the page. So this needs to be clarified to refer only to categories (or groups of categories) appearing at the end of 1) A language section 2) the entire entry. --Connel MacKenzieTC17:45, 7 May 2006 (UTC)Reply
Well, I can see that. If there is any (consistency?) reason at all for prohibiting the space after ","framed":false,"label":"Reply","flags":,"classes":}'>Reply
Some more random thoughts: for the syntax ] on a talk page or referenced elsewhere, this may make sense. But in entries, for the ] syntax, I can see the need for consistency. There is no good reason for me to break with tradition on this one. --Connel MacKenzieTC16:50, 6 May 2006 (UTC)Reply
I don't think that the blank space is necessary. Coming from a programming background, I see this as being just like the C++ scope resolution operator :: for namespaces. The convention there is not to insert any spaces either side of the operator: namespace::class::subclass::method, for example. I think this is sufficiently readable as the colon takes up much less space than a letter and so can easily be skipped by the eye, IMO. — Paul G07:21, 7 May 2006 (UTC)Reply
OK, this one gets stricken. Not controversial: rather, this is not liked by anyone (except me.) I have stopped doing this (in the main namespace) but I'll continue to use it as needed, when discussing long category names in WT:BP or other non-main-namespace places. --Connel MacKenzieTC08:59, 7 May 2006 (UTC)Reply
18. Definition lines should be sentences, starting capitalized, ending with a period "."
18. I thought our policy was that if they are sentences they must be capitalized and end with a full stop, if they are simple glosses they should be all lower case with no full stop. This I agree with. — Hippietrail16:32, 30 April 2006 (UTC)Reply
18. Definition lines should be sentences, starting capitalized, ending with a period "."
I strongly disagree with this point. First, very few of the definitions found here are complete sentences. For example, for Armenian, the definition is "1. Of, from, or pertaining to Armenia, the Armenian people or the Armenian language". I believe rewriting the definition as a complete sentence would not be beneficial.
Second, almost no dictionary capitalizes definitions, and in the case of some definitions, capitalization actually causes confusion. If a definition starts with a noun, for example, capitalization sometimes suggests that the word is actually a proper noun.
Third, some words have translations instead of definitions. For instance, the Russian word солнце is "defined" as sun. The capitalized Sun is the wrong meaning. Even if we decide to keep capitalizing definitions, we certainly should not capitalize translations. In my opinion, neither should be capitalized, but parenthetic categorizations such as (Law) or (Slang)should be. —Stephen09:16, 2 May 2006 (UTC)Reply
For what it's worth, there seem to be two types of definitions that could benefit from sentence-style vs. non-sentence-style differentiation.
The common type of definition is one of equivalence. "foo ==Noun== # a type of bar" says that "foo" means "a type of bar".
The lesser common type of definition is used where such equivalence is impossible, unclear, or difficult. "the ==Definite article== # The is the definite grammatical article that...." describes "the" but does not provide its equivalence.
It would be great to see the two types of definitions differentiated in some way. Why not format the common type in the simple manner (i.e. no forced initial capital and no period) and format the rare type in sentence style (i.e. forced initial capital and ending in a period)? Hmm, I suppose this belongs on BP instead of Connel's talk page, so feel free to dismiss this post for its location or to ridicule its naïve hope for consensus. Rodasmith18:34, 2 May 2006 (UTC)Reply
If the above " sentences must be capitalized and end with a full stop simple glosses should be all lower case with no full stop" is current policy, it completely agrees with my above recommendation, so I hereby withdraw the above post. Rodasmith19:36, 2 May 2006 (UTC)Reply
If this turns out to be controversial, I would no longer regard it as normalization but as a formatting standard that needs to be voted on. I am completely open to thoughtful opinions on this. — Hippietrail21:56, 2 May 2006 (UTC)Reply
If you mean that the definition of cow, say, should be "A cow is an animal with four legs, one at each corner." rather than "an animal with four legs, one at each corner" - then I disagree. I prefer the second version. SemperBlotto22:02, 2 May 2006 (UTC)Reply
I'm not sure whom you were addressing, SemperBlotto, but if you were addressing me, then don't worry, I do not mean that definitions of such words should be complete sentence. Most words are best defined with "simple glosses" instead and hence have no need for an initial capital, a full stop, or anything else normally imposed by English grammar on sentences. As Hippie says, though, further discussion would be beyond the scope of normalization. Rodasmith22:33, 2 May 2006 (UTC)Reply
Perhaps I misjudged how controversial this is. I can see this as a topic worthy being voted on. But to my understanding, it was. This was a minor skirmish on Wiktionary talk:Entry layout explained, that I though had been resolved.
SemperBlotto, please explain why you think your second format is better. I don't see it at all. To me, the second format you gave is just inconsistent. --Connel MacKenzieTC17:00, 6 May 2006 (UTC)Reply
This one is a little bit contentious. As far as I am aware, very few, if any, definitions in Wiktionary are sentences. There is a linguistic principle that a definition should be substitutable for the word it defines, so that in a sentence, the word can be replaced by the definition and leave the meaning of the sentence unchanged. Hence you can replace "I saw a cow" with "I saw an animal with four legs, one at each corner" and the sentence has the same sense (provided cows are the only quadrupeds with a leg at each corner). It is not possible to do this with full sentences: *"I saw a cow is an animal with four legs, one at each corner" is incorrectly formed. Children's dictionaries sometimes use this format to make their definitions easier to understand to youngsters, but it is not appropriate for Wiktionary. Newbies and one-off contributors sometimes post "full-sentence" definitions, and when I see them, I change them to "substitutable" definitions.
Having said that, I think the issue here has been incorrectly worded: I see it as being whether definitions should be all in lower-case or should begin with a capital letter and end in a full stop/period. That is not the same as their being full sentences, because, simply put, they are not. (I'll leave it as an exercise to the reader to look up the rules for what is required for a string of words to be a sentence.)
I have no strong views either way, but agree with the points made about possible confusion between the capitalised and lower-case initial letter of the first word. I probably come down in favour of the lower-case form, for several reasons:
Avoidance of the confusion mentioned above.
Most other dictionaries do this (although it should be noted that the OED does not). This could be to save ink or space, which, given that the current OED runs to 20 large volumes, is clearly less of an an issue for them.
Initial capitals and final full stops suggest sentences, when the definitions are not (although see how I am formatting this list :) ).
Consistency with non-English entries, where only translations or glosses are given and these are in lower-case with no final full stop.
It makes it clearer that the definition can be substituted for the word.
It looks silly when the definition is a single word.
Wikification of the initial word is straightforward (] rather than ]).
Wow. Well, spot checking a few Webster's 1913 entries, they do all seem to be in sentence form, not replacement form. Perhaps it is a pondian issue, after all? As far as I knew, the replacement form is only used in smaller dictionaries, to save space.
To be honest, I never understood the replacement form until I read your explanation above, Paul. Thank you for the clarity.
For your reason #4, I was suggesting this rule apply to those as well.
For your reason #6, I am pretty sure all English words can be a sentence by themselves. Subject/noun/verb is of course the correct requirement, but two of the three are and often can be implied. Run. (Yup, that's a sentence.) Fire! (Yup, that's a sentence.) I. (Yup, that's a sentence.) No. (Yup, that's a sentence.) Yes. (Yup, that's a sentence.) Spaghetti. (Yup, that's a sentence.) Leeds. (Yup, that's a sentence.) Fishing. (Yup, that's a sentence.)
For your reason #7, that is a very good point. For nouns, I usually precede the term with "A " to avoid that issue; for verbs I use "To ".
I also forgot to mention: the cow example wansn't quite right. Substituting the Wiktionary definition, you'd get "I saw An animal with four legs, one at each corner.." which if you read without regard for capitalization or punctuation, would be coherent, even in your scenario. --Connel MacKenzieTC08:55, 7 May 2006 (UTC)Reply
I actually don't think this is really part of the normalization process, but something of a different nature. After all, it does make a difference for the reader, doesn't it? So perhaps this has to wait for a second round of discussion, if all this is brought to the BP. But on topic: I'm with Connel here (I think so), and I don't think it's a Pondian issue. I prefer "An animal with four legs, one at each corner." On the other hand, I understand that many definitions are still lacking, and it would be a waste of time to make lacking or embryonic definitions into sentences, as they still need to be expanded. —Vildricianus | t | 09:55, 7 May 2006 (UTC)Reply
I think this has to be taken on an entry-by-entry basis. I feel, with Paul and Stephen, that having to make every definition a full sentence may sometimes be a constraint. However note that with some complicated terms, eg theological terms or abstract concerpts, a ‘replacement form’ is not always possible, and full-sentence (ie natural English) explanation is desirable there. Widsith10:44, 7 May 2006 (UTC)Reply
I can't see any rationale to support one form over another. The only comment I'd make is that all the definitions for a single word should be formatted in a single form, rather than mixed (which looks bad, as if someone wasn't paying attention to wehat they were doing). --EncycloPetey14:23, 7 May 2006 (UTC)Reply
I guess my rationale for thinking it was a non-controversial "normalization issue" (which it is not) was that if we are striving for consistency, then all definitions in Wiktionary should appear as sentences. I'd never heard Paul's eloquent rational for the "replacement style" before, and while that does affect my POV, I'm not entirely sold by any means. I still think that to be consistent, Wiktionary should choose a single style...which would force it to be "sentence style." --Connel MacKenzieTC17:50, 7 May 2006 (UTC)Reply
Wow. Lots of good arguments here, which I haven'd digested all of. Me, I'm strongly in favor of the "replacement style", for precisely the reason Paul described. I'm somewhat in favor of formatting most definitions (even though they be fragments) with initial caps and final periods, if for no other reason than that I think they look better that way. But there are exceptions. Sometimes, for a complicated definition, "replacement style" is unwieldy, and the reader is better served by a full, grammatical sentence. When a definition needs a second (or third) clarifying sentence, those are full sentences even if the first is a fragment. Finally, when a definition is a translation I agree that it's best left unadorned, with neither initial-cap nor final-stop. So I'm guessing -- at least based on my own proclivities -- that the "policy" here would end up involving several decision points and judgement calls, and would not, after all, end up imposing any kind of absolute uniformity, neither decreeing always or never full sentences, nor always or never caps and periods. –scs14:30, 5 June 2006 (UTC)Reply
I (somewhat controversially) altered the default monobook CSS to hide the ---- but increase blank space in its place. I think it ought to be default so I've started a topic on the Beer parlour. I think this is more cross-platform that Stephen's solution which in my experience gives different results in different browsers. Please comment. — Hippietrail20:35, 6 May 2006 (UTC)Reply
Disagree in cases where we have inflection lines and images and wikipedia links and... I'm not sure how this should be handled, but multiple blank lines is the only slution I've found for certain cases where all the included items end up overlapping each other. --EncycloPetey14:23, 7 May 2006 (UTC)Reply
No Vild, it's not bad layout. EncycloPetey, what I do in those cases is migrate the float=right items around. So, one before the ==English==, one after ===Etymology===, two after ===Noun=== (before the inflection line, with no blank lines) and any others below. Could you please provide an example term or two, so we can all clearly see what you mean? I am pretty sure I still disagree with multiple blank lines even in this circumstance. The worst I've had to do so far, to date, is use {{-}} to help things align...but not multiple blank lines. --Connel MacKenzieTC17:54, 7 May 2006 (UTC)Reply
Hmm? I think it is (and this is regarding this section's topic, namely two blank lines). What do you think about another point that widely varies between editors: placement of the {{wikipedia}} link? In most instances it is placed under the POS header, but if Ncik's boxy templates are in place, there's overlap between them. BTW, I didn't even know of {{-}}'s existence. Nice thingy. —Vildricianus | t | 19:15, 7 May 2006 (UTC)Reply
20. controversial: Categories to bottom of entire page, not language section
20. controversial: Categories to bottom of entire page, not language section
A related issue is categories between headings where a blank line would otherwise go. I've been leaving these untouched so far. I tend to agree that this one is controversial and that takes it beyond the scope of normalization for now. It would need discussion and perhaps voting on the Beer parlour first. — Hippietrail22:39, 2 May 2006 (UTC)Reply
I disagree - it is often useful to put categories alongside what they apply to. For example, I routintely put ] in the pronunciation section, which makes it clear that this has been considered. Putting it at the bottom can make it look like it has been overlooked.
Another reason for putting categories in the place where there apply is if, for any reason, that content is deleted (perhaps because the content is wrong), it is clear that the category should be deleted as well. If the category is at the bottom, it is very easy to overlook it.
Furthermore, as categories do not add any formatting to the final page (except for being listed at the end), there is no harm in putting categories close to the content they apply to. (Or maybe they do add whitespace - see #26 below.)
So, you are saying this should be discussed in the "controversial issues" section instead then, right?
Note that many entries already do have all categories moved to the bottom. If you wish to remove a section now, you currently have to check both places; where the category might be relevant, and at the bottom of the entry. And perhaps the end of that language seciton as well. If we decide at some point that categories belong where they are most relevant, who will go back and change the last 71,000 English entries, to comply? --Connel MacKenzieTC08:33, 7 May 2006 (UTC)Reply
Disagree for non-English. Users editing a single language need to be able to find all categories listed with that language's section. Otherwise, what's the point of being able to edit long pages by section? I don't want to have to hunt for categories that might be at the bottom of the page or might be carried in an included template or might have been dropped somewhere else. I favor placing all categories for non-English languages immediately after the language header. For English, the bottom of the page makes the most sense. --EncycloPetey14:23, 7 May 2006 (UTC)Reply
Personally I'd like to agree, because I'm using a fully UTF-8 capable browser now, but that's a pretty recent thing for me. For people who aren't able to (or don't know how to) edit Unicode, HTML entities are preferable. Are we ready to lock such people out?
(Side notes on what I just said: (1) Yes, since most of our entries do use UTF-8 unapologetically, someone who can't handle it is in big trouble already. But I worry -- even though it's a pretty small possibility -- about someone who makes a new entry using HTML character entities, comes back tomorrow to work on it some more, and can't, because the entities have been autoconverted to UTF-8 behind his back. (2) Even for the majority of editors who do have UTF-8 capable browsers, I'm not sure they're all suitably aware of all of the new distinctions which can and sometimes must be made. If you're used to working just in ASCII, or just in 8859-1/Latin1, you've got some surprises in store when you start using Unicode. There are three kinds of double quotes " “ ” and four kinds of apostrophes/single quotes ' ʼ ‘ ’. This ASCII hyphen - is not the same as this en dash – which is not the same as this minus sign − which is not the same as this em dash —. This turned letter ǝ is not the same as this schwa ə (a distinction which I only learned of after observing the difficulties Hippietrail and Paul G had with the rhymes:English:-eɪʃǝn page). And so on. And if you're not aware of these and several other equally subtle distinctions, you can goober things up, as witness the redirect of aren’t to aren't (or, for that matter, from it's to it’s -- everybody caught the inconsistency there, right?). And even if you are aware of the distinctions and your browser does support UTF-8, you may not know how to enter all those strange characters that aren't on your keyboard...) –scs15:12, 5 June 2006 (UTC)Reply
Well, we already do, by policy. The choice could have gone either way - towards HTML coded for editing or towards UTF-8 for editing. It went towards UTF-8. The recommendation to avoid HTML coding at all costs, is so that Searching works. --Connel MacKenzieTC15:26, 5 June 2006 (UTC)Reply
I agree, but we need a good and easy to find resource available explaining the ins-and-outs of tables, including how all our own templates are set up. Most of what I've needed, I've had to pull from existing examples I've come across here and on Wikipedia. --EncycloPetey14:31, 7 May 2006 (UTC)Reply
I've never seen such HTML tables, only in templates. Perhaps it's a better thing to say that in the main namespace, all wikitables should be hidden in templates, notably the top/mid/bottom ones, and preferably, also inflection templates. —Vildricianus | t | 09:57, 7 May 2006 (UTC)Reply
23. All POS (or equivalent sections) must have at least one line starting with "#" before the next heading
23. All POS (or equivalent sections) must have at least one line starting with "#" before the next heading
I have a CSS / Javascript idea for those who don't want to see sense numbers for single-sense articles that should overcome any difficulty here. — Hippietrail22:49, 2 May 2006 (UTC)Reply
I agree, subject to what Connel says - a few pages exist purely for the purpose of providing translations (see also day after tomorrow). Perhaps #23 can be reworded to take this into consideration. — Paul G07:21, 7 May 2006 (UTC)Reply
I think day after tomorrow deserves a definition. Agreed, it's a bit weird for English, but taking into account that in other languages it's often a single word, I'd say we can just as well define the concept. —Vildricianus | t | 10:02, 7 May 2006 (UTC)Reply
I don't see how this wording doesn't already take that into account. I think my pet peeve I was trying to address when I wrote this was this style:
There already is a less intrusive place for alternate spellings (before etymology.)
Interleaving them makes parsing harder, as any program must assume the definitions "belong" to the alternate spellings heading, instead of the noun heading.
Even in the case where it is possible for alternate spellings to exist for a single part of speech, the sub-heading (as all other sub headings) needs to follow the definitions, not precede them.
Reducing the number of third level headings in en.wikt:, by combining things like "===Pluralish noun===" or "===Noun phrase===" into 'standard headings' like "===Noun===". --Connel MacKenzieTC13:38, 2 May 2006 (UTC)Reply
I am in favour of this but again I feel it's too controversial for this discussion. I would love to see it fully fought out and decided elsewhere though. — Hippietrail22:51, 2 May 2006 (UTC)Reply
Broadly in favour, although trimming everything to "Noun", "Verb", etc, may be too extreme. For example, the OED uses "vbl. sb." (verbal substantive ) and "ppl. a." ("participial adjective") for words like "freezing" in "it's freezing cold" and "this food is suitable for freezing" to show that these derive from the verb "to freeze". I think it is useful to retain parts of speech like "verbal noun" and "participial adjective". On the other hand, "noun phrase" (which should probably be "substantive phrase" anyway) can be trimmed to plain "noun" without loss of useful information - a noun is a noun, and you can tell it is a phrase by seeing that it contains more than one word. — Paul G07:21, 7 May 2006 (UTC)Reply
I think this should be deferred to the "too controversial" list, for now. All print dictionaries that I know of list parts of speech as abbreviations. Spelling out the meaning of the abbreviation is very confusing to the average reader (who just wants a frikkin definition!) My pet peeve is Transitive vs. Intransitive being split into sepatate headings, instead of a single Verb heading. That however, is spectacularly controversial. Because of the embyonic state of Wiktionary today, the focus most often leans towards assisting entry of translations. As Wiktionary matures, the focus will shift towards making entries readable especially to the average reader. If we want to retain this, on this list, we'll have to specifically exclude my controversial Tr/Intr issue, I think.
I find that "Noun phrase" is utterly useless; I completely agree with Paul that "phrase" should be omitted in that case. OTOH, the "Phrase" heading alone/itself is particularly useful for phrasebook entries. The "Idiom" heading is astoundingly useful; even when a particular form of an idiom can be pigeon-holed into a particular part of speech, other similar forms (that redirect to it) often are not the same part of speech/function! I feel strongly that idioms should be listed under the "Idiom" heading, while any part of speech should be listed at the start of a definition line. That, of course, mimics what print dictionaries do. --Connel MacKenzieTC08:12, 7 May 2006 (UTC)Reply
Agree with HT. Too controversial for this topic, and it has recently been "discussed" again in the BP. Even though personally, I'd love to see, at last, an exhaustive and final list of POS headings compiled, each with considerable archived arguments for future subdual of contestation. But that'll be for the next round. —Vildricianus | t | 10:12, 7 May 2006 (UTC)Reply
This deserves it's own discussion, but it is worth pursuing to see what POS headers are desired, needed, and used. I thought I had a good handle on these until I started creating Latin entries. --EncycloPetey14:31, 7 May 2006 (UTC)Reply
I strongly agree this must go to the "controversial" list. Part of the actual resolution will have to be devising a list of headers (confer: /todo2) for discussion. --Connel MacKenzieTC18:02, 7 May 2006 (UTC)Reply
Even though there are aspects which are controversial, I think we could and should do some consolidation now, as part of this normalization. If you look at Patrik Stridvall's header list at http://tools.wikimedia.de/~stridvall/headers.php under English, you see wild variation. We may not have decided (and may never decide) whether to have "Transitive verb" and "Intransitive verb" or just "Verb", but let's get rid of "Transitive Verb" and "Verb, transitive" and all the other inconsequential variations.
Although this makes no difference to the output, it is possible that some time in the future we might (although I wouldn't like to see it) change {{m}} to expand to masculine rather than m. Having used the template for this everywhere would make this very simple and quick to change. We have already seen this happen with {{p}} which has changed from pl to plural (there is a separate discussion of this elsewhere and so it would be off-topic to discussion here whether this is right or not).
I think that conversation is welcome here. As another side note, I think Hippietrail is doing some experimental magic/css with these particular templates as well. --Connel MacKenzieTC08:01, 7 May 2006 (UTC)Reply
Yes, HT made it possible to choose whether they have a period or not: m vs. m.
NO, IT CANNOT BE DONE BY 'BOT! I had this particular change in my monobook.js for a long time; it worked correctly about 70% of the time - but there are a gazillion cases where it did false-positive replacements that I had to undo by hand. (This was why I started considering the "edit row buttons", so that I'd be able to skip certain types of edits manually.) To fully automate this would be a dreadful mistake. --Connel MacKenzieTC18:08, 7 May 2006 (UTC)Reply
Disagree, because this contradicts what was said above above removing templates from translation tables. I would like to see these gender/number templates used everywhere except in the translation tables.--EncycloPetey14:31, 7 May 2006 (UTC)Reply
Um, translation tables happen to be the place where they were made for and where they're most used. In most other instances, the unabbreviated word should be mentioned. —Vildricianus | t | 15:02, 7 May 2006 (UTC)Reply
EncycloPetey, unfortunately I think you misunderstood the guideline/recommendation in the section above. This change would not be limited to translation sections, nor would it be limited to non-translation sections. This is about replacing the text ''f'' with {{f}} wherever it occurs. --Connel MacKenzieTC18:08, 7 May 2006 (UTC)Reply
Monstrously controversial: At the bottom of a page, since numerous categories add blank lines to the bottom of a page, all categories should be listed on a single line. Note that this is a distinct fork from current practices. Effecting this massive change can only be done with semi-automatic (e.g. WP:AWB) or automatic (pywikipediabot.py) assistance. --Connel MacKenzieTC16:54, 6 May 2006 (UTC)Reply
Hm, I'm not sure what you are saying, Connel - do you mean they should be typed on one line, or rendered by the software on one line? I was under the impression that categories do not add blank lines to a page (see #20 above). If they do, perhaps the software should be modified so that they do not. Or do you mean all on one line when they are rendered? Probably not, because that is how they appear. I don't like this proposal, in any case. — Paul G07:21, 7 May 2006 (UTC)Reply
I'm saying that if each category is on a separate line at the bottom of the entry, the MediaWiki software make that line invisible/blank for the next pass of rendering. If there is one blank line, it is not problematic. If there are 20 categories, the intermediate processor will render 20 blank lines, resulting in a screen-full of nothing at the end of the page. Actually, I have not sufficiently tested this, so I'll do so now, on this page. --Connel MacKenzieTC07:54, 7 May 2006 (UTC)Reply
Perhaps this could be better restated. "One space after line-start wikisyntax." Or: "One space between wikisyntax and visible content." The reason I am inconsistent is that "*:''" is something I confuse with "*: ''". Um, I mean without the double-quotes.
Argh. OK, said a different way: line start wiki-syntax characters that can have a space after them, before the content starts, should. Doing so helps newcomers understand which characters are wiki-formatting and which are content-formatting. This "guideline" could apply to stackable ("*", ":", "#") and non-stackable ("{|", "||", "|}") wiki-syntax.
Thornier issues exist, like definition line "tags." For a while, we've waffled between (tag1), (tag2), (tag3,), (tag4, tag5):tag6: and many others. Recently, I was scolded for ending a list of tags with a colon, as there was already parenthesis there. But it is also improper to have a list of parenthetical items. I think the parenthesis are astronomically stupid looking now. I'd like to see that issue on the BP and voted on. Maybe parenthsis abuse is a British thing, I dunno. But we probably shouldn't have any parenthesis on any definition lines, ever.
This whole topic could also be restarted for each namespace, as each seems to have its own rules: Templates (doc on page, or in talk?,) Categories (crazy pipe partial-sorting thing,) Appendix (pseudo-namespace, Wikipedia=style heading rules), Wiktionary (1/2 Help: format, half blog format) etc.
Let me comment on your points. Please do not change their order or remove any since I'll refer to them by number:
comments moved into corresponding sections above
Definition tags are a problem. However I've been thinking a lot about lists lately and I think we can achive a lot by making them use simple # for editing them, and CSS to format them, probably with some kind of ((list)) and ((end)) templates to contain the CSS classes and id's. Our current systems cannot handle placing multiple tag templates within one set of parentheses and muliple parentheses are ugly. Another simpler idea is to just forgo the parentheses as many print dictionaries do. Italics alone should suffice. My pet peeves are: 1) mixing italicized and non-italicized parentheses. 2) italicized parentheses altogether. 3) use of colons together with parentheses.
The definition tags need perhaps a whole separate conversation. Whatever we end up with has to adhere to the KISS principle. Multiple parenthesis are more than ugly; they are incorrect. More and more, I think we should not have parenthesis at all. Your point #3 is exactly what people complained about me doing. I think multiple parenthesis are far worse, but that is my POV. --Connel MacKenzieTC23:41, 30 April 2006 (UTC)Reply
As an interim compromise, I would propose that we do recommend using templates for definition tags, always. Rendering (whether italic or not, parenthesized or not, abbreviated or not, etc.) can be handled by the template expansion and by Hippietrail's CSS magic. The only hard problem is how to deal with multiple tags (e.g. UK-specific vulgar computer slang), but I'm willing to defer that, and to live with redundant, uncollapsed parentheses today. —scs15:36, 5 June 2006 (UTC)Reply
On other namespaces, I think it would be too distracting to worry about them at this stage. I think more can be accomplished by concentrating on the main area first. The rest can be addressed when we see our progress. — Hippietrail16:32, 30 April 2006 (UTC)Reply
Speaking of "topics deferred", do we ever want to address the formatting of pronunciations, the handling of the several different schemes, etc.? —scs18:05, 5 June 2006 (UTC)Reply
As a fervent normalizer (12k edits that rely heavily on this business), I'd like to add some things. I understand from the above points that this is more or less the desired output:
The "perfect" format
{{see|Word}}
{{wikipedia}}
==English==
===Noun===
{{infl}}
# After a space, a definition with first-letter uppercase and full stop.
====Related terms====
*]
*]
====Translations====
'''gloss'''
{{top}}
*Dutch: ] {{m}}
{{mid}}
{{bottom}}
'''other gloss'''
{{top}}
*Dutch: ] {{f}}
{{mid}}
{{bottom}}
===Reference===
{{R:Webster 1913}}
]
----
==Spanish==
===Noun===
'''headword'''
# ]
]
]
Additional comments
Comments
This is not entirely the way I've been doing it but I understand that it's largely what Connel's points involve. Right? Never mind the placement of categories now.
Individual comments moved to appropriate section above.
On tags: I've been thinking and looking to what print dictionaries do, and have found the SOED, which uses italics and small caps, to have a nice format. Thanks to the templates we use for them, we can change this overnight, although we'll need to instate commas where necessary. To give you an idea, it looks like this:
AERONAUTICS Definitions.
NAUTICAL, CHEMISTRY Two tags here.
It's of course also possible to "solve" the tag issue by adding the parentheses manually and leaving them out of the templates, like ({{biology}}, {{chemistry}}). —Vildricianus18:27, 30 April 2006 (UTC)Reply
Note: I added the blank line after the inflection line in your example above, but I left the "incorrect" category placement as that is so touchy. --Connel MacKenzieTC23:41, 30 April 2006 (UTC)Reply
NOTE: (as I said above) I plan to move all of this to subpages here. Each numbered list item above will become a heading and I'll rearrange some of the related ones after adding yours and HT's comments into each section. --Connel MacKenzieTC23:41, 30 April 2006 (UTC)Reply
Yup, fine. I'd concentrate for this round on the 20ish points, leaving discussion about tags and category placement for later (the latter is "ongoing" at BP). —Vildricianus07:59, 1 May 2006 (UTC)Reply
I'm finding it difficult to relate the comments to the points, but in general I agree with the sample layout that Vildricianus layed out above. There are just a few points that I would disagree on or don't understand:
Individual comments moved to the appropriate section above.
Oops, I forgot to comment on this first time round. I prefer to put the {{wikipedia}} tag between the POS and the inflections. Not only does this put the Wikipedia link along side the word to which it refers, it also usually avoids adding any blank space to the rendered page. Putting it at the top or elsewhere can often do this, making the page look inelegant. — Paul G07:27, 7 May 2006 (UTC)Reply
My convention is dependent on the number of headings in an entry. If there are more than three headings, an automatic TOC will be generated. When a TOC is present, it makes sense to have the {{wikipedia}} link above the first heading so that it appears in the white-space to the right of the TOC. But if there are less than four headings, I do exactly as Paul says: between the POS heading and the inflection line. --Connel MacKenzieTC07:50, 7 May 2006 (UTC)Reply
Regarding terminology: "heading" vs. "header". I understand the confusion that exists with the overlapping of terms with regard to C/C++ ".h" files. However, we are in a Wiktionary context, not a C or C++ context. I use "heading" to refer to a rendered == == section heading and "header" to refer to the wikitext that denotes it. I'd prefer to not change my informal convention, as the distinction is perhaps helpful, sometimes. --Connel MacKenzieTC13:46, 2 May 2006 (UTC)Reply
Actually there are other senses I was think of such as in binary file formats. Encarta does however give a sense for "header" that is pretty much a synonym for "heading". Collins doesn't but hey this is all just trivia. Back to the topic (-: — Hippietrail22:55, 2 May 2006 (UTC)Reply
I think this thread is a valuable resource regarding Wiktionary terminology (things like "inflection line", "POS headings" etc.) Anyone feels like expanding Wiktionary:Glossary? Or shall I put it on my Todo? Having a comprehensive reference list of these is beneficial for mutual understanding on all this matter. —Vildricianus | t | 10:29, 7 May 2006 (UTC)Reply
I think we are nearing the wrap up time for this, as Vild pointed out in the top-most section. I would like to thank everyone who has participated. I also request that each continue to participate.
Vild, HT or I will take this list, glean the least controversial dozen or so items and build a small list to post on the BP in the next day or two. Some rewording of HT's preamble may be in order. My initial list had some pretty bone-headed stuff, that I think you've all helped clear away.
I have enjoyed (perhaps the most) Paul's linguistics lessons, even if I do still disagree. I did not expect this to be so educational, but I am glad it was.
Thank you all again. Let's see where we take this next, eh?
How about wrapping up? I could make a summary of this, put it in the Beer parlour and expect a couple of people to laugh at us. Most of the above described format rules are exercised by my javascript, though, so given enough time, all entries will move towards this standard (especially the blank lines stuff, which is largely at odds with what most entries have and most contributors do). — Vildricianus11:57, 5 June 2006 (UTC)Reply
Several unrelated goals here
You guys may be ready to "wrap this us", but remember, some of us just got here. :-) Me, besides the comments I just sprinkled above, I've got one biggie: some of this stuff matters much more (or at least, differently) than others.
There are several quite different goals someone might have in pursuing this normalization:
(A) Make pages look consistent to readers.
(B) Make page source look consistent to editors.
(C) Enable automatic processing, today, e.g. by using templates for gender and definition tags.
(D) Enable machine parsing of wiktionary entries (for other purposes).
(E) Turn Wiktionary into the more-structured database some of us wish it were.
Of these, to me, (B) is the least important, although about half of the entries on the normalization list have to do only with this. A reader doesn't care about blank lines before or after headers, or extra spaces between the == == and the heading text. And a (reasonable) parser doesn't care, either. Obsessive editors might care (and I don't mean to be critical when I say "obsessive" here, as there are plenty of these things that I'm obsessive about, too), but to me, if an entry is complicated and hard to edit I'll add a few blank lines here and there without thinking about it too much, and if an entry is too sparse I'll delete some blank lines without thinking about it too much, and I really don't worry about "standardizing" this sort of thing. A guideline for the preferred formatting at this level would certainly be useful, but it doesn't have the same kind of urgency as the other four goals I've listed.
Of these, to me, (D) and (E) are quite important, although I know that there are lots of editors for whom they're not important at all, who are just as uninterested in machine parsing as I am in normalizing newlines. And there's nothing wrong with that, either; there are legitimately multiple goals here (only partly overlapping, or sometimes wholly distinct). (So what I'm saying here is that it doesn't bother me if someone is uninterested in machine parsing, or interested in blank lines, as long as they're not bothered by the fact that I'm not.)
But I bring this up because I think the larger audience is going to be equally struck by what they'll see as the same kind of differential importance of these issues. So I think we need to at the very least split them up, and perhaps even address them as somewhat separate subprojects. Here's my take:
issues that matter for proper functioning of existing software
3, 4, 5
issues that are visible to readers
7, 8, 18, 23, 24
issues that enable wiktionary-specific processing, visible to readers
25, (definition tags templateized)
issues that are visible only to editors (cosmetic)
1, 2, 6, 10, 11, 12, 13, 14, 15, 16, 19, 27
issues that are visible only to editors (possibly more significant)
There's some overlap there; in particular, everything I've listed as "issues that matter for machine parsing" is also in some other category (usually, interestingly enough, "issues that are visible to readers").
I have included "definition tags templateized" (which was in Connel's "Topics deferred" section), because I think it's as least as interesting as some of the other issues listed here, but not as controversial as some. Call it #28?
1/ I have a gut feeling that there are more editors than readers. 2/ This list was initially intended for the hardcore normalizers like Connel, Hippietrail and a few others. Other options got stuffed in afterwards and it turned out to become a more general discussion. So (B) was really the first purpose of this thread. Having the blank lines appearing correctly is not very important, but fun for those who care and easy for a javascript to add. It also allows for quickly spotting "bad" entries, i.e. those with everything compressed, which is usually done by the less experienced here, and which are therefore possibly "bad". 3/ The other options you presented are also worked on, for instance with the inflection templates. I'm not sure though how urgent they are. Machine-parsing Wiktionary has only been done by the few (Connel, Patrik,...) who wanted to put up todo lists or stats. There's much more work on the actual content before we should consider any other fancy option. That doesn't defer normalizing for machine parsing, though. But it's not "urgent". It's work in progress just as much as the other jobs are. Compare the format of two years ago with the current. Also keep in mind that it changes constantly. 4/ I'm really bothered by the fact that you don't like the blank lines :-(. 5/ Thanks for commenting on it. I guess it's a topic that will pop up from time to time in order to get one another's confirmation of existing practice (which is what I think Hippietrail intended to do). — Vildricianus17:47, 5 June 2006 (UTC)Reply
Agreed that machine parsing is a longer term work-in-progress -- but note that it applies even though (nay, because) the format "changes constantly": if/when we do a big format change, the more we can automate it, the happier we'll be. (Now, as for those cotton-picken blank lines, I don't just "not like" them, I can't stand them, I fly into a blind rage when I see them, I delete them on sight, I'm really bothered that you could consider sneaking your slovenly blanklineist POV into this vital emerging policy...) —scs18:27, 5 June 2006 (UTC)Reply