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. —RuakhTALK06:34, 4 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
@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}}). —RuakhTALK07:11, 4 October 2013 (UTC)[reply]
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? DCDuringTALK16:22, 5 October 2013 (UTC)[reply]
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.) —RuakhTALK19:26, 5 October 2013 (UTC)[reply]
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. DCDuringTALK21:27, 5 October 2013 (UTC)[reply]
"A script on this page is causing Internet Explorer to run slowly" on library computer[edit]
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. DCDuringTALK16:14, 7 October 2013 (UTC)[reply]
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. —CodeCat16:29, 7 October 2013 (UTC)[reply]
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. DCDuringTALK17:44, 7 October 2013 (UTC)[reply]
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. —MichaelZ. 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? DCDuringTALK22:14, 7 October 2013 (UTC)[reply]
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. DCDuringTALK22:24, 7 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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. DCDuringTALK01:01, 9 October 2013 (UTC)[reply]
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. —CodeCat02:13, 9 October 2013 (UTC)[reply]
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. DCDuringTALK02:41, 9 October 2013 (UTC)[reply]
@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.) —RuakhTALK02:43, 9 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. —CodeCat22:36, 12 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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
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 (talk • contribs) 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.) —RuakhTALK16:31, 26 October 2013 (UTC)[reply]
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. -- 76.65.131.21706:15, 19 October 2013 (UTC)[reply]
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. -- 76.65.131.21704:35, 21 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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 . . . —RuakhTALK16:36, 20 October 2013 (UTC)[reply]
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)[reply]
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.
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)[reply]
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.) —RuakhTALK16:57, 20 October 2013 (UTC)[reply]
@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.DCDuringTALK19:47, 20 October 2013 (UTC)[reply]
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. —CodeCat19:39, 20 October 2013 (UTC)[reply]
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. —CodeCat19:45, 20 October 2013 (UTC)[reply]
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. --WikiTiki8920:58, 20 October 2013 (UTC)[reply]
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)[reply]
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. —CodeCat12:36, 21 October 2013 (UTC)[reply]
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). --WikiTiki8915:10, 21 October 2013 (UTC)[reply]
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). --WikiTiki8916:31, 21 October 2013 (UTC)[reply]
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. —CodeCat16:34, 21 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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. —CodeCat13:21, 22 October 2013 (UTC)[reply]
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)[reply]
(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)[reply]
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. —CodeCat16:15, 24 October 2013 (UTC)[reply]
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)[reply]
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. —CodeCat19:11, 24 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Can't get some alternative forms display correctly[edit]
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):
forms["pres_futr_2sg2"] = args["pres_futr_2sg2"]
forms["pres_futr_2sg2"] = prefix .. "сы́пешь"
forms["pres_2sg2"] = forms["pres_futr_2sg2"]
if forms["pres_2sg2"] and not perf then alt_pres_2sg = forms["pres_2sg"] .. ", " .. forms["pres_2sg2"] end
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)[reply]
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. —CodeCat23:08, 20 October 2013 (UTC)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
Russian nouns with inflections reported as missing it[edit]
Because the headword is missing the inflections. The category could be removed until the number is brought down to a more manageable number? —CodeCat21:43, 22 October 2013 (UTC)[reply]
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)[reply]
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:
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. —CodeCat00:24, 23 October 2013 (UTC)[reply]
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.
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)[reply]
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. —CodeCat12:26, 23 October 2013 (UTC)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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.) —RuakhTALK23:59, 23 October 2013 (UTC)[reply]
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)[reply]
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. --WikiTiki8918:36, 23 October 2013 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
Headers and shortcuts for Beer Parlour, Grease Pit, etc[edit]
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/JulyWiktionary:Beer parlour/2013/July.
Automated assistance or performance of maintenance tasks[edit]
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. DCDuringTALK17:06, 24 October 2013 (UTC)[reply]
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? —CodeCat17:19, 24 October 2013 (UTC)[reply]
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? DCDuringTALK19:21, 24 October 2013 (UTC)[reply]
Re filtering changes to pages with non-Latin characters in their titles: Try this JS:
mw.config.get("wgPageName") === "Special:RecentChanges" && $(function(){
$("table.mw-enhanced-rc").each(function(){
var $t = $( this ), text = $t.find(".mw-title a").text();
if( /[^\x00-\x80]/.test( text ) ) {
$t.hide();
}
});
});
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)[reply]
@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)[reply]
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)[reply]
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. DCDuringTALK10:54, 25 October 2013 (UTC)[reply]
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 ξ(x) 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)[reply]
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 ξ(x) from 'x' to 'kh'" you must mean "xiξ(x) from 'x' to 'ks'", right? Because the module already transliterates chi χ(kh) as 'kh'. —RuakhTALK06:33, 27 October 2013 (UTC)[reply]
(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.) —RuakhTALK06:36, 27 October 2013 (UTC)[reply]
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. ἔκστασις(ékstasis, “displacement”)). —Aɴɢʀ (talk) 22:25, 27 October 2013 (UTC)[reply]
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 ἔκστασις(ékstasis, “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)[reply]
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. —MichaelZ. 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. --WikiTiki8904:19, 28 October 2013 (UTC)[reply]
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)[reply]
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).
Quite possibly. The lines that reference a variable in Ruakh's Tbot script could cause the JS to break if the script hasn't finished loading by the time those lines are run. Do you get any error messages? --Yair rand (talk) 19:11, 28 October 2013 (UTC)[reply]
Uncaught TypeError: Object 50 has no method 'getElementsByTagName' -- index.php?title=MediaWiki:Gadget-FastRevert.js&action=raw&ctype=text/javascript&16104807:37
The last one was probably the issue. Fixed, I think. (Also fixed the UTCLiveClock bit. I thought we had already changed over all the gadgets to use protocol-relative URLS?) --Yair rand (talk) 20:00, 28 October 2013 (UTC)[reply]
You fixed something (my fonts are no longer broken), but the history pages (and now the edit pages) are still broken, despite Ruakh's attempt to fix it. Here are my current errors:
You seem to have fixed the edit page now. But the History radio buttons still don't work, with only those first two errors remaining. --WikiTiki8920:12, 28 October 2013 (UTC)[reply]
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.) DCDuringTALK17:25, 28 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
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φr12:16, 31 October 2013 (UTC)[reply]
Comic Sans burns my eyes!—MichaelZ. 2013-10-31 14:47 z
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)[reply]
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 54453. —MichaelZ. 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)[reply]
Use the default font by adding #p-lang div.body ul { font-family: sans-serif; } to your common.cssyour 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. —MichaelZ. 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)[reply]
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. —MichaelZ. 2013-11-01 20:04 z
How can I edit the *text* of a category page?[edit]
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)[reply]
Done. [[не к месту]] looks right now. Please revert, and/or let me know, if you see any problems anywhere. —RuakhTALK 07:23, 4 October 2013 (UTC)
