Jump to content

Wiktionary:Grease pit/2007/June

Add links
From Wiktionary, the free dictionary
Grease pit archives edit
2024
2023
Earlier years
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006


In an effort to solve the formatting woes that {{wikipedia}} and friends cause, I have created {{projectlinks}}, which draws on new lite-version templates for all the projects that I also just created. I've put it in United States (only because that's an article with several crossproject links) as an example. You can see all the parameters demonstrated at User:Dmcdevit/Test1. This is an improvement on the current scheme in several ways. All interproject links go in their own section at the bottom titled == Sister projects ==, and do not interfere with any other sections or images on the page. This also means that you can have as many project links as you want without overloading the page with boxes. It's noticeable, but not intrusive, and simpler. It also combined all of the potential project links into one template; I created the output on United States with just {{projectlinks|pedia|commons|news|quotes}}. I also made these cuter than the previous {{pedialite}}, with logos and bolding.

Finally, I recently imported the "interProject" class from Spanish Wikipedia. You may have noticed it already in the sidebar for anything that has {{wikipedia}}. Look at the sidebar at United States and you'll see links, just as with interlanguage links, to the other projects. The template does this (though now you can create this functionality anywhere with <span class"interProject">[[w:foo|Wikipedia</span>). This ensures that the links are visible, and don't get washed out by long articles, especially since someone looking at, say, the German section, is not necessarily going to read all the way to the bottom, after Japanese and Swedish.

