Hello, you have come here looking for the meaning of the word Wiktionary talk:Project-Nogomatch. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary talk:Project-Nogomatch, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary talk:Project-Nogomatch in singular and plural. Everything you need to know about the word Wiktionary talk:Project-Nogomatch you have here. The definition of the word Wiktionary talk:Project-Nogomatch will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary talk:Project-Nogomatch, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
Since this is the page displayed before you start editing, we have the whole screen to add links to other research type sites. This might even be a good place to include template:artfl, or any other on-line copy of Webster's 1913.
Just catching up now; I'm not sure how I missed this before. Thanks for the encouragement. "WS" is short for Wiktionary Shortcut, explained at WT:WS. So, WT:BP is a link to the Beer Parlor, WT:ELE is a link to Entry layout explained and WT:CFI is a link to the Criteria for inclusion. --Connel MacKenzie13:36, 12 September 2005 (UTC)Reply
Just a pity it seems one can't get rid of the (unnecessary) associated text field... (there is a minimal width, so writing width=0 doesn't work...) \Mike09:01, 6 February 2006 (UTC)Reply
Brion explained to me why some time ago, but I forget (and can't find that conversatin now...probably on IRC.) I think it had something to do with interwiki redirects. --Connel MacKenzieTC19:20, 9 February 2006 (UTC)Reply
Well, now it looks like I need to add the combinations (plural+3rd person, noun+adj, etc) and get to work on revamping intermediate and advanced to conform to current standards. Horray! \Mike is AMAZING! --Connel MacKenzieTC09:32, 6 February 2006 (UTC)Reply
Nice. However we probably should write our own extension with support for multiple languages and whatever ever else we might need. Perhaps we could use categories to create the form dynamically. It might not be that hard... --Patrik Stridvall16:21, 6 February 2006 (UTC)Reply
I admit, your php skills are far beyond mine. Also, I haven't a clue where to begin with adding an extension. Have you done this before?
I have been a professional programmer for over 10 years with experience with PHP as well as a lot of other languages. PHP is definitely not my favorite language, but I have had clients that insisted on PHP. So yes, I know it pretty well. I have no experience with MediaWiki itself though. --Patrik Stridvall20:24, 6 February 2006 (UTC)Reply
Note also I started the naming convention "Template:new_{language-code}_{POS/form}" to allow for other languages, but I am clueless on how to determine what someone's browser's default language is, in this context. Or perhaps, their default language from user preferences somewhere?
Yes, I noticed. Determining the default language from the user preferences is easy. I already know how. The problem is that MediaWiki:Nogomatch is not shown when I set Swedish as the default language. The default data is shown instead. Not sure why. Of course I only started to look a the source code of MediaWiki yesterday...
After looking more carefully at the source code I now understand why. If you set any other language than the main language (English) as the default language it tries to fetch a subpage. The "nogomatch" page for Swedish is called MediaWiki:Nogomatch/sv for example. --Patrik Stridvall21:04, 6 February 2006 (UTC)Reply
BTW, wouldn't it make sense to use Swedish in that template, as it only should be visible as one uses "Svenska" in the preferences? (And hence makes "all" the interface into Swedish?) \Mike13:41, 15 February 2006 (UTC)Reply
Still, it not so much a matter of skill as it is a matter of time. Doing something advanced takes time and there seems to be some technical limitations on what mere extensions can do so perhaps hacking MediaWiki itself will be nessary to do something really advanced.
Just patching Inputbox to support hidden input fields is very trivial though. I do that kind of things almost every day. The problems lies more on where to send any patches... And of course setting up a test enviroment so I can test it properly so I don't lose credibility with whomever I send it to... I know from experience that even very simple patches that "can't possibly be wrong" needs to be tested. :-) --Patrik Stridvall20:24, 6 February 2006 (UTC)Reply
I think I may need to nominate you on WT:A so you can help with all this. It might be politically benefical if someone else made the nomination and I abstained though. --Connel MacKenzieTC18:25, 6 February 2006 (UTC)Reply
While, I probably would accept a nominatation, I'm not in any hurry. I have a lot of other things that I can do without being an administrator. I don't believe that chasing vandals will be a favorite passtime of mine. :-) Still I guess you need help... --Patrik Stridvall20:24, 6 February 2006 (UTC)Reply
Best regards, de:Melancholie 03:22, 9 February 2006 (UTC)
P.S.: But don't do so if somewhere else the search field is necessary ;-)
I don't think we can hide that untill all the language sub-pages exist. I'm not sure I'd want to remove it, anyway. But thanks for the clever trick. I shall file that one away in my toolbox for future reference. --Connel MacKenzieTC19:12, 9 February 2006 (UTC)Reply
Patrick, are you just explaining that you need time to download the MediaWiki code base and install it before doing any experiments?
Yes. However, now I have done so and I have hacked together a quick patch. If you add "hidden=yes" it shows only the button. It seems to work. Now I just have to cleanup it up and try to find out where to send it. bugzilla.wikimedia.org seems to have a "bug" type called "Enhancements". So unless somebody have any better idea, I will try to submit it there. This will have to wait until Saturday or Sunday though... As to how to have it deployed here I have absolutely no idea... --Patrik Stridvall22:31, 9 February 2006 (UTC)Reply
I keep getting mired in the details of actual words and entries here on Wikt: instead. I don't have any very clever ideas on how to reformat this page now. I think what I've done to MediaWiki:Nogomatch looks messy and unattractive, but is efficient.
Is it worth considering removing general templates: new_en_basic, new_en_intermediate and new_en_advanced? The intermediate and advanced templates seem to cross paths with contested issues (WT:CFI, WT:ELE, WT:BP) representing the approved format from only a short period in time. The part-of-speech new_en_* templates have been maintained much better, so far.
Also, what do people think about adding the two templates: new_en_adj_noun and new_en_pl_third for entries that are 1) both adjectives and nouns and 2) both plural nouns and third person verb forms? The addition of those two would balance the POS table. That would at least partly address the attractiveness issue, right?
I haven't had time to think it through properly. At some point in the future I have plans to try to design something similar for Swedish. The technical issues also make the problem non-trivial. Of course we could always try to design some sort of MediaWiki extension or even modify MediaWiki itself. I certainly have the skill nessary to do it. Time is in much shorter supply though. --Patrik Stridvall22:31, 9 February 2006 (UTC)Reply
Possibly. However, doing it using Javascript would be a serious kludge IMNSHO. The .css hack above is bad enough... Note that .css hack would prevent other pages of using the Inputbox properly and while doing it in Javascript might work around that problem it would be very very ugly. Whether I could do it or not is beside the point since I would refuse to it that way as a matter of principle. --Patrik Stridvall23:29, 9 February 2006 (UTC)Reply
Well, it has grown out of the developers focusing on Wikipedia whilst seemingly ignoring other projects - at least that was the perception at one time. Please don't ever look at User:Connel MacKenzie/monobook.js. :-) There has been a lot done here in the name of expediency. A very great deal of it is kludgy. --Connel MacKenzieTC23:46, 9 February 2006 (UTC)Reply
I understand. I have been guilty of doing things in the name of expendiency MANY times in the past. If that was a crime I would already be serving life. :-) However, when I do things on voluntary basis I prefer to do things the "right way"(TM). Still, your script doesn't look that bad. The text replacements in particular are not wrong to have in Javascript. --Patrik Stridvall10:09, 10 February 2006 (UTC)Reply
It seems to work for me as well. While it is seriously ugly, I don't think it will disturb anything else. Ah well, I guess it will have to do for now. I will try to submit the my "hidden=yes" patch when I have cleaned it up so perhaps we can remove the kludge in the future. --Patrik Stridvall12:18, 10 February 2006 (UTC)Reply
Latest comment: 18 years ago11 comments2 people in discussion
The button labels are not quite correct. As it applies to verbs, "-ing" words are present participles while "-ed" applies to both past and past participle (if regular, as most). It would be a lot clearer to me to just list the endings: "v. + ing", "v. + ed" Davilla23:33, 11 February 2006 (UTC)Reply
So, what is incorrect? That "present" should really be labelled "present participle"? Please remember the target audience here is not you, but rather the random new user. (And I know you do fine entries without the templates.) Do we really want these to be any more cryptic than they already are? --Connel MacKenzieTC23:54, 11 February 2006 (UTC)Reply
You're right, the correct labels would be more confusing. I was thinking that the labels "v. + ing" and "v. + ed" would be more translucent, but I'm starting to wonder if it would be even simpler to drop the part of speech and just use the endings. Apart from the basic noun, verb, and adjective, these are:
-s
The equivalent of "Plural and 3rd person":
===Noun===
<!--applies-if-word-is-a-countable-noun-->
===Verb===
<!--applies-if-word-is-a-regular-verb-->
-es
Nearly identical to the above. This would only be necessary if, for convenience and legibility, the page-name substitution could be carried out before editing takes place.
Otherwise listed as the adverb button. The benefit of a separate page, rather than redirecting to the adjective, is the inclusion of synonyms not derived from adjectives.
In my opinion this reduces the layer of obfuscation in the selection of new-page buttons when there's no match. In fact, it may even be possible to reduce the choice of buttons mechanically depending on the search string, which is why I've listed -ly separate from the other parts of speech. That would be a major benefit to breaking it down this way. The question is if the instuctions above are too confusing. Personally I find it very easy to delete blocks of text. (Deleting little inline chunks here and there is a completely different matter.) Davilla01:56, 12 February 2006 (UTC)Reply
Damn. I finished my edits to Nogomatch before I saw this.
So instead of 12 or 16 boxes, you could then work it down to 8?
How about these then?
Connel version
You can also preload the format from these:
Basic
--All--
Noun
Plural
Verb
Third Person
Participle
Past & PP
Adjective
Adverb
Comparative
Superlative
That way, right up front, advanced users have something to pick (which is a matter of just cutting lines out) yet all the "raw" forms are still there?
or
Davilla version
You can preload from these helpers based on your word's ending:
Basic
-s
-es
-ed
-er
-est
-ing
-ly
Then if needed, the -s and -es could be combined to make room for an --All-- here also. This has the very-slight disadvantage of needing a new set of preload templates to match these concepts.
My description of the "Davilla version" included n., v., and adj., but their inclusion depends on practicality. (The -ly and adv. are too similar to distinguish.) -es and -s should be combined for now. The difference between those templates is just a handful of characters, all of them e's. It's really just a convenience if the technical hurdles are ever achieved, and the design depends on the technical implementation anyways. Davilla05:40, 12 February 2006 (UTC)Reply
If you consider the above (add n., v., adj. and *all*, and combine -s, -es) there's only one more template in your list than mine, and it's a result of combining the plural with third personal. Davilla07:36, 12 February 2006 (UTC)Reply
I can see how that might end up much cleaner. I agree also that yours lends itself better to automatic defaulting of the "correct" one from a drop-down combo box.
Shall we discuss it a little more, or shall I be bold here?
Maybe it's not such a big change. In fact all of the templates already exist (see section below). It's just another way of looking at it. Davilla07:32, 12 February 2006 (UTC)Reply
We could always include both tables for a couple days, to see which ones get used. I suspect yours being more specific and naturally more automated will quickly gain popularity. --Connel MacKenzieTC15:09, 12 February 2006 (UTC)Reply
Missing POS
Latest comment: 18 years ago17 comments2 people in discussion
I have modified some of the templates not because of style preference but because they were missing parts of speech. Please review my definitions, particularly for "-ing":
Gerund form of the verb blog; the action of one who is blogging.
I asked around (especially on IRC) months ago for a long time before proceeding with this stuff.
You have a very POV stance on these things. The only coherent way to deal with the separate situations is to have separate buttons for each situation. Remember, the target audience IS NOT YOU! It is the newcomer who has never made an entry on any wiki ever before.
Most importantly, the raw forms must be raw. Why are you asserting that there are no present participle forms of verbs that have no identically spelled noun? (If you didn't realize you were asserting that, please go back and review the changes you made!)
Hmm... I left a comment saying that the adjective form doesn't apply to transitive verbs, but if you think this is confusing then I have no problems with a minimalist approach. I added it because I've seen Wikipedia entries that cover the case of "a blogging student", but most dictionaries do not list these in the general case. However, the gerund form is well known. "Blogging is a useless activity." "Throwing a ball is fun." That should certainly be included, but I'll slow down as you request and let someone else do it. Davilla01:09, 12 February 2006 (UTC)Reply
Thank you. We have not discussed gerunds on the beer parlour for a long time. I do not have any objection to creating a template:new en noun part. I think that would be a great idea actually. I do have a strong objection to overloading the present participle template, as I think you now may understand.
I'll reorganize the Nogomatch table once more. As much as I want to, I don't think I can do away with the "" template. The intermediate and advanced are problematic however. Our regular contributors don't ever use them, as new words are tracked down from various lists most of the time. Would a new user be overwhelmed by the advanced and intermediate choices? Of course! So it is not wise to continue advertizing theose two buttons so prominently, I think. --Connel MacKenzieTC01:35, 12 February 2006 (UTC)Reply
I agree with your comments on removal. I'm in the same boat as the users you mention who think the advanced template is difficult to use, the reason being that it's so thoroughly commented. Why would an advanced user need so many directions? It should be discarded in its present rendition, but I wonder if it could find a new raison faire in a skeleton form, a more useful version of the Entry Layout page and at the same level of hierarchy in terms of its definitive authority over standards. As to the basic one, it has to remain as a brief tutorial, but there should be more motivation to move away from it. Maybe the choices could be "Tutorial" (presently Basic), "Basic", and "Advanced" (or "Complete"). The new Basic template would replace Intermediate and provide a practical backbone to work off of. Practical means that it is annotated only where necessary. A single part of speech will suffice because it can be copied and pasted when needed. I'll try to start something at, say, template:new_en_useful. Davilla02:24, 12 February 2006 (UTC)Reply
If it makes any sense whatsoever, upon implementation the function of "Basic" and "Complete" have been rolled into the latter. Davilla16:19, 12 February 2006 (UTC)Reply
The "users" that I mention are not talkative; I have had to delete a few entries where the only contents were the template. I haven't seen anyone properly use them. OTOH, if someone did use it properly, I would have no way of knowing for sure. But so far it doesn't look like that has been the case. Wiktionary entries develop over time. I cannot think of any entry that has multiple etymologies, that was entered with more than one etymology at the outset.
The benefit of providing separate skeletons for ===Adjective===, ===Noun===, and ===Verb=== are to give someone like you or me an opportunity to select the right form for the inflection line and delete the rest. With that said, it very strongly supports using your "endings" selection criteria...if we know beforehand what the ending is, then lots of pieces fall into place. All of the inflection lines no longer have a choice of items, but instead a single (correct) line. So now, how do we make this work? --Connel MacKenzieTC04:24, 12 February 2006 (UTC)Reply
This is the verion I tried to make of template:new_en_compar before it was understandably rolled back. See the confusing talk page, or better yet don't. "
Um, I was hoping that the old templates would be restored to their last state, and the new templates would have all the new formatting, so that we don't get our wires crossed any more. --Connel MacKenzieTC09:59, 12 February 2006 (UTC)Reply
Umm, thanks. Hope one of these words out. At some point in the near future I'll hardly be active anymore though.
If you want to keep the old templates that's no problem, just copy them and update the styling. I know the style can be a fairly contentious issue around here, and I'd just as well let template:new_en_useful pan out. That template is kind of a monster though, whereas the others are pretty basic, so maybe you had something else in mind? Davilla16:10, 12 February 2006 (UTC)Reply
I was certainly thinking bare-bonez, it is true. But having seen your useful template, I see that I can finally figure out how to do the new quotations style (that style in particular refuses to stick in my brain.) The major change I would consider suggesting at this point, would be to stick to English. That is, each language is intended to have its own set of "new_xx_*" templates. Adding a language is opening a can-o-worms. --Connel MacKenzieTC16:27, 12 February 2006 (UTC)Reply
Boy this sure garnered a lot of attention! All kidding aside, I am concerned that such an ugly version is still sitting there right now. I'll add your "useful" template now, and comment out the bottom row to try to make it look a little better. I'm tempted to put {{Wiktionary:Project-Nogomatch}} as the entire contents of MediaWiki:Nogomatch so that you can edit it at your leisure, just like the templates themselves. I will also start taking your other comined template versions and move them into the names I provided above (unless you have objections to those names.) --Connel MacKenzieTC03:50, 13 February 2006 (UTC)Reply
What do you mean by "attention"? It's just the two of us.
I don't really care about the names. I think only a handful of people ever really look them up by name. But if you're concerned about it, --all-- looks funny to me. Why not just template:new en?
Latest comment: 18 years ago10 comments2 people in discussion
Looking at WT:BP, I see the new simple English simple:MediaWiki:Talkpagetext which clicks in place one more piece of the puzzle for me. That would definitely be the place to put a row of small buttons to "reload this new page" using one of your templates. That is the row of buttons would be one button for each. Depending on the size of buttons we find/make, we could probably fit about 50 different preload templates if we could dream up that many variations.
The challenge then becomes on how to follow the KISS principle. There certainly should be a links to WT:ELE, WT:CFI, Help:Contents, etc. But for the "magic button row" I think we'd be best starting out with just your templates. Maybe also a "Proper noun" template, an "{{abbreviation}}" template, an "{{initialism}}" template and an {{acronym}}" template.
For button design, we won't be able to integrate any logos; these need to stay small. Normal blue/gray buttons, (perhaps gradient like the top of this edit box I'm typing in now) with black text: "N", "-s", "-es", "-ed", "-er", "-ing", "-est", "-ly", "PN", "{Ab}", "{I}", "{a}", "ALL".
Those are the combinations you suggested in the first place, plus the few that were missed along the way.
With a bit of javascript, we can determine if the edit box has been typed in yet. If so, then clicking any of those buttons would pop up an alert (w/ a cancel button) before reloading the page using the newly selected preload template. I know the Russian Wikipedia had some similar code, so it shouldn't be hard at all. (See w:WP:TOOLS.)
You know anyone good at making buttons? Or should I try goofing around in the Gimp?
With a tiny bit more javascript, the variable {{PAGENAME}} can be inspected, and special cases like "-y" endings, "-e" endings and "-ch" and "-sh" endings can be detected, then adapted for. Little XMLish placeholders within the templates could tell the javascript where to do replacements. Et voilà! Complete regular English inflections can be done for people at the click of a button, as per Uncle G's templates. --Connel MacKenzieTC08:32, 17 February 2006 (UTC)Reply
Simplicity is good. Leave the inflections to the Javascript, eliminating the need for those buttons. For the rest, I would take a personal survey of what people are using to create and augment pages. There are probably a lot of "templates" out there stored on hard drives and not the server. You may discover that people have different interests, certain groups of words they target. If I were a translator I would probably start with the definitions as given on the page being translated. But you can't be sure what you'll discover until you ask. Davilla07:43, 18 February 2006 (UTC)Reply
Erm, that's why I'm talking about these changes before doing them. I am very well aware that people have different interests. But the only thing preload templates can be used for is populating a new page. Translators will not encounter these. Regular contributors tend to work off lists...they will not see MW:Nogomatch. People not using "Monobook" skin will not see these. So these features I'm proposing are directed almost exclusively to the brand new Wiktionary user. I fail to see how the Javascript can correctly accomplish the inflections without the buttons. --Connel MacKenzieTC08:12, 18 February 2006 (UTC)Reply
Sorry, I thought you meant you were putting the buttons on the edit page itself. I take it you still want to use a button for the suffixes, which is probably better than assuming what the user wants. I meant that Javascript would reduce the number of those buttons down, potentially to one suffix at most. And by survey I didn't mean talk about changes here, I meant actually ask people, via individual messages. I'd be willing to volunteer if you like. Davilla09:10, 18 February 2006 (UTC)Reply
That would be great (you doing a survey.) As far as buttons, um, well, I was talking about both. I was assuming that the buttons would hide themselves (or at least gray out) if the edit was not for a new page. I guess that would cover more than just new users, but still exclude translators (by and large.) --Connel MacKenzieTC20:40, 18 February 2006 (UTC)Reply
I've recently discovered how to add buttons to the row of buttons above the edit box. In my monobook.js, I add the #R button currently. I'll have to glom a blank button from somewhere, then make these buttons. Then I can just add the row of buttons in my monobook.js to further test. These buttons will only be active when editing a new page, so I still have to figure out how to tell if the "Article" link is red, but that shouldn't be too hard.
It may be easier on you and more versitile overall to make the buttons active when the edit box contents is blank. Davilla17:34, 9 April 2006 (UTC)Reply
Clicking on any of these buttons will simply reload the current edit page with "&preload=Template%3Anew_en_{whatever}". Once this works, we can just scrap the overly verbose MediaWiki:Nogomatch approach. IIRC, on small screen sizes, it will just auto-flow the buttons onto a second or third row...so we can have as many varieties as we can dream up.
I'd like opinions on syntax for what should go inside the preload templates. To accomplish "PAGENAME"-ing (minus the "ing" ending) I'll have to use Javascript again. But I think the preload template syntax should not be {{PAGENAME}}-ing as that might be ambiguous, and conflicts with current wikisyntax.
Latest comment: 18 years ago3 comments2 people in discussion
I have done a page with English and Swedish subpages for listing the available templates. The reason I called them entry templates and not something using "nogomatch" in the name is that I see a future there they can be parameterized and used by other things like bots or MediaWiki extensions. --Patrik Stridvall22:29, 19 February 2006 (UTC)Reply
Very impressive! Nicely done. Question though: What is the "uses" column is for? Any entry that "uses" these templates cannot appear on whatlinkshere as the template is not included, is was preloaded (and therefore is a part of that entry.) The column being there makes it look like they are not used (when in fact they are, and have been quite heavily at certain times.) --Connel MacKenzieTC02:16, 20 February 2006 (UTC)Reply
Thanks. Well, while I agree that the "uses" column is not that useful for the the reason given above, it not entirely useless either talk pages and other kinds of pages might and does link to them. Still, since it might cause some confusion we probably should add some sort of comment explaining that... --Patrik Stridvall17:25, 20 February 2006 (UTC)Reply
MediaWiki:Searchdisabled
Latest comment: 18 years ago10 comments3 people in discussion
During very heavy load times, searching is sometimes disabled. When this happens, the alternate page is used. Is there any reason that should not also use the identical layout? The options presented to the user (by this) shouldn't be any different, whether there are search results listed below or not, right? --Connel MacKenzieTC02:18, 20 February 2006 (UTC)Reply
Do you arrive at Searchdisabled by pressing Go or either Search or Go during heavy volume? I would presume either button. Nogomatch applies to the first, not to all searches, so it wouldn't be exactly the same. I don't think there's much conflict though. By changing Searchdisabled to match Nogomatch, you're adding entry templates to the case when users press Search during heavy volume. Better if it can be avoided, but not a big problem IMO.
By the way, is it possible to turn off some searches, particularly those from Go, and not all searches?
Also, considering how valuable searches are in terms of computation time, wouldn't it be better to place the entry templates at the bottom? Davilla03:29, 20 February 2006 (UTC)Reply
I don't know.
I don't know.
When searches are disabled, there are no search results, right?
These are good questions. Anyone reading this know? Searching hasn't been disabled for a while, so I can't check. And when it has been disabled, it has been disabled for weeks at a time.
If that's the case, then provided there's no match, Nogomatch is always displayed on Go, even if search is disabled, so there's no need to duplicate the entry templates on the Searchdisabled page. The semi-disabled function I suggested above would output Nogomatch and then stop; for a search, the user would have to do one explicitly.
It seems to be trivial to implement. However, nobody have even commented on the patch I submitted some time ago concerning the inputbox extension. So I guess it will have be the hard way. Subscribe to the relevant mailing lists get to know some people then possible get CVS access. Don't hold your breath though. --Patrik Stridvall21:28, 21 February 2006 (UTC)Reply
I don't understand what you mean. If there are search results they are displayed regardless of whether you did "Go" or "Search" (providing you don't get a near match or searching is disabled of course). --Patrik Stridvall21:28, 21 February 2006 (UTC)Reply
The last time searching was disabled, I recall the text from Nogomatch disappearing. Searching has not been disabled for a while now, but when it is, it is disabled for weeks at a time. Maybe that bug has been fixed. --Connel MacKenzieTC21:56, 21 February 2006 (UTC)Reply
Perhaps. However, the current CVS version always displays "Nogomatch". I have both read the source code and tested disabling search with my own installation. --Patrik Stridvall22:24, 21 February 2006 (UTC)Reply
Latest comment: 18 years ago2 comments2 people in discussion
Why was the "dictionary.com" thing removed? The discussion about it in the past concluded that that was the worst offender (by far) and therefore should be emphasized by name. --Connel MacKenzieTC06:30, 18 June 2006 (UTC)Reply
Latest comment: 18 years ago4 comments2 people in discussion
I posted this previously at the Wiktionary:Grease_pit#Search_special_page_correction, but unfortunately it was mostly ignored by those there. On the page MediaWiki:Noexactmatch, there is a phrase ("Expert blank template") and a dependent clause ("When she crosses"), both with periods after them that should not be there. Considering that this is probably a much-frequented page, this grammatical error should be corrected. 24.5.197.12107:53, 8 July 2006 (UTC)Reply
I hope you don't mean to say that no one here will correct it either. I would be most happy to correct it myself, but it is a locked page that only certain users can edit. I feel it would be untoward to let its locked status prevent changes such as the one I suggest, that is, a minor grammatical correction. 24.5.197.12118:09, 8 July 2006 (UTC)Reply
That's why there's an undelete. And judging from the little I know of mediawiki development they tend to change to wholly new identifiers rather than to previously deprecated ones. --Bequw → τ19:00, 22 February 2010 (UTC)Reply
Generally, the burden of proof lies with keeping something (except of course in the User:). Obsolete files create confusion over what is valid as well as impede editors in finding and using the valid/useful files. --Bequw → τ20:25, 27 February 2010 (UTC)Reply
Well these are mostly protected pages and when they are edited (extremely rarely) it is only by highly experienced users (admins). If there is actually some evidence of end users being affected by deprecated Mediawiki messages I would love to see it, otherwise this is just a waste of time and effort. - DaveRoss00:16, 3 March 2010 (UTC)Reply
Admins aren't necessarily always highly experienced in all aspects of Wiktionary. And no amount of experience will let you know when a message is obsolete, if all of that experience predates the obsolescence. If I see a bit of text in the interface, and I search the MediaWiki namespace for that bit of text, it's very unhelpful and confusing if I end up at an interface page that no longer does anything. I consider it a service if Bequw (or anyone else) is willing to go delete all these obsolete pages; that is the very best way to document that they're obsolete. —RuakhTALK02:58, 3 March 2010 (UTC)Reply
Well, it (or this discussion at least) helped me find what to update in another Wiki that had be broken since the change. I can't see it's doing that much damage being around. Most users won't even know it's there so deletion seems a little obsessive. ☸ Moilleadóir☎16:54, 16 May 2010 (UTC)Reply