Do we have, or can someone develop, a tool that word search other language Wiktionaries for pages with a particular name? I can see this as particularly helpful in situations where an unfamiliar word has been requested or discovered without the context of language. Such a tool would allow us to quickly search the other Wiktionaries for a match. --EncycloPetey05:02, 2 December 2009 (UTC)[reply]
Interesting. Interwicket has a complete global index. If the entry is there for more than a couple of hours, and there is a match on the others, the entry will pick up iwikis, then you can follow them. So a simple way is to create a stub, and wait a bit. I don't have any simple way of making the DB available now though. (Could be done in various ways.) Robert Ullmann12:57, 13 December 2009 (UTC)[reply]
When I'm logged in with the Vector skin (Monobook is fine), headings that are the word "head" float in the upper left of the page (like WT:RFV#head and this simple Sandbox page). It happens in IE 8, Firefox 3.5, and Chrome and even after I comment out my entire User CSS and JS file. Anyone know what could cause this? Something in the master skin files? --Bequw → ¢ • τ20:24, 8 December 2009 (UTC)[reply]
Definitely known and reported already. Vector skin has a CSS instruction which places all objects with id="head" at the top left corner. Headings have a id parameter which is their content, so having a heading called "head" causes a conflict. -- Prince Kassad21:29, 8 December 2009 (UTC)[reply]
Knowing how complicated {{context}} is, what happens when there's a context label to replace like {{Star Wars}} and I replace it with {{context|Star Wars}} and delete the template? The template is not orphaned. Seems like quite a unique case, as I've never seen another template that works like this. I should look at the source code, although I suspect I won't understand it. Mglovesfun (talk) 08:42, 9 December 2009 (UTC)[reply]
It will change to read "Star Wars" because that's what you typed as opposed to "Star Wars" because that was the label on the context template (i.e. it will do nothing). Conrad.Irwin15:00, 9 December 2009 (UTC)[reply]
I fixed comics/comic books by the number of transclusions. For the steroids set, yes that's an awful mess, and I know just about nothing about biochemistry. Good luck guys! Mglovesfun (talk) 23:24, 13 December 2009 (UTC)[reply]
Use of images on the English Wiktionary is not picked up by Wikimedia Commons.
Those tools you were linked to on the deletion discussion seem to work, and anyway, when they delete a file from commons, it gets deleted from here by User:CommonsDelinker, in the current debate they just want to replace it by File:U+2192.svg which looks the same, and the CommonsDelinker bot will replace it on wikt like here, so there's no problem. Conrad.Irwin13:13, 13 December 2009 (UTC)[reply]
Just a tiny niggle: if you delete a page and then try to view one of its "diffs" (from another earlier browser tab, for example), it comes up with "Sorry: the page title you requested is not supported by our software." That doesn't seem like the appropriate error message. Equinox◑06:23, 13 December 2009 (UTC)[reply]
Meant to post this ages ago; there is a way used on fr:Modèle:catégorie redirigée to have the page sub-categorize categories that are not empty, or are redirects to a page that does not yet exist. Seems like a good idea. Also, do we have any policy over which of these categories to keep, or not? On fr.wikt there are something like 600 of these, but we have about 60. I tend to think it's worth keeping the ones that are not misnamed, such as alternative names for languages (Old Occitan/Old Provençal) but should be deleted when it's just a mistake. Mglovesfun (talk) 23:18, 13 December 2009 (UTC)[reply]
Some browsers need to have the font enforced because they fail to select it by default (IE and Opera instantly come to my mind). If the font is installed correctly it should show up in BabelMap. -- Prince Kassad21:04, 14 December 2009 (UTC)[reply]
Was thinking that one main way I could help the project is to complete, where I can, Old French words used in etymologies. But how to find them? Anything using {{term||lang=fro}} would be a good start. Btw I only enter words I've seen in use, I don't just "guess" as the risk/reward is too low. Mglovesfun (talk) 11:05, 15 December 2009 (UTC)[reply]
I suggest entering the string {{term||lang=fro}} in search. It seems to give some good results. Someone with access to the database could probably do a lookup which would be more convenient, but until then... -- Prince Kassad11:43, 15 December 2009 (UTC)[reply]
Some Etymologies contain the words "Old French" without the template. They offer the potential for multiple improvements. Scanning a simple search for "Old French" for the pattern that yields what you want can be fairly rapid.
Also Hippietrail has been doing useful dump SQL searches on headwords, headings and categories. I don't know what the next step in extending that is, but you might ask him once more instantly available means stop yielding results. Perhaps HT, RU, Conrad or someone else can create lists of redlinked term words by lang (including those with no lang parameter for further cleanup).
Latin, ancient Greek, Middle English, Anglo-Norman, and the various older Germanic languages are all of great importance for English. In some cases the glosses don't match the full range of meanings of the word in these older languages. DCDuringTALK13:04, 15 December 2009 (UTC)[reply]
Me neither. All I know is that some references make the distinction and thence we inherit it. Also some entries have "Old North French" (lang=?), "Middle French" (lang=frm), and "Frankish" (lang=?). Resolving Old North French into fro, xno, or whatever would be useful if you can figure that out at some point. Similar with Frankish. They may not be "resolvable", but perhaps could be supplemented by additional etymology using languages with ISO codes. DCDuringTALK13:20, 15 December 2009 (UTC)[reply]
I don't know what Old Northern French is, but Middle French is a separate language (frm) and Frankish (frk) even more so as it's a Germanic language brought in by the tribes invading France during Roman rule. I'm not actually sure it's well enough attested to have entries here, a bit like Transalpine/Cisalpine Gaulish, which have ISO codes but aren't really recorded in writing. Mglovesfun (talk) 13:55, 15 December 2009 (UTC)[reply]
This failed RFD and has been recreated. However using lang=vro in {{wikipedia}} doesn't take you to the Võro Wikipedia, it takes you to nothing, because Wikipedia does not use the correct ISO 639 code. So is this a keeper after all? Mglovesfun (talk) 17:26, 15 December 2009 (UTC)[reply]
Could the assisted translation adding system prevent the addition of English translations of English words. Seems to be used by vandals rather than accidentally. SemperBlotto08:15, 18 December 2009 (UTC)[reply]
I've noted perhaps a half a dozen of these starting about a month ago while addressing rfc-trans table tags. I don't know whether it should be fixed. If a vandal claims the translation is Yoruba, how would I know? It is much easier for the bot to detect and for me to correct vandalistic translations if the language is English. I don't routinely put a ttbc tag on something I make conform to trans-table standards. Do we need a procedure for marking and checking anon-added translations (either all or just those to empty language section)? DCDuringTALK12:03, 18 December 2009 (UTC)[reply]
It can be fixed easily, and probably should be. I also have thought about a way of making it easier to check added translations. Either the translation thing could append the word to a per-language list somewhere (ideally with rollback and patrol links), that some dedicated person could then sift through; or it could get added to (yet-another) request category. Neither of these solutions seem particularly amazing, though maybe if we allow each language to "opt-in" to the system only if we know we have someone who will actually bother reviewing them, it wouldn't be so bad. Conrad.Irwin14:33, 18 December 2009 (UTC)[reply]
From my (en-N, other languages 0.5) perspective, the language-list idea seems good, even if there is a big backlog. Checking and correcting translations might be a good starter/restarter task for new/occasional contributors with a specific language skill. But opt-in seems like a good way to start in any event. Should they just go into ttbc if added by anon and link to absent language section? DCDuringTALK15:28, 18 December 2009 (UTC)[reply]
The problem with putting them into ttbc is that someone needs to edit every entry to remove them, the idea behind an explicit list was so that all edits by X could be easily removed from the list in one go; a big problem with such a page is that it would double the size of recent changes, but I suppose it could be collated on the toolserver as it would not be publishing any information that isn't already available (providing it was limited to anonymous users). Conrad.Irwin15:56, 18 December 2009 (UTC)[reply]
But Semper's point is about people adding a translation line of "* English: [[garbagetext]]". These can and should be vetted by bot, since we never have English translation listings in English translation tables. --EncycloPetey 05:01, 19 December 2009 (UTC
The volume of "English" that I see at rfc-trans which is what the bot catches is low. At least some of it seems like a kind of typing error. It is sometimes a recoverable translation with the wrong language. If the linked word is blue, I follow the link, confirm that the translation is right and insert the language. I find it simple to do in the course of correcting the other things that impede the operation of assisted translations. There are perhaps as many as half a dozen items a day, usually fewer. No language skills are required, except for the refractory cases, which look to remain on the list for months if not years.
If the bot finds problems of this "English" type, is that not evidence of likely problems in other languages? Perhaps this warrants a test of some kind. How many translations are added by anons in each of a sample of languages over a month? How many are vandalism? How many are erroneous (script, language, other)? How many can bear improvement? Is it usually a single contributor? If the process as originally implemented is ineffective or inefficient, it could be improved or abandoned based on that information. DCDuringTALK10:52, 19 December 2009 (UTC)[reply]
I have stopped the addition of English through the assisted tool, which should lead to fewer mistakes when a user put the wrong language code in (assuming they did it through the tool). It should not be that hard to set up a system that extracts most assisted edits from recent changes (except the ones that the edit summary disappears on), it'd be slightly harder to work out what % of those get undone or rolled-back, or that have transliterations etc., though it should be doable. Conrad.Irwin12:53, 19 December 2009 (UTC)[reply]
When there's a right-hand side element next to these tables, the latter type stay in place vertically and just span the horizontal space available whereas the former type jump below the right-hand side elements (creating a gap in the page) so that they can actually span 100% of the content area. As this gap creates horrible layout, I'd like to fix this by wrapping the former type in a <div> tags (probably <div style="width:auto;margin:0px;overflow:auto;"> in the "top"s and </div> in the "bottom"s). This would create the following side-effects:
People who don't realize that {{bottom}} != "|}" would use the template to close a hand-inputted wikitable and cause a spurious </div>. While technically invalid, it doesn't really cause any rendering problems that I know about. I scanned a en.wikt dump and found that this only happened two times currently.
People often erroneously close {{trans-top}} with {{bottom}}. The way things currently are, this causes the rest of the page to be hidden (because there's two missing <div> tags), an easily overlooked error. With the proposed change, the rest of the page would be visible, but styled like the translation table (there'd only be one missing <div> tag). This would be an obvious error and more likely to be fixed immediately rather than waiting for someone to scan for mismatched templates. At last scan, I fixed about a 100 of these errors, so it's much more common than #1.
I think #1 is so minor as not to worry about, and #2 is an ancillary benefit to the proposed change. Does this sound like a feasible and beneficial change? --Bequw → ¢ • τ01:10, 19 December 2009 (UTC)[reply]
The layout errors cause by RHS elements' interaction with the "plain" table templates would be completely fixed by the proposed addition of the div tag. As for errors caused by editors mismatching the template, I scan the dumps every once in a while and fix them. --Bequw → ¢ • τ06:37, 19 December 2009 (UTC)[reply]
What right-hand elements (other than images) are a problem with the tables? Most such items are misplaced in the entry, in my experience. --EncycloPetey04:58, 19 December 2009 (UTC)[reply]
It happens frequently with right-hand side ToCs. That's how I browse so I see it a lot. It's usually when there's a plain top-style table in the upper part of a long page. Because of frequent layout problems I changed {{mul-numberchart}} (which originally used {{top3}}) to use just a plain table. It would look better using a div-wrapped {{top3}}. --Bequw → ¢ • τ06:37, 19 December 2009 (UTC)[reply]
If an entry requires a ToC, RHS ToC improves the value of any language section that appears at the top of the entry by enabling context, especially definitions, to appear on the initial screen a user sees. Were it possible for the ToC to be rhs by default (with opt-out for registered users), we could enhance the value of Wiktionary relative to the other choices that users have. DCDuringTALK11:01, 19 December 2009 (UTC)[reply]
I thought about this. It would make things cleaner. We aren't worried about the extra bits sent with the second div tags are we? --Bequw → ¢ • τ20:59, 19 December 2009 (UTC)[reply]
Is there a template something along these lines? Something similar to {{also|来|徠}} to go at the top of an entry? I think it would be useful for Chinese words which can be switched around, of which there are many (蜜蜂 & 蜂蜜, 合适 & 适合, 现实 & 实现, 来自 & 自来, etc). These are a common source of confusion for many Chinese learners. Tooironic 04:53, 19 December 2009 (UTC) (P.S. And no, I don't think the "see also" template is explicit enough to serve this purpose. Tooironic04:55, 19 December 2009 (UTC))[reply]
There isn't a template, and those ought not to appear at the tops of pages. When we do identify words often confused, we tend to do it either in a "See also" section at the end (without comment, which isn't particularly helpful), or in a "Usage notes" section to point out the confusion. There are lots of reasons that two words can be confused, and it isn't just the result of character reversal. --EncycloPetey04:57, 19 December 2009 (UTC)[reply]
There's also a very bizarre category loop that needs fixing, involving a redirect that isn't empty. But yes, we have fr:Catégorie:Verbes transitifs en anglais in French, but almost any verb can be used transitively and intransitively. Some can't, I grant you, but unfortunately categories become of very little use when they are very small or very large. But I see no reason to delete them (or not create them). Mglovesfun (talk) 22:45, 23 December 2009 (UTC)[reply]
The more interesting categories would be "ambitransitive" or others for verbs that can take clausal or phrasal complements of various types. I don't think we've done much of that work yet, putting us far behind the Longmans dictionaries, which do the best job I've noticed,, showing 12 types of verb complement classes at the sense level in my edition. DCDuringTALK * Holiday Greetings! 00:17, 24 December 2009 (UTC)[reply]
Some people suggested the addition of categories such as Category:English idioms and Category:English phrases to {{poscatboiler}}. Instead, I'm finishing (on my PC, not at Wiktionary yet) a new similar template to organize these possibilities, among others. Supported categories are: abbreviations, acronyms, contractions, initialisms, phrases, phrasebook, idioms, proverbs, alternative spellings, misspellings and obsolete spellings. --Daniel.01:20, 24 December 2009 (UTC)[reply]
WT:AWB states that the option "Unicodify entire article" is probably a bad idea. While unicodification is generally a good idea, as it allows for searching, it would mess up instances where we use character references to display a non NFC Unicode character (which we talked about above). Is this the only reason it's discouraged? If so, then this is so rare that we could just make a template like {{HTML char|hex=...}} (or something better named) that displays the reference (allowing decimal, hex, and entities) but that wouldn't be auto-unicodified by AWB. --Bequw → ¢ • τ09:30, 25 December 2009 (UTC)[reply]
Is there documentation of what exactly unicodification does? Does it translate all character and entity references? Because we sometimes escape wikisyntax metacharacters that way; is the unicodification smart enough not to unescape those, or at least to wrap them in <nowiki> tags? —RuakhTALK01:03, 27 December 2009 (UTC)[reply]
After some testing, AWB doesn't automatically unicodify character references for { } [ ] | nor any inside templates. So one can still do things like [http://w.tf Re: [ADMIN] and more] to include brackets in the text of a URL link w/o fearing AWB will destroy it. I've encoded non NFC-characters using {{HTML char}} so they will be AWB safe too. I think we fine to discourage the general use of character references and allow AWB to . --Bequw → ¢ • τ07:24, 31 December 2009 (UTC)[reply]
Interesting to set all the red linked rhymes entries. Couldn't a bot such as Conrad.bot create these using Special:WhatLinksHere? Not only would it avoid all the red links, but anything tagged with the wrong rhyme would be quite visible in such a list. Mglovesfun (talk) 17:53, 25 December 2009 (UTC)[reply]
The Rhymes pages require knowing the language of the entry and that the coding for the link was correctly put in. There are only two or three people here that know the coding system for Rhymes well enough to judge that, and in my case I've usually created the page myself already when there was a valid link. there are experienced editors here whom I have seen add an incorrect Rhymes link because they didn't know our conventions for parenthetical characters, UK weighting, and stress considerations. I don't think a bot could successfully create the entries. A bot also would not be able to sort items into sections by number of syllables, since the syllable breaks aren't always indicated, and aren't always correct. However, it might be worth having a bot generate some sort of list for inspection. --EncycloPetey16:25, 26 December 2009 (UTC)[reply]
Could there be a way to 'watchlist' a user's contributions?
I know one is able to watch a user's talk and userpage, but could there be a way to have all of that user's contributions show up on the watchlist? ('twould only be useful for very new or iffy users (i.e. users listed on WT:VIP but not blocked as vandals), of course...) L☺g☺maniac☃02:54, 26 December 2009 (UTC)[reply]
{{etyl}} already has a language code as its second parameter, so for a Spanish word of English origin, type {{etyl|en|es}}. {{sports}} also has a lang= parameter. It's just a matter of people remembering to use them. —Angr15:22, 26 December 2009 (UTC)[reply]
Sorry, maybe I was unclear. Templates that are already in our entries, but categorize in English, as English is the default for almost every template. So you get Japanese, Russian (etc.) words in English categories. I'd have thought this would be pretty damn machine readable. Mglovesfun (talk) 15:27, 26 December 2009 (UTC)[reply]
According to User:AutoFormat, AF already does fix context labels; have you seen evidence of that not working? As for {{etyl}}, we might want to ask Robert to add that to AF as well, though there's the complication that (for example) {{etyl|ar}} in a ==Hebrew== section is more likely to be an error for {{etyl|ar|-}} than for {{etyl|ar|he}} (though both are quite possible). I suppose the safest thing to do would be {{etyl|ar|-}}{{attention|he|some sort of message here about what happened}}. (Though with {{etyl|la}} in a ==Spanish== section that's a bit of a waste, since it's almost certainly supposed to be {{etyl|la|es}}.) —RuakhTALK15:49, 26 December 2009 (UTC)[reply]
This would probably be better done as a manual search from a generated list. As Ruakh indicates, there is no safe assumption about what is correct without looking at the entry. --EncycloPetey16:21, 26 December 2009 (UTC)[reply]
As for {{context}} with no language given, AutoFormat can correct this, but it only checks the recent changes, so pages that aren't updated (excluding bots like Interwicket) will continue to categorize in English, even when not so. Mglovesfun (talk) 11:55, 28 December 2009 (UTC)[reply]
It might be interesting from a formatting point of view to see which entries don't use {{plural of}} and eventually remove the overt written [[Category:English plurals]] from entries, as AFAICT all plurals should use plural of. This could later be extended to some other languages, but not all of them. Mglovesfun (talk) 16:24, 26 December 2009 (UTC)[reply]
How are the boundary cases handled? For example, plural-only nouns. I would guess that they should only be in their own category with the category being included in English plurals. What about redlinked plurals? More vexing are words that are in contemporary general usage in one sense (or more) as plural only, but not in other senses (often, but not always, dated or technical). (See hackles.) Might these cause trouble for the (desirable) process you seem to be advocating? DCDuringTALK * Holiday Greetings! 16:51, 26 December 2009 (UTC)[reply]
{{trreq}} was designed to add categories such as "Translation requests (French)" to entries. As it's commonly done for other templates supposed to be only used in entries, I'll edit {{trreq}} to not automatically add categories to pages outside the main namespace. --Daniel.01:42, 28 December 2009 (UTC)[reply]
I'm not thinking of a way to list them automatically right now. Perhaps it's simply better to edit them when such change becomes necessary. --Daniel.02:23, 31 December 2009 (UTC)[reply]
Sounds like a possible idea, but what would the purpose of the category be? If each template were tagged one at a time, I could see it being a useful tool. However, it's more likely that the catgeory will contain a mix of many pages containing many different deprecated templates. So, anyone using the category would have to spend time figuring out which template on the page is deprecated, where it is, and what to do about it. It doesn't seem like having the category would produce a useful payoff. --EncycloPetey17:54, 28 December 2009 (UTC)[reply]
If editors don't mind the headache of creating and deleting the resultant categories as templates are deprecated and then cleaned away, then it sounds like a feasible plan to me. --EncycloPetey18:35, 28 December 2009 (UTC)[reply]
The problem is that even if a template is not very widely transcluded, a change to the template can take a while to get through the job queue (depending what else is on the queue at the same time), so the category won't necessarily get populated very quickly. WhatLinksHere, on the other hand, is normally up-to-date, or at least closer to it. (It, too, is affected by the job queue, but using it doesn't require editing the template.) —RuakhTALK19:56, 28 December 2009 (UTC)[reply]
Hey, guise [sic]... I have Windows 7 and have tried on several occasions and through several methods to install Kass' Code2000 font with no success. I have already successfully installed his Code2001 with no problems. But when I try to install Code2000 by clicking on it, I get the message:
Windows cannot complete the extraction.
The destination file could not be created.