Wiktionary:Grease pit/2013/October

← September 2013 · October 2013 · November 2013 →

Template linking to transliteration - ne k méstuEdit

moved from wrong month's Grease pit

See не к месту. Some template is currently linking to the transliteration - "ne k méstu", which should be delinked - "ne k méstu". --Anatoli (обсудить/вклад) 01:04, 4 October 2013 (UTC)

The template-call is {{ru-adv|head=[[не]] [[к]] [[место|ме́сту]]}}; what's happening is that [[не]] [[к]] [[место|ме́сту]] is being transliterated to [[ne]] [[k]] [[mesto|méstu]], with the brackets, and therefore the links, being left intact. —RuakhTALK 06:34, 4 October 2013 (UTC)
Yes, I know, I had a similar issue at the old {{t-SOP}}. The delink function should be used. It's probably between ZxxZxxZ and CodeCat. They fixed it with nouns but it now appears on adverbs. Manual transliteration would fix it but I'd like to have this fixed, so that multipart adverbs would work as well.--Anatoli (обсудить/вклад) 06:43, 4 October 2013 (UTC)
Maybe you could just add [[]] and any other undesired characters to your table so it "transliterates" those characters to empty strings. Chuck Entz (talk) 06:52, 4 October 2013 (UTC)
Sorry, I don't understand. I did use [[]]. It's the brackets [[]] themselves that have to be removed from the transliteration. --Anatoli (обсудить/вклад) 07:06, 4 October 2013 (UTC)
@Anatoli: Chuck is saying that the transliteration table could "transliterate" [ and ] out of existence. —RuakhTALK 07:11, 4 October 2013 (UTC)
Oh, I see. Then perhaps, every module should have this? It can easily be done, though. --Anatoli (обсудить/вклад) 07:17, 4 October 2013 (UTC)
@Chuck Entz: No, because then you'd get ne k mestoméstu (instead of ne k méstu). But if I understand correctly, Anatoli is saying that we can just change {{{tr|{{#invoke:ru-translit|tr|{{{head|{{{sg|{{PAGENAME}}}}}}}}|nogen=1}}<!--tr-->}}} to {{{tr|{{#invoke:ru-translit|tr|{{#invoke:links|remove_links|{{{head|{{{sg|{{PAGENAME}}}}}}}}}}}}<!--tr-->}}} (replacing some of the code from {{ru-adv}} with its analogue from {{ru-noun}}). —RuakhTALK 07:11, 4 October 2013 (UTC)
Yes, that's right. The code seems too long, I was worried, I'll break it, if I do it myself. --Anatoli (обсудить/вклад) 07:15, 4 October 2013 (UTC)
Yes check.svg Done. [[не к месту]] looks right now. Please revert, and/or let me know, if you see any problems anywhere. —RuakhTALK 07:23, 4 October 2013 (UTC)
Thank you! --Anatoli (обсудить/вклад) 07:31, 4 October 2013 (UTC)

Dump, Search, and Special pages timingEdit

The most recent dump is dated 2 October. At this posting the special pages are dated 10 September. The previous dump was 9 September.

I expected the special pages to already have run, but I realize that I am ignorant of the actual dependency and sequential relationships involved. Are the special pages dependent on the XML dump?

Relatedly, I notice that the content of newly created pages is not immediately searchable, though the entry is findable if one has the exact name. Is search dependent on the most recent dump or on some other updating? DCDuring TALK 16:22, 5 October 2013 (UTC)

Re: "Are the special pages dependent on the XML dump?": I very much doubt it. I know for a fact that they used to be generated directly from database queries (just as the dumps are), and I assume that that's still the case. (The more-expensive special pages are still turned off on en.wikt, yes? What makes them expensive is that the database queries are expensive.) Also, the previous dump was dated 19 September (not 9 September), so I bet the scheduling is unrelated as well (though I have no real information about how the special pages are scheduled).
Re: "Is search dependent on the most recent dump or on some other updating?": That indexing is separate from both the dumps and the special pages, and occurs on a much more frequent basis, with updates being performed incrementally based on which pages have recently changed. (See mw:Extension:Lucene-search.)
RuakhTALK 19:26, 5 October 2013 (UTC)
Thanks. I've got to read much more carefully.
re: "The more-expensive special pages are still turned off on en.wikt, yes?"
Yes, but there is some thought to update the more-expensive pages a couple of times a year for largish wikis like ours. The pages that are "most"/"fewest" and "wanted" are the big resource consumers. I don't know which ones of those are the most valuable, but I really wonder whether any of them are needed every 3-4 days, which had been the frequency for a while. DCDuring TALK 21:27, 5 October 2013 (UTC)

"A script on this page is causing Internet Explorer to run slowly" on library computerEdit

Header was: == Script problems on library computer ==

Our JS problems have notable consequences for users with older PCs, such as those at libraries. I don't expect that getting messages about scripts, as I have at this session, is going to make Wikitionary very enticing for such users. I guess we are just amusing ourselves and not serving users. DCDuring TALK 16:14, 7 October 2013 (UTC)

Yes, let's lament the occurrence of problems to all eternity, without any suggestions or solutions whatsoever, or even any information about the problem. I guess we are just amusing ourselves and not serving Wiktionary OR its users. —CodeCat 16:29, 7 October 2013 (UTC)
OK I'll start learning Javascript now. The first thing I'll do is put up a splash screen that recommends that any user who sees a problem either fix it themselves or STFU. That should save you a lot of time. I'll get to JS right after I get through Perl. DCDuring TALK 17:44, 7 October 2013 (UTC)
DCD, what are the problems observed on the library computers? What messages about scripts are you seeing? What OS and version, and browser and version is in use? What are the consequences? – interruptions, some unreadable text, all unreadable text, or what? Thanks. Michael Z. 2013-10-07 18:17 z
The library had IE 8 on what might have been Windows 7. The message was the one that asks whether the user wants to let the script continue or stop it. I was logged in on the Watchlist page, so it may have had to do with my preferences. It happened both times I first looked at my watchlist (Sessions are interrupted after an hour.). I wasn't there to do testing and didn't have time to determine an actual problem, other than the message. I did verify that no such problem arose at my WP watchlist and also noted that WP seemed faster to load than enwikt. I have seen a similar message about JS scripts on my Windows 7 laptop with FF, but not on my Watchlist page.
What distressed me is that our public face is on such machines. I suppose that a possible implication is that we need to test any functionality which we depend on JS to deliver to unregistered users on such machines. Who tends our JS these days? DCDuring TALK 22:14, 7 October 2013 (UTC)
If someone has some suspicions or hypotheses about the nature of these problems or concern about the user experience, I would be happy to go to some of the the public libraries around here and run whatever stress tests might be appropriate both logged in and not. I have noticed that some problems that I experience (eg, with fonts and show/hide for translations, quotations, and {{rel-top}}) seem not to occur when I am not logged in. DCDuring TALK 22:24, 7 October 2013 (UTC)
If you could give a list of gadgets you currently have enabled, that might help narrow down the possible sources of the problem. --Yair rand (talk) 22:25, 7 October 2013 (UTC)
Thanks for asking. The list is at User talk:Yair rand. DCDuring TALK 00:55, 8 October 2013 (UTC)
It is increasingly apparent that we now have a large enough codebase that we need stress tests, regression tests, etc. I hope that pointing this out without being able to fix it will be taken as constructive criticism. Equinox 22:26, 7 October 2013 (UTC)

A job for someone's botEdit