This is a good compromise between the visibility issues of the lite-version templates, and the formatting problems with the boxes, and I propose that it be used universally. (Note that it's not final yet, I still have to add the parameters from the existing templates for full functionality.) Thoughts? Dmcdevit·t 08:45, 8 June 2007 (UTC)[reply]

I managed to add the language parameters (see example), but it is messy. I'm not sure if that was the most efficient way to do it. I'm having trouble with the other two (changing the page specified, and/or the page displayed). Dmcdevit·t 09:59, 8 June 2007 (UTC)[reply]

[...] The documentation of the parameters is at Template:projectlinks. Perhaps I'm getting ahead of myself, but I would like to propose that we migrate all of our crossproject links to this unified system. (Also, thank you to Pathoschild for help on the template coding.) Dmcdevit·t 00:54, 9 June 2007 (UTC)[reply]

I do not agree with certain aspects of your solution. We need to really think through how to link to each sister project, especially Wikipedia for which there's a distinction between disambiguation pages, paralleling our own entries in some ways, and pages that refer to specific meanings of a word that may have many definitions. {{pedialite}} or an alternative needs to be included several times, and having a single call to do this is not elegant. I have an example at fish that's a little ugly visually (I don't know how to fix the CSS stuff) but makes that nice distinction in code, using a new template {{pedia}} which calls either {{pedialite}} or the new {{sister}} depending on the parameter. The one thing I fully agree with you on is that the {{wikipedia}} template should be phased out in the near future. DAVilla 01:15, 9 June 2007 (UTC)[reply]
I agree also that the {{wikipedia}} should go (even though I've added a lot of them) - seems like I never see them in the same place twice, although I always try and stick 'em at the top of the page. What about links to foreign-language Wikipedia projects (I've put in a number of those as well, see e.g. deism and pandeism)? bd2412 T 01:26, 9 June 2007 (UTC)[reply]
The template can easily link to disambiguation pages, or any page with a different name, where needed, with the "pageX" parameter, and to any language for any of the projects (with "langX=Y"). Take a look at the documentation. I'm not sure what specifically you don't like about how it would look at fish. I've changed fish to this template (revert back after you've seen it if it's terrible), so you can see what I'm getting at. We can work on the details. Dmcdevit·t 01:28, 9 June 2007 (UTC)[reply]
Each use of the template would appear in only one language section, so having lang1=, lang2=, etc. is pointless. There should only be one lang paramter. While my implementation is a little simplistic at the moment, this one is already far too complex. DAVilla 01:46, 9 June 2007 (UTC)[reply]
That's not necessarily true, since a page with multiple languages may have the need to link to projects in multiple languages.
In which case the template would be used several times, in multiple language sections. DAVilla
In any case, it should be simple enough to make it so that simply lang=X with no number will use that language for all projects used. Dmcdevit·t 01:51, 9 June 2007 (UTC)[reply]
That's not the only simplification I want to make. Consider the ease of use for {{sister|pedia}} and {{sister|disambig}} for linking to disambiguation pages, the latter appending (disambiguation). DAVilla 01:55, 9 June 2007 (UTC)[reply]
If I understand it right, all that template does is recognize that "disambig" means you want a disambiguation page on Wikipedia, without you telling it the project. That's no harder, {{projectlinks}} does that now. Dmcdevit·t 02:19, 9 June 2007 (UTC)[reply]
So you've hijacked my example? Okay, no hard feelings, and actually not bad visually, except you've got two lines that read:
It's probably not hard to change the second one to read "disambiguation page" instead of "article", but you have a problem in that you assume that (disambiguation) is part of the page title, where not all disambiguation pages are so. (Or does Wikipedia have some policy that (disambiguation) will always redirect? Why Wikipedia doesn't just have a Disambiguation: space I don't know.) I think in the case of disambiguation pages, the box is warrented.
Another problem is the complexity for the use of this template. Do you expect people to remember, or have to look up every time, the intricacies of a syntax that could require:
{{projectlinks|pedia|species|disambig|pedia|pedia|pedia|page4=fish (food)|page5=fishing|page6=Florida Marlins}}
That's not only difficult to write, it's a bit difficult to read. Compare to the following:
{{sister|disambig|species}}
{{pedia|fish}}
{{pedia|fish (food)}}
{{pedia|fishing}}
{{pedia|Florida Marlins}}
The first even I'm a bit timid to edit. The second is just that much more straight-forward. DAVilla 06:43, 9 June 2007 (UTC)[reply]
Okay, you can now put in any label for the disambiguation just like the others; I hadn't thought of that. You can change any label with "labelx=Y" [1]. Isn't assuming that the page is at "X (disambiguation)" inherent to all such templates? If it's unpredictable, the template can't fix that; the template now duplicates the exact same functionality as {{sister}}. If the disambiguation is somewhere that the template can't predict (#ifexist doesn't work on interwiki links), then you just have to tell it where to look in one of the parameters. That's true for any template.

As for the complexity, I don't quite see how it is any more complex. It looks the same to me. It should be clearer if I clarify the formatting. The long string at fish can be made into: [2]

{{projectlinks
|pedia
|species
|disambig
|label3=disambiguation page
|pedia
|page4=fish (food)
|page5=fishing
|pedia
|pedia
|page6=Florida Marlins}}
This is easier to read, and just as understandable as the other, isn't it? Dmcdevit·t 07:39, 9 June 2007 (UTC)[reply]
We really need some feedback from others to compare your example and mine above it. As for the disambiguation problem, {{sister}} solves this by using disambig to indicate a disambiguation page at (disambiguation), and pedia to indicate a disambiguation page without (disambiguation). If in the latter case it were possible to create redirects on Wikipedia, then there wouldn't be any problem with your template. My template still takes the approach that the boxes are sometimes useful, but only for exact name matches—and for Wikipedia only for disambiguation pages, hence the option to use pedia to mean a disambiguation page. Otherwise the links should be bulleted. DAVilla 11:00, 9 June 2007 (UTC)[reply]
I'm still not sure what you mean by "{{sister}} solves this," {{projectlinks}} does the exact same thing. Use disambig, just like {{sister}}, and then modify it with pageX=Y for any non-"(disambiguation)" page. In fact, {{sister}} currently only has the options of the pagename, or the pagename "(disambiguation)." {{projectlinks}} can handle a disambiguation that exists at any other place. You couldn't have done this. I don't understand the logic that a box makes sense only for disambiguations. If boxes are bad, they are just as bad for any of the links equally. Dmcdevit·t 20:31, 9 June 2007 (UTC)[reply]
Sorry, I misread you earlier to mean that your template could not handle the two cases for disambiguation pages. I don't think having to enter pageX={{PAGENAME}} (disambiguation) is the most elegant solution, but clearly that would cover the bases. Anyway, our styles are going to differ because we're addressing opposite goals here. See Wiktionary:Votes/2007-06/Wikipedia box template. If I agreed with you that all boxes were evil then I wouldn't but pushing a template like {{sister}}. But since I think boxes are useful in certain restricted cases, I have restricted {{sister}} to only allow those cases, the disambiguation pages named w:{{PAGENAME}} and w:{{PAGENAME}} (disambiguation). DAVilla 21:15, 9 June 2007 (UTC)[reply]
Yes, I think consistency, lack of screwing up all the rest of the formatting, and lack of gaudiness, are more important than whatever benefits the box offers. I'd be happy to hear from more than just the two of us, though. :-) Dmcdevit·t 21:24, 9 June 2007 (UTC)[reply]
Amen. DAVilla 21:30, 9 June 2007 (UTC)[reply]
As per your w:Doherty (disambiguation) example, there are no listings of "Dougherty" there, and in fact a disambiguation page for "Dougherty" seems to be entirely missing. There used to be an example at Douglass/Douglas, which had been lumped together, but those are now separated as well. Are there any solid examples out there where the simplistic approach fails? DAVilla 21:30, 9 June 2007 (UTC)[reply]
That probably was a bad example. But Wikipedia is immense, I'm sure there will always be such an exception somewhere. I think we'll want to be able to link alternate spellings and synonyms to their Wikipedia disambiguations, no matter the name. Something like colour, when Wikipedia has a disambiguation at Color, or cease-fire to w:ceasefire (disambiguation). Dmcdevit·t 21:42, 9 June 2007 (UTC)[reply]
Hmm... okay then. I've gone ahead and added that function, and fairly elegantly if I may say so. Have a look at Template talk:sister. DAVilla 04:17, 10 June 2007 (UTC)[reply]

Bot questions

1) I have sometimes been running two instances of SemperBlottoBot at the same time and it doesn't seem to affect the wiki - is this OK (even more instances allowed?)

2) I am now ready to expand its function to add plurals of Italian nouns (program tested) - do I have to go through the vote process before I can let it rip? — This unsigned comment was added by SemperBlotto (talk • contribs).

  1. Yes (but not recommended, due to python inconsistencies I've observed when trying to do so.)
  2. I don't think so; your approval was for "forms of".
--Connel MacKenzie 04:37, 2 June 2007 (UTC)[reply]
A plural of isn't a form of? DAVilla 17:35, 7 June 2007 (UTC)[reply]

Bullets and Numbers

Numbered lists and bulleted lists are displayed with different indentation see volo#Latin for a side by side comparison. Could the stylesheet be edited so that both lists appear more similar, is there any reason for not doing so? Conrad.Irwin 22:27, 2 June 2007 (UTC)[reply]

This is a function of individual browsers and operating systems. Talk to your browser software provider about adjusting it. --EncycloPetey 01:19, 3 June 2007 (UTC)[reply]
No, I have run some tests, and in IE7 and Opera 9, they are both indented differently on wiktionary with the monobook style, yet both render the with the same indentation when the stylesheets are removed. The Nostalgia theme also renders with both indented the same amount. Conrad.Irwin 20:44, 3 June 2007 (UTC)[reply]
Well, there you go then - just use the Nostalgia skin. I suppose it could be added as a WT:PREF, if it really is an issue. --Connel MacKenzie 17:03, 4 June 2007 (UTC)[reply]
Oh, it's a huge issue with the examples/quotations mixture and with one of the proposals I was working on to allow "subdefinitions". But I'd like to see much more radical changes, such as # implementing an invisible table layout in the Mediawiki software, which would allow for control of numbering rather than defaulting to the browser's HTML implmenetation of DL/DD.
Incidentally, I've also wondered why the crazy ugly implementation of tables in the wiki code matches so closely to that of HTML. For instance, why can't we implement tables column-wise rather than row-wise, and have the Mediawiki software do the transposition? DAVilla 17:42, 7 June 2007 (UTC)[reply]
I think it is because the wiki-markup was intended as a shorthand notation for HTML. What syntax would you propose for an auto-transposed table? Do you feel like writing that PHP as a MediaWiki extension? --Connel MacKenzie 19:27, 7 June 2007 (UTC)[reply]
No, I would consider rewriting the entire syntax. The particular problem I raised isn't really an issue on Wiktionary. Thank God we so rarely have to use tables here. But one thing that could be done fairly simply is to separate the style from the form. If you start bold in one cell and close it in another, the wiki interpreter would take care of closing and opening across every cell boundary, as HTML requires. That way the style of an entire head row, for instance, need only be declared once. DAVilla 21:53, 9 June 2007 (UTC)[reply]

Interlingual harvesting?

Could we harvest entries from Wiktionary in other languages (in the way that certain of these harvest our entries)? Not to create entries, perhaps, but maybe to create a project page with a list on of entries in other languages of Wiktionary that ours lacks (along with a link to the source)? Cheers! bd2412 T 03:23, 7 June 2007 (UTC)[reply]

Someone already experimented with doing this against the French Wiktionary (User:Darkdadaah/Diff), specifically looking for any English entries that we lack. The results are rather amusing. --EncycloPetey 15:37, 7 June 2007 (UTC)[reply]
Well that's a pretty amusing approach. Sounds more like a check on French Wiktionnaire there than on the English wiktionnear here.
¿Wasn't there also a French bot that created foreign-language entries on Wiktoinnaire based on French translations of words found on other language projects? for instance, mining Spanish Wiktionario for contributions that French translators had made (which would clearly only apply to Spanish words). DAVilla 17:32, 7 June 2007 (UTC)[reply]
The lists I generated for Wiktionary:Project - Spanish#Red links include all of the Spanish entries in the es.wikt that do not have entries (e.g. Spanish sections) here. Pretty easy to generate for any given language. (Just have to look up the details of how they do language headers, and add that to the table.) Robert Ullmann 15:47, 7 June 2007 (UTC)[reply]
Maybe we could put together a lost of entries that RobotGMwikt would add lots of interwiki links? Diffs for individual languages are great too. Cynewulf 17:45, 7 June 2007 (UTC)[reply]

Template:es-noun-mf

Template:es-noun-mf, when given a parameter for the feminine should assume the headword is the masculine, and display the feminine, along with both plurals in the parentheses. It does this correctly; for example, in abacalero, {{es-noun-mf|f=abacalera}} correctly expands to:

However, the template only works when the masculine form is the page title, as above. The feminine form abacalera should work the exact same way. {{es-noun-mf|m=abacalero}} should produce:

Instead, it expands to:

(where "abacalero" isn't even the correct page title!) Of course, there are words where such a form is appropriate, because the male and female forms are identical (see artista), but the template outputs that with no parameters already ({{es-noun-mf}}). Specifying "m=X" should be enough to tell the template that the page title is feminine, and produce the desired outcome. Okay, sorry for the long explanation, but can someone look at the template and figure out how to make this work? I'm at a loss. Dmcdevit·t 08:11, 7 June 2007 (UTC)[reply]

There is no problem with the template. The problem arises from the fact that you are using the inflection line template on a non-lemma page. These inflection templates should appear only on the lemma page, which for Spanish adjectives is the masculine singular, unless there is no masculine singular. Non-lemma pages should simply have the page name in bold the gender template, and the "definition" will note that it is an inflected form of lemma. --EncycloPetey 15:33, 7 June 2007 (UTC)[reply]
There is no reason not to include such information in the template output, I just need help doing it. "inflected form of" is not a translation, that's an etymology. The translation of abacalera is already given. Dmcdevit·t 01:39, 8 June 2007 (UTC)[reply]
But that is how we handle non-lemma pages. We do the same thing for English plurals, third-person singulars of verbs, and so forth. There is no reason to duplicate definitions across multiple pages, and there are many reasons not to. If you object to this community practice, then you should make a proposal at WT:VOTE. Our practice at this point is to put the definitions/translations only on the lemma page. All inflected forms and other non-lemma pages point to the lemma with an inflectional soft-redirect. --EncycloPetey 16:26, 10 June 2007 (UTC)[reply]

Accented Characters in Special:Search

Would it be possible to add the box for special characters from the edit pages to the Special:Search page. The WT:PREF option only adds it to the sidebar, which while useful, is quite intrusive and requires some knowledge to set up. By adding the box from the edit pages to Special:Search, it would be possible for any user to search using special characters, simply by clicking on the search button. Conrad.Irwin 22:12, 8 June 2007 (UTC)[reply]

Hey, that's a great idea! See also Wiktionary:Votes/2007-06/Expand default namespaces for searches for mostly off-topic discussion of other ways to beef up that page. DAVilla 22:53, 8 June 2007 (UTC)[reply]

Random page

It seems somewhat pointless to have a random page section which can link to words from any language. The only function for a random page capability in Wiktionary would be to learn new words from the language which you speak, or desire to speak, and not from other languages. I think it would be a good idea to have the ability to view random pages from one's desired language only, english, spanish, etc. But as I am browsing for words I don't know, I find that I must first go through many words languages I don't quite care to see.

Would this kind of idea be possible to put in to use?

--68.41.43.166 01:46, 7 June 2007 (UTC)[reply]

Yup. http://tools.wikimedia.de/~cmackenzie/rnd-en-wikt.html
Or http://tools.wikimedia.de/~cmackenzie/rnd-wikt.html (to pick a language other than English.)
--Connel MacKenzie 03:21, 7 June 2007 (UTC)[reply]
To anyone using the old interface: the language parameter changed recently, from the 639-2 code, to the full language name instead. For example, instead of "lang=ru" use "lang=Russian"; instead of "lang=gae" use "lang=Scottish_Gaelic", etc. --Connel MacKenzie 06:04, 7 June 2007 (UTC)[reply]
Would it be possible to change the button on that http://tools.wikimedia.de/~cmackenzie/rnd-wikt.html-page into a link instead so that we who are using firefox may open the random page in a new tab? \Mike 06:26, 7 June 2007 (UTC)[reply]
Perhaps this should move to the grease pit. Anyone object to me replacing the "Random page" link, with a link to this in MediaWiki:Monobook.js, pulling the user's default language from Special:Preferences? Or should I add it as a separate link, and override ALT-X? (Or some combination thereof?) --Connel MacKenzie 06:29, 7 June 2007 (UTC)[reply]
At minimum, another link is a good idea, provided you de-MacKenzie-ize the page. (Sorry for using a circumfix.) But replacing the link would be much nicer, if you'd just be sure to keep the any-random-page utility accessible somewhere, perhaps by selection of "any language" on the drop-down, which would link back to the Special page here, or however that works. DAVilla 15:50, 7 June 2007 (UTC)[reply]
Perhaps this should move to the grease pit. (Note: de- is the addition of a prefix, -ize is the separate addition of a suffix. An apology is only expected for calling that combination a "circumfix" in English, not for using them together!)  :-)   All that aside, I'm not quite sure what you mean, by "de-MacKenzie-ize" it. Are you suggesting we add Hippietrail's "language-aware" extension from http://wiktionarydev.leuksman.com/ and rewrite the Special:Randompage there (if he hasn't already?) Or do you mean I should explore some other magic, rather than trying to do it via toolserver/my server? (BTW, great suggestion, re: 'any language.') --Connel MacKenzie 16:58, 7 June 2007 (UTC)[reply]
Oh, sorry for the apology. De-MacKenzie-ize means it shouldn't read "Spanish is listed first because Hippietrail is the one that tests this for me, and he focuses on them." It's not just that me’s a problem—and ideally the text would be editable—it's also the fact that Spanish is listed first! DAVilla 17:16, 7 June 2007 (UTC)[reply]
Oh, I see. Instead of "Hippitrail is the only one" it should say "Stephen and Hippietrail..."  :-) Spanish does have the next-highest number of definitions entered here, after English...so I guess that comment is a bit misleading. (WT:STATS#Detail.) No, the toolserver page is not part of the Wiki, so there is no way for "anyone" to edit it. If you give me exact wording that should be there, (within reason) I'll be happy to comply. --Connel MacKenzie 08:25, 8 June 2007 (UTC)[reply]
You could add Wiktionary:Random page to your watchlist, and update the wording on the toolserver occasionally. If not, just delete that new page when this topic expires. DAVilla 15:22, 8 June 2007 (UTC)[reply]
Perhaps this should move to the grease pit. OK, I haven't added the "Any language" feature yet; let me make sure that doesn't have any weird problems before making that wording change. I also need to revisit incoming parameters on that PHP. --Connel MacKenzie 19:52, 8 June 2007 (UTC)[reply]
The text is highly subject to change at this point, depending on final implementation. If the any-language feature is difficult to implement from the drop-bar, it's also fine to make it a separate link or button. You should definitely add English to the list, by the way, even if there are other shortcuts to a random English entry. Also, what about a second drop-bar and go button that lists the languages alphabetically, or that instead of the current order? Just throwing ideas out there. DAVilla 23:08, 8 June 2007 (UTC)[reply]

This has been working very well for some months now, but suddenly it doesn’t work at all anymore. Selecting "Random (ru)" in the navbox only gives English words. Having to go to http://tools.wikimedia.de/~cmackenzie/rnd-wikt.html each time is very inconvenient. —Stephen 02:23, 9 June 2007 (UTC)[reply]

Change "ru" to "Russian". --Connel MacKenzie 19:34, 9 June 2007 (UTC)[reply]
There is no "ru" to change, as far as I can see. —Stephen 18:48, 10 June 2007 (UTC)[reply]
Fixed, replied on user talk page. --Connel MacKenzie 06:20, 11 June 2007 (UTC)[reply]

Thanks for the link to the language specific random page. However, I was refering more to the general function of the Random page for everyone that uses wikipedia, not just for my own capability. I'm going to assume that most users are like I and quite unskilled in the area of programming, and unless there were a direct link to a page, such as a language specific random page, they would not be able to find it unless someone else gave them a link to it, just as you did for me. I don't know if this already exists or if its not possible to change or anything but I think having some kind of universal link to specify random page language would be a great idea. Thanks again and tell me your thoughts. --68.41.43.166 04:40, 12 June 2007 (UTC)[reply]

Objection to namespace search vote

There are much better things for developers to be working on...such as having an editable "robots.txt" that can pinpoint what namespace the search engines should be looking at (and which ones they shouldn't. E.g. skip the page WT:RFD.) Furthermore, the search page, as it comes up now, very clearly gives the option of expanding the namespaces searched, right at the end of the search results. If defaults are to be more maleable, I would hope we'd choose for much greater restriction of the initial searches, i.e. entries with ==English==, and not obsolete, etc., being the only results returned by default. (Assuming, of course, that corresponding checkboxes were added for the additional restrictions.) --Connel MacKenzie 08:59, 8 June 2007 (UTC)[reply]

Really, the biggest problems are that you can't get the list of namespaces until after you've searched for something — searching for the empty string pulls up the same, less-than-optimal search form — and that you can't restrict by language. I don't think there's a problem with pulling up "obsolete" words, as they generally direct people immediately to the modern term (if there is one). —RuakhTALK 15:32, 8 June 2007 (UTC)[reply]
From my perspective (concentrating on automated lookups from external sources) having the default give wrong results is worse. I agree it would be nice to have a Search page somewhere clickable that allows one to toggle the checkboxes first. Um, perhaps we can... At any rate, that doesn't change my opposition (but perhaps would change your support?) --Connel MacKenzie 22:35, 8 June 2007 (UTC)[reply]
The obvious place to do this is from the blank search page when no search is entered. I think the implementation of seach is currently overloading that page, but it's pretty straighforward to substitute and make it work as Ruakh suggested. I've even suggested as much on the bugs/features site, but nobody really seems to take the search utility very seriously. Like all opensource software, it lacks that final polish that refines the user's experience. The problem stems from steady contributors such as yourself, who know how to find their way around and are not dumbfounded like users, not taking it seriously either. DAVilla 22:44, 8 June 2007 (UTC)[reply]
I'm sorry, but I don't get WHAT you are talking about. You have the equal ability I do, to learn PHP and offer up some sample code for the developers to look at. (If you write code like I do, they'll quickly rewrite it, once it is clear what is intended.) As for the specific case of search, what are you talking about? You have a bug filed on bugzilla for it? (Number or link, please!) Have you looked at the recent progress being made with http://ls2.wikimedia.org/? That isn't exactly chopped liver. Or is it? And what on EARTH do you mean I don't take newcomers frustrations seriously? (Sorry, but that is waaaaay out in left field, besides being unfounded!) --Connel MacKenzie 23:27, 8 June 2007 (UTC)[reply]
I'm actually already familiar enough with PHP to hate it, but who doesn't? And you're right that I mainly complain when I really should be more involved with bugzilla. In fact I don't keep a list of comments I've made there, so I don't know under which bug the comment was with, though it seemed highly pertinent. It also got a positive response from one of the regulars there and must have just fallen through the cracks.
There is a technicality in that a newcomer, in the sense of a new contributor at least, is not a user. I know you take newcomers seriously, greeting probably the majority. Additionally you take users seriously too, I'm absolutely certain, so that technicality is irrelevant. Anyways, most users are new to the site, and that's the correct way to address the experience. If the developers haven't made the search a high priority, when I said that you don't either, I had specifically meant the search from the user perspective.
The main problem in addressing the user experience is that we're already so familiar with the site—with the jargon, (e.g. "namespace"), layout (e.g. what each namespace is for), and navigation (e.g. how to locate what {{template}} expands to)—that it's difficult to see through the user's eyes. The user is a person who can't be bothered to scroll down the page. The user experience is a sequence of maybe three page clicks. Hundreds of thousands of opinion of this site, of all of our collective effort, derive from no more. By opposing this resolution, think of what you're expecting of the user. Some users are not even going to see the special seach at the bottom of the page. Most who see it will not be bothered to search again. Those who do are not going to know which namespaces to select. And ironically, when the first search comes up empty, half of those who select specific namespaces are going to enter new search terms in the top field and/or click the top Search button, and will be clueless as to why their search failed, if they even know that it did. DAVilla 00:27, 9 June 2007 (UTC)[reply]
Another thing that bureaucrats should be able to do, and I think they might already be, is to specify the default protection for creating/editing/moving entries by namespace. Would it be beneficial for bureaucrats to have the ability to mark entire namespaces as robot excluding? Actually the more pages we exclude the harder it is to search this site externally, so that might be a really bad idea.
[Did you mean that robots should skip WT:RFD or Wiktionary:Requests for deletion? There could probably be some sort of ___META__ command at the top of a page such as that or {{RFD}}, which would then mark not only the page as no-robots but also all redirects to it. But anyway, this is off-topic.]
As far as languages go, we have the capacity right now make searches restrictable by establishing a slew of language namespaces and redirecting from the main namespace or, when there is more than one language, transcluding them. This wouldn't be difficult to control with robots either. The fact that we'd rather wait for a software solution leads me to believe that this is not as high priority as you claim. DAVilla 22:26, 8 June 2007 (UTC)[reply]
Um, no, we don't have that capability now. There's a maximum 127 namespaces we can have, two per language...I don't think that comes close to covering SIL's 6,912 languages. --Connel MacKenzie 23:17, 8 June 2007 (UTC)[reply]
English Wiktionary does not have 6,912 languages. We have fewer than 100 with any sizable content. 127 namespaces is enough to implement Top40 1 for all others. But one thing you're right on is that I'm wasting my breath because, while a language restriction would be nice, that wouldn't even be the right way to do it. It was only a hypothetical for comparison. In truth I applaud Hippietrail's direction and effort. DAVilla 00:44, 9 June 2007 (UTC)[reply]
Besides which, the topic at hand isn't languages, but rather "other unattested." --Connel MacKenzie 23:29, 8 June 2007 (UTC)[reply]
No, the topic at hand is searching by default, at the very least, Appendex, Index, Concordance, Rhymes, and Help, as well as Wikisaurus. If you think Wikisaurus equates to other unattested and this vote equates to searching Wikisaurus for wacky unattested terms, then I can see how you're opposed to it. I for one would have no problem restricting Wikisaurus to attested terms, or with compromises like excluding or deprioritizing Wikisaurus/more pages in the results. DAVilla 01:00, 9 June 2007 (UTC)[reply]
As long as we're going free-association here...
Why not just add a JS button to the page you just linked above, that says [WIDEN SEARCH TO ALL "EXTRA" SECTIONS] which then auto-checks those boxes, and SUBMITs the form again? That way, automated searches from the ether don't get unexpected results, while at the same time making it plain that there may be more?
Continuing the free-association... Much as we do the case-sensitive check, we could probably assume that if they have JS enabled, they are humans coming in off a default browser (not an automated search of any sort) and go ahead and resubmit the search for them.
But such an approach wouldn't harass the developers. --Connel MacKenzie 04:55, 9 June 2007 (UTC)[reply]
It's a bit patchy, but takes the bull by the horns. Not a bad idea at all, and the developers should catch up to us some day. I'm wondering if it would be possible to have the top search button apply the namespace selections as well. That would solve a separate problem that I mentioned above. If so, I've got kind of a crazy idea. If it's possible via JS, match the top and bottom search fields when one of them has changed. That would require simply remembering the old value, and if one field matches the old value but the other does not, update the old field with the new search terms. The result might be a little spooky, so it's not really a necessity.
If I can clarify and make an alteration to your proposal, the [Widen Search] button wouldn't uncheck any boxes, and it would only auto-search if the text field has not been altered. As far as resubmitting for the user, I would say no if it's actually a second submition, as searching consumes a lot of resources. DAVilla 06:10, 9 June 2007 (UTC)[reply]
Erm, auto-submit only if zero search results returned, would be another tweak. Adding a dummy parameter to prevent cycling, was what I was considering. Now, just how urgent is this? --Connel MacKenzie 06:24, 9 June 2007 (UTC)[reply]
No dummy parameter required, just don't resubmit if there were no boxes to check. (Or you could do both, to be safe.) This vote ends July 7. Could you assess the feasibility by then? in which case the petition would be a moot point. By the way, I'm going to disappear soon (yes, finally! I'm finished with my school) until some time in August, which would be a bit more reasonable timeframe for implementing it. DAVilla 07:04, 9 June 2007 (UTC)[reply]

Template:trans-mid

Would someone more technically minded than myself please take a look at this, as all of our translation sections currently have this weird code sitting in the middle of them. Thanks. Atelaes 21:24, 9 June 2007 (UTC)[reply]

I reverted the three trans- templates to the pre-June 9 versions but trans-mid seems to be "locked" and wont revert - I should have left them alone - now 2 templates now reverted to where they were before my interferance. Saltmarsh 06:14, 10 June 2007 (UTC)[reply]
I noticed today that it is broken. Someone has altered "trans-top" and emptied "trans-mid", but clearly that hasn't worked... could someone fix it, please? I've posted a comment to Jon Harald Søby, who made these changes, to sort them out. — Paul G 07:38, 10 June 2007 (UTC)[reply]
If you use navigations popups from WT:PREFS it is easier to pick which revision it is that you mean. Otherwise, you end up reverting all revisions of the last user (who, ironically, was you yourself, in this example.) I've reverted {{trans-mid}} so that at least it matches trans-top. Now let's watch Special:Statistics to see when the job-queue clears... --Connel MacKenzie 07:52, 10 June 2007 (UTC)[reply]

trans-top/trans-mid/trans-bottom column magic implementations

I am very disappointed that the completely brain-dead Wikipedia implementation of "column-count" was the version copied here. The Wikipedia "solution" is to throw errors in Mozilla AND InternetExplorer flavors. Brilliant. Currently, with the AFU version of trans-top in effect, it is impossible to debug JS using the JS console. --Connel MacKenzie 08:04, 10 June 2007 (UTC)[reply]

I've restored the top/mid/bottom versions for now. Without abstracting this into a class, and selecting the behavior, based on "sniffed" browser-type, in Common.js, the solution without "trans-mid" is unworkable. It is simply too sloppy to use the incorrect shit-code from Wikipedia. --Connel MacKenzie 08:13, 10 June 2007 (UTC)[reply]

double-diacritics in enPR

I'm using Firefox 2.0 on Windows XP, Media Center Edition. Is there any font or extension or anything I can install to see the difference between o͞o (two lowercase o's sharing a double macron, which is how enPR claims to represent the sound in "lose", "soon", and "through") and o͝o (two lowercase o's sharing a double breve, which is how enPR claims to represent the sound in "put" and "foot")? (And is there really no better way to represent this distinction? ū vs. û, perhaps?) —RuakhTALK 19:37, 10 June 2007 (UTC)[reply]

Are those characters even in Unicode, somewhere? I seem to recall Hippietrail mentioning that they had somehow been left out. --Connel MacKenzie 06:19, 11 June 2007 (UTC)[reply]
Yes, they're definitely in Unicode; if nothing else, you can tell by the fact that we have them. Specifically, they're … *manipulates bits for a minute* … U 035E COMBINING DOUBLE MACRON and U 035D COMBINING DOUBLE BREVE, respectively. (Now, that's no guarantee that any font has them, or even that any operating system's Unicode support extends to double-diacritic support, but I have to assume that some does.) —RuakhTALK 15:35, 11 June 2007 (UTC)[reply]
For what it's worth, the characters appear fine in my browser. In edit mode, the first ("o͞o") looks like "ōo" but with the macron between the two o's. In view mode, the macron is above and extends across (spans) both o's. Similarly, in edit mode, the second ("o͝o") appears like "ŏo" but with the breve between the two o's. In view mode, the macron is above and extends across (spans) both o's. I'm running IE 7 on Vista with East Asian support. Rod (A. Smith) 16:45, 11 June 2007 (UTC)[reply]
Isn't the first supposed to be a swoop-y thing, not a macron? And isn't the second supposed to be an upside-down swoopy thing? (My browser displays them as macrons and breves, respectively.  :-( At any rate, they each are supposed to be one character, not three. Right? I don't think we should proceed with adding them right now, if unicode itself doesn't have special characters for them. When they do add them, we could end up with quite a nightmare to clean up with numerous formats. Can anyone tell what the characters are, that we are currently using? --Connel MacKenzie 03:59, 13 June 2007 (UTC)[reply]
I don't understand Connel's response, but it is apparently based on a missing post about this topic from Hippietrail. At any rate, as Ruakh points out, they are in Unicode (see [3]) and their Unicode names declare them to be a double combining macron and a double combining breve, i.e. a macron and a breve that is each two characters wide and combines with the neighboring characters. Some browsers and OS's may not yet support combining characters but IE, Vista, and Connel's machine all display them as intended. Rod (A. Smith) 06:48, 13 June 2007 (UTC)[reply]
The following comment is by Ruakh. The fact that it starts by addressing Connel should not be taken to imply that I want people to think Connel wrote it. Connel: We're currently using sequences of three characters: "o" (U 006F LATIN SMALL LETTER O), followed by a double-diacritic, followed by another "o". Rod: I've installed East Asian support, and they still won't display. I guess Vista has improved on XP in this regard. By the way, I don't think they're displaying for Connel, either; I may be misunderstanding, but it sounds to me like he's referring to the "ōo" and "ŏo" in your comment. —RuakhTALK 07:34, 13 June 2007 (UTC)[reply]
Ruakh, my guess is that you may not have a font which includes this character. I'm running firefox on XP, and it displays fine for me (I have taken great pains to acquire the necessary fonts to see just about everything, even characters from the Phaistos Disc). If you're not using firefox, you may want to consider it, as it is generally better with crazy characters than IE. Atelaes 07:42, 13 June 2007 (UTC)[reply]
Thanks, Rod and Atelaes. I am using Firefox, but I guess I don't have any fonts that include these characters; maybe I'll see about downloading one (or seeing if I can make a simplistic font for myself that contains just a few such characters). It's not a huge deal to me, but it seems like we shouldn't be using characters that many users won't have. —RuakhTALK 07:56, 13 June 2007 (UTC)[reply]
Hmmm.....speaking of creating fonts....perhaps Wiktionary should consider writing a Wiktionary font, which could contain every character used in Wiktionary, and would be downloadable from the Main Page. The most extensive font system seems like a natural companion to the most extensive online dictionary. This would be a worthwhile project in its own right, and would make many sections of Wiktionary accessible to users who currently cannot see large parts of our little dictionary. The obvious choice for heading up such a project would be Stephen, if he's interested. Does anyone know if this would be feasible, worthwhile? Atelaes 22:55, 13 June 2007 (UTC)[reply]
If we design a GDFL font, we ought to put it on Meta (and link it on the front page, too, of course) for everybody. First, we ought to see what GDFL fonts are out there already. (Question for lawyers- is the OFL compatible with the GDFL to an extent that we could provide an OFL font for download? I am thinking of Gentium.) — Beobach972 02:14, 14 June 2007 (UTC)[reply]
For what it's worth, I can see the correct display of the double-O-with-macron in the edit window, but not in regular text and not in the Edittools. I'm using Safari on a Mac. --EncycloPetey 17:32, 13 June 2007 (UTC)[reply]

Welsh mutation templates

Unless anyone objects, I will overhaul the templates used to show Welsh initial consonant mutations. Currently there are two designs - contrast {{cy-mut-c}} with {{cy-mut-t}}, which also link to different places on en.wp for explanation. Templates in this naming format exist for all the lower case letters that change (b,c,d,g,ll,m,rh), and duplicate ones exist for b,c,d and p in the format {{welsh mutation b-}}. Neither naming format includes any templates for uppercase (B,C,D,G,Ll,M,Rh) needed for entries like Caerdydd (Cardiff) and Lloegr (England). None of the templates are categorised.

I propose to standardise on the {{cy-mut-c}} design (including the en.wp link target w:Welsh morphology) and naming scheme, creating templates for intital capital letters and redirects from the other naming scheme (including currently missing entries) to them. I also propose to categorise them in category:Welsh mutation templates, but I am not certain whether this meets the naming guidelines for such categories, and where this category should in turn be categorised.

Template documentation will also need to be written, should this go in a noinclude section or on the talk page?

Does anyone object to this? Am I going about this the right or wrong way? Thryduulf 16:17, 12 June 2007 (UTC)[reply]

Documentation is supposed to go on the talk page. My apologies for not speaking Welsh. Now, by "mutations" you mean the Welsh language has yet-another-term for "Conjugations"? Or are they truly "inflections"? Or derived terms or synonyms or alternative spellings? --Connel MacKenzie 04:05, 13 June 2007 (UTC)[reply]
In Welsh some initial consonants can change in up to three ways (soft mutation, nasal mutation or aspirate mutation) depending on what precedes it, and "mutation" is the correct term for this.
For example "stone" is carreg, but "the stone" is y garreg (soft mutation), "my stone" is fy ngharreg (nasal mutation) and "her stone" is ei charreg (aspirate mutation). The same can happen with proper nouns, e.g. "Wales" is Cymru but "to Wales" is i Gymru (soft mutation) and "in Wales" is yng Nghymru (nasal mutation). See w:Welsh morphology for more information. Thryduulf 08:54, 13 June 2007 (UTC)[reply]
Yes, this is a needed step in the right direction. Yes, documentation is usually placed on the template's talk page, with a note on the template page indicating that placement. — Beobach972 19:06, 13 June 2007 (UTC)[reply]

These templates are currently implemented with the syntax, e.g. {{cy-mut-c|arreg}} (for "carreg"), which works to produce carreg for the base, garreg for the soft mutation, etc. In a soft mutation the initial 'g' is omitted from a word (e.g. "gardd" ("garden") becomes "yr ardd" ("the garden")) which works fine with the template in lower case. However if an upper case G is dropped, the following letter is capitalised, e.g. "Gŵyr" (Gower) becomes "i Ŵyr" (to Gower). Is there a way for the template to change the case of the letter, or will the {{cy-mut-G}} template need to have a different syntax, perhaps {{cy-mut-G|ŵyr|Ŵyr}}? Thryduulf 19:49, 13 June 2007 (UTC)[reply]

Well, one approach (perhaps not the best approach) would be to design a template with parameters that required the input of each form... {{cy-mut|carreg|garreg|ngharreg}} for carreg (soft mutation garreg, nasal mutation ngharreg). — Beobach972 20:47, 13 June 2007 (UTC)[reply]
There exists [[{{ucfirst:ŵyr}}]] (which produces Ŵyr); it's a bit limited in application, for various reasons, but it seems like it might be perfect for what you need.. —RuakhTALK 01:43, 14 June 2007 (UTC)[reply]
I'd prefer Beobach972's format, myself (not that I plan on learning Welsh.) It does seem to result in simpler template code, simpler (and more comprehensible) wikitext and also, makes XML database-dump parsing easier. --Connel MacKenzie 04:56, 14 June 2007 (UTC)[reply]

cat-redirecting the categories in Wantedpages

So, I started to use {{catred}} to clear out Special:Wantedpages, recalling that we thought redirecting the nonsense categories called for by the {{nav}} and {{context}} templates was the best solution, but noticed after doing several that several had previously, recently been deleted. Is my recollection faulty; is there any reason not to redirect these categories? — Beobach972 16:33, 13 June 2007 (UTC)[reply]

You might be best off asking the specific editors who deleted those, but if I can guess at their motivations . . . One problem is that {{#ifexist:...}} switches will think the category exists when it really doesn't, and we have a few templates that cause categories to be included if and only if {{#ifexist:...}} thinks they exist. —RuakhTALK 02:58, 14 June 2007 (UTC)[reply]

Gothic

Hello to everyone down here in the basement. Can someone who knows how please add the Gothic alphabet to the Edittools? Ta. Widsith 07:33, 15 June 2007 (UTC)[reply]

Damn! Ruakh beat me too it. Atelaes 08:21, 15 June 2007 (UTC)[reply]
Except that I don't actually know the Gothic alphabet or have a Gothic font, so I had to just stab at it. If one of you could check the results, I'd appreciate it. :-) —RuakhTALK 08:23, 15 June 2007 (UTC)[reply]

Thanks! Looks all there, except er.....on my browser at least it doesn't seem to appear in the list, so I have to get it by selecting Greek (Modern)....and all subsequent character sets are in the wrong place...... Widsith 08:32, 15 June 2007 (UTC)[reply]

Apparently, Ruakh's edit screwed up the whole order of things.....but I can't for the life of me see why. The edit looks completely correct. I suppose this is the point where we sit and wait for one of the computer geniuses to come and save us mortals. Atelaes 08:50, 15 June 2007 (UTC)[reply]
Yeah, that's a problem. You have to edit both MediaWiki:Edittools and MediaWiki:Monobook.js, which I did, but browsers cache the results of MediaWiki:Monobook.js, so that even once you've edited it, browsers can still be using the old version. Really, we need to change how MediaWiki:Monobook.js handles the menu — there's no reason it shouldn't be able to populate it automatically. —RuakhTALK 16:07, 15 June 2007 (UTC)[reply]
Hmmm. I know I've written that JS before...http://bg.wiktionary.org/ perhaps? --Connel MacKenzie 02:33, 20 June 2007 (UTC)[reply]

New experiment: WT:WL

Sysops, please try it out. --Connel MacKenzie 11:57, 15 June 2007 (UTC)[reply]

That is, please watchlist Whitelist. --Connel MacKenzie 05:21, 20 June 2007 (UTC)[reply]

Russian Romanization

Does anyone else here feel that any Russian/Cyrillic words should be also written in the Latin alphabet and/or IPA. Being speakers of english, most of us wont know how to pronounce those russian words. So if anyone else could give their two cents on this, I'd appreciate it.

Bearingbreaker92 18:54, 16 June 2007 (UTC)[reply]

Not as entry names, no. However, we do have a standard of transliterating Russian (and other Cyrillic script languages) in any translation table and on the inflection line. See Wiktionary:Transliteration for details. --EncycloPetey 01:47, 21 June 2007 (UTC)[reply]
Ah thanks, thats what I was looking for. Bearingbreaker92 15:24, 21 June 2007 (UTC)[reply]
Does our policy allow transliterations of Chinese but not any other language? Or if there are others, where is the "official" list of those that are allowed, or is it left to each About:Language page? I'm sorry as I (DAVilla) am not fluent and cannot contribute in any other languages. 203.155.1.251 14:44, 28 June 2007 (UTC)[reply]
I would hope it would be strongly frowned upon, except in cases of languages that are often written the Roman alphabet, or where a specific romanized form has somehow found its way to widespread use (sufficient to meet CFI in its own right). I think the only reason it's allowed for Chinese is because there is no other transparent-to-Westerners way to represent Chinese homophones (I haven't really followed the issue, though; perhaps there's more to it). -- Visviva 15:02, 1 July 2007 (UTC)[reply]
I thought we had decided not to have transliterations of most Chinese words as entries, except for the individual pinyin syllables (since that is how Chinese is transliterated). Cheers! bd2412 T 14:46, 6 July 2007 (UTC)[reply]
We have entries for Mandarin (e.g.) words in Pinyin not because they are romanizations or transliterations, but because Mandarin is routinely written in Pinyin. We don't have entries when it is just a romanization (e.g. of Russian or Greek). If, say, Russian were routinely written in the roman alphabet, we would have entries because the spellings are used. Robert Ullmann 15:13, 6 July 2007 (UTC)[reply]

Distinct info for each meaning, please

I think pronunciation, etymology, translations etc. etc. should come after each _meaning_ of a word like this:

  • Meaning #1 here
  • info of meaning #1 here
  • Meaning #2 here
  • info of meaning #2 here
  • Meaning #3 here
  • info of meaning #3 here

The layout of all entries should be converted to this.

At the moment the info seems to be messed up on some entries. —This unsigned comment was added by P.numminen (talk • contribs) 2007-06-17T17:26:02.

See WT:BP#ELE level 4 header sequence. Rod (A. Smith) 17:48, 17 June 2007 (UTC)[reply]
EC, who was a huge contributor not too long ago, had mentioned (though not actually proposed) breaking down the structure in a way as you mention. If you like, you can use your user space to fully illustrate the concept. 203.155.1.251 14:40, 28 June 2007 (UTC)[reply]

Separate Wiki* units, how complicated

All language versions of Wiktionary, Wikipedia and Wiki* seem to be separate, so that the info contributed on one unit cannot be used on another. Doesn't this just make things more difficult? If you wish to edit entries on other units, you even need to register there, too... —This unsigned comment was added by P.numminen (talk • contribs) 2007-06-17T17:26:02.

Shared resources are kept in the Commons. Bots run around linking up certain types of entries across projects. Yes, each WikiMedia project has its own set of goals and users. Rod (A. Smith) 17:48, 17 June 2007 (UTC)[reply]
There's an urban legend (half joking here) about a universal login, which seems would solve part of your problem. 203.155.1.251 14:31, 28 June 2007 (UTC)[reply]
No, that doesn't instantaneously conjoin the various communities; it just makes it a little faster setting up accounts as you join other sister projects. --Connel MacKenzie 16:31, 28 June 2007 (UTC)[reply]

template:polytonic

When Ancient Greek characters with breathing, accents etc. are used with the {{polytonic}} template, I can see them fine on my work computer. But I can't input them, because they don't display on the MediaWiki Tools thing or whatever it's called (they just show up as boxes), so I don't know which one's which until I stick it in and preview the page. Is there any way of having the Edit Tools display as within templates like that? And does anyone understand what I'm trying to say? Widsith 11:11, 22 June 2007 (UTC)[reply]

I think the required change is to add style="font-family: {{polytonic fonts}};" to <p class="specialbasic" id="Greek (Ancient)"> in MediaWiki:Edittools but I'll let somebody confirm that as the appropriate solution since I cannot test the change myself (as the tool characters display fine in my browser). Rod (A. Smith) 16:32, 22 June 2007 (UTC)[reply]

Doesn't seem to work....perhaps I'm doing it wrong though.. Widsith 08:08, 26 June 2007 (UTC)[reply]

It should be working for you now. —RuakhTALK 16:27, 26 June 2007 (UTC)[reply]

Yes! That's fantastic, thanks! This is going to make my life so much easier.. Widsith 08:13, 27 June 2007 (UTC)[reply]

{{Grek}} uses {{Greek fonts}} (Athena, Gentium, Palatino Linotype, Arial Unicode MS, Lucida Sans Unicode, Lucida Grande, Code2000), while {{polytonic}} uses {{polytonic fonts}} (Palatino Linotype, Athena, GentiumAlt, Gentium, Arial Unicode MS, Tahoma, Lucida Sans Unicode, Lucida Grande, Code2000). Is there any reason not to merge {{polytonic fonts}} into {{Greek fonts}} and to merge {{polytonic}} into {{Grek}}? Rod (A. Smith) 05:52, 8 September 2007 (UTC)[reply]

light

Why don't L6 headings work anymore? --Connel MacKenzie 05:03, 21 June 2007 (UTC)[reply]

Odd, the problem seems to have fixed itself. --Connel MacKenzie 16:48, 21 June 2007 (UTC)[reply]

Board Election Candidates message confilicts with word of the day archive note

The [dismiss] link for the "All community members are invited to give Board Election Candidates" their endorsements" message at the top of the page (I've not spotted where this is being generated, MediaWiki:Sitenotice (where I'd expect it, based on en.wp) is blank) is overlapping with the page top note about previous words of the day, e.g. on bona fide. If it matters I'm running Firefox 2.0.0.4 on Windows XP (due to hardware failure on my linux box) on a 1024 × 768 display. Thryduulf 18:26, 23 June 2007 (UTC)[reply]

On my display, (FF 1.5/WinXP) the {{was wotd}} is slightly above the [dismiss] notification from meta's boardvote notice, with maybe a pixel or two overlap. (I had to turn the sitenotice back on in WT:PREFS to see it, though.) --Connel MacKenzie 16:27, 28 June 2007 (UTC)[reply]
I was also unable to find the site notice. This has been a problem before, so I've just pushed down the WOTD notice by an arbitrary 40 pixels. Looks okay for me both with and without the notice, although it displays above or below the topmost horizontal rule depending. Someone with more technical knowledge might find a better solution. DAVilla 09:53, 1 July 2007 (UTC)[reply]

RSS for WOTD

We've had another inquiry about problems with the RSS feed for Word of the Day. Seems like it's still not working, but users are still desiring it. --EncycloPetey 23:51, 28 June 2007 (UTC)[reply]

I'd appreciate such reminders on my talk page. It has been working partially for quite some time. I'll look into fixing it properly tomorrow. --Connel MacKenzie 17:10, 30 June 2007 (UTC)[reply]

vagaries

I've noticed this morning, that {{vulgar slang}} is now showing the evil parenthesis at the start of the line. I've checked my WT:PREFS and I do indeed still have the item checked, to remove the parenthesis. Did anyone else notice a change recently that would have caused this?

Also, #ifexist doesn't seem to be working right. until he's blue in the face (please leave as a redlink for now, instead of redirecting to until one is blue in the face, so people can see the problem.)

--Connel MacKenzie 17:20, 30 June 2007 (UTC)[reply]

Did my edit to {{context/template}} fix the problem?
Yes it did, thank you. --Connel MacKenzie 03:46, 1 July 2007 (UTC)[reply]
> until he's blue in the face does not exist
> until one is blue in the face exists
Red link does not exist, blue link exists. Seems to be okay. DAVilla 18:35, 30 June 2007 (UTC)[reply]
Um, I mean there is a problem with did you mean as it appears on until he's blue in the face. If they are redlinks, they should not appear. --Connel MacKenzie 03:45, 1 July 2007 (UTC)[reply]
Where exactly is the code for that? It's not present in nor linked from Wiktionary:Project-Newarticletext and I can't find it in the MediaWiki space. DAVilla 09:45, 1 July 2007 (UTC)[reply]
{{didyoumean}} doesn't actually use {{#ifexist}}; instead, to test if a page exists, it will try to transclude it, and then see if the result is the same as an attempt to link to it (MediaWiki converts transclusions to redlinks if the target of the transclusion doesn't exist). This generally works, but apparently it coughs if there's an apostrophe in the page-name? (I really don't see why — {{urlencode:{{:until he's blue in the face}}}} and {{urlencode:[[:until he's blue in the face]]}} are both [[:until he's blue in the face]] — but O.K.) At any rate, it seems like the solution is just to change {{didyoumean}} to use {{#ifexist}}, but before I do that I'd like to make sure there isn't anything I should know … ? —RuakhTALK 14:53, 1 July 2007 (UTC)[reply]
Well, I made the change, and it seems to be working fine now. Let me know if you encounter any problems. —RuakhTALK 15:58, 1 July 2007 (UTC)[reply]
The only reason it wasn't using #ifexist originally was because it didn't work - since whatever it was is fixed now, you absolutely did the right thing, fixing {{didyoumean}} to use it now. THANK YOU. --Connel MacKenzie 19:00, 1 July 2007 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2007/June&oldid=49611350"