Do we have any bot like Wikipedia's that fixes common spelling errors? I've noticed that a lot of entries include the misspellings occured and occuring (both requiring -rr-). If anyone feels like dealing with these, watch out for initial capitalisation, and don't touch the special misspelling entries at occured and occuring! Equinox 22:20, 8 October 2013 (UTC)

I only get around a dozen of each by using search with quotes around the term. Is that worth a bot? DCDuring TALK 22:29, 8 October 2013 (UTC)
User:DTLHS/defnotexist- words that are in the English misspellings category that appear in (English) definitions. DTLHS (talk) 00:10, 9 October 2013 (UTC)
And I guess there's no reason to restrict it to definitions- I'll run an improved search later. DTLHS (talk) 00:26, 9 October 2013 (UTC)
Well, based on a limited sample (32 instances of refering) the problem can arise in {{trans-top}} and {{qualifier}} and under the headings Etymology and Usage notes. I would expect it potentially in {{sense}} and {{n-g}}/{{non-gloss definition}}. There are misspellings we may need to keep, eg, in quotations. I also don't think that fixing can be safely delegated to a bot, even in cases like refering which has no ambiguity, let alone affect/effect, but it might be worth taking a chance for terms like refering if the error rate is low enough. DCDuring TALK 01:01, 9 October 2013 (UTC)
Words that are misspellings in English might appear legitimately in other languages. Since we haven't wrapped all foreign text in language-tagging templates yet, bots can't recognise it, so there is a danger of false positives. —CodeCat 02:13, 9 October 2013 (UTC)
Can't a Perl script manage to keep L2 sections apart? There should be no problem in English L2s except for the Etymology section. The definiens in other L2 sections is supposed to be in English in all cases. It would be possible to create a list of all those that were unique to English in Wiktionary (ie, no FL entry and no FL translation.). One could even go to other Wiktionaries to help identify other potential clean ups.
In any event a partial solution to this would be a significant improvement while we await the millennial straitjacket improvements. DCDuring TALK 02:41, 9 October 2013 (UTC)
@CodeCat: Good point. Re: "Since we haven't wrapped all foreign text in language-tagging templates yet, bots can't recognise it": I doubt it will be feasible for bots to be able to recognize even when text is language-tagged; there are simply too many templates that perform language-tagging, and they all use different conventions. (Also, AFAIK we're currently not even planning to language-tag transliterations, except perhaps with lang="". IIRC, when you tried it, it turned out to cause weird behaviors in certain browsers.) —RuakhTALK 02:43, 9 October 2013 (UTC)
I've searched for this using Google before, AutoWikiBrowser has a wiki search (text) option as well to look for strings of characters inside pages of all namespaces (so here by string of characters, I might be 'wizzard'). But it's just whatever misspellings I happen to come up with at the time, not systematic. Mglovesfun (talk) 16:43, 9 October 2013 (UTC)
Might be better to limit it to words that are only misspellings, for example to has 95530 occurrences! It's a misspelling of 'too'. Mglovesfun (talk) 20:43, 19 October 2013 (UTC)

Template:list helper and User:CodeCat/list helperEdit

There are literally hundreds of transclusions of CodeCat's version in the Template namespace. Given the state of the main version until recently, that's certainly understandable, but I believe that's been fixed. Shouldn't we change all of these to the new, improved main version? I see that there are some differences in how they're used, and there's no documentation for either, so I'm not sure what would be involved. Chuck Entz (talk) 20:18, 12 October 2013 (UTC)

What improvements have been made to the main version? —CodeCat 20:30, 12 October 2013 (UTC)
By new, improved, I'm referring to the changes relative to the old, resource-hog version- not relative to the version in your namespace. My point is that, all else being equal, we should have all of the templates in general mainspace use located in the template namespace. You spent a good number of edits on the namespace version, and its rfdo was recently closed as kept on the grounds that the problems had been fixed, so I assumed that all else was now indeed equal. Was I wrong? Chuck Entz (talk) 20:46, 12 October 2013 (UTC)
As far as I know, nothing has ever been done to the original version. —CodeCat 21:31, 12 October 2013 (UTC)
I see that you changed it to use language utilities instead of langscript, but, point taken. My misinterpretation aside, my general intent still stands: the version we use in all those lists should be in template space, and the old version should be retired. What do we need to do to make that happen? By my count there are 78 transclusions by templates and 477 in mainspace for the old version. Even if we don't de-userfy, that's 78 template transclusions too many, given the problems with the old template. Chuck Entz (talk) 22:30, 12 October 2013 (UTC)
I think the idea was originally to orphan the old template, then move the new one over the old, and then orphan the newly-created redirect. But the first step was never completed, so it was just left this way in limbo. —CodeCat 22:36, 12 October 2013 (UTC)
How are the two templates different in their use requirements? I notice that the templates transcluding the user-space version have <noinclude>{{list doc}}</noinclude>, and wrap the list members in {{l-self}}. Is there anything else? I'm willing to chip away at the 78 if I can be sure I'm not messing up the 477 in the process. It doesn't look like there are any recent new uses of the old template, so it might not be that hard to orphan it. Chuck Entz (talk) 23:46, 12 October 2013 (UTC)

Gadgets in the Norwegian WiktionaryEdit

Is anybody willing to help me set up some sweet gadgets in the Norwegian Wiktionary? E.g., a tool that makes adding foreign entries easier. I have seen on some other projects that if someone has added a translation to a word, you can simply click on that translation to get a new article that creates a correct entry complete with class of word, meaning in local language etc. I am sure there are many other nice gadgets around that could come in handy.

Unfortunately, the number of steady contributors in the Norwegian Wiktionary is quite small. To my knowledge, we don't have anyone capable of porting these kind of gadgets into our own project. It would really help if someone could help us out here. --Teodor (talk) 07:46, 14 October 2013 (UTC)

Recent changes recently changed?Edit

I can no longer see the "Current number of entries" count in Recent changes. If I log off, or if I log on as my bot, then I can see it. Any ideas? SemperBlotto (talk) 09:54, 17 October 2013 (UTC)

  • PS - MonoBook or Vector, Google Chrome or IE, makes no difference.
  • This is annoying. The difference in the source of the pages is as follows:-
  • Me - Show new changes starting from <a href="/w/index.php?title=Special:RecentChanges&from=20131026071645" title="Special:RecentChanges">07:16, 26 October 2013</a>
  • Other - Show new changes starting from <a href="/w/index.php?title=Special:RecentChanges&from=20131026071840" title="Special:RecentChanges">07:18, 26 October 2013</a> | Current number of entries: 3,541,454

I have been through all my preferences (both sorts) and can't find an significant difference between me and my bot. What is the cause? SemperBlotto (talk) 07:24, 26 October 2013 (UTC)

The relevant difference is that your bot's language preference is set to en - English, whereas your own language preference is apparently set to something else, most likely en-GB - British English, which therefore causes MediaWiki:Rclistfrom to be ignored and the default British-English message to be used. (The total-number-of-entries thing right there is not a MediaWiki feature, it's just something TheDaveRoss (talkcontribs) added to the end of an existing interface message.) I've now copied the contents of MediaWiki:Rclistfrom to MediaWiki:Rclistfrom/en-GB, so you should now see it again? (Please confirm.) —RuakhTALK 16:31, 26 October 2013 (UTC)
Well done (you're assumption was correct). SemperBlotto (talk) 16:34, 26 October 2013 (UTC)

captcha/catchpa broken?Edit

I caught one!

The catchpa seems to be broken for External Links. When I enter it correctly, it just dumps me back to the edit screen instead of saving my edit. -- 06:15, 19 October 2013 (UTC)

I didn't even know we had catchpas. Mglovesfun (talk) 20:19, 19 October 2013 (UTC)
It's only if you're not logged in. And they're called "captcha"s. --WikiTiki89 21:40, 19 October 2013 (UTC)
Well, it's supposed to be able to save, if you enter the catpcha/captcha/catchpa properly, except it doesn't. It's hard to link to quotations if it doesn't work. -- 04:35, 21 October 2013 (UTC)
Maybe it's something imposed by Ma to keep her hubby out of mischief... Chuck Entz (talk) 22:03, 19 October 2013 (UTC)
Sorry I knew it wasn't spelt right but couldn't remember how to spell it. Mglovesfun (talk) 09:43, 20 October 2013 (UTC)
Sounds like capture. Michael Z. 2013-10-21 03:19 z

Can't update another User's subpage.Edit

Your system won't allow me to update User:SemperBlottoBot/feedme - I wanted to add the French adjective "allodial". Toasted Almonds (talk) 13:39, 19 October 2013 (UTC)

It's semiprotected; you won't be able to edit it until your account is not quite so brand-new. Maybe you can put the request on the talk page. —Aɴɢʀ (talk) 19:37, 19 October 2013 (UTC)
It's actually Abuse Filter 24 that's the problem. It's labeled "Users creating other users' user pages", but it seems to also prevent any edits at all to another user's user page or sub-pages by anyone who isn't a bot, admin, or autopatroller. It stops lots of vandalistic and spam edits, but there must be some way to exempt the types of subpages that are intended to be open for edits. Chuck Entz (talk) 20:27, 19 October 2013 (UTC)
I've updated the description so it's accurate. As for exemptions . . . I'm not sure. In the specific case in question, I'm not sure we want unpatrolled editors to be able to tell a bot to create entries . . . —RuakhTALK 16:36, 20 October 2013 (UTC)
Oh, and we might want to create a MediaWiki:Editnotice-2 that warns people not to waste their time. —RuakhTALK 16:52, 20 October 2013 (UTC)
I agree with Ruakh: I don't think we want un-autoconfirmed users to be able to tell bots to create entries; the potential for mess is too great... - -sche (discuss) 23:22, 30 October 2013 (UTC)

French verb forms ending in -é and -antEdit

Could someone make a list of all the entries in Category:French verb forms ending in -é and -ant. This is because entries in Category:French past participles and Category:French present participles shouldn't be double categorized. Mglovesfun (talk) 09:40, 20 October 2013 (UTC)

Have a look here. --flyax (talk) 13:02, 22 October 2013 (UTC)

Stale special pages no longer staleEdit

The Special Pages like Special:WantedPages and Special:AncientPages (Oldest pages) that had not been upddated since 2009 have been successfully run. WantedPages at least is useful for directing some cleanup efforts.

The page message at the top of Special:WantedPages is now erroneous and should be changed to something more accurate and robust. DCDuring TALK 12:14, 20 October 2013 (UTC)

That's great news! Just a quick look shows some overlooked problems: {{derivcatboiler}} is referencing etyl:xx language code templates, there are inflection templates linking to grammatical terms in other languages, and a batch of bot-created entries with the deleted template mf. Now if they could update Special:WantedCategories... Chuck Entz (talk) 16:21, 20 October 2013 (UTC)
Re: page message: You can use Special:WantedPages?uselang=qqx (which displays the names of messages rather than their contents) to see that the big yellow "obsolete" box is generated by MediaWiki:wantedpages-summary and the "currently disabled" text is generated by MediaWiki:querypage-no-updates. We actually probably don't want to modify the latter; rather, we should ask the devs to remove that message from any pages where it's no longer accurate. (Unless there are no pages where it's no longer accurate, in which case, sure, we can blank it out or something.) —RuakhTALK 16:57, 20 October 2013 (UTC)
How does one find and address the devs? DCDuring TALK 19:12, 20 October 2013 (UTC)
@Chuck: The special pages that had been normally run twice a week hadn't been run for 40 days and 40 nights because someone tinkered with and broke that normal run while trying to clean up some script or something. The previously disabled pages were run "manually", mostly to make sure they didn't break the servers. They apparently will be run monthly. frequency with which they will be run has not been determined. DCDuring TALK 19:47, 20 October 2013 (UTC)
@DCDuring: In this case probably via bugzilla:15434 for the general problem. If you have a specific bug in mind, see [1] --AKlapper (WMF) (talk) 08:27, 25 October 2013 (UTC)
I've used Bugzilla. I thought there was some other low-overhead channel for non-bug routine maintenance task. DCDuring TALK 10:58, 25 October 2013 (UTC)

Convert rhyme pages into categories?Edit

Rhyme pages like Rhymes:Dutch:-ɔp are really glorified categories. They list pages. I see only two real differences between them and an actual category, at least in terms of the way the words are displayed: the rhymes pages group words by the number of syllables, and they list red links. Having these rhyme pages also creates maintenance problems because entries have to be added to the list, and the rhyme has to be added to the page at the same time. People seem to have a habit of misinterpreting rhymes as meaning any words ending in the same letters, so they end up adding rhymes that then need to be removed from both the list and the pages. It would be easier if this was just a matter of placing a template on an entry, and letting it add the category. In fact, if we want to we can go even further and add it to {{IPA}} as a feature: a module could extract everything that comes after the first stressed vowel.

So I think it would be beneficial to migrate away from the Rhymes: pages and replace them with categories. We already have some of the category structure in place, see Category:Dutch rhymes:-ɔ-. The information at the top of each rhyme page, which gives pronunciation and such, can be put at the top of the category without much issue. —CodeCat 19:39, 20 October 2013 (UTC)

Don't different languages have different rhyming rules? Which would complicate any automation from IPA. DTLHS (talk) 19:43, 20 October 2013 (UTC)
Yes, the module would have to take that into account. I'm not saying we should add it to {{IPA}}, only that it becomes a possibility. Languages with many words with initial stress like English would end up with a lot of categories with one word that nothing else rhymes with, if we made it completely automated. So we can keep using {{rhymes}} for now and let it add the category. —CodeCat 19:45, 20 October 2013 (UTC)
Support. I think this would work in any language whose rhymes exhibit the transitive property. Since I can't think of how that could possibly not be the case, I am willing to assume that it should work for all languages. --WikiTiki89 20:58, 20 October 2013 (UTC)
I proposed something like this some time ago, and still think it's a good idea. However, at the time I felt strongly that dividing the words by number of syllables was useful. (I still do.) IIRC, I proposed categorizing using a number-of-syllables sortkey: thus, for example, English invasion would be sorted as 3invasion in the -ejʒən (or whatever) category. IIRC, someone commented that that would limit good categorization to terms of nine syllables or less. However, that's not insurmountable: longer terms can be sorted s.v. >, say, which is after the numerals (in Unicode order) and symbolic of being a longer-than-nine-syllables term, and the categories can have a notice indicating the sort scheme.​—msh210 (talk) 06:03, 21 October 2013 (UTC)
The problem with that is that this support needs to be added not just to {{rhymes}} but also to all entries that use it. So it's not feasible in the short term. —CodeCat 12:36, 21 October 2013 (UTC)
What needs to be changed on the pages that use it? As far as I can tell {{rhymes}} is all that needs to be changed, (along with creating a category for every rhyme). --WikiTiki89 15:10, 21 October 2013 (UTC)
It would need to be told how many syllables are in the word. —CodeCat 15:39, 21 October 2013 (UTC)
I wouldn't say need to. We can make that optional and slowly go through and add them in. Also, many words can be pronounced with different numbers of syllables (I'm not sure how we currently handle that). --WikiTiki89 16:31, 21 October 2013 (UTC)
Let's focus on one thing at a time for now? We can do the conversion to categories first, and then we can see if the syllable count is really such a big thing that we want to add it back in. —CodeCat 16:34, 21 October 2013 (UTC)
That's basically what I said, isn't it? --WikiTiki89 16:35, 21 October 2013 (UTC)
  • Oppose. Rhyme pages offer means of organization that categories do not such as by the number of syllables. --Dan Polansky (talk) 17:30, 21 October 2013 (UTC)
    • But is that actually useful? Or is it just a matter of "it goes up to 11"? —CodeCat 17:51, 21 October 2013 (UTC)
      • That is absolutely useful. Rhyming lines often contain endings containing similar number of syllables. Compare e.g. Rhymes:Czech:-ajiː. By the way, Category:Czech_rhymes has 1,368 items. --Dan Polansky (talk) 18:01, 21 October 2013 (UTC)
        • I agree: if this includes dropping the number-of-syllables information, even if not forever but indefinitely, I oppose.​—msh210 (talk) 05:55, 22 October 2013 (UTC)
      • Another plus: rhyming guide pages can contain countless redlinks. --Dan Polansky (talk) 18:04, 21 October 2013 (UTC)
        • So can categories (listed in the category description). We have (or at least have had) a number of categories like that.​—msh210 (talk) 05:45, 22 October 2013 (UTC)
Another issue with turning rhymes pages into categories: I think the general practice is that we encourage {{rhymes}} in entries for English third-person singular present forms and English plurals, but do not list such terms on Rhymes: pages (unless they have other senses). Converting {{rhymes}} to a categorizing template would require a |nocat=1-type thing for such terms.​—msh210 (talk) 06:05, 22 October 2013 (UTC)
Or we can just change that rule. There is no reason not to include plurals and conjugated verbs. --WikiTiki89 12:59, 22 October 2013 (UTC)
They're already included for Dutch anyway. After all, what good is a list of rhymes if many potential rhymes are not listed on principle? Sometimes I may actually need something that rhymes with bitten. —CodeCat 13:21, 22 October 2013 (UTC)
Does it have to be one or the other? {{rhymes}} could categorize then we'd automatically have both at once. Mglovesfun (talk) 17:37, 22 October 2013 (UTC)
You want a list of rhymes in category form and another on a Rhymes: page, manually maintained? (1) It's redundant: the same information in two places. (2) No one would maintain the Rhymes: pages, trusting to the automatic categorization. Nonetheless, (3) people would need to look in two places to be sure they had the most complete information available.​—msh210 (talk) 18:29, 22 October 2013 (UTC)
(Re CodeCat.) Bitten is included anyway: only very standard plurals (-s, -es) and the like aren't.​—msh210 (talk) 18:31, 22 October 2013 (UTC)
(Re Wikitiki.) I think the idea behind not including English plurals is that the interesting rhymes would get lost among all the plurals. That said, I, for one, don't see a problem if they do, or if we include English plurals and the like on the lists.​—msh210 (talk) 18:29, 22 October 2013 (UTC)
I do see quite a lot of support for this, but also some opposition. Would it be ok to implement this for Dutch alone for the time being? The Dutch rhymes pages have few red links, so not much information is lost and it would be easy to create those pages anyway. Dutch also already has a category structure in place for rhymes. —CodeCat 16:15, 24 October 2013 (UTC)
Could you please make explicit what you're proposing? That is, what information did the Dutch Rhymes: pages have until now (or, knowing your habit of starting things sans support, perhaps I should say "until recently"), and what information did the categories have until now (or recently), and what information do you propose each will have in the future? And how has that information been presented and how will that information be presented? by information I mean to include, for each word, what words it rhymes with, how many syllables it has, and anything else included in the Rhymes: page, category page, inclusion-in-Rhymes:-pages scheme, or categorization scheme.​—msh210 (talk) 19:07, 24 October 2013 (UTC)
I didn't change anything yet so what you see on Rhymes:Dutch and Category:Dutch rhymes is how it has been for the last year at least. For now I only intend to make a change to {{rhymes}} so that, if the language is "nl", it adds the current entry to Category:Dutch rhymes:(whatever the rhyme is). And I will create those categories then, as needed, as subcategories of the ones that already exist. The text at the top of each category will be copied from the matching Rhymes: page. I won't delete the original Rhymes pages yet, until we decide it's ok. —CodeCat 19:11, 24 October 2013 (UTC)
I see the benefit: autocategorization. But it's at the dual cost of redundancy (with what that entails, as I wrote above) and lack of syllable information in the category (with, if the category exists, less incentive to add rhymes manually to where they are divided by syllable). IMO the cost outweighs the benefit, and I oppose.​—msh210 (talk) 03:42, 25 October 2013 (UTC)
So add a sort key with the number of syllables. This is a non problem. DTLHS (talk) 03:49, 25 October 2013 (UTC)
  • I oppose converting rhyme pages into categories for Dutch, no less than for other languages. --Dan Polansky (talk) 08:27, 26 October 2013 (UTC)
    A note: from browsing a random selection of Special:PrefixIndex/Rhymes:Dutch, I only found pages with one or two sections for the number of syllables. There quite possibly are pages with more sections, but my random browsing has not found them. Here is a random sample, in the collection of which I have discarded each found page that had less than 7 items: Rhymes:Dutch:-ʏs, Rhymes:Dutch:-ɑst, Rhymes:Dutch:-ɑŋk, Rhymes:Dutch:-ɪk, Rhymes:Dutch:-ɔrst, Rhymes:Dutch:-ɛi̯dən, Rhymes:Dutch:-ʏkt. I don't think one can appreciate the value of separation by the number of syllables from these Dutch rhyme pages. I don't think that the pages reflect the hypothesis that Dutch rhymes always have to match the number of syllables very closely; more likely, whoever has created the pages has not found a way of identifying more extensive lists of items that would include a larger variety of numbers of syllables, as has originally happened to me when I started to create Czech rhyme pages such as Rhymes:Czech:-atʃ or Rhymes:Czech:-ats. Again, to appreciate the separation by the number of syllables--and not by the letter of alphabet as categories automatically do--, check e.g. Rhymes:Czech:-ajiː or Rhymes:English:-eɪʃən. An aside: the Czech page uses a markup to create three column layout in Firefox and Chrome, which the English page does not. --Dan Polansky (talk) 08:56, 26 October 2013 (UTC)
    Furthermore, categories are limited to showing 200 items, whereas a rhyme page can easily host 5000 items, which is much more convenient. For instance, Rhymes:Czech:-ɛɲiː has over 3000 items, which requires 15 times clicking on "next" in a category; forget about pressing Control + F on a category page and finding what you want. --Dan Polansky (talk) 09:04, 26 October 2013 (UTC)

Can't get some alternative forms display correctlyEdit

In module Module:ru-verb-testmodule, I'm trying to make some alternative forms to work for the verb сы́пать (sýpatʹ) (to pour friable substance). Currently, {{ru-conj-irreg-сыпать}} points to this test module.

E.g. there should be two forms for 2nd person singular: "сы́плешь" and "сы́пешь" Lines of interest (to see how the variables are used):

  1. forms["pres_futr_2sg2"] = args["pres_futr_2sg2"]
  2. forms["pres_futr_2sg2"] = prefix .. "сы́пешь"
  3. forms["pres_2sg2"] = forms["pres_futr_2sg2"]
  4. if forms["pres_2sg2"] and not perf then alt_pres_2sg = forms["pres_2sg"] .. ",
    " .. forms["pres_2sg2"] end

In the last line forms["pres_2sg2"] is nil but I'm expecting it to be "сы́пешь". --Anatoli (обсудить/вклад) 22:01, 20 October 2013 (UTC)

If I call the template with {{ru-conj-irreg-сыпать|impf|pres_futr_2sg2=сы́пешь|past_pasv_part=сы́панный}} then it works. Is there something you may have overlooked? —CodeCat 22:51, 20 October 2013 (UTC)
The verb has specific function (conjugations["irreg-сыпать"]) to add the alternative forms without having to pass long parameters for this verb and its derivatives. 2nd example (2nd line above) is meant to override forms["pres_futr_2sg2"] - originally nil because "args["pres_futr_2sg2"]" is not used. --Anatoli (обсудить/вклад) 23:06, 20 October 2013 (UTC)
But that is why it's nil. args["pres_futr_2sg2"] is nil if the parameter is not given. So the first line sets it to nil and overrides what is done in the second line. —CodeCat 23:08, 20 October 2013 (UTC)
Thanks for the explanation and the suggestion in the module. I got confused with the order of execution - so much better when you can trace into the program with debuggers! --Anatoli (обсудить/вклад) 01:15, 21 October 2013 (UTC)

subcategories of Category:Roman mythologyEdit

They describe themselves as containing "terms related to roman mythology", when they should say "terms related to Roman mythology" with a capital R. Could someone fix that? I'd do it myself, but at the moment I'm drawing a blank on how to.

Also, they and other categories, e.g. the "alcoholic beverages" category, link to Roman mythology and alcoholic beverages, etc. Is there a way to override that and make them link to [[Roman]] [[mythology]], [[alcoholic]] [[beverage]]s, etc? - -sche (discuss) 18:32, 21 October 2013 (UTC)

The Edit Description link will take you to the subtemplate that controls the capitalization. It looks to me like there's a bit too much template logic for generalizing things, since the subtemplate is unique to a given category (the main one, not the language-specific one). It would just be a matter of removing a couple of :"lcfirst"s. I'd do it myself, but I'm not experienced enough with templates to be sure I wouldn't break something by accident, and there are too many transclusions for getting it right by trial and error. Chuck Entz (talk) 02:39, 22 October 2013 (UTC)
See this. I'm pretty sure these used to use {{subst:SUBPAGENAME}} meaning once you'd saved it, it changed from {{lcfirst:{{SUBPAGENAME}}}} to roman mythology, at which point you could edit it again and change the 'r' to a capital. Not sure when this changed. Mglovesfun (talk) 17:47, 22 October 2013 (UTC)

Russian nouns with inflections reported as missing itEdit

Why do all Russian nouns appear in Category:Russian nouns needing inflection? --Anatoli (обсудить/вклад) 21:37, 22 October 2013 (UTC)

Because the headword is missing the inflections. The category could be removed until the number is brought down to a more manageable number? —CodeCat 21:43, 22 October 2013 (UTC)
I think so. Or maybe it should be "... needing inflection in the headword" instead? For multipart words where only one or two words are declined the category/message (??? please provide...) seems redundant, like having to add genitive to "Федера́льной слу́жбы безопа́сности Росси́йской Федера́ции" to proper noun Федера́льная слу́жба безопа́сности Росси́йской Федера́ции (Federálʹnaja slúžba bezopásnosti Rossíjskoj Federácii) or both genitive and plural to multipart nouns. I don't have a very strong opinion on this but it seems a bit annoying, even considering benefits. I appreciate your efforts but maybe we should get some more feedback? Also, as I mentioned, it can be error prone and there could be a mismatch (missing accent) between the inflection table and the headword, like япо́нка (japónka), plural shown as "японки" in the headword but the table has "япо́нки". --Anatoli (обсудить/вклад) 22:20, 22 October 2013 (UTC)
I disagree. I think for such nouns it's especially helpful to see which parts decline and which don't. If you don't want to link to the whole phrase, you can add links to the declining words:
{{ru-proper noun|[[федеральный|Федера́льная]] [[слу́жба]] [[безопасность|безопа́сности]] [[Российская Федерация|Росси́йской Федера́ции]]|f|[[федеральной|Федера́льной]] [[слу́жбы]] безопа́сности Росси́йской Федера́ции}}
And if the accent is missing from the headword, it shows in Category:Russian noun inflections needing accents. —CodeCat 22:28, 22 October 2013 (UTC)
Indeclinable nouns shouldn't ask for gen. sg and nom. pl. but I see you have removed "decl=no"? What do you think of splitting Category:Russian nouns needing inflection into this plus Category:Russian nouns needing inflection in the headword? --Anatoli (обсудить/вклад) 23:43, 22 October 2013 (UTC)
I removed that parameter but the feature still exists. Just give "-" as the genitive.
We could make that split but I think it's really only useful temporarily, until the category is small enough for it to be manageable. I have a way that might reduce the number some as well. Module:nl-verb has a parameter bot=1, and when you give that, then instead of showing the forms in a neat table, it just shows them in a list that a bot can easily read. I used that feature to fill in the verb forms in the headwords of Dutch verbs, based on what the inflection tables contained. We could do the same with Russian nouns, by extracting the forms from the table if it's present, and then putting that into the headword template. It does require the tables to be correct and parseable by bot, though. —CodeCat 00:24, 23 October 2013 (UTC)
It sounds interesting, if it's possible. I don't know know if the tables are parseable. --Anatoli (обсудить/вклад) 01:36, 23 October 2013 (UTC)
Not currently, no. "Parseable" means the output is really just a list of forms, without any table formatting; something a bot can easily understand. But there are currently lots and lots of noun templates, and it would be almost unmanageable to convert all of them separately just for this. I assume we are going to convert them to Lua at some point, so we can work on simplifying them then. We can probably eliminate quite a few of them in the process. I think even now we could cut the number in half by converting the "unc" templates into an extra parameter "n=sg" for the remaining half. Once the number of templates has been reduced some, then it might be worth trying to make adjustments to them to accommodate this change.
Another point that matters separately is, how many entries have inflection templates and how many are missing them? —CodeCat 02:24, 23 October 2013 (UTC)
I do not like the changes made to {{ru-noun}}, particularly the removal of decl=off and forcing to provide the genitive and nominative plural. I do not intend to provide that superfluous information in the headword line ever, because it is already present in the declension table. --Vahag (talk) 08:28, 23 October 2013 (UTC)
Then don't provide it? And I don't understand the objection to removing decl=off when the same result can be achieved another way. —CodeCat 12:26, 23 October 2013 (UTC)
When I don't provide it, it yells at me "(??? please provide the genitive!)". I don't like that. I have to use {{head}} instead. --Vahag (talk) 16:18, 23 October 2013 (UTC)
Please don't use {{head}}. If you don't want to provide the genitive then don't provide the genitive. —CodeCat 16:51, 23 October 2013 (UTC)
Then don't force me to see that scary message. Use silent categories for masochists who want to waste their time on adding duplicate content. --Vahag (talk) 17:44, 23 October 2013 (UTC)
(Butting in: Now as before, I oppose CodeCat making major changes to templates that are not based on consensus as evidenced at least by the shoddy evidence of previous Beer parlour discussion.) --Dan Polansky (talk) 17:54, 23 October 2013 (UTC)
I have to say that many of the changes done by CodeCat were good, but not this one. --Vahag (talk) 18:03, 23 October 2013 (UTC)
He kind of reminds me of Hitler: his first ideas were good, but then he went more and more insane and at the end he was little more than a psychopath. -- Liliana 18:38, 23 October 2013 (UTC)
Misgendering and a histrionic (and historically ignorant) comparison to Hitler... impressive! - -sche (discuss) 18:58, 23 October 2013 (UTC)
I would add more about CodeCat's history since 2006, but he just keeps revdeleting this kind of information whenever it appears on Wiktionary. So I won't invest my precious time and leave it to you to figure out what makes him so uncomfortable sharing his past with others. -- Liliana 19:04, 23 October 2013 (UTC)
Guys, let's stop gossiping and focus on the issues. --WikiTiki89 19:28, 23 October 2013 (UTC)
I see no reason to care about "CodeCat's [off-site] history since 2006", and given that she has consistently presented herself here as female-gendered (e.g. by setting the "How do you prefer to be described?" preference to "She edits wiki pages"), it is inappropriate to refer to her here using masculine pronouns. (If, as you seem to be implying, you know her in an offsite context where she presents herself as male, I can understand that it can be difficult to avoid doing so; nonetheless, you must make an effort.) —RuakhTALK 23:59, 23 October 2013 (UTC)
Well, I am suspecting something, but I won't share these kinds of thoughts on a public platform since this is, after all, the Internet, which never forgets. CodeCat does probably know what I am talking about but so far hasn't gone ahead to confirm or deny what I am thinking. I am just kind of between two fronts since I have seen photos and until proof to the contrary is presented this is what I will have to go by. -- Liliana 21:10, 24 October 2013 (UTC)
I happen to agree with Vahag, I don't find the genitive necessary in the headword line and don't think it should complain when it's not there. For Russian speakers, the singular genitive is rarely a source of confusion (unlike the plural genitive). Also, it might make sense for Germanic languages, which have relatively few cases, but in Russian there is no reason to stress the genitive over the other cases. It is by no means more interesting, important, or hard-to-guess then, say, the instrumental case. --WikiTiki89 18:36, 23 October 2013 (UTC)
First of all, the hate speeches are completely unjustified. CodeCat has done a lot of good work, including useful major changes (I agree there should be more consensus first, though). Russian verbs are getting into a pretty good shape - with all categorisations, transliterations and headers - thanks to Module:ru-verb we worked together on. Nouns and other SoP's can be improved too, even if they are very good already. I don't know her past history but what she does now is pretty impressive.
Here's my opinion on the topic.
It makes sense to make the parameters optional and without the messages and with a different category, not Category:Russian nouns needing inflection. Russian verbs go in pairs impf/pf but the pair is optional and it should stay that way.
If most nouns have gen. sg, nom. pl forms loaded by a bot, then it's not a bad thing at all - but optional. Nouns with more than one inflection table or comma-separated forms should have all those.
The choice for gen. sg, nom. pl is not bad, it won't substitute for the full table but it's pretty useful. E.g. слон - слона́, слоны́/бегемо́т - бегемо́та, бегемо́ты; тра́ктор - тра́ктора, трактора́; кошелёк - кошелька́, кошельки́/зо́нтик - зо́нтика, зо́нтики gives a good hint to which declension type these nouns belong. --Anatoli (обсудить/вклад) 22:58, 23 October 2013 (UTC)
@Wikitiki89. Genitive singular may be sufficient (along with nominative plural) to determine the stress pattern (may not be 100%, can't say off the top of my head) - see Appendix:Russian stress patterns - nouns. As you can see, the 3rd row includes multiple cases, one of them is genitive, so if you know how to stress the genitive form, you'll know how to stress instrumental. Thus, the optional two parameters would be quite useful for Russian as well, even if it may not seem so at first. --Anatoli (обсудить/вклад) 00:58, 24 October 2013 (UTC)
CodeCat you can't have it both ways, you can't deliberately break ru-noun then complain when users use {{head|ru|noun}} instead. Mglovesfun (talk) 19:13, 24 October 2013 (UTC)
Most of the changes to {{ru-noun}} have been positive and useful and the entries using it were modified and restructured accordingly and timely. The annoying messages and unwanted categorisations were removed before your last comment. {{ru-noun}} is the main and the standard template for Russian nouns, any problems with it should be addressed, rather than seeking other methods to create Russian noun entries. Anyway, my question was answered and the problems resolved. I'm going to use the optional parameters (for solid terms, at least), which I find useful. --Anatoli (обсудить/вклад) 01:13, 25 October 2013 (UTC)--Anatoli (обсудить/вклад) 01:13, 25 October 2013 (UTC)

How do I put a module into a category?Edit

How to do this is non-obvious to me. Michael Z. 2013-10-24 01:31 z

Add it to the doc page with includeonly. DTLHS (talk) 01:33, 24 October 2013 (UTC)
Thank you. Michael Z. 2013-10-24 01:37 z
Now, what’s the right place to document this for editors? Do we have a Wiktionary Lua style or Lua best practices page? Michael Z. 2013-10-24 01:40 z
Wiktionary:Scribunto could be used, I suppose. --Yair rand (talk) 03:29, 24 October 2013 (UTC)
Thanks. I started documenting this at Wiktionary:Scribunto#Organizing_Lua_modulesMichael Z. 2013-10-27 16:41 z

Headers and shortcuts for Beer Parlour, Grease Pit, etcEdit

Monthly discussion pages are great. But now that we never look at the aggregate pages like WT:BP and WT:GP, the headers there aren’t helpful. Can we put a simple header at the top of this page to link the previous and next months? How do we automatically create such a thing for each month? I manually did this at the top of WT:BP/2013/July Wiktionary:Beer parlour/2013/July.

And how can we automatically have shortcuts for WT:BP/2013/10 or WT:BP/2013-10, etc? Michael Z. 2013-10-24 01:35 z

Automated assistance or performance of maintenance tasksEdit

Are there ways to ease the effort involved in some of the necessary maintenance tasks, like archiving and patrolling?

It would seem desirable to have some means of moving sections (or links to appropriate archive sections) of RfV, RfD, even RfC and TR pages to the relevant entry or entries. Is there a way to do this that can be "fire and forget" from the point of view of the maintainer, so that the maintainer could proceed to another window or tab? Could items be queued? Could a bot do it? Even better, is there a way this can be done on or between servers, preferrably by bot?

Can't JS be used to filter items from Recent changes? For example, I can contribute little to changes in translations. I would like to be able to exclude as many of them as possible. Similarly for edits to non-English, non-Translingual sections or entries. Even just excluding entries with non-Latin characters would be a help. DCDuring TALK 17:06, 24 October 2013 (UTC)

A bot might be able to help with archiving. They do it on Wikipedia too. But I don't really know how it's done, and I don't feel comfortable trying to parse people's posts to try to find the most recent signature date in it. The code used on Wikipedia seems reliable enough, though. Could we use it somehow? —CodeCat 17:19, 24 October 2013 (UTC)
I was also thinking about maybe using javascript to add a button. That way it would still be half manual. --WikiTiki89 17:41, 24 October 2013 (UTC)
See [[user:Conrad.Irwin/beerArchiver.js]].​—msh210 (talk) 19:11, 24 October 2013 (UTC)
Even a modest experiment would be useful in surfacing problems or in showing that anticipated problems are not common ones.
For the archiving, I'd vote that discussion sections themselves be archived to talk pages. But a link on the talk page to the appropriate section of the appropriate archive subpage would be OK. No link means the discussion will probably never be seen again. In some cases that seems like a good idea, but it seems like bad policy.
Also, I assume that we would want access to such a tool to be limited to admins, whitelisted, or registered users, maybe whitelisted for starters? DCDuring TALK 19:21, 24 October 2013 (UTC)
Re filtering changes to pages with non-Latin characters in their titles: Try this JS:
mw.config.get("wgPageName") === "Special:RecentChanges" && $(function(){
  var $t = $( this ), text = $t.find(".mw-title a").text();
  if( /[^\x00-\x80]/.test( text ) ) {
--Yair rand (talk) 21:50, 24 October 2013 (UTC)
And here's a hastily thrown-together script for filtering out translations added with WT:EDIT:
mw.config.get("wgPageName") === "Special:RecentChanges" && $(function(){
  var $t = $( this ), comment = $t.find(".comment").text();
  if( $t.find( ".comment a[title=\"Wiktionary:EDIT\"]" ).length && /^\(t\+[a-z-]{2,7}\:/.test( comment ) ) {
(Sorry about all the duplication.) --Yair rand (talk) 22:08, 24 October 2013 (UTC)
I've noticed on other occasions, too, IIRC, that you use boolean && function instead of either if boolean then function or boolean ? function. How come? Is it faster? Or is this just a personal preference? Or what?​—msh210 (talk) 03:50, 25 October 2013 (UTC)
@msh210: First of all, x ? y isn't actually a thing. That'll just give a syntax error. I assume you're thinking of x ? y : z, and the reason I don't use that is because there isn't actually a second possible value that would be useful to return. The only reason I use && instead of if(){} where possible is because it saves a couple characters. There's no performance benefit as far as I know. --Yair rand (talk) 21:17, 27 October 2013 (UTC)
  • Patrolling Recent Changes is no big deal. What I used to do is, at the start of every session, look at Recent Changes from the ending time of my last session (hiding patrolled edits). Edits by the same user or IP tend to get clustered together, so you only have to look at a few of each to see if they are OK or not. If I had time I would mark good ones as patrolled. For obvious vandalism I would issue a block and revert or delete. For honest bad edits I would just revert / delete. If you could persuade ALL sysops to do the same, then the amount of work each had to do would be very little. Cheers. SemperBlotto (talk) 07:22, 25 October 2013 (UTC)
    Indeed. The total number of English contributions by those not whitelisted or better seems quite low. Which is good because the JS doesn't seem to exclude as much as I'd like. DCDuring TALK 10:54, 25 October 2013 (UTC)


Lua seems to have made a big splash since I was last here (this is Lua, right?), and so I don't have a grasp on how expensive it is, and how careful we have to be about editing it. I'd like to change the transliteration of chi ξ (ks) from "x" to "kh". Can I just go ahead and change it, and if someone doesn't like it we can just edit back and forth into eternity (with a few flame wars on the BP, various third partys' talk pages, etc. thrown in for good measure), or would that cause the Wiktionary servers to explode, sending transistor shrapnel into innocent bystanders? Alternatively, should I make a proposal, wait for a week while everyone ignores my proposal, and then proceed to edit and subsequent edit war? -Atelaes λάλει ἐμοί 04:46, 27 October 2013 (UTC)

It's not a big deal (any more than editing a template that is). DTLHS (talk) 04:49, 27 October 2013 (UTC)
This being the Grease pit, DTLHS has given you the technical answer; but I can't help but wonder about the rest of your comment. By "chi ξ (ks) from 'x' to 'kh'" you must mean "xi ξ (ks) from 'x' to 'ks'", right? Because the module already transliterates chi χ (kh) as 'kh'. —RuakhTALK 06:33, 27 October 2013 (UTC)
(Also — in general, yes, you should make a proposal before changing a behavior seen on who-knows-how-many pages; but in this case, if you mean what I think you mean, then you're just fixing a transliteration module that fails to conform to the relevant policy page, so I don't think that really requires discussion. Just be sure to include an edit-summary explaining what you're doing.) —RuakhTALK 06:36, 27 October 2013 (UTC)
Yep, that's the one. Thanks.  :-) -Atelaes λάλει ἐμοί 06:41, 27 October 2013 (UTC)
I don't think it's a good idea to transliterate ξ with "ks" rather than "x". "x" is unambiguous and familiar from Greek loanwords in English, and "ks" should be reserved for κσ (e.g. ἔκστασις (ekstasis, displacement)). —Aɴɢʀ (talk) 22:25, 27 October 2013 (UTC)
I disagree. To begin, let me reiterate the point I feel compelled to repeatedly make when discussing transliterations. If you are already cognizant of it, I hope you'll forgive me. Our transliterations do not need to losslessly capture the word, such that one could recreate the original script from them; we have the original script, and it's always right next to any of our transliterations. The sole purpose of our transliterations is to give a quick and dirty pronunciation approximation for the uninformed. So, let's admit right off the bat that the transliterations serve absolutely and utterly no purpose for those who know Greek script (you and I, for starters). I now have a bad habit of mentally filtering them out, such that it takes me awhile to note mistakes in them (or not quite mistakes, but things that run contrary to my preferences). However, when I come upon OCS, Sanskrit, or Old Armenian words, which are written in scripts that I haven't yet learned, it's kind of handy to get a rough gist of how that word sounds. With that in mind, we need to imagine how an average English speaker is going to interpret various characters in such a context. Take the letter "y", for example, which I have so ardently, and thus far successfully, argued against using for anything in Ancient Greek transliterations. "Y" does not have a consistent sound in the English language. It stands for one consonant sound, and at least three vowel sounds that I can think of. Critically, none of these sounds is terribly dominant; it's not as though there is an "orthodox" vowel sound of "y" and the rest are exceptions. Consequently, if an English-speaker finds a "y" in a transliteration, it's quite unpredictable how they'll take it, and chances are they'll take it pretty far from the truth. "U", on the other hand only really has two vowel sounds, one is fairly close to upsilon's, and one which admittedly isn't. However, I think that, in the context of a transliteration, the average English speaker is more inclined to envision the long "u" sound /u/ (the one close to upsilon) than the short "u" sound /ʊ/. Additionally, it's fairly robust. It doesn't change dramatically when put at the end of a word and it works well in diphthongs (quite unlike "y" on both counts). The two possible transliterations of ksi have a similar story, if admittedly rather less pronounced. "x" is fairly consistent in pronunciation, though there are a few possibilities such as /tʃ/, and English speakers tend to do /z/ at the beginning of words, after xylophone. "ks" does not suffer these problems, and it is illustrative of the merging of merging of k and s sounds that ksi genuinely represented to the Greeks. Words like ἔκστασις (ekstasis, displacement) certainly do exist, but they are rare. In the majority of cases, a kappa followed by a sigma is converted to a ksi.
All that being said (I still have a long way to go towards my mastery of being laconic), please do feel free to disagree. I've gotten far too used to getting my way with Ancient Greek here, and could probably use some resistance. -Atelaes λάλει ἐμοί 23:10, 27 October 2013 (UTC)
Still, it might be useful sometimes for one of our readers to perceive or express, through transliteration, the fact that ἔκστασις, ekstasis, is spelled differently than ἔξοδος, exodos.
For detailed pronunciation we have IPA and audio, and transliteration can’t capture many non-English pronunciations at all. A main purpose of transliteration in this dictionary is as a surrogate for a term’s original written form (more so for alphabetic scripts than logographic ones, I guess). Transliteration renders written form accessible for readers who don’t know another writing system or whose device won’t display it.
This is a very good kind discussion. We should establish our criteria and priorities for transliteration systems, because what we have put into practice varies wildly. Michael Z. 2013-10-28 00:49 z
I agree with Atelaes. "x" is much more ambiguous than "ks", as, for one thing not already mentioned, it is used in our Russian transliterations for /x/ for reasons that could just as easily apply to Greek. Also, I can hardly imagine someone caring about the difference between "ξ" and "κσ", while not knowing enough of the Greek alphabet to be able to tell them apart. --WikiTiki89 04:19, 28 October 2013 (UTC)

AWB cuts off categories at 25 000Edit

Say I want to find out which entries in Category:French verb forms don't use {{fr-verb-form}}. I can't do it because it cuts off at 25 000 which is part way through C, so everything alphabetically later than that is ignored. Trying the same for for Italian and {{head|it|verb form}} I didn't even get to the end of A! Is there a tool somewhere that allow all entries in a category, no matter how big, to be put into a text file? Mglovesfun (talk) 11:14, 28 October 2013 (UTC)

  • I think it is category.py - in your python directory on your PC. I've never used it though. SemperBlotto (talk) 11:17, 28 October 2013 (UTC)
  • There is a bash script, written by User:ArielGlenn, but you need a Linux/Unix environment to run it. --flyax (talk) 15:54, 28 October 2013 (UTC)
Linux is in the Unix family of operating systems, which is surprising because unix can't have children. Ha ha! Haplogy () 16:56, 28 October 2013 (UTC)
This is perfect, thank you. Mglovesfun (talk) 13:23, 29 October 2013 (UTC)

Diff radio buttons on history pagesEdit

This has been bugging me for over a year already. On the History pages, the radio buttons are not updated when I click one, thereby not a allowing me to move the second radio button down even after having moved the first one down. To get around this I've been having to click a random link and then click the back button. I assume it is some sort of JavaScript bug and may be related to some gadgets I have enabled).

Is this a global issue, or just me? --WikiTiki89 17:08, 28 October 2013 (UTC)

The same has been happening to me for some time. Firefox/Opera on Fedora here. — Ungoliant (Falai) 17:23, 28 October 2013 (UTC)
I've had analogous problems, with my screen looking a lot better when I was not logged in. I had some luck with User:Yair rand, who has JS knowledge. See the thread on his talk page. What he fixes for you may help clean up residual minor problems for me. I might be able to "like" people's edits, for example. (Perhaps he could improve my vision.) DCDuring TALK 17:25, 28 October 2013 (UTC)
Somehow after all this discussion, the issue got fixed! --WikiTiki89 04:41, 31 October 2013 (UTC)
Not only that, but pages are loading faster for me. Clearly someone fixed something... --WikiTiki89 04:49, 31 October 2013 (UTC)
Credit goes to User:Kephir. :) --Yair rand (talk) 05:07, 31 October 2013 (UTC)
…and the reason it does, I already figured this out back in September. I think we seriously need to thoroughly go over our scripts, modernise them and fix bugs. Keφr 06:03, 31 October 2013 (UTC)
I've just realized that the show/hide radio buttons in page histories are the wrong way round. That's why when I tried to hide a load of revisions it told me I wasn't trying to change anything so it produced an error message; when I then clicked 'Visible' on all the revisions I wanted to hide, it worked. D'oh. Mglovesfun (talk) 13:55, 1 December 2013 (UTC)

In other languagesEdit

See also: Wiktionary:Feedback#Menu "In other languages"

A feedback user complained that the font used to display "In other languages" (on the Front Page) is nasty. I agree. Can we make it more like the others? SemperBlotto (talk) 08:13, 31 October 2013 (UTC)

Indeed, how did that happen? Mglovesfun (talk) 11:40, 31 October 2013 (UTC)
I see nothing bizarre happening to fonts. (ULS/WebFonts again? You two are not listed in the MediaWiki:Common.js WebFonts killer opt-in. Maybe the time has come to enable it globally?) Keφr 12:16, 31 October 2013 (UTC)
Comic Sans burns my eyes! Michael Z. 2013-10-31 14:47 z
I agree that WebFonts has been a disaster. We should open up a vote to disable it. --WikiTiki89 12:35, 31 October 2013 (UTC)
It's nothing to do with WebFonts, it happens even for me. (Unless it's some new thing our script doesn't cover yet...) -- Liliana 13:23, 31 October 2013 (UTC)
Front page looks fine to me in Safari 6.1/Mac. Can everyone please explain what it looks like, what font their browser is using, or supply a screenshot? What OS/browser is the problem appearing in?
ULS web fonts behaviour just changed today, so it doesn’t add font-family styles to text that we style. The web fonts killer might not be necessary any more. Details at Bug 54453Michael Z. 2013-10-31 14:38 z
I'm seeing the small "nasty" font with Chrome 30 (Windows 7). Firefox 25 & IE 10 are ok.
It's happening only in the "In other languages" section in the sidebar (the interwiki links), not just at the main page, but at all pages that have interwikis.
Not only en.wikt is affected: other Wiktionaries, Wikibooks, Wikisource, Wikiversity, Commons, Wikispecies, Wikinews, Wikiquote, Wikivoyage also; Wikipedia is ok though. Zooming a bit (110%) gives normal characters. HTH. -- Curious (talk) 23:02, 31 October 2013 (UTC)
It's Bug 56346, they've known about it for two days or so. --Yair rand (talk) 00:55, 1 November 2013 (UTC)
Explanation of the font: The Autonym Font for Language Names — Wikimedia blog.
Use the default font by adding #p-lang div.body ul { font-family: sans-serif; } to your common.css your vector.css (I haven’t tested this). Or try turning on font antialiasing on your system.
It renders just fine on Safari 6.1/Mac, Firefox 25/Mac, and Chrome 30/Mac. Michael Z. 2013-11-01 15:14 z
The code is intentionally broken, probably to discourage people from trying to workaround this (remember, it's a feature, not a bug). There is no element with the class "body" anywhere. -- Liliana 19:45, 1 November 2013 (UTC)
Still using Monobook? Keφr 19:55, 1 November 2013 (UTC)
Monobook has a div class="pBody" where vector has div class="body". The untested fix for Monobook might be #p-lang div.pBody ul { font-family: sans-serif; } in your your monobook.css. Likewise Modern, but Cologne Blue has different HTML. Michael Z. 2013-11-01 20:04 z

How can I edit the *text* of a category page?Edit

I asked at the Information Desk, but got no response... https://en.wiktionary.org/wiki/Wiktionary:Information_desk#Category:Japanese_language

The Edit button (rather mysteriously) just provides a list of interwiki links, and there is no trace of the actual text.

(If this is not the right place to ask, please point me in the right direction!) Imaginatorium (talk) 15:52, 31 October 2013 (UTC)

All the text there is actually generated by the call to {{langcatboiler|ja|fam=Japonic|Japan}}. It might be complicated to just edit it. What changes did you want to make? --WikiTiki89 16:05, 31 October 2013 (UTC)
  • Hi Imaginatorium, this is a fine place to ask, as is the info desk. Sorry you were ignored. As WikiTiki89 said, the text is generated formulaically by some code which is invoked on the category page with the text {{langcatboiler|ja|fam=Japonic|Japan}} which is near the top. To address your concerns posted in the earlier thread, I agree that it is strange or maybe just wrong to write Hiragana and Katakana with capital letters, and usually people do use the term "kanji" when referring to Han characters used in Japanese. I have taken a look at the code and it looks easy to change the text by editing {{langcatboiler/description}}. Another editor may jump in at this point and say that it's not, but probably this is something doable. Haplogy () 16:27, 31 October 2013 (UTC)
Follow-up: I've made the changes. Haplogy () 13:29, 5 November 2013 (UTC)

Sorting problem with Ancient GreekEdit

It seems that Ancient Greek words having an initial capital vowel with iota subscript aren't sorted correctly. See the words ᾍδης and ᾨδεῖον in their category. --flyax (talk) 21:41, 31 October 2013 (UTC)

Last modified on 29 December 2013, at 16:45