Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
Jump to: navigation, search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

It is said that while the classic beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives +/-
2006
2007
2008
2009
2010
2011
2012
2013
2014


Contents

July 2014[edit]

Loading entry data in JavaScript[edit]

I was thinking of having pregenerated entries stored somewhere on Wiktionary so that those entries could instead of being mass-uploaded by a script on demand (which is objectionable on various grounds) be generated on a mouse click on a green link like those Pinyin entries (e.g. from translation tables, also stealing pagename and a translation table gloss for a stub translation), which is much more interactive and appealing to editors. Is it feasible? We're talking about few dozen MB of textual data per language, much lower if some kind of runtime decompression binary->text is possible. Data should be stored centrally as a simple dictionary, key=lemma content=entry or, at worst, I could have it uploaded on subpages e.g. {entryname}/langcode/data, which could then be script-deleted when used. --Ivan Štambuk (talk) 10:40, 1 July 2014 (UTC)

If we could do this then why bother having "regular" entries at all? DTLHS (talk) 20:04, 1 July 2014 (UTC)
Well Wiktionary should evolve into a fancy interface for some structured storage (WikiData, what else), where every data item is properly tagged and can be independently queried by its attributes and relationships in Lua and JS. But the technology still isn't there yet...
Anyway, the simplest working solution seems to be plain ajax + storing everything in a database with CORS-enabled REST interface. --Ivan Štambuk (talk) 21:03, 1 July 2014 (UTC)

Lua error: not enough memory[edit]

At . Appears to be caused by Module:och-pron, although I'm not sure how to fix it. Wyang (talk) 12:37, 1 July 2014 (UTC)

And that, folks, is why depending on Lua for critical structure like inflection lines or even simple links is a bad idea. -- Liliana 18:22, 1 July 2014 (UTC)
No, that is why shoving 600K of data into one page on which even the syntax highlighter screams in agony is a bad idea. Loading it with mw.loadData instead of require seems to have helped, but if we do not manage this data responsibly, there is another disaster waiting to happen here. User:Wyang and User:kc_kennylau, you should follow the example of Module:languages and Module:Unicode data and split this. Keφr 19:27, 1 July 2014 (UTC)
If there is some way to group the characters, then you can split it the way we've done with Module:languages/data. --WikiTiki89 19:44, 1 July 2014 (UTC)
Well, the easiest way would be to divide it into pages of contiguous code point numbers, since the data seems to be assigned to individual characters and accessed as such. Keφr 19:51, 1 July 2014 (UTC)
That's one way, but the downside is that humans don't know the code points and thus won't be able to find the correct page. The work around is to add a JS text box to a disambiguation page, where you would type in the character and press a button and it would take you to the correct subpage. --WikiTiki89 19:55, 1 July 2014 (UTC)
Thanks! There seem to be problems with mw.loadData in Module:zh and Module:zh-usex. For example, the functions in {{zh-new}} (Pinyin, ts-conversion) relying on Module:zh no longer work, and {{zh-usex}} is not working on . @Kephir: How could this be fixed? Wyang (talk) 23:42, 1 July 2014 (UTC)
Hi guys. Just saw this conversation. I reverted Kephir's change to Module:zh as it now made things worse by causing module errors when using subst:zh-new. JamesjiaoTC 23:48, 1 July 2014 (UTC)
I was going to complain about {{zh-new}} not working (see this revision of 君主制, which failed to generate pinyin) . If Module:zh is "improved", it shouldn't break the stuff that's working. --Anatoli (обсудить/вклад) 23:51, 1 July 2014 (UTC)
Note to self: mw.loadData tables do not play well with mw.ustring.gsub. Note to User:Wyang: when you have a single character in a variable, using mw.ustring.gsub to look it up in a table is completely unnecessary. Just index the table. (There were also some arguably legitimate uses of gsub there, but I changed these.) Keφr 05:16, 2 July 2014 (UTC)
Also, User:Wyang: I noticed that in all these Chinese modules you often forget to declare variables as local. Which means they become globals, and they are not garbage-collected after they they stop being used. Which probably contributes to the memory problem. Keφr 10:10, 2 July 2014 (UTC)
OK, thanks. Wyang (talk) 23:50, 2 July 2014 (UTC)
Well, there are now 120 module errors that seem to be due to your removing a variable, but not changing all the references to it in the code. I'm not quite sure how your rewrite is supposed to work, so I can't fix it myself with my limited knowledge of Lua. Could someone correct this obvious error that's been sitting there untouched for over a most of the day? Chuck Entz (talk) 00:16, 4 July 2014 (UTC)
Eventually fixed, by Kc kennylau‎ and Wyang. Thanks! Chuck Entz (talk) 17:24, 4 July 2014 (UTC)
Hi again guys. I am not sure exactly why the Chinese pronunciation section is erroring out on . JamesjiaoTC 03:39, 3 July 2014 (UTC)
It was wrong Jyutping. Fixing now. --Anatoli (обсудить/вклад) 03:49, 3 July 2014 (UTC)

User:Wyang, I warned you about large pages causing problems, and now you upload Module:zh/data/och-pron-ZS, which is more than twice the size of the previous culprit? [[]] already fails to render. Keφr 10:59, 5 July 2014 (UTC)

Could you please demonstrate how it should be split by codepoint? I'm not sure how it should be done. What's an acceptable size for a split page? Wyang (talk) 11:06, 5 July 2014 (UTC)
When I created the Unicode character names list, I split the Unicode database into contiguous pages of 4096 (0x1000) code points each. This makes an individual page contain no more than 30K of Lua source code. My aim was having it below 50K or 100K (compare Special:Longpages), so I was rather satisfied. To access this list, I use the lookup_name function in Module:Unicode data. The most important fragment here being:
function export.lookup_name(codepoint)
	-- ...
 
	local success, data = pcall(mw.loadData,
		('Module:Unicode data/names/%03X'):format(
			math.floor(codepoint / 0x1000)
		)
	)
 
	if success then
		return data[codepoint] or ("<U-%06X>"):format(codepoint)
	else
		return ("<U-%06X>"):format(codepoint)
	end
end
where codepoint is a numeric value of the Unicode code point, which you can extract with mw.ustring.codepoint. You may even use metatables to create a proxy table which does something like that in the __index metamethod; it may save you some code rewrites, though I think they are due anyway. Just a caveat (I doubt it will be relevant here, but here it is): for the Unicode database I usually only need to get names for a handful of characters, or a contiguous block, which means I only have to load up to four or something data subpages, and usually only one. In your case, I guess accesses will be more spread out; if you keep running into out-of-memory errors, you will probably need to make pages even smaller. And do not expect it to work on a mass scale. Processing hundreds (or maybe even tens) of words in this module is rather out of the question. Keφr 11:56, 5 July 2014 (UTC)
@Kephir: Thanks for the explanation. Working now. Wyang (talk) 02:37, 7 July 2014 (UTC)

Converting WT:Information desk to monthly pages[edit]

Moved to WT:Beer parlour/2014/July#Converting WT:Information desk to monthly pages

Bare subpages as destinations for discussion section links?[edit]

Shouldn't a watchlist link to a section of a discussion page take one to a page that appears like the entire page - or at least has more orienting context for newer users rather than ultra-terse abbreviations? It now has the look of something designed by insiders for insiders, probably because that's what has happened. DCDuring TALK 11:35, 2 July 2014 (UTC)

I failed to parse the first sentence. Keφr 11:42, 2 July 2014 (UTC)
I think what he means is that in the watchlist, we should have links to Wiktionary:Beer parlour whenever any of the subpages are edited, rather than to the specific subpages. I have mixed about this. And regardless, it will be very difficult on the technical side. --WikiTiki89 13:37, 2 July 2014 (UTC)
That is what I meant. Isn't that the way it worked until recently — or did I just now notice the newish header because it was the beginning of the month? DCDuring TALK 15:34, 2 July 2014 (UTC)
No, it hasn't been like that since before we started using monthly subpages. --WikiTiki89 15:47, 2 July 2014 (UTC)
@Wikitiki89: Has it been like that continuously since we started using monthly subpages? DCDuring TALK 19:01, 2 July 2014 (UTC)
What newish header? The watchlist link points to the page that has been edited, simple as that. Changing it would be nonsensical. Half the reason for these monthly subpages is that one can open a page with a much smaller number of discussions and not overtax their browser. Keφr 16:57, 2 July 2014 (UTC)
@Kephir: The minimalist subpage header makes sense to us because we know what GP, BP, et al mean. I don't object to it as a subpage header, but I was under the impression that the link from, for example, the watchlist page went to a page that appeared the same as the page did before we had subpages. I thought that it was only on click-to-edit would we go to the subpage, via the edit box. In other words, the existence of the subpages was only apparent because users could sometimes start a discussion on the main page, which is not intended to have actual content. DCDuring TALK 19:01, 2 July 2014 (UTC)
The monthly subpages are pages like any other. Since this is where the actual discussions are located, they are added directly to the watchlist. Simple. And the inter-room navigation is a quite recent addition. Keφr 19:08, 2 July 2014 (UTC)
The only way you can see more than one month is to go to the main page for the discussion forum, such as Wiktionary:Grease pit, which has the necessary transclusions and altered edit links to create the illusion that it's all one page. The only time the main forum page shows up in your watchlist listing is when an edit has been made to that page- the software that does the watchlist has no way to know that the pages are related or linked in any way. It's true that the watchlist membership for the main pages has been extended to the subpages by fooling the system into sort of thinking they're the same page through some tricky deleting/moving/restoring maneuvers, but the links are always to the page where the actual edits have been made. This has been true ever since the subpages were implemented.
Not that it makes much difference to non-regulars, since they would normally go to the main page for the Information Desk to start with, and the doctored edit links would create the topic in the monthly page where we would want it to be. The only irregularity is when they follow the link from the watchlist- and I assume they would generally be more interested in the content they're checking out than in the details of the page name. There would be some difficulty in figuring out how to manually link to a topic from elsewhere, though. Chuck Entz (talk) 01:37, 3 July 2014 (UTC)
So I just hadn't noticed before, because the top of the subpage was not visible to me either because it was above the section of interest or because I was "more interested in the content" and didn't notice. And, in any event, there's no currently known way to make the subpage architecture completely invisible at the beginning of the month, such as by substituting a link to the main page presentation for the link to the subpage. I suppose there would be a way, but it doesn't seem worth the apparently substantial trouble. DCDuring TALK 01:53, 3 July 2014 (UTC)

Template:t-check and Template:t-needed[edit]

Previously: Wiktionary:Beer parlour/2014/January#Proposal to change how translation checks and requests are formatted

Some time ago WT:EDIT has been edited to use {{t-needed}} instead of {{trreq}}, while keeping compatibility with the latter. Likewise, xte has been changed to mark suspicious translations with {{t-check}} instead of marking the language header with {{ttbc}}. No problems have arisen since then. Shall we migrate {{ttbc}} and {{trreq}} to the new format? Keφr 13:51, 3 July 2014 (UTC)

I support doing this by orphaning the old templates and replacing them with the new ones. But we would need to look at the entries in Category:Language code is name, as the replacement would mean using "und" as the language code for these translations. —CodeCat 15:51, 3 July 2014 (UTC)
I've managed to fix about a third of the things in Category:Language code is name/ttbc/unrecognised. The things in Category:Language code is name/trreq look like they can be bot fixed without difficulty. Hopefully nothing, or very few things, will have to use "und" as the language code. - -sche (discuss) 04:20, 7 July 2014 (UTC)
Support. This will fix the issue where the translation-adder (WT:EDIT) breaks down if you try to add a translation and it falls in alphabetical order next to a ttbc, right? - -sche (discuss) 04:20, 7 July 2014 (UTC)
Oh, that has been fixed already. The main issue here is more straightforward markup: only the thing that actually needs checking is denoted as such, and the markup for the "translation request" case corresponds a bit more intuitively to the rendered text. I think even DP should be okay with this (jugding from his last reply here; though you never know). Starting up my bot. Keφr 07:43, 7 July 2014 (UTC)
{{trreq}} has been orphaned. {{ttbc}} will take a bit longer, though. Keφr 18:47, 7 July 2014 (UTC)
More than half of {{ttbc}} transclusions have been converted. The task is somewhat tricky though, and some items will probably have to be dealt with manually. Keφr 07:47, 9 July 2014 (UTC)

Linkrot in IP Contributions Page Footer[edit]

Someone earlier fixed the footer displayed at Special:Contributions for regular accounts, but there's a different footer for IPs, which is showing the effects of the Toolserver phaseout. Could someone fix it, please? Chuck Entz (talk) 17:33, 4 July 2014 (UTC)

{{anontools}}. Keφr 18:58, 4 July 2014 (UTC)

Rhymes adder doesn't set lang parameter[edit]

I notice that the rhymes adder (the "add new rhyme" function accessed via rhymes pages like Rhymes:English:-ɪpsi) does not specify lang=. I believe a bot goes around and adds lang= to entries which it notices are missing it, but this seems like working harder not smarter. Couldn't we simply adapt the rhyme-adding code to pull the language from the title of the page the rhyme is added via (Rhymes:English:-ɪpsi)? - -sche (discuss) 18:27, 4 July 2014 (UTC)

Worse yet, the "add new rhyme" function, which is not supposed to add the rhyme to the entry page if it's already present, does add the rhyme to the entry page if the entry page uses {{rhymes|lang=en}} as opposed to {{rhymes}} alone. In other words, if I add tipsy to Rhymes:English:-ɪpsi using the "Add new rhyme" button, then if tipsy already has {{rhymes|ɪpsi|lang=en}} on it, {{rhymes|ɪpsi}} will be unnecessarily added to the page (though the page is left untouched if {{rhymes|ɪpsi}} is already present). —Aɴɢʀ (talk) 19:01, 4 July 2014 (UTC)
I tried to make some minor adjustments to User:Yair rand/rhymesedit.js, but I don't know if that fixed it. Please test it. —CodeCat 19:17, 4 July 2014 (UTC)
It seems to work. It doesn't add a new "rhymes" line to a page if one is already present, regardless of whether or not the pre-existing "rhymes" line has lang= set. And it does add a "rhymes" line to a page if one doesn't already exist. - -sche (discuss) 01:40, 7 July 2014 (UTC)

template:suffix and Hebrew hyphens[edit]

{{suffix|lang=he|בֵּן|וֹ|tr1=ben|tr2=o}} generates:

<i class="Hebr mention" lang="he">[[בן#Hebrew|בֵּן]]</i> (<span lang="" class="tr mention-tr">ben</span>) +&lrm; <i class="Hebr mention" lang="he">[[־ו#Hebrew|־וֹ]]</i> (<span lang="" class="tr mention-tr">־o</span>)

Note that the character before the suffixed o is U+05BE. This is an error: it should have the standard hyphen-minus character. (It is correct, however, to have U+05BE before the וֹ and the ו, as above.) I'd fix it, but don't know how to edit the module to do so. Can someone please? Note also that the other functions in the same module may need similar adjustment.​—msh210 (talk) 05:49, 6 July 2014 (UTC)

Why is the normal hyphen correct in this case, but not in some other cases? —CodeCat 10:32, 6 July 2014 (UTC)
Because it's part of the English-transliteration string -o, not a Hebrew-language Hebrew-script string.​—msh210 (talk) 23:42, 6 July 2014 (UTC)
I think I understand. What you're saying is that the hyphen should be transliterated too? —CodeCat 00:01, 7 July 2014 (UTC)
Yes, from U+05BE to a hyphen-minus character. That's the way the template used to work. (Note also that the current way displays terribly.)​—msh210 (talk) 02:50, 7 July 2014 (UTC)

{{look}}Can someone please do this? As mentioned, the templates displays badly now (at e.g. [[בנו]]). Pinging CodeCat: you're the one who converted the template to use the module, and you're the one who's done most of the editing of the module. You should test when you write code that's to be used live (and perhaps you did), but at the very least should fix a bug when informed of it.​—msh210 (talk) 16:21, 9 July 2014 (UTC)

Yes check.svg Done (diff). The bug was introduced by User:Kc kennylau in this edit. --WikiTiki89 16:57, 9 July 2014 (UTC)
Thank you! And my apology to CodeCat for the above tirade. Striking this section and nowikiing the look template.​—msh210 (talk) 20:46, 10 July 2014 (UTC)

Chinese interwiki warnings[edit]

I oppose Chinese interwiki warnings as with 赫茲, which is a traditional form of 赫兹. Traditional and simplified forms in Chinese are considered the same word. Even if the Chinese Wiktionary may only use one form (simplified forms are more common), a traditional form will redirect to simplified and a traditional form may be for a Japanese term. Missing interwikis will not allow users to look up terms on sister projects. It's just the way Chinese wiki works. So, please make an exception for Chinese interwikis, which is also made for translations into Chinese (i.e. use of {{t+}} when only the other form exists). --Anatoli (обсудить/вклад) 23:27, 6 July 2014 (UTC)

I gather you added [[zh:赫兹]] as an interwiki to 赫茲, and were warned by the filter that discourages people from adding interwikis to non-identical pagetitles. I don't know that there's a feasible way for the filter to recognize and make exceptions for trad—simp pairs without allowing other things that aren't desirable (e.g. vandalistic addition of links to zh:暴君 to , or additions of translations as interwikis). And even if there were a way to make the filter make such exceptions, the bots which maintain our interwiki links remove links that aren't to the same pagetitle, so the links would still get removed, unless all of the bots were also updated with the massive list of allowable trad—simp correspondences... all of which is asking a bit much. I say the onus is on zh.Wikt to make use of redirects from the trad forms to the simp forms, or vice versa (whichever set of forms they centralize the content on), so that we can have interwiki links to those redirect pages, so that users get to the content in the end. We ourselves already make use of redirects like this to accommodate such things as fr.Wikt's use of curly apostrophes (and fr.Wikt reciprocally makes use of redirects to accommodate our use of straight apostrophes). - -sche (discuss) 01:34, 7 July 2014 (UTC)
Yes, it was [[zh:赫兹]] as an interwiki to 赫茲. That would be a pity if the interwiki were removed by a bot. I don't know how Chinese redirects work (or searches) but [[zh:赫兹]] would/should match an existing Chinese redirect, even if it redirects to [[zh:赫兹]] (a simplified form). --Anatoli (обсудить/вклад) 01:49, 7 July 2014 (UTC)
There are various forms of phrases on enwikt, some of which hard redirect and others of which soft redirect. Same for things like color and colour. There are various (plene and defective) spellings of Hebrew words, where hewikt and enwikt have different entries; enwikt soft-redirects between them and hewikt hard-redirects. We handle all of these the same way: we interwiki only between the exact titles, and let the redirects work. (As -sche pretty much has stated.) I don't see justification in the above discussion for making an exception for Chinese. (I'm not saying no such justification exists: I don't know. But it hasn't been voiced here yet AFAICT.)​—msh210 (talk) 02:54, 7 July 2014 (UTC)
Just to clarify that our English wiki entry 赫茲 has an interwiki to the same title [[zh:赫茲]] on the Chinese Wiktionary. The redirect is handled on the Chinese side. The justification, if one is needed, is that Chinese and English wiktionary shows both trad. and simpl. forms on each form but the Chinese Wiktionary usually has only one, e.g. simplified zh:赫兹], which displays (or supposed to) both forms and has all linguistic info there. I see no problems in having interwikis to redirects, same with French, Hebrew, etc. --Anatoli (обсудить/вклад) 04:09, 7 July 2014 (UTC)

Indentation and RQ templates[edit]

I have just now discovered that when an RQ template is used in a line starting with ##* then the extra indentation doesn't happen. For example, when this is used for a second level quotation, it actually takes the displayed text back to the first level as far as numbering is concerned. Would someone with the necessary skills please fix this.—ReidAA (talk) 05:47, 7 July 2014 (UTC)

This request doesn't seem have attracted any attention. Maybe I should give an example. So:

  1. This is a sense.
    1. This is a second level sense.
      • This is a simple second level quote.
      • So is this.
      • 1960, P. G. Wodehouse, Jeeves in the Offing, chapter V:
        This should be a second level quote with an RQ template.
      • This is a simple second level quote (should be an unnumbered quote of the second level sense).
      • So is this.

I hope this makes the problem clearer—ReidAA (talk) 08:45, 8 July 2014 (UTC)
Hmm, compare this:

  1. This is a sense.
    1. This is a second level sense.

The difference is that {{RQ:Wodehouse Offing}} uses {{quote-book}}, so that seems to be where the/a problem lies. I vaguely recall problems with indentation being noticed in the past. Pinging User:Robin Lionheart who's edited the template heavily in the past, and User:Visviva who fixed the previous problem with indentation, in case they know how to fix it. - -sche (discuss) 19:27, 8 July 2014 (UTC)

Thanks very much for your response! Of course, the problem doesn't seem to be simply with the {{quote-book}}:

  1. This is a sense.
    • This is a simple quote.
    • So is this.
    • 1066, William, I came:
      This is a quote with a quote-book template.
    • This is a simple quote.
    1. This is a second level sense.
      • This is a simple second level quote.
      • So is this.
      • 1066, William, I came:
        This is a second-level quote with the same template.
      • This is a simple second level quote.
      • So is this.

That's probably why the problem hasn't been cleaned out already. I hope User:Robin Lionheart will be able to fix it.—ReidAA (talk) 22:28, 8 July 2014 (UTC)   Or User:Visviva (sorry; I overlooked him/her, though I now see that the single message on User:Visviva suggests (s)he has become inactive).—ReidAA (talk) 03:08, 9 July 2014 (UTC)

Trying out Template:wgping: (pinging: Keφr, Yair rand, CodeCat, Ruakh, Kenny, ZxxZxxZ from workgroup technical). - -sche (discuss) 02:11, 13 July 2014 (UTC)
It's fixed !! Great !!!! Many thanks to whoever managed it. Maybe this item (and the related one in the Information Desk) should now be crossed out, if someone who knows how could do that, please. — ReidAA (talk) 09:55, 13 July 2014 (UTC)
'Twas Kephir who fixed it, with diff. I just checked, and as of the last database dump, Template:RQ:Wodehouse Offing is the only RQ template that used an explicit "#*". Who knows why it did. - -sche (discuss) 16:39, 13 July 2014 (UTC)

The new lemmas that are popping up.[edit]

I'm actually in favour of them, and the way to get a word on the list for the respective language seems to be to update the entry. However it doesn't seem to work with some entries with outdated headings, so the only way to cure that seems to be to rewrite them, altering them to {{head|nb| or whatever. I did this with linje, and it's now on the lemma list. On the other hand, I didn't do it with stoff (Bokmål) and stoff (Nynorsk), and it hasn't appeared on the lemma list. Both entries' headings will have to be updated, and the same may be true with entries in other languages. Donnanz (talk) 18:19, 8 July 2014 (UTC)

I'm a bit confused about the edit you made. Why didn't you update the template instead? In the discussion you had with me you mentioned replacing form-of templates with others because of not displaying the correct text, rather than fixing the templates themselves. I wonder, is there something you have in principle against fixing templates, and instead prefer to work around using them in strange ways? (I don't mean this as any kind of attack, I just don't understand your thought process here) —CodeCat 18:40, 8 July 2014 (UTC)
Which edit are you referring to - linje or stoff? Donnanz (talk) 18:44, 8 July 2014 (UTC)
linje. You replaced the normal Norwegian headword template - which should presumably be used on all applicable entries - with a rather large and unwieldy call to {{head}}. —CodeCat 18:47, 8 July 2014 (UTC)
I agree with CodeCat. Why didn't you just fix the template or ask someone else to fix the template? Clearly that would be a much cleaner and easier solution than just throwing the template away because one thing in it is broken. --WikiTiki89 18:48, 8 July 2014 (UTC)
  • OK. I am highlighting a problem, and I get shot down in flames about templates. If templates need fixing, someone will have to do it. I don't regard it as my job. Donnanz (talk) 18:56, 8 July 2014 (UTC)
    We didn't say it was your job. You could have highlighted the problem without making the destructive edit to linje. --WikiTiki89 18:58, 8 July 2014 (UTC)
    The edit was hardly destructive. It works rather well. As for the template used for stoff, you can sort that out. Donnanz (talk) 19:04, 8 July 2014 (UTC)
    Obviously it works well, but it defeats the purpose of having templates if we're gonna go write everything out anyway. --WikiTiki89 19:21, 8 July 2014 (UTC)
    If a template acts incorrectly or in an undesired way, it is altogether fitting and proper to avoid using it (using plain wikitext or a more general template like template:head instead). That is, in fact, far better than using the incorrectly acting template. Our primary concern should be how pages look to our readers, not uniformity of template use. This case is less crucial, as the template merely lacked a feature rather than acting truly badly, but the same principle applies, if to a lesser extent. Certainly, one should also bring the incorrectly acting template to the attention of someone who can fix it — and that's what Donnanz did.​—msh210 (talk) 16:29, 9 July 2014 (UTC)
    In this particular case, everything was displaying fine except that the new lemma category wasn't being added. --WikiTiki89 16:47, 9 July 2014 (UTC)
  • By the way, whoever is creating the lemmas needs to add an ABC index at the top. Donnanz (talk) 19:08, 8 July 2014 (UTC)
    No one is creating them. They get added whenever a page is purged, thus updating the templates on it. Anyway, I think the ABC index is automatically added when there are enough entries in the category. --WikiTiki89 19:21, 8 July 2014 (UTC)
    OK, if not, I have added ABC indexes before, though I'm looking for an ABC template specific to the Danish and Norwegian alphabets, i.e. including Æ, Å and Ø. Donnanz (talk) 19:36, 8 July 2014 (UTC)
    The rules for automatically adding indexes are in Module:category tree (at the bottom), and they're more or less as follows. If the category contains more than 2500 items, and a template called "xx-categoryTOC/full" exists, use that. Otherwise, if the category contains more than 200 items, and a template called "xx-categoryTOC" exists, use that. Otherwise, show nothing. This only applies to categories for a specific language, so "by language" categories never get an automatic index. This will probably be added at some point, though. —CodeCat 19:59, 8 July 2014 (UTC)
    I will try to make some sense out of that, if not, I may have to call on your services. These lemma files could grow to a massive size, as they contain all nouns, adjectives, verbs etc., in other words everything except noun forms etc. Donnanz (talk) 20:44, 8 July 2014 (UTC)
    Yes, they would basically contain a list of all the entries that can be found in a paper dictionary. That's also why it's useful, though. —CodeCat 20:52, 8 July 2014 (UTC)
    To translate that to something more useful, Danish categories get indexes because Template:da-categoryTOC exists. Norwegian Bokmål ones do not because Template:nb-categoryTOC does not exist. --WikiTiki89 02:07, 9 July 2014 (UTC)
    Thanks for finding the Danish template. Can you create the nb template, and could it be used for nn as well, or would that require yet another template? (nb/nn would be the same as the Danish one) Donnanz (talk) 07:10, 9 July 2014 (UTC)
    Can you? You know more about Norwegian than I do and you can use the Danish one as a starting point. For Nynorsk, you would have to also create Template:nn-categoryTOC (I thought that would have been obvious...). --WikiTiki89 13:43, 9 July 2014 (UTC)
    At the very least, just give me a list of the letters in the desired order and I will create the templates for you. --WikiTiki89 13:44, 9 July 2014 (UTC)
    The Danish and Norwegian alphabets are exactly the same, and have exactly the same letter order. The Danish template alphabetical order is correct, so it can be adapted without change for nb and nn. I did confirm this in the Norwegian Wikipedia (Det danske-norske alfabetet). Donnanz (talk) 14:41, 9 July 2014 (UTC)
    In that case, all you need to do is copy the code in the Danish template into the Norwegian templates, changing only the name of the category at the bottom. But if you are really that afraid to do it yourself, then ask and I'll do it for you (but I will be disappointed). --WikiTiki89 14:52, 9 July 2014 (UTC)
    You're calling my bluff, huh? OK, I've created Template:nb-categoryTOC. You had better check it before I do nn. Donnanz (talk) 17:58, 9 July 2014 (UTC)
    Looks fine! --WikiTiki89 19:27, 9 July 2014 (UTC)
  • Template:nn-categoryTOC is now done, but now I have discovered another little problem. All da, nb and nn files are sorted incorrectly as Å Æ Ø instead of the correct order of Æ Ø Å. This may have occurred years ago. Donnanz (talk) 21:46, 9 July 2014 (UTC)
    We're not able to fix that unfortunately. The software is limited to sorting by Unicode codepoint order. —CodeCat 21:47, 9 July 2014 (UTC)
    Oh I see. I guess we'll have to live with that problem. Donnanz (talk) 21:57, 9 July 2014 (UTC)

add a word[edit]

Noticed Wiktionary doesn't have the words kevlar or xray......Just to name a couple... New here...don't know how to add...

kevlarKevlar
x-rayX-ray
--Catsidhe (verba, facta) 04:25, 10 July 2014 (UTC)

Template with raw link[edit]

Category:Template with raw link/ga-noun contains over 1500 entries, and as far as I can tell, there's nothing wrong with any of them. Template:ga-noun includes the following code:

{{#if:{{isValidPageName|{{{1}}}}}||[[Category:Template with raw link/ga-noun]]}}
{{#if:{{isValidPageName|{{{2}}}}}||[[Category:Template with raw link/ga-noun]]}}

Now Template:isValidPageName says it's deprecated and will soon be deleted and should be removed. Can I simply delete the two above lines of code from {{ga-noun}} without breaking anything? —Aɴɢʀ (talk) 16:12, 13 July 2014 (UTC)

I think it's done via a module now, which may or may not be Module:links. I think it (isValidPageName) needs to be replaced not removed. Renard Migrant (talk) 16:27, 13 July 2014 (UTC)
The template is fine, but there was a bug in the code you pasted above. I fixed it now, and it looks like the category is emptying out slowly. —CodeCat 16:35, 13 July 2014 (UTC)

Template:quote-web[edit]

This template breaks the numbering of definitions and doesn't play well with quote-hiding. See rape culture and "what links here" for instances. DCDuring TALK 22:20, 13 July 2014 (UTC)

Probably because of the explicit "#*" it contains (compare Wiktionary:Grease pit/2014/July#Indentation_and_RQ_templates). - -sche (discuss) 00:13, 14 July 2014 (UTC)
Now it works, though there has been no net change in the template. Changes not in the template seem to be the cause. I miss the days when sometimes folks would own up to having caused this kind of thing. DCDuring TALK 00:48, 14 July 2014 (UTC)
Apparently the problem was a glitch in a tidying of {{cite meta}} that was done earlier today. DCDuring TALK 00:53, 14 July 2014 (UTC)

Template:wikimedia language name seems incomplete[edit]

Hi,

{{wikimedia language name|nrm}} should return "Norman" according to Wiktionary:Wikimedia language codes, isn't it? (Current result: "Narom") — Automatik (talk) 01:13, 14 July 2014 (UTC)

(general questions, not specifically for Automatik:) What is the difference between Template:wikimedia language and Template:wikimedia language name? Template:wikimedia language contains some things that Template:wikimedia language name and Wiktionary:Wikimedia language codes don't; do the latter need to be updated? - -sche (discuss) 01:34, 14 July 2014 (UTC)
For the first question: it seems {{wikimedia language name}} take a code and returns a language name whereas {{wikimedia language}} take a code and returns a wikimedia code. — Automatik (talk) 12:50, 21 July 2014 (UTC)

"Show-hide" boxes that are full width[edit]

I have noticed that we have templates that insist on occupying the full width of the frame whether or not they need to. This has the effect of forcing white space to appear when there are right-hand side elements, especially images. An offending template that I noticed today is {{hy-noun-ի-եր}} as used in [[սեխ]].

What is the cause? What is the remedy? How can I help apply the remedy? DCDuring TALK 12:58, 20 July 2014 (UTC)

What white space? I see no white space. --Vahag (talk) 22:20, 20 July 2014 (UTC)
See screenshot at Talk:սեխ. DCDuring TALK 22:49, 20 July 2014 (UTC)
I don't think the boxes are forcing anything- if they weren't there, the right-hand elements would be in exactly the same position relative to the left side of the screen, with the same amount of white space. The boxes simply fill the available space- with the size of the available space being determined by other elements on the page. Chuck Entz (talk) 00:23, 21 July 2014 (UTC)
I think he means the whitespace between the ===Declension=== heading and the declension table. --WikiTiki89 00:27, 21 July 2014 (UTC)
Thank you. Yes.
Also, the Old Armenian declension template on the same page didn't seem to have the same problem when I inserted an image. It simply rendered a narrower declension table, leaving room for the image. DCDuring TALK 00:31, 21 July 2014 (UTC)
Perhaps it has something to do with the right-hand TOC, which is pushing the other right-hand elements down the page: perhaps the Javascript that's moving the TOC box is running after the code that sizes the collapsible box. Chuck Entz (talk) 00:39, 21 July 2014 (UTC)
@Chuck Entz: That's a good hypothesis, so I tested using {{tocright}} at User:DCDuring/Sandbox. {{rel-top}} behaves the way I think a well-behaved show-hide template should, despite the rhs ToC. DCDuring TALK 01:40, 21 July 2014 (UTC)
You have a point. In preview mode, I just moved the declension template up to where the dialect alternative forms box is, and it refused to share horizontal space with the image in the same place where the {{rel-top}}-based box behaved correctly. The declension template does, indeed, behave differently. Chuck Entz (talk) 03:35, 21 July 2014 (UTC)
I'm guessing that it's CSS, but almost anyone has a better idea about this kind of thing than I do. DCDuring TALK 04:55, 21 July 2014 (UTC)
It looks like <div class="NavFrame" style="width:100%"> in {{hy-decl-noun}} is the culprit. I created {{hy-decl-noun-test}} without the style parameter, and {{hy-noun-ի-եր-test}} to use it in the entry. The box behaves nicely when collapsed, but has an annoying way of overlapping with the Wikipedia box when you uncollapse it. Even worse, the Wikipedia box displays on top of the declension table, which could hide some of the content. I'm sure that's why the difference is there. Chuck Entz (talk) 05:42, 21 July 2014 (UTC)
I took the liberty of changing {{hy-decl-noun}}. Please revert if it misbehaves. DCDuring TALK 11:51, 21 July 2014 (UTC)
OK, but why this? --Vahag (talk) 12:16, 21 July 2014 (UTC)
Sorry. That was a quick test that I thought was only in preview mode and not saved. DCDuring TALK 14:32, 21 July 2014 (UTC)
  • Am I correct that if a template intended for use in an entry uses NavFrame directly or indirectly and NavFrame width is "too wide", eg, 100%, then it does not play well with images, project-link boxes, and right-hand side tables of content? DCDuring TALK 20:32, 21 July 2014 (UTC)

POS TOC[edit]

I notice that the TOC for categories with a shitton of pages has aa, ab, ac, etc, and it has æ and œ, but it doesn't have 1, 2, 3, 4, 5, 6, 7, 8, 9 and 0, even though some POSes have hundreds of entries that start with those. Where does one go to fix this? Purplebackpack89 21:45, 21 July 2014 (UTC)

The answer is actually above in #The new lemmas that are popping up. But to save you some reading time, each language has its own TOC. The English one is: Template:en-categoryTOC for smaller categories and Template:en-categoryTOC/full for large categories. --WikiTiki89 22:45, 21 July 2014 (UTC)
I have added 0-9 for Template:en-categoryTOC/full and the 10th, 11th and 12th parameters to Template:Cattoc Purplebackpack89 23:02, 21 July 2014 (UTC)

User page filter[edit]

Seriously. Whenever I try to edit anyone else's user page, the filter always says my edit was unconstructive, even if the edit actually was clearly not vandalism or anything and was trying to help. I think we should get rid of this dumb filter, because the filter is getting on my last nerve. I can't even edit the user pages of my own backup accounts unless I log into those accounts.

If we don't want people editing other people's user pages, we should just protect everyone elses' user pages from ability to edit. I believe Pikipedia, the Pikmin Wiki website, has already found a way to do this, since they apparently don't want people editing user pages there that aren't your own.

So here are some suggestions:

  1. Make it clear that there is a rule about editing other users' user pages somewhere in Wiktionary's namespace.
  2. Lock all user pages from others so that others can't edit them, instead of using a filter, if we don't want people editing user pages.
  3. Let's just forget the entire idea of restricting edits on user pages and get rid of the filter altogether and let people freely edit user pages, as this is a "free, collaborative dictionary". Rædi Stædi Yæti {-skriv til mig-} 23:32, 22 July 2014 (UTC)
You hit this filter like, four times and you are already bloodthirsty? Chill, mate.
Previous discussions:
Anyway, since nearly all (if not all) vandalism hits for this filter have been from IPs and brand-new accounts, I have lowered the rights threshold to confirmed. Keφr 08:50, 25 July 2014 (UTC)

cmn user templates playing up[edit]

User:Ready Steady Yeti advised me that Babel with {{User cmn-3}} now displays two cmn, before it was showing a red link, even if the template existed. Not sure what's happening there. --Anatoli T. (обсудить/вклад) 23:40, 22 July 2014 (UTC)

What happened in my eyes was that the template zh-3 was before missing on Anatoli's user page as a red link, but either when someone pressed the save page button on Anatoli's user page, or the template was recreated somehow, the template now redirects to cmn-3, furthermore making his babel repeat the "cmn-3" box twice. Rædi Stædi Yæti {-skriv til mig-} 23:47, 22 July 2014 (UTC)
Just edit {{User zh-3}} if you don't want it to redirect to cmn. DTLHS (talk) 00:02, 23 July 2014 (UTC)
Thanks, done. Recreated Category:User zh. --Anatoli T. (обсудить/вклад) 00:13, 23 July 2014 (UTC)

Edit filter to prevent bad sh L2's[edit]

Can we add a filter to disallow "Serbian", "Croatian" and "Bosnian" as L2s? Chuck Entz (talk) 14:04, 24 July 2014 (UTC)

There is one already: "THL". It only tags for now, but that can be changed. If you are going to flip the switch, I suggest adding an explanatory warning too. Keφr 14:11, 24 July 2014 (UTC)

Updating legacy scripts[edit]

(pinging: Keφr, Yair rand, CodeCat, Ruakh, Kenny, ZxxZxxZ from workgroup tech)

For a quite a bit of time, I have been drafting plans to modernise JavaScript modules on Wiktionary; deprecate loads of shabby code and replace them with something faster, more modern and reliable; turn scripts scattered around people's user space into proper gadgets. The plans have grown quite ambitious, and I will most probably not carry them out at once, nor in the nearest future, and I hope not alone. But to make some preparations at least, I came up with an idea to move most of our scripts from MediaWiki:Common.js into a separate gadget, enabled by default, which individual editors could then turn off. The rationale being that it would aid in developing the replacements in a more "vanilla" environment, avoiding interference between the new and old scripts.

But truth is, I am not sure what would be the side effects of that. Scripts could run faster or slower, race conditions may start appearing which we have not noticed before, we might get missing symbols (like newNode some time ago), older browsers may stop working. So, this is a bit risky. Shall I go with it? Keφr 13:25, 25 July 2014 (UTC)

I think some temporary minor problems are worth the risk, and I think you are competent enough to handle it. —CodeCat 13:26, 25 July 2014 (UTC)
I performed the move. Nothing seems to break yet. It even feels a bit faster, but I am not sure if this is ResourceLoader magic, or just a perception.
I left in only three enhancements: "add section" link redirection, &withmodule= query parameter and WT:Preferences/V2, my intended replacement for WT:PREFS (whose preference page you can test without logging out by using the aforementioned &withmodule=). Disabling the "legacy scripts" gadget now will break collapsible inflection tables, so I do no recommend doing that. Unless you want to develop a replacement script for that — which I am planning to do, but I am not so sure if I will fulfil this plan. Keφr 15:36, 26 July 2014 (UTC)
As for the collapsible inflection tables, see also mw:MediaWiki:Gadget-collapsibleTables.js, which is now rasonably similar to the one used on English Wikipedia, and consider using the default jQuery.makeCollapsible plugin instead of a local implementation. Helder.wiki 13:49, 27 July 2014 (UTC)
Thanks, but I think we will have to keep around a custom "collapsibles" script anyway; we also have collapsible quotations, which cannot be made so merely by slapping a CSS class on them. Keφr 15:07, 27 July 2014 (UTC)

After editing a page with duplicate headings[edit]

Page 'all' has three 'Translations'. After editing #Translations_2, clicking 'Save page' went to #Translations, not #Translations_2. History entry '→‎Translations' also linked to #Translations. (JS disabled.) Jisok (talk) 03:29, 27 July 2014 (UTC)

That always happens. If you edit a "Noun" section in one language, and there's another "Noun" section for another language higher up the page, when you click "Save" you'll be taken to the highest "Noun" section on the page, even if it's not the one you just edited. It's a little annoying, but not really bad, since the correct section was edited. —Aɴɢʀ (talk) 07:05, 27 July 2014 (UTC)

Gothic declension templates are acting out[edit]

Some or all of the Gothic noun inflection-table templates are causing the entries where they're transcluded to be categorized into Category:Terms with manual transliterations different from the automated ones/got. Not sure why, or how to fix it. —Aɴɢʀ (talk) 12:25, 27 July 2014 (UTC)

It's because the Gothic headword line templates add a link to the transliteration. You can ignore it though. —CodeCat 12:38, 27 July 2014 (UTC)
Of course you can ignore it, but it makes the cleanup category useless, since you can no longer use it to find terms that genuinely need cleaning up. —Aɴɢʀ (talk) 14:32, 27 July 2014 (UTC)
All the entries that can be ignored are in Gothic script though, so it's not that much of a problem to sift them out. —CodeCat 14:35, 27 July 2014 (UTC)

Update to xte[edit]

I have updated the list of pages at User:Kephir/t.love. It has not changed much since the last Buttermilch run. Unfortunately, I cannot see much pattern in the current dumps, which means that the remaining translations will have to be dealt with manually. Many of them use some bizarre hybrid markup - half of the translation is inside {{t}}, the other half is not. Or a two-word SOP translation with each word under {{t}}.

But the good news is, xte has been updated to deal with this case too. It has to be noted that these cases have to be reviewed more carefully than usual. So if you feel sad and lonely and in need of filling your time with an utterly brain-dead activity, here is your chance. Open one of the subpages of User:Kephir/t.love, load it into the xte basket (xte menu → "Add links on this page"), Alt-Shift-], Alt-Shift-\, review, Alt-Shift-s, Alt-Shift-], Alt-Shift-\, review, Alt-Shift-s, Alt-Shift-], Alt-Shift-\, review, Alt-Shift-s…

Keφr 15:41, 28 July 2014 (UTC)

What would Freud say about "have to be death with"? —Aɴɢʀ (talk) 16:20, 28 July 2014 (UTC)
"A sure sign of deeply repressed homosexual urges", of course. Either that, or "indication of unconscious lust for the poster's mother". Or both. Keφr 17:43, 28 July 2014 (UTC)

Category TOCs, collapsible rows in a table?[edit]

I noticed that with the new lemma categories, some of them take a long time to load. I found the culprit, and it's the line I commented out here. The mw.site.stats.pagesInCategory function is very slow; it make the page take up to 4 seconds for Category:English lemmas, compared to 0.1 seconds with the code commented out.

This code is used to determine whether to display an alphabetic index ("table of contents" is a rather bad name for these) like {{en-categoryTOC}} or {{en-categoryTOC/full}}, and which one to display depending on how large the category is. I don't think there is much doubt that we should get rid of mw.site.stats.pagesInCategory, but it means that we would have to show the index template regardless of how many entries are in a category, and we can only have one of them, rather than the current standard one and longer one, as there is no way for the module to determine which to use (because it can no longer count entries).

So I'm wondering if we could use the longer version as the base, but make the extended part collapsible. By default it would show only the basic alphabet, but clicking the expand button would show the rest. Is this possible, and if so, how? —CodeCat 19:53, 28 July 2014 (UTC)

Before we do that, is there any faster way to determine the size or approximate size of a category? (Also note that mw:Extension:Scribunto/Lua reference manual#mw.site.stats.pagesInCategory mentions that this function is expensive.) --WikiTiki89 20:01, 28 July 2014 (UTC)
I don't think so. That function is the only one available in Scribunto for counting in categories. It's the Lua equivalent of the magic word {{PAGESINCATEGORY:(name)}}, which is also expensive. This magic word is what {{catboiler/toc}} used before it was converted. —CodeCat 20:07, 28 July 2014 (UTC)
I can see why it would be expensive to count the exact current number of entries, but it seems like it would be pretty easy to add a cached size to categories that may not always be current, but would be good enough for determining the type of TOC. But I doubt we'd be able to convince the developers to do that. On the other hand, does it really matter that it is so slow? The only time it runs is when updating/purging the category page. --WikiTiki89 20:13, 28 July 2014 (UTC)
It's actually so slow that it has caused timeouts on a few occasions. And it's also slow just to view the page, by any user. Is the minor convenience of changing the TOC really worth a 40 fold increase of load time? Especially when there are alternatives? —CodeCat 20:21, 28 July 2014 (UTC)
No it's not worth it. But why does it affect page load time? --WikiTiki89 20:25, 28 July 2014 (UTC)
I'm not sure but I think that caching works differently for content generated through templates/modules. I've noticed before that loading a page with a slow template/module, and then loading it again, gives intermittent results. —CodeCat 20:33, 28 July 2014 (UTC)
CodeCat's idea seems promising, minimizing the loss of content space on the visible landing page while speeding page loading. I hope that it actually works as intended. The big (eg, 40x) benefit would be limited to really large categories, not those with mere thousands of members.
But where does the N come form in "The following 200 pages are in this category, out of N total." DCDuring TALK 20:25, 28 July 2014 (UTC)
I think that number is probably cached. Why templates and scripts don't use that cache, I'm not sure. But that's not really something we can change anyway. And yes you're right, the benefit would be less for smaller categories. But those are the ones that don't need those big index tables anyway. —CodeCat 20:33, 28 July 2014 (UTC)
Maybe it's all cached, but the cache gets invalidated often for big categories, like "English lemmas". I suppose it wouldn't be updated incrementally, but recomputed from scratch.
The only loss is a tiny (I hope) loss in content-available screen space, which can be annoying for really small (ie, one-page) categories. IOW, please make the index the smallest horizontal format that you can. DCDuring TALK 21:17, 28 July 2014 (UTC)
I'll try, but right now the question is how to make it partly collapsible. —CodeCat 21:19, 28 July 2014 (UTC)
Here's what I think: All category members must be found when updating the Category's cache, so the number of members is available at that time for use in the 200 of N. However, the {{PAGESINCATEGORY:(name)}} and mw.site.stats.pagesInCategory are meant to find the number of members of any category when loading any page, and thus does not take advantage of this when counting the members of the current category being loaded. There are things the devs could do (if we can convince them): either make {{PAGESINCATEGORY:(name)}} and mw.site.stats.pagesInCategory run faster when requesting the category from the category page itself or create a new function that does only this and works only from the category's own page. --WikiTiki89 21:26, 28 July 2014 (UTC)
(pinging: Keφr, Yair rand from workgroup JS) Can you help out? —CodeCat 22:37, 28 July 2014 (UTC)

Sanskrit transliteration[edit]

Why is Sanskrit no longer automatically transliterated by {{l}}, {{m}}, and {{t}}? —Aɴɢʀ (talk) 20:23, 28 July 2014 (UTC)

This edit did it. I have no idea why Ivan did that though. —CodeCat 20:36, 28 July 2014 (UTC)
The module overrides the more accurate transcription in IAST so I turned it off. It was a dumb idea to have it in the first place. --Ivan Štambuk (talk) 20:45, 28 July 2014 (UTC)
But the module generated the IAST transcription; how is the user-written one more accurate? Anyway, I've been removing Sanskrit transliterations left, right, and center for several weeks now because they were being generated automatically, and now all those forms are left without any translit at all. Couldn't manual translits override the automatic translits, but automatic translits still appear when no manual is provided? That would at least be better than no translit at all when there's no manual one, which is what we have now. —Aɴɢʀ (talk) 21:05, 28 July 2014 (UTC)
Automatic transliterations don't have stress marks, but that's the only problem I can think of. —CodeCat 21:18, 28 July 2014 (UTC)
Of course they could. The language code just needs to be removed from the list in Module:links. The "override_translit" list has been greatly expanded some time ago, I have no knowledge why. Keφr 21:26, 28 July 2014 (UTC)
The generated transliterations don't have accent marks and don't separate members of compounds. You need to undo all of your edits. --Ivan Štambuk (talk) 22:08, 28 July 2014 (UTC)
The stress marks on Sanskrit entries/translations were rare, I don't know who added them and how reliable they are. I personally haven't removed any transliterations with stress marks. The problem is - 1. it's not very common to have stress marks in dictionaries, 2. Devanagari script is not marked with stresses, 3. we lack a dedicated, knowledgeable Sanskrit speaking editor. As I suggested before, a system with invisible stress marks could be employed (like invisible spacing (ja and zh), capitalisation (symbol ^) and hyphens with Chinese, Japanese and Korean transliterations). Of course, care should be taken not to break consonant conjuncts and the original script otherwise. --Anatoli T. (обсудить/вклад) 22:24, 28 July 2014 (UTC)
Undoing my edits isn't an option at this point. I've been doing this for weeks if not months, usually in combination with removing several other redundant transliterations from translation tables at the same time. For Cyrillic, I've been dutifully moving the stress mark onto the Cyrillic before deleting the translit, but for Sanskrit the stress mark just gets lost. It isn't really all that crucial anyway; having it on the entry page itself is probably sufficient. —Aɴɢʀ (talk) 22:29, 28 July 2014 (UTC)
This is an example of an edit I have no intention of undoing, especially since the Sanskrit entry didn't provide stress marks in the first place. But now those Sanskrit words are without any translit at all. That's why it would be better if manual translits overrode automatic ones, but if automatic translits appeared when no manual one was present. —Aɴɢʀ (talk) 22:33, 28 July 2014 (UTC)
Yes, I agree it's not crucial, having a standard IAST transliteration is more important than non-standard with stress marks. Besides, it seems hard to verify the accuracy of the stress. If I don't know the stress, say for Bulgarian, I just leave it unstressed. Can anyone say, which Sanskrit dictionary provides stress marks? I've seen them in a Sanskrit textbook and here but not in dictionaries I've seen. I have restored automatic transliteration for Sanskrit in Module:languages/data2 but it's not mandatory - not in "override_translit" list in Module:links. --Anatoli T. (обсудить/вклад) 22:40, 28 July 2014 (UTC)
I do think the stress marks are important. According to w:Vedic accent, there is a native way to transcribe the accent. I think we should use it as it would simplify transliteration. —CodeCat 22:47, 28 July 2014 (UTC)
@Atitarev: Accent marks are a part of IAST, read here p. 13. --Ivan Štambuk (talk) 22:57, 28 July 2014 (UTC)
@Atitarev: Pretty much all Sanskrit dictionaries mark accents, either in Devanagari or Latin transcription. Having accents marked in Devanagari is not an option due to many different conventions used in various texts, the difficulty to type them, and the lack of font support. Accents are important and have to be marked. It's absurd to argue that they don't matter, or that they are not reliable (do you think that they were guessed by editors who added them?). Devising an obscure secondary system with invisible stress marks and whatever in Devanagri is similarly absurd. Why not just type it in Latin instead? Jesus. --Ivan Štambuk (talk) 22:49, 28 July 2014 (UTC)
I can see that in Wiktionary the stress marks are rather rare, it's not easy to find words marked with accents. OK, they do matter but who will maintain them - who is the Sanskrit editor? As for invisible accent marks, I'm actually suggesting this - e.g. use संस्कृत́ (saṃskṛtá) with an invisible acute accent on Devanagari word, visible here, which would link to संस्कृत (saṃskṛtá) (without the acute accent on Devanagari word) and display transliteration "saṃskṛtá" with a stress mark. --Anatoli T. (обсудить/вклад) 23:00, 28 July 2014 (UTC)
Anyway, this dispute should be over now. Module:sa-translit will now provide automatic transliteration only when the manual is missing. It can also be used to add a more standard manual transliteration with a stress mark (using preview). --Anatoli T. (обсудить/вклад) 23:09, 28 July 2014 (UTC)
We don't necessarily have to faithfully represent all the stress marks, as we add them to many words that never had them in the original text. So we can choose our own scheme. A very simply one is to use the vertical "udātta" mark for stress, and mark nothing else. —CodeCat 23:23, 28 July 2014 (UTC)
Accent are only marked for words for which they are unpredictable, i.e. of pre-classical Vedas. There are no instances of accents marked for words that "did not have them".
Yes, acute accent was just one idea. If there are any native means, it would be even better. We can use udātta, anudātta, svarita, etc. --Anatoli T. (обсудить/вклад) 23:45, 28 July 2014 (UTC)
There are many schemes for marking accents in Sanskrit text that employ some dozen different special marks, and it makes no sense to invent some Wiktionary-specific one that is not used anywhere, solely to impose some kind of artificial uniformity. --Ivan Štambuk (talk) 23:37, 28 July 2014 (UTC)
I think you misunderstood. You were worried about one missing symbol - acute accents marking the stress, is that right? We can still use automatic transliteration if we add one of invisible symbols (can be your choice - doesn't have to be acute accent), which would convert to áéíóú in transliterations. I don't know why are you being uncooperative, what exactly seems to be a problem, Ivan? --Anatoli T. (обсудить/вклад) 23:45, 28 July 2014 (UTC)
Three symbols - acute, grave and hyphens. The first two for accents, hyphen for compounds. I'm not being uncooperative it's just that you're trying to solve a non-issue. --Ivan Štambuk (talk) 00:14, 29 July 2014 (UTC)
We can add all three, you know :) Automatic is still far better than manual when none of those accents are present or necessary. Some hyphens may not be necessary too, etymology sections can show the compounds. E.g. Korean is now much more selective with the usage of hyphens. The "issue" was numerous Sanskrit translations without transliterations, which is now solved. --Anatoli T. (обсудить/вклад) 00:21, 29 July 2014 (UTC)
I'll maintain the accents. Just don't remove them anymore. संस्कृत (saṃskṛta) is in fact a perfect example why manual transcription is superior and irreplaceable. --Ivan Štambuk (talk) 23:40, 28 July 2014 (UTC)
Good idea to maintain the accents! Note that you can do संस्कृत (saṃskṛtá) with a manual transliteration. --Anatoli T. (обсудить/вклад) 23:45, 28 July 2014 (UTC)
Okay, so the etymology sections of both φέρω (phérō) and ferō claim that the stress of भरति (bharati) is bhárati, so I added an acute accent to its transliteration on the entry page, but then I remembered from Sanskrit class 20 years ago that finite verbs in Sanskrit are always unstressed. So why is this bhárati and not bharati? —Aɴɢʀ (talk) 14:34, 29 July 2014 (UTC)
All verbs have an inherent accent, it's just that it's often lost in some syntactical positions. bharati would mean that the verb was not recorded accented in MSS, and occurred only in classical Sanskrit works when accent was always unmarked, and turned to predictable stress. --Ivan Štambuk (talk) 07:36, 31 July 2014 (UTC)

Invoking/using templates within a module[edit]

So, is it possible? Currently, something like this won't work

return "{{term|word|lang=en}}"

this just returns text... The template is not run.--Dixtosa (talk) 17:54, 29 July 2014 (UTC)

There is a method that does this: frame:expandTemplate, but for some reason we tend to avoid using it. --WikiTiki89 17:58, 29 July 2014 (UTC)
Probably because it is usually cleaner to invoke the underlying Lua function directly. Keφr 18:11, 29 July 2014 (UTC)
If there is an underlying Lua function (which in this case there is, so it should definitely be used). --WikiTiki89 18:18, 29 July 2014 (UTC)
That was too bad example it seems :D.
Actually, What I'm trying to do is a lot different. I have several templates for the sake of simplicity call them temp-1, temp-2 and temp-3. Each of them receives different number of arguments (say, 2-4). I want to have one unified template that, based on the logic of some helper Lua module, calls appropriate template. The thing is that I'd prefer to do Lua processing rather than template one. Moreover the only template-oriented solution I can think of is ugly:

{{temp-{{#invoke:module|get_id}}|{{#invoke:module|get_first_arg}}|{{#invoke:module|get_second_arg}}|{{#invoke:module|get_third_arg}}|{{#invoke:module|get_4th_arg}}}}

Ugly in the sense that it passes unused dummy arguments.--Dixtosa (talk) 18:38, 29 July 2014 (UTC)
And why not implement the logic for the three templates in Lua too? Keφr 18:41, 29 July 2014 (UTC)
If you just want to format output, I created a template-like string processing module: Module:string utilities. For an example, scroll down to the bottom of Module:ru-noun. --WikiTiki89 18:47, 29 July 2014 (UTC)
@Kephir, well, I thought I would just use what is already written. Plus, there are ~6 not-so-small templates to be rewritten.
@Wikitiki89, that will definitely ease my life if I plan to rewrite the whole thing. Because I am too working on improving declension-related templates.--Dixtosa (talk) 20:14, 29 July 2014 (UTC)

Bot request: Interlanguage links in Rhymes namespace[edit]

I just added interlanguage links to en.wikt on de.wikt rhyme pages. Now someone could just add the backlinks over here. --Kronf (talk) 01:57, 31 July 2014 (UTC)

Already Yes check.svg Done by YS-Bot, thanks :) --Kronf (talk) 12:58, 13 August 2014 (UTC)

Orange links in tables of contents[edit]

A few hours ago, some lines in some entries' tables of contents started showing up in the same orange colour as links like kitten (links to nonexistent sections of pages). For example, the link in Courtney's TOC to "Anagrams" is orange, and the links in book's TOC to "Statistics", to "Anagrams" and to both "Synonyms" sections are all orange. Quite a large swath of iron's TOC is orange. The other links are the usual blue, and all of the links work as expected. The orange colouring only shows when I am logged in and the page has finished loading. It persists even if I clear my cache. I am using Windows 7 and Firefox 31, and I thought I had enabled the gadget that turns links to nonexistent sections of pages (like the aforementioned kitten) orange — and that link does looks orange to me — but the "OrangeLinks" box isn't checked when I go to Special:Preferences#mw-prefsection-gadgets. Checking it and clearing my cache does not, however, have any effect. - -sche (discuss) 04:43, 31 July 2014 (UTC)

I had noted the same problem, but was too lazy to report it. It seems to have gone away. DCDuring TALK 10:17, 31 July 2014 (UTC)
The OrangeLinks gadget in Preferences is a rewrite of Yair rand's version. WT:PREFS still used the old version until now, however. I redirected the old version to the new one while investigating another problem. And it has a few glitches like that. Which I have never noticed because I have Tabbed Languages enabled. (Why is it not the default yet?) Keφr 13:55, 31 July 2014 (UTC)
Because only a few editors actually prefer tabbed languages... --WikiTiki89 14:01, 31 July 2014 (UTC)
Mostly because noone's yet written a bot that sorts categories into their proper sections. There are also a few other minor blockers. --Yair rand (talk) 17:19, 31 July 2014 (UTC)
Things are back to normal now, with the tables of contents blue and links like kitten orange. Thanks. (Wait, now kitten has turned blue. Hrmf... it's orange when I preview the page, but not when I save the page.) - -sche (discuss) 17:24, 31 July 2014 (UTC)

Module help[edit]

I would like to arrange it so that, for Old Irish, templates like {{l}}, {{m}}, {{t}}, {{head}}, etc., automatically convert 'ḟ' and 'ṡ' to 'f' and 's' when making links and automatically delete '·'. In other words, I would like to be able to type {{l|sga|ra·ḟinnadar}} and have it link to rafinnadar. Is it sufficient if I add the following code:

        entry_name = {
                from = {ḟ, ṡ, ·},
                to   = {f, s}} ,

to Module:languages/data3/s under the entry for m["sga"] = {, or is there more to it than that? —Aɴɢʀ (talk) 13:38, 31 July 2014 (UTC)

You forgot the quotation marks. But otherwise yes. Keφr 13:43, 31 July 2014 (UTC)
So it should be:
        entry_name = {
                from = {"ḟ", "ṡ", "·"},
                to   = {"f", "s"}} ,

right? —Aɴɢʀ (talk) 14:06, 31 July 2014 (UTC)

Yep. Don't forget to use the "Preview page with this template" box before saving. --WikiTiki89 14:10, 31 July 2014 (UTC)
Huh? There is no preview page option on modules. —Aɴɢʀ (talk) 14:16, 31 July 2014 (UTC)
There is a text box labeled "Preview page with this template" (just control-F that text and you'll find it), which lets you preview any page with the changes to the module, so you should preview a page that contains a link such as ra·ḟinnadar (for example, this page). --WikiTiki89 14:26, 31 July 2014 (UTC)
Oh, cool, I've never used that function before. I got a module error:
Lua error: unexpected symbol near '='".

Backtrace:
1.[C]: in function "loadPackage" 
2.mw.lua:53: in function "loader" 
3.package.lua:75: in function "load" 
4.package.lua:99: ? 
5.(tail call): ? 
6.mw.lua:493: in function "executeModule" 
7.mw.lua:764: in function "loadData" 
8.Module:languages:118: in function "getRawLanguageData" 
9.Module:languages:137: in function "getByCode" 
10.Module:links/templates:52: in function "chunk" 
11.mw.lua:518: ? 

I have no idea what any of that means. —Aɴɢʀ (talk) 14:28, 31 July 2014 (UTC)

Can you copy and paste the whole Old Irish section that gave you the module error? --WikiTiki89 14:35, 31 July 2014 (UTC)
Here:
m["sga"] = {
        names = {"Old Irish"},
        type = "regular",
        scripts = {"Latn"},
        family = "cel-gae",
        sort_key = {
                from = {"á", "é", "í", "ó", "ú", "ḟ", "ṡ" , "^h"},
                to   = {"a", "e", "i", "o", "u", "f", "s"}} }
        entry_name = {
                from = {"ḟ", "ṡ", "·"},
                to   = {"f", "s"}} ,
Maybe there should be a comma after the sort_key's closing curly bracket and no comma after the entry_name's closing curly bracket? —Aɴɢʀ (talk) 14:40, 31 July 2014 (UTC)
Yes there needs to be a comma after the sort_key block. A trailing comma in the last block is optional. Also, you need to move the outer closing curly brace (the one closing the whole sga block) to after entry_name. --WikiTiki89 14:44, 31 July 2014 (UTC)
Solved it! The entry_name bit has to come before the sort_key bit. —Aɴɢʀ (talk) 14:45, 31 July 2014 (UTC)
It doesn't "have to", but it makes you not have to do what I said above. --WikiTiki89 14:47, 31 July 2014 (UTC)
I guess putting the sort_key bit last had the same effect as moving the closing curly brace to the end. But here's another twist: I'd like links to remove the hyphen "-" as well, but not if it's the first or last character in the string. In other words, for prefixes and suffixes, {{l|sga|ro-}} and {{l|sga|-us}} should link as normal, but {{l|sga|a-t·baill}} should link to atbaill. Is that doable? —Aɴɢʀ (talk) 14:49, 31 July 2014 (UTC)
Maybe, you can add a replacement from "(.)-(.)" to "%1%2". The . character acts a wildcard that matches any one character, the parentheses capture those characters and the %n represents the nth set of parentheses. But the problem is this will fail if there are two hyphens in a row (a--b), or if there are two hyphens separated by one character (a-b-c), in which cases it will only replace the first one. There might be a way around this problem, but I don't currently know what it is. --WikiTiki89 15:04, 31 July 2014 (UTC)
OK, I've done that and it works. I can't think of a case where I'd need two hyphens in a row or two hyphens separated by a single character in Old Irish anyway. —Aɴɢʀ (talk) 18:36, 31 July 2014 (UTC)
Great! By the way, WT:ASGA does not mention hyphens. What are they for? --WikiTiki89 18:42, 31 July 2014 (UTC)
It works until it breaks. Using "(.)%-%f[^%-\0]" to "%1" as the replacement would be more robust. But frankly, I would avoid relying on this substituion altogether. Why do you need it anyway? Keφr 20:47, 31 July 2014 (UTC)
Can you explain that to me? I have no idea what %f is. --WikiTiki89 21:01, 31 July 2014 (UTC)
Frontier pattern. Keφr 07:08, 1 August 2014 (UTC)
Well, I was using hyphens to show infixed pronouns, but then I remembered that nasalization of vowels also involves hyphens (i n-inis) and there the hyphen should be part of the page name, so I'm going to remove the hyphen-removing code from the module and just not have hyphens be part of the display of the infixed pronouns (e.g. {{l|sga|at·baill}} instead of {{l|sga|a-t·baill}}). It's easier to read that way anyway. —Aɴɢʀ (talk) 21:10, 31 July 2014 (UTC)
Good idea. Also, you should add the dieresis and dot characters to the sort_key (unless you want them sorted as separate letters). --WikiTiki89 21:13, 31 July 2014 (UTC)
And just for the record, the most robust way to do this would probably have been: from = "[^-](-+[^-])+", to = function(m) { return mw.ustring.gsub(m, "-", "") }. --WikiTiki89 21:21, 31 July 2014 (UTC)
Functions cannot be put into data modules, though. Keφr 07:08, 1 August 2014 (UTC)
Oh. What happens if they are? --WikiTiki89 13:55, 1 August 2014 (UTC)
The dieresis and dot characters don't get used in page names though, so they never get sorted anyway, do they? —Aɴɢʀ (talk) 21:32, 31 July 2014 (UTC)
You're probably right. I hadn't thought of that. --WikiTiki89 22:33, 31 July 2014 (UTC)

August 2014[edit]

Pages Running Out Of Time and Memory[edit]

I've been seeing a good number of pages lately in Category:Pages with module errors with module errors saying "The time allocated for running scripts has expired" or "Out of memory". It's not language-specific: I've seen it in monolingual pages of various languages (including English), as well as multilingual ones. So far, they've all cleared with a null edit, but it's a clear sign that some recent change has brought us to the limits of what the system can sustain. Does anyone have any idea what's going on? Chuck Entz (talk) 19:11, 1 August 2014 (UTC)

Those messages may also be the result of an infinite loop. Some of Kephir's recent changes may have caused them. —CodeCat 19:18, 1 August 2014 (UTC)
Non-template items are affected, too: the interwikis are showing up as redlinks to Wiktionary destinations in the entry and not in the sidebar. The language-name links from the {{etyl}} template are redlinks, as well, so it looks like everything stops before the system does some kind of link-conversion step. Chuck Entz (talk) 19:35, 1 August 2014 (UTC)
The times I've seen it, purging the page fixed it. I think it's just a random delay. @Chuck: If any module on the page takes too long, it will screw everything up that comes after it, not just that instance of the module. --WikiTiki89 23:15, 1 August 2014 (UTC)
The point is, it only started happening recently, but now it happens regularly. I was careful to say "a recent change" without being specific about whether it's in a module or in the system. The fact that I've cleared these and had new ones come back over several days is worrying.
If there is something wrong, it's going to be hard to track down, because the breaking point is where the cumulative execution time hits a certain point, which is often not the point at which the delay occurs. It might even be something minor common to multiple items on the page, which only in combination are enough to push the total over the line. Chuck Entz (talk) 00:29, 2 August 2014 (UTC)
One idea for how to troubleshoot this issue is to invoke each common module and template (in turn) in a sandbox an increasing number of times — i.e. put 100 {{l}}s in a row, then 200, etc — until a timeout error occurs with reliable frequency. If {{foobar1}} runs into an error only when invoked 200 times, but {{foobar2}} runs into one when invoked a mere 60 times, that will tell us which module is eating the most resources. Disclaimer: such testing might put strain on the servers and be a bad idea (I don't know)... OTOH, the problem itself would seem to put strain on the servers, so going through a some strain to identify the problem might be worth it in the long run. - -sche (discuss) 03:30, 2 August 2014 (UTC)
Presumably the purpose of the timeout is to avoid strain on servers. Therefore I don't think this form of testing should cause much strain. --WikiTiki89 20:50, 2 August 2014 (UTC)
OK, I tested the following:
  1. {{term|lang=en|foobar}}: Saving the page, which is still quick with up to 350 transclusions, starts to take longer once 400 transclusions are present. It takes an average of 1 min 35 sec to save the page when 4400 transclusions are on it, and it times out after an average (based on four data points) of 4240 transclusions.
  2. {{l|en|foobar}}: Saving the page is quick until about 600 transclusions, whereupon it starts taking longer. Saving the page with 4400 transclusions on it takes an average of 1 min 8 sec. I tested all the way up to 6000 transclusions and it never timed out.
  3. {{m|en|foobar}}: Saving the page is quick until about 600 transclusions, whereupon it starts taking longer. Saving the page with 4400 transclusions on it takes an average of 1 min 18 sec. I tested all the way up to 6000 transclusions and it never timed out.
  4. {{head|en|noun}}: Saving 100 transclusions takes 4 seconds; 300 takes 10 seconds; 600 takes 10 seconds; 1000 takes 20 seconds; 2000 takes 33 seconds; 3000 takes 44 seconds. Saving the page with 4400 transclusions on it takes an average of 1 min 9 sec. Even with 6000 transclusions on the page (it took 1 min 37 sec to save the page with that many transclusions on it) it doesn't time out.
  5. {{head|en|noun|g=f|plural|foobar}}: It times out after an average (based on four data points) of 4255 transclusions. After that threshold is crossed, further uses of {{head}} curiously do not all necessarily turn into red "module error" messages; sometimes, after a swatch of a few hundred module error messages, the remaining transclusions turn into simple links to "Template:head".
- -sche (discuss) 08:04, 3 August 2014 (UTC)
Next, I'll test the linking templates with more parameters set. I'm intrigued that {{term}} eats noticeably more resources than {{m}}; is there some benefit to using positional vs named parameters? I suppose I can test that by testing {{l|en|foobar||this is a gloss}} against {{l|en|foobar|gloss=this is a gloss}}. - -sche (discuss) 08:10, 3 August 2014 (UTC)
More results:
  1. {{term|lang=en|foobar|gloss=glossy}}: when 4400 transclusions are present on the page, saving the page takes an average of 1 min 53 sec, and the template times out and starts spewing module errors after an average (based on five data points) of 4050 transclusions.
  2. {{term|lang=en|foobar||gloss}}: when 4400 transclusions are present, it takes an average of 1 min 53 sec to save the page, and starts spewing module errors after an average (based on five data points) of 4092 transclusions.
  3. {{m|en|foobar||gloss}}: with 4400 transclusions present, saving the page takes an average of 1 min 37 sec. There are no module errors. Saving the page after adding enough transclusions to bring the total to 6000 takes 2 min 10 sec, and it fails in an interesting way. 5089 transclusions work just fine, and then two transclusions resolve into links to "#invoke:links/templates", and the rest of the transclusions resolve into links to "Template:m". The page finds itself in, but does not display any module errors.
  4. {{m|en|foobar|gloss=glossy}}: with 4400 transclusions present, saving the page takes an average of 1 min 37 sec; all transclusions work, there are no module errors. Saving the page after adding enough transclusions to bring the total to 6000 takes 2 min 17 sec, 5064 transclusions work, the 5065th resolves to "#invoke:links/templates", and the rest resolve to "Template:m".
It seems there is exactly no difference in how long it takes to save a page with the gloss set as a numbered parameter vs a named parameter, and there is little difference (attributable to mere noise) in how many resources each eats. It is apparent that there is, however, something about Template:term which cases it to eat more resources and fail more quickly than Template:m or Template:l. - -sche (discuss) 19:35, 4 August 2014 (UTC)
Perhaps it is the call to {{#invoke:term cleanup|cleanup}}. --WikiTiki89 19:44, 4 August 2014 (UTC)
@-sche: For comparative testing: are the contents of the links always identical and to a page that exists?
I wonder how long does it take to save a page with 300, 4400, and 50,000 bare links, piped links, bare links to section headers, piped links to section headers. DCDuring TALK 21:31, 4 August 2014 (UTC)
For all the tests of Template:l, Template:m, and Template:term, I used an identical mix of ~60% links to the English sections of the pages 1-10 and one-ten, and ~40% links to the French sections of those pages. Of the numerals, 1, 2, 4, 6 and 8 have English sections, while only the number 2 has a French section; of the words, all have English sections, while only four and six have French sections. In the wild, all of the linking templates sometimes point to entries/sections which exist, and sometimes point to entries/sections which don't. I wouldn't expect it to make a difference from the template's point of view whether the section exists, but I suppose I could test that. For the tests of Template:head, I used 50% {{head|en}} and 50% {{head|fr}}. - -sche (discuss) 21:57, 4 August 2014 (UTC)
Thanks, especially for the rationale. I subsequently realized that I can copy the exact pages you ran by looking at your userpage history, rerun some for calibration, and modify them to answer my specific questions. DCDuring TALK 00:27, 5 August 2014 (UTC)
I think I'm beginning to see a pattern: there are days when this doesn't happen at all, but today and yesterday there were quite a few. There are at least a couple of the maintenance reports at Special:SpecialPages that were updated yesterday. I think the extra load on the system might be slowing things down to the point where some of the more script-intensive pages are timing out. Chuck Entz (talk) 14:08, 11 August 2014 (UTC)
I was also making a lot of changes to modules so that might also be it. —CodeCat 14:16, 11 August 2014 (UTC)

Can Persian be added to the input keyboards?[edit]

I notice that there are input tools available for languages other than English now. Is there any chance that a Persian keyboard could be added? Kaixinguo (talk) 18:34, 3 August 2014 (UTC)

@Kaixinguo:. Do you mean MediaWiki:Edittools#Arabic? You can type in Persian (Arabic, Urdu, Kurdish) using the tool and add transliteration symbols missing on standard keyboard, e.g. â, š, ž, č and ğ. --Anatoli T. (обсудить/вклад) 02:50, 1 September 2014 (UTC)

-1[edit]

Any idea what is generating the 937 links to -1? See Special:WhatLinksHere/-1. I presume it's a template? It doesn't seem to be a problem, it's just intriguing... - -sche (discuss) 15:40, 5 August 2014 (UTC)

What all those links seem to have in common is a Scots entry. --WikiTiki89 15:43, 5 August 2014 (UTC)
It is the line {{#if:{{#ifeq:{{{1|-}}}1|-||{{#invoke:ugly hacks|is_valid_page_name|{{{1|-}}}1}}}} in {{sco-noun}} (and likely other Scots headword templates). Although I'm not quite sure how to cleanly fix it in a way that both works and does not link to something random. --WikiTiki89 15:57, 5 August 2014 (UTC)
Perhaps User:Kephir can help, since he has been working with the ugly hacks stuff. --WikiTiki89 15:58, 5 August 2014 (UTC)
Just convert {{sco-noun}} to use {{head}}. It will go away. Keφr 18:43, 7 August 2014 (UTC)
I still don't quite understand why it's generating these links. I searched the page encyclopaedia (one of the "linking" pages to -1), but I didn't find any links to "-1" on the whole page neither on the edit form or from the actual page... Strange. Rædi Stædi Yæti {-skriv til mig-} 07:22, 16 August 2014 (UTC)
Well actually, what's going on here is User:Kephir created the ugly hacks module with a is_valid_page_name function to replace the old {{isValidPageName}}, and he made the module essentially create a fake link to the page being queried. I didn't realize this before, but now I realize that this is the wrong behavior, since checking whether a page name is valid does not mean that you depend on the existence of the page, unlike checking whether a page exists, which should create a fake link. --WikiTiki89 13:33, 16 August 2014 (UTC)
And anyway, couldn't -1 be an actual entry? I can kind of see why it isn't, but isn't it at least considerable?
Also, well maybe I shouldn't be speaking since I know very little about module code, but couldn't we make it so that it links to a Wiktionary user page or something so that it's not hectic in the mainspace namespace? Something that generally is not used and maybe deleted, such as Wonderfool's old user page. (Well maybe not that, lol, but you get the idea) Rædi Stædi Yæti {-skriv til mig-} 04:21, 18 August 2014 (UTC)
If you go to one of the pages that "links" to -1, I don't think you'll find anything to click on- look at graip, for instance. The only way you can tell that anything is referencing the page is by going to the nonexistent entry and clicking on "what links here", or by looking at Special:WantedPages. It's just part of the way templates and modules check to see if a page exists, and it doesn't show up in their final output. Chuck Entz (talk) 05:20, 18 August 2014 (UTC)
Like I already explained, checking whether a page name is valid is not the same as checking whether it exists. That is why I think the something is wrong and there should not be a fake tie to the page. --WikiTiki89 14:38, 18 August 2014 (UTC)

Creating an entry for the Unicode replacement character[edit]

I just tried to create an entry at Unsupported titles/Replacement character for the Unicode replacement character. This triggered an abuse filter, so I would appreciate it if an administrator could help me. I was trying to create the page with the following text:

{{unsupportedpage|[insert Unicode replacement character here]}}

==Translingual==

{{Specials character info|hex=FFFD|name=REPLACEMENT CHARACTER|image=[[File:Replacement character.svg]]}}

# Unicode [[replacement character]], used to represent a symbol that the system is unable to [[render]].


Thanks —Mr. Granger (talkcontribs) 05:13, 7 August 2014 (UTC)

Created. {{unsupportedpage}} is not working for some reason. — Ungoliant (falai) 05:24, 7 August 2014 (UTC)
Thank you. I seem to be unable to add a link from Appendix:Unsupported titles so that it displays correctly. Help with this would also be appreciated. —Mr. Granger (talkcontribs) 05:30, 7 August 2014 (UTC)
Done as well. — Ungoliant (falai) 05:40, 7 August 2014 (UTC)

Duplicate mineral elements - fixable by bot?[edit]

I just became aware of this problem, inadvertently caused by me a while ago, where minerals' elements (auto-extracted from their chemical formulae) have been duplicated in some cases: [1]. It might only be hydrogen, or there might be other cases. If anyone with a bot and spare time feels like trying to resolve it, that would be kind! Equinox 03:37, 9 August 2014 (UTC)

Module:etymology language/data[edit]

I (and User:I'm so meta even this acronym) think that it would make etymologies more accessible (see eg οξύτονος) if Koine Greek was output by {{etyl}} rather than Koine, unfortunately my simple change to Module:etymology language/data led to new categories to be assigned. However the terms apparently derived from Koine (see Category:Terms derived from Koine) are only: Latin:1, English:0, Greek:34), which I would be happy to sort out.

Are any other effects likely? — Saltmarshαπάντηση 15:43, 9 August 2014 (UTC)
Probably not. Renaming it should be ok, as long as you monitor Category:Categories with incorrect name. —CodeCat 15:57, 9 August 2014 (UTC)
Thanks! — Saltmarshαπάντηση 16:02, 9 August 2014 (UTC)
Yeah, thanks CodeCat. — I.S.M.E.T.A. 16:40, 9 August 2014 (UTC)

A Peculiar Edit[edit]

I must be missing something obvious, but why did this edit (diff) have {{also|liriope}} display as See also: {{{1}}}? I also noticed that the list of templates below the edit window was lacking {{also}} and the module it invokes. Chuck Entz (talk) 00:23, 10 August 2014 (UTC)

I cut and paste from something that has that in it. It was not intentional and not a sign of something technically wrong. DCDuring TALK 00:32, 10 August 2014 (UTC)
If {{also}} on a page has as an argument the name of that page, it shows as you saw it. That is supposed to draw an editor's attention - and usually does. DCDuring TALK 00:40, 10 August 2014 (UTC)
[Post–edit-conflict]: @Chuck Entz: {{also}} is designed to omit self-referential links; see Template talk:also#Implement self-hiding. — I.S.M.E.T.A. 00:43, 10 August 2014 (UTC)
I corrected the ones for taxonomic names and English, but 240 or so remain. They are easy to search for. DCDuring TALK 00:49, 10 August 2014 (UTC)
@DCDuring: Do you mean like this? Wouldn't changing {{also}}'s code to this:
  • {{#if:{{{1|}}}|{{#invoke:Template:also|main}}|}}
fix this problem? — I.S.M.E.T.A. 00:59, 10 August 2014 (UTC)
I particularly like intègrerai: it was created by a WF bot five years ago, and all the edits since have been by other bots. Chuck Entz (talk) 01:12, 10 August 2014 (UTC)
Ah, that's the "something obvious" I missed. It did lead me to spot an erroneous interwiki ([[en:Template:also]]) in the template documentation. I also noticed [[Category:Limit of template reached| ]], which seems unnecessary now that the template is based on a module. Chuck Entz (talk) 01:00, 10 August 2014 (UTC)
  • Why do we insert these manually anyway? If a bot is good for anything it should be good for detecting headwords that differ only by diacritical marks and capitalization or other orthography. There is some need to avoid duplication between what appears in {{also}} and under the Alternative forms header. DCDuring TALK 02:14, 10 August 2014 (UTC)
    I agree. I agitate from time to time for bot implementation of {{also}}. Somewhere around here I had a fairly detailed proposal for it, which I'll find if anyone is interested. - -sche (discuss) 03:32, 10 August 2014 (UTC)
    Here was the proposal to make existing {{also}} links symmetrical: Wiktionary:Grease pit/2012/July#symmetric_use_of_Template:also. And here was the proposal to "create {{also}} links between any pagetitles which are identical except that one contains character(s) with diacritic(s) and the other contains the same character(s) but with different or no diacritic(s)": Wiktionary:Grease pit/2012/August#Template:also_links_by_letter_decomposition. It was pointed out that some entries with very short titles might have more "twins" than {{also}} could handle, but we already have a way of handling such cases, namely Appendix:Variations of "a" et al. - -sche (discuss) 03:51, 10 August 2014 (UTC)

Module:ru-verb help needed[edit]

In function "conjugations["6c"]" I'm passing an additional parameter no_iotation=y to change the bahaviour of "present_je_c" function. It didn't work, though.


<pre>
        local no_iotation = args[no_iotation]; if no_iotation == "" then no_iotation = nil end
...
        if no_iotation then
                present_je_c(forms, stem, no_iotation)
        else
                present_je_c(forms, stem)
        end

I have removed "or no_iotation" but this is what I tried:

        -- Verbs ending in a hushing consonant do not get j-vowels in the endings.
        if mw.ustring.find(iotated_stem, "[шщжч]$") or no_iotation then
                forms["pres_futr_1sg"] = iotated_stem .. "у"
        else
                forms["pres_futr_1sg"] = iotated_stem .. "ю"
        end

Purpose: For the verb стона́ть (stonátʹ) the 1st person singular is "стону́", it should use the first part before "else". --Anatoli T. (обсудить/вклад) 07:41, 10 August 2014 (UTC)

Problem fixed by User:Wyang. Thank you! --Anatoli T. (обсудить/вклад) 23:48, 10 August 2014 (UTC)
No worries. The present adverbial participle is стоня́, is this correct? Wyang (talk) 23:49, 10 August 2014 (UTC)
The forms "стона́в" and "стона́вши" are much more common and preferred (from the 2nd conjugation pattern) (also "стена́я" from related verb "стена́ть"). However, "стоня́" is also used, which may be considered a less standard form. I will check if "стоня́" should be overwritten with "стона́в" and "стона́вши" but it seems attestable and looks like a dated form. BTW, many verbs are seldom used in certain forms, adverbial participle for стона́ть seems relatively rare.--Anatoli T. (обсудить/вклад) 00:21, 11 August 2014 (UTC)

Module:fro-verb is open for business[edit]

The purpose of this module is to implement Old French verb conjugations. These conjugations have a number of problematic aspects:

  • Complex but regular phonological adjustments in parts of the present-tense singular, when adding morphological zero, -s and -t.
  • Multiple sets of endings, used in different circumstances (e.g. there are distinct endings when the final consonant of the stem was once a palatal consonant).
  • Multiple alternatives for endings, more or less interchangeable but often marked for particular dialects or time periods.
  • Multiple possible formations for e.g. the preterite: weak-a, weak-a2, weak-i, weak-u, strong-i, strong-o, strong-u, strong-st, strong-sd, etc.
  • All manner of irregularities, which often involve the stem (leaving the endings alone) but sometimes affect particular forms (e.g. 1st-singular present indicative).
  • Very frequently, multiple more-or-less-interchangeable alternative ways of conjugating a particular tense for a particular verb.

I handle all of this. You can

  • specify multiple stems;
  • specify distinct stressed and unstressed stems in the places where such a distinction makes sense (present indicative, present subjunctive, imperative, preterite);
  • override particular forms either by replacing all alternatives, inserting alternatives at the beginning or end or replacing a particular alternative by index;
  • specify the entire conjugation of a given tense in a compact fashion, useful when there are lots of irregularities, e.g. pres=vois,vai/vais,vas/vait,va/alons/alez/vont for the present tense of aler, where slashes separate forms in the paradigm and commas separate alternatives within a given form, i.e. 1st singular is either vois or vai, 2nd singular is either vais or vas, etc.;
  • request palatal endings;
  • request two distinct types of archaic/dialectal endings (useful if the stem is also archaic or dialectal);
  • add a prefix to all forms, to easily implement verbs like convenir or secorre, with the same conjugation as convenir or corre;
  • specify a search/replace that applies to all forms, useful when listing the conjugation of a verb with non-standard spelling (e.g. nestre should conjugate like naistre but with all occurrences of nais- replaced by nes-) -- note that prefixes could be implemented this way, since search/replace uses Lua patterns (aka crippled regexes);
  • etc.

This is used by four primary templates:

  • {{fro-conj-er}} (for group I -er verbs);
  • {{fro-conj-ier}} (for group I -ier verbs);
  • {{fro-conj-ii}} (for group II verbs, i.e. -ir verbs with -iss- infix);
  • {{fro-conj-iii}} (for group III verbs, i.e. ir verbs without -iss- infix, plus -re, -oir, and -eir verbs as well as a few -er verbs where the -er here is an Anglo-Norman reduction of -eir).

These templates are thoroughly documented.

This code was originally based on Module:it-conj but greatly expanded and rewritten. In turn it could serve as the basis for another language with similarly complex and irregular verbal morphology.

Please feel free to look over the code and/or the documentation and give me comments, suggestions, critiques, etc.

Benwing (talk) 10:06, 12 August 2014 (UTC)

Stray word "valid"[edit]

Some recent edit to {{ga-proper noun}}, presumably one of these two, has had the effect that the word "valid" appears at the end of the headword line; cf. [[Cáisc]]. I have no idea how to fix it, though; could someone else please look into it? —Aɴɢʀ (talk) 15:04, 12 August 2014 (UTC)

Actually, it was broken before. (Happens.) But fixed. Keφr 15:13, 12 August 2014 (UTC)

(U+378D) and Template:ja-readings not working correctly[edit]

For some reason, the "on=" (Japanese on form) and "kun=" (Japanese kun form) reading information in Template:ja-readings isn't displaying for me (in two different browsers). I don't know if it has something to do with the character being in the CJK Unified Extension A range or if it's just some other miscellaneous bug. This is similar to the issue I reported back in June regarding 𩙿 (U+2967F) in Extension B (which, for now, is displaying correctly). Bumm13 (talk) 17:04, 13 August 2014 (UTC)

Not my area of expertise, or even work, but I notice that Module:ja is coded only to accept CJK characters, and, in doing so, missed the Extension A block causing this problem. I have to wonder why this restriction exists in the first place. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 17:29, 13 August 2014 (UTC)

Polysynthesis help[edit]

Is grease pit the right place to ask this? What's the general policy with creating conjugation/declension templates for heavily polysynthetic languages - is it possible or even desired? —JakeybeanTALK 21:53, 13 August 2014 (UTC)

I'd say the Beer Parlour is the more appropriate place to discuss the question of whether it's desirable, and the Grease Pit is the place to discuss how to do it if it is desirable. We do have a few entries like xłp̓x̣ʷłtłpłłs and xłp̓x̣ʷłtłpłłskʷc̓, and the latter survived an RFD, but I don't think we've ever discussed the possibility of inflection templates that would generate such forms. —Aɴɢʀ (talk) 22:20, 13 August 2014 (UTC)
There are some somewhat-large tables in Category:Finnish verb inflection-table templates. There are also some specific Georgian inflected forms like გვფრცქვნი which we have because they, like xłp̓x̣ʷłtłpłłs(kʷc̓), are interesting — but they don't seem to be linked-to from their lemma entries (ფრცქვნის?). So, what Angr said. - -sche (discuss) 22:58, 13 August 2014 (UTC)
Thanks for your input. My main contributions at the moment are in Greenlandic so the problem for me is knowing where to stop. For example if you take the verb 'atuarpoq' (to read), I could provide purely the indicative forms, but each one comes with a negative counterpart:
atuarpunga (I read) + atuanngilanga (I don't read)
atuarputit (you read) + atuanngilatit (you don't read) etc. for each person
There are also interrogative, imperative, optative, conjunctive, past subordinative, future subordinative, habitual subordinative, participial moods and others that are sort of semi modes, with each of those having positive and negative forms. Also, each mode has a transitive inflection so for the verb 'asavoq' (to love) you could have 36 different combinations purely in the indicative e.g. You love him (asavat), they love me (asavaanga), you pl. love us (asavassigut) and so on...I think the best thing to do would be to start by creating an indicative form template. Including positive and negative forms and maybe the transitive combinations as well. There already exists a basic noun declension table which only includes the bare noun cases without any further affixing such as possessive markers, so maybe simplicity is best? —JakeybeanTALK 00:22, 14 August 2014 (UTC)
In addition to those mentioned above, there's Hebrew, which has binyanim (different forms of the stem that conjugate through the whole paradigm), and Turkish- but there we have a contributor for that language who is the poster child for the "don't know when to stop" problem, and has created all kinds of unnecessary templates and categories. I haven't gotten that far with Cahuilla verbs, but those will definitely have similar issues, so I've started to think a little about it. How much do the affixes interact phonologically with the stems and with each other? If they stay discrete, you could have one complete subparadigm, and a list of the counterparts to the part that stays the same within the subparadigm (I don't want to say the root, because I'm sure each one contains its own combination of affixes). At any rate, you would want to make heavy use of multiple collapsible boxes, which, if memory serves, can even be nested within each other. Chuck Entz (talk) 02:59, 14 August 2014 (UTC)
I'm not worried about the layout of the tables, but of whether we need to mass-create all the red links produced by these tables. (Also, I wouldn't consider Hebrew binyanim, or their equivalents in other Semitic languages, to be examples of polysynthesis.) --WikiTiki89 14:30, 14 August 2014 (UTC)
Finnish has the case of possessive suffixes and other suffixed particles, which exponentially increase the number of possible word forms. Latin also has a few clitic suffixes which we agreed not to include as entries. Zulu and other related languages include not just the subject but also the object noun class into the verb, so that makes for some 100+ forms for each mood-tense-voice combination, totalling perhaps 1000 forms per verb. And there are probably more still. —CodeCat 14:32, 14 August 2014 (UTC)
English has John's're, Hebrew has, as an extreme example, וּכְשֶׁבְּבֵיתְכֶם (u-kh'-she-b'-veit'-khém, and when in your house), with a similar situation in other Semitic languages, and we do not include any of these constructs as individual words. --WikiTiki89 15:04, 14 August 2014 (UTC)
The mention of Finnish seems apt. If some of the categories of Greenlandic inflected forms (e.g. negative forms, possessive forms, etc) differ from other, 'simpler' categories of inflected forms (e.g. plain present tense) only in some predictable way, such as by the addition of an affix, it would probably make sense to leave those (negative, possessive, etc) forms out of the inflection tables and not bother creating entries for them except in exceptional cases, such as when the same string that is a negative possessive third person verb form also happens to be a noun, or when the string is oft-mentioned on account of some exceptional quality. The full paradigms of a few representative verbs could (and IMO should) then be provided in an appendix. - -sche (discuss) 16:01, 14 August 2014 (UTC)
I think that sounds like a good idea. I'll come up with a basic indicative template and provide an appendix with full paradigms (or as full as one can be without becoming ridiculous!).—JakeybeanTALK 17:47, 14 August 2014 (UTC)
But what about looking up such forms? Given that we have no real space restrictions, can we still have entries for them? —CodeCat 17:51, 14 August 2014 (UTC)
I'm against it. --WikiTiki89 18:16, 14 August 2014 (UTC)
I wasn't saying Hebrew was polysynthetic, just that it might be helpful to look at because it's an example of how experienced, sophisticated editors have dealt with an extra dimension in the paradigm. Polysynthesis isn't really that useful of a term because no one seems to completely agree on what it means, but I'm not so sure that any of the languages discussed are universally considered polysynthetic, anyway. Chuck Entz (talk) 02:48, 15 August 2014 (UTC)

With these sort of languages I find it hard to know what to prioritise for inclusion; whether the viewer would benefit more, for instance, from a breakdown of the different moods, or if the indicative is enough in itself but with both intransitive and transitive paradigms...neither, or both...and with both outcomes whether the negative of each inflection is desired. Greenlandic in particular doesn't really indicate tense in ways we're used to in Indo-European; the indicative verb can mean both past and/or present, but instead they add morphemes which define tense, such as: vague future, inevitable future, recently, a long time ago etc. and I think we'd all agree those are better off in an affix Appendix. Hard to know where the line should be drawn. —JakeybeanTALK 12:39, 15 August 2014 (UTC)

I think the best thing to think about is which parts of the inflection can differ depending on the word itself (these should always be in the table), and which parts are added unchanged to any word of that type (these are ok to move to an appendix). --WikiTiki89 12:47, 15 August 2014 (UTC)

Is there a way without a bot to determine if an entry is in category A but not category B?[edit]

In particular, I'm trying to find Old French verbs lacking conjugations, which will be in Category:Old French verbs but not in any of the categories created by the conjugation module. Benwing (talk) 04:33, 15 August 2014 (UTC)

There's the API, but I think it would be easier to download an XML dump and scan it offline. DTLHS (talk) 04:39, 15 August 2014 (UTC)
Bots can retrieve lists of pages in a category. If you use a language like Python that can handle sets, then it's a matter of doing some set operations to get the result you want. —CodeCat 13:06, 15 August 2014 (UTC)
Any language "can handle sets". --WikiTiki89 13:58, 15 August 2014 (UTC)
I think his point is that some semi-crippled languages like Lua don't have built-in API's that implement sets, so you end up needing to implement them yourself using hash tables. Benwing (talk) 16:08, 15 August 2014 (UTC)
A hash table is a set, but with a few extra features, and without built-in set operations like unions, intersections, etc., which are all very easy to implement. --WikiTiki89 16:12, 15 August 2014 (UTC)

Objectionable coding convention saying "don't comment code"[edit]

In WT:Coding conventions it says

Comments should be used sparingly; good code does not need much commenting. Keep comments brief and to the point. Do not put ASCII art in comments.
Comments should not be used for documentation; use the documentation subpage instead.

I disagree with all of this. When you have 1000+ lines of code, you better have comments in there otherwise it will take 3x as long to understand. I've worked with systems with 200,000+ lines of code and commenting is incredibly important. I get that the goal is to discourage stupid comments that don't add anything, but in reality lack of commenting is a much bigger issue than too much commenting. And too much commenting, if it ever happens, is easy to fix. As for "comments should not be used for documentation", (1) this will discourage people from commenting internal functions, whereas in reality pretty much *all* internal functions should be documented, and (2) yes in theory the doc page should be kept up to date but in practice most of them aren't, and it's more likely that someone will comment in the source code that in the doc page.

I think we should add something like "add a comment at the top of all functions describing what it does". This doesn't have to be long if it's obvious, but much of the time, it's not.

Also, I think we should add something like "always write a change summary for every change you make". I've noticed that certain users (CodeCat, among others) don't normally do this, and it makes it much harder to sort through the change history.

Benwing (talk) 04:54, 15 August 2014 (UTC)

Agree about "always write a change summary"; this should be very strongly encouraged if not actually mandated. Equinox 07:18, 15 August 2014 (UTC)
This is a crazy convention. I used to understand Lua functions but these days I find that most of them are totally incomprehensible - bring back comments! SemperBlotto (talk) 08:11, 15 August 2014 (UTC)
The only part of the first line I agree with is "Keep comments brief and to the point." (well the ASCII art thing too, but I don't think it needs to be mentioned explicitly). But I entirely agree with the second line. --WikiTiki89 14:01, 15 August 2014 (UTC)
Fortunately, it's just two people's opinion, not a real policy. DCDuring TALK 17:46, 15 August 2014 (UTC)

Language links[edit]

By the way, this has to do with the entire Wiktionary project, not just the English one, and I put this discussion here since this is like the central Wiktionary anyway.

So my experience with language links here is very tedious. One usually would add language links to the bottom of a page as such:

[ [ ar:word ] ]

[ [ da:word ] ]

[ [ fr:word ] ]

etc.

And as far as I know, on all language wikis, this is supposed to be handled by bots. In many Wiktionaries in other languages, they do not have language links at all for thousands of pages and haven't been added by bots for several years. Also, there then comes the problem of having to alphabetically sort all of the language links, which also sometimes causes bugs in the programs of the bots. And I know I have a lot of big ideas, but this one could actually be very useful to the project, well, ALL of the projects.

My idea is that we should have what Wikipedia has, where they have a central database that holds all of the Wikipedia articles and the articles in other Wikipedias with which they are associated. In other words, if we had this on Wiktionary, one could just add a language link to "edit links", and enter the name of the page that you want to add to the language links. The bots could also come in handy for adding these links, such as if a Wiktionary page for a word is added in another language, it would automatically be added to the list by a bot.

If we had a system like this, opposed to the one we have now, it would be so much easier for Wiktionaries in all languages to have links to all of their associated pages. We may also want to have a filter, like we do now, that filters out pages for other words. For instance it would filter out someone trying to add a language link to Danish menneske from the word human on the English Wiktionary.

I am not actually sure if we've had a discussion about this kind of thing before, and I also do understand that it would take a lot of work to set up and implement something as huge as this, especially for the entire project, including all of its subdomains, but I really think we should (re)consider this idea, since I personally think this would be very helpful for all of us. Rædi Stædi Yæti {-skriv til mig-} 04:51, 16 August 2014 (UTC)

Yes, this is probably what wikidata is supposed to do (seems simple to me, but who the fuck knows what it would actually take to make that happen). DTLHS (talk) 04:54, 16 August 2014 (UTC)
Yes, one of the things Wikidata was supposed to do was take interwiki linking off projects' hands. And Wiktionarians such as me have repeatedly suggested that Wikidata start taking Wiktionary's interwikis off our hands, since Wiktionary interwikis are easier to handle than other projects' — all the mainspace pages which are to be linked have the same title. However, Wikidata-ers seem uninterested in that, and instead have technically complex and IMO linguistically unsound and unmaintainable ideas about taking definitions off our hands and putting them in a repository so sea and de:Meer could transclude a single unified definition. (Never mind that even denotatively synonymous words are rarely connotatively synonymous.) Meh. You can read about the plans here; my most recent suggestion that Wikidata just take interwikis off our hands is here if you'd like to add your voice. - -sche (discuss) 06:56, 16 August 2014 (UTC)

New entries by language[edit]

  1. 29 September 2014: κριτσίνι
  2. 28 September 2014: απείθεια κατά της αρχής
  3. 26 September 2014: γκλάσο
  4. 26 September 2014: κάποτε
  5. 26 September 2014: Κογγό
  6. 24 September 2014: άνετος
  7. 24 September 2014: ακροβολιστής
  8. 24 September 2014: γώπα
  9. 24 September 2014: γόπα
  10. 24 September 2014: αποτσίγαρο
  11. 23 September 2014: τσεχοσλοβάκικος
  12. 23 September 2014: Τσεχοσλοβάκα
  13. 23 September 2014: Τσεχοσλοβάκος
  14. 23 September 2014: τσεχοσλοβακικός
  15. 23 September 2014: τσέχικα
  16. 23 September 2014: τσέχικος
  17. 23 September 2014: Τσεχικά
  18. 23 September 2014: τσεχικός
  19. 22 September 2014: κυπριώτικα
  20. 22 September 2014: κυπραίικα

There used to be a list/feed (some years ago - not always reliable) of new entries in a chosen language - has this gone, or is it hidden somewhere? — Saltmarshαπάντηση 19:12, 20 August 2014 (UTC)

That very useful feature, maintained by User:Visviva at http://www.fraktionary.com/, stopped working long ago. Now people can add crap in the languages I work with and I wouldn't know. --Vahag (talk) 19:25, 20 August 2014 (UTC)
Actually, we could enable this another way. There is a feature that shows when entries were last added to a category, and we've used that for a few cleanup categories to show the oldest and newest members. Now that we have the lemmas/non-lemmas categories, we could apply something similar there? —CodeCat 22:05, 20 August 2014 (UTC)
Yes, let's do it. Can we just put a collapsed list of the newest entries on the page of each lemmas category? --WikiTiki89 00:12, 21 August 2014 (UTC)
It turns out that you don't even need to include the list on the category it monitors. You can put it anywhere. Here's the list for Category:Greek lemmas: —CodeCat 00:15, 21 August 2014 (UTC)
Yes, but I think the category is the best place to permanently host such a list. Is it possible to show who created the page? --WikiTiki89 00:30, 21 August 2014 (UTC)
You can see all the features here. I'm not sure about putting it on the lemma category page itself, because this is primarily useful for editors, while the lemma category is for users. —CodeCat 00:39, 21 August 2014 (UTC)
Why wouldn't a reader be interested in the new entries created for a language? Anyway, it shouldn't be too bothersome for those who don't care if it is collapsed. --WikiTiki89 00:43, 21 August 2014 (UTC)

Visviva's tool tracked also newly added translations by language and, IIRC, had an RSS feature. --Vahag (talk) 13:07, 21 August 2014 (UTC)

It tracked all changes by language. It was very useful for patrolling a specific language. --Panda10 (talk) 13:16, 21 August 2014 (UTC)


lalala Index:Georgian lalalala--Dixtosa (talk) 13:33, 23 August 2014 (UTC)

Well, it worked!. I have an idea, let's return this string <span style = "display:none">[[Index:langname]]</span> whenever {{t}} and {{head}} is used. and then we can use Special:RecentChangesLinked page. in this case this. With this we will be able to monitor newly added translations too.
(inspired by User:ZxxZxxZ's Recent changes for fa.--Dixtosa (talk) 13:40, 23 August 2014 (UTC)

RQ Template[edit]

I'm an inexperienced editor who concentrates on adding quotes to senses. To save time and space, and to allow systematic updating, I would like to use RQ templates. My first investigation suggests that I could use something like:
<includeonly>'''1915''', {{w|George A. Birmingham}}, ''[http://gutenberg.org/ebooks/24394 Gossamer]''{{#if: {{{1|}}}| , ch.{{{1}}} }}</includeonly>
Does this present any problems? If I go ahead with it, should I add an entry for it in Wiktionary:Quotations/Templates? — ReidAA (talk) 08:48, 21 August 2014 (UTC)

If you plan to add many (not just a few) quotations from that particular source, then go ahead. Also, there is no reason for the <includeonly> tags, in fact they get in the way of testing out the template on its own page. --WikiTiki89 13:00, 21 August 2014 (UTC)
Thank you for your advice. I do plan to add many, and this will save both time and space. — ReidAA (talk) 00:17, 22 August 2014 (UTC)

Category:English words prefixed with auto-[edit]

Why does autoaway appear at the bottom of the A list, after autozygous? It was added more recently, but how does this explain the incorrect alphabetical positioning? Equinox 04:47, 22 August 2014 (UTC)

Template:confix isn't applying the sort key correctly- some problem with Module:compound. DTLHS (talk) 04:55, 22 August 2014 (UTC)

Why are long pages slow to load?[edit]

I've been looking at ways to make Wiktionary:List of languages load faster, and at first I focused on making the Lua code more efficient. But when previewing the page, it showed in the statistics that Lua was only taking about 2-3 seconds to do its work, whereas the whole page took 19 seconds. So I tried expanding the page's code completely, so that all module invocations were eliminated. This only brought down the load time to 16-17 seconds, which is basically what it was before minus the Lua load time.

It seems that Lua is not the culprit in this case, but that the wiki software just does very badly at handling large pages. Is there anything we could do to speed this up somewhat? And if we can't, what can we do to make this list load faster so that it's more useful for quick lookups? I imagine the majority of people who use the page only go there to look up names and codes, so we could get rid of the extra information like script and family information? —CodeCat 14:59, 23 August 2014 (UTC)

  • I don't have any problem loading long pages, but I do notice that they take a long time to save after they have been edited. Donnanz (talk) 15:04, 23 August 2014 (UTC)
I think we should keep the List of languages as it is, but it would be nice to have indexes of codes and of the names they stand for. I would like to be able to go to a single page that has every code, including languages, families, etymology-only languages, etc., with their name, their type and the name of the data module they're in. Likewise for another index with the same data, but arranged by name, and having separate lines for each alias. Chuck Entz (talk) 16:33, 23 August 2014 (UTC)
Such a page would be possible, but it would be prohibitively slow to load, so not really suited to quick lookups. But I've just been working on something that may be more feasible. I wrote a JavaScript that looks up language data by code on the fly. It's not really full-featured yet, but it's a good start. To try it out, copy the code at User:CodeCat/common.js to your own common.js, and then go to User:CodeCat/lookup language. A small form should appear where you can type in a language code. @Kephir, Yair rand: Could you review my code and post any comments you may have about any specific coding practices on my talk page? I'm not very experienced with JavaScript, so feedback would be very welcome. —CodeCat 20:59, 23 August 2014 (UTC)
Because you're downloading more bytes of HTML. --WikiTiki89 22:58, 24 August 2014 (UTC)
1.3 MB should not take 16+ seconds to load though. —CodeCat 23:08, 24 August 2014 (UTC)
Also the rendering takes time, due to all the formatting. I'm curious if it would load any faster if we had a page of that size with just plain text. --WikiTiki89 23:32, 24 August 2014 (UTC)

Module errors on Old Church Slavonic translations[edit]

In a couple of cases (diff and diff), removing manual transliteration has caused a module error with the message: "Lua error in Module:Cyrs-Glag-translit at line 129: This module can only transliterate Old Cyrillic (Cyrs) and Glagolitic (Glag)". In both cases, these were existing entries (моуха (muxa) and орьлъ (orĭlŭ)). Is this a problem with the spelling, or with the module? Chuck Entz (talk) 19:22, 23 August 2014 (UTC)

Never mind- it was use of "sc=Cyrl" in the template. Chuck Entz (talk) 19:27, 23 August 2014 (UTC)

Red link headline in abbreviations[edit]

This problem was fixed for suffixes yesterday, but still exists in some abbreviations. Please see these entries: kft. (uses {{hu-noun}}) and és tsai. (uses {{head}}). --Panda10 (talk) 12:12, 25 August 2014 (UTC)

I fixed it. és tsai. now links to és and tsai., which is how it should be. If tsai. does not exist on its own, then the head= parameter should be specified to override it. --WikiTiki89 14:54, 25 August 2014 (UTC)
Thank you. --Panda10 (talk) 15:39, 25 August 2014 (UTC)

Template:pt-adj[edit]

When making the ACCEL links,this happens, which classes a feminine plural as a feminine. I guess the ACCEL function needs to be changed somehow. Any takers? --Type56op9 (talk) 20:47, 28 August 2014 (UTC)

Template:character info adding bogus script cats[edit]

Discussion moved to Wiktionary:Grease pit/2014/September.

September 2014[edit]

Where is the documentation on Javascript in Wiktionary/MediaWiki?[edit]

For Lua there's WT:LUA aka WT:Scribunto, which gives a nice introduction to Lua and has links to explain the MediaWiki-specific things. Is there an the equivalent for JavaScript? I don't have that much experience with this language and it's a bit confusing trying to make sense of e.g. the stuff going on in MediaWiki:Common.js or User:Ruakh/Tbot.js. I've found some documentation on www.mediawiki.org but it seems rather disjointed. Benwing (talk) 02:52, 1 September 2014 (UTC)

You won't find much in MediaWiki because those were written by people here at Wiktionary. I suppose there might be documentation somewhere of the Wikimedia infrastructure that the JavaScript code is manipulating, but it wouldn't explain what we're doing with it. Chuck Entz (talk) 03:47, 1 September 2014 (UTC)
Right, I get that those were written here but I assume the documentation should be common to both projects. Is there any JavaScript documentation here on Wiktionary? Benwing (talk) 05:53, 2 September 2014 (UTC)

Template:character info adding bogus script cats[edit]

Discussion moved from Wiktionary:Grease pit/2014/August.

There are at least four redlinked "script" categories in Special:WantedPages that bear the names of Unicode blocks that aren't actually scripts:

  1. Category:CJK Compatibility Forms script
  2. Category:Enclosed CJK Letters and Months script
  3. Category:Miscellaneous Symbols And Pictographs script
  4. Category:Supplemental Punctuation script

With my limited template skills, I'm not sure if it's the parameters passed to {{character info}}, or something about these Unicode blocks themselves that the template code can't handle, but {{character info}} is where the cats are generated.

Can anyone figure out why this is happening, and make it stop? Thanks! Chuck Entz (talk) 00:10, 1 September 2014 (UTC)

@Kephir: —CodeCat 23:59, 15 September 2014 (UTC)
The problem is simple: the various {{Unicode block character info}} templates pass the Unicode block to {{character info}} in a |script= parameter, which is then used to form a category name. It may be suppressed by adding an empty |category= parameter to {{character info}}, or removing the |script=. And the category name is wrong anyway. (I am sure you could have figured that one easily.) The replacement I have been working on, {{character info/new}} does not add any categories, but I am not sure if this is right (probably not). Additionally, the code for it (Module:character info) is relatively messy, and uses a rather crude hack for script detection (although using Module:scripts for that would make it even worse, if it be possible at all). So it is not really ready for deployment. Keφr 04:46, 16 September 2014 (UTC)
@Kephir, Chuck Entz: I have made some changes to these templates and I think it has solved the problems. The parameters of {{character info}} are more straightforward now. {{{block}}} specifies the Unicode block name to display and the appendix to link to; {{{sc cat}}} specifies the script code of the character category to add it to. Because you specify a script code, it's ensured that the category will always be valid. —CodeCat 23:55, 16 September 2014 (UTC)

quote-newsgroup is not suitable for non-Usenet groups[edit]

I was looking at Twihard and noticed that it has several citations from Google Groups, which (even though Google also archives Usenet newsgroups) are not part of Usenet. However, because the citations are formatted with the quote-newsgroup template, it incorrectly says "Usenet" beside them. What is the best solution? Equinox 07:52, 2 September 2014 (UTC)

In this case, the best solution is probably to remove them, because non-Usenet Google Groups are not durably archived, and the non-durable citations do not significantly differ from the durable citations in date or in how well they illustrate the use of the word.
But there will be other cases where non-durable citations are worth keeping — words need three durable citations to meet CFI, but once they have three durable citations, there's no prohibition on them also citing non-durable things, e.g. as usexes (if they illustrate the typical usage of the term better than the durable citations), or as support for a statement that the word has been attested since year X (if they predate the durable citations). After all, the online editions of Merriam-Webster and Dictionary.com are cited in many etymologies. I suppose the question is whether we need a new "non-Usenet-group" citation template for the non-durable citations we do keep, or whether {{quote-web}} is enough. - -sche (discuss) 15:45, 2 September 2014 (UTC)
I don't have an issue with Google Group postings being used as citations, but I went ahead and replaced the ones in the Twihard entry with cites from Google Books. -Cloudcuckoolander (talk) 19:23, 5 September 2014 (UTC)

Template:head should take f1tr etc. params[edit]

(Notifying CodeCat): {{ar-verb}} passes in a parameter f1tr that's intended to be a translation of an additional verb form (the imperfect), but {{head}} doesn't support that. Presumably it should support it; in the meantime, what's the best way to make this visible? Benwing (talk) 05:45, 3 September 2014 (UTC)

No, it shouldn't. Most foreign script languages don't transliterate inflected forms in the headword, e.g. Russian (e.g. ве́ра (véra), де́лать (délatʹ)). One reason: it makes it cluttered, the other: if the transliteration is irregular, one should always supply it. --Anatoli T. (обсудить/вклад) 05:50, 3 September 2014 (UTC)
Whether the transliteration is irregular has nothing to do with whether it should be displayed. As for cluttering, I think that's questionable. There's only one inflected form here and it's not going to clutter things by adding the transliteration. The general practice anyway is to transliterate most words -- why do we bother providing transliterations in inflection tables if someone's just going to say it "clutters" the tables? The intention was clearly to provide such transliterations, that's why the imperfect transliteration is provided. Was there a general decision made at a certain point not to provide transliterations of inflected forms? Benwing (talk) 06:20, 3 September 2014 (UTC)
I think there was but I can't find it at the moment. User:CodeCat might remember, she has also edited {{ar-verb}} but it's probably controlled by {{head}}, sorry, my programming skills are not great. --Anatoli T. (обсудить/вклад) 06:34, 3 September 2014 (UTC)
BTW {{ar-noun}} does include transliteration of the inflected form (the plural). It does it by manually inserting the transliteration, although with your changes it looks like it now appears twice (one comes from the use of {{l}}). An example is زرد. We should probably remove the manual insertion. Benwing (talk) 06:36, 3 September 2014 (UTC)
Hmm, I don't know what happened there but it's a bug. Arabic headword templates also need attention, sorry, you are busy as is. --Anatoli T. (обсудить/вклад) 06:39, 3 September 2014 (UTC)
There was a discussion about this some months ago. I don't know where it went, but I think there was some opposition to transliterations for every form in the headword line, if I remember? —CodeCat 11:36, 3 September 2014 (UTC)
I think this should be decided on a per-language basis. For some languages the transliteration of the plural does not add much, for others, it is very useful. In other words, the template should support both possibilities. --WikiTiki89 15:21, 3 September 2014 (UTC)
I won't oppose it, if the majority decides so. Would be great if Lua-skilled people addressed Arabic headword modules/templates. --Anatoli T. (обсудить/вклад) 01:10, 5 September 2014 (UTC)
I think overall we are overusing Lua. See my new Belarusian and Ukrainian adjective declension templates for examples of what I think is the proper mix of templates and Lua, ending up with the same effect as the fully Lua Russian adjective declension template. Likewise, the Arabic headword templates need only use {{head}}, which they already do, however some more functionality needs to be added to {{head}} such as what we are discussing here. --WikiTiki89 19:43, 5 September 2014 (UTC)
I find complicated template hacking to be nightmarish, much harder than using Lua. But then again, I am a programmer. Certainly, I don't see how I could have possibly implemented the whole set of Arabic conjugations in a reasonable amount of time using templates, as I did with Module:ar-verb. Templates also lead to tons of code duplication, almost necessarily (although some of the Lua modules have lots of duplication, too, e.g. Module:ru-verb). Benwing (talk) 20:24, 5 September 2014 (UTC)
Yes, complicated templates are nightmarish, and that's why I support replacing all the complicated parts with Lua, but that doesn't mean that the whole thing needs to be Lua (look at the examples I linked to above, they are both very simple). --WikiTiki89 21:35, 5 September 2014 (UTC)
Indeed, these are parsable although IMO they're about at the limit of where it makes sense to switch the whole thing to Lua, just because template syntax is so horrible.
BTW in the case of these two templates, I would make it so it automatically infers the stem and ending from the headword. This needs to be done in Lua but it will make it much easier to add conjugations to new adjectives since you just cut and paste the same call to {{be-decl-adj}} or whatever in every adjective lemma. I did this with Old French verb conjugation and with Arabic verb conjugation (in this latter case, inferring the radicals is significantly more complicated than inferring the stem/declension for Ukrainian or Belarusian). Benwing (talk) 07:44, 6 September 2014 (UTC)
Unfortunately, the template needs to know the location of the stress. Otherwise a simple template that requires no arguments would have obviously been better. --WikiTiki89 19:34, 6 September 2014 (UTC)
Ah of course ... I forgot that the stress isn't in the page title. Benwing (talk) 19:40, 6 September 2014 (UTC)

Category:J. R. R. Tolkien[edit]

Would somebody be willing to do whatever is necessary to make Category:English terms derived from Tolkien's legendarium into a subcategory of Category:en:J. R. R. Tolkien? I tried doing it myself, but I couldn't get it to work. Thanks! -Cloudcuckoolander (talk) 22:45, 3 September 2014 (UTC)

Done. Subcategories are just categories that are in a category. --WikiTiki89 23:42, 3 September 2014 (UTC)
What is that category for, anyway? I'm not really thrilled about mixing categories like this. —CodeCat 23:54, 3 September 2014 (UTC)
From its use of {{topic cat}}, it seems like Category:en:J. R. R. Tolkien is supposed to house terms which are (semantically) about Tolkien... but then it contains balrog, which is derived from but not about Tolkien. (Side note, balrog’s formatting needs to be cleaned up.) I'm not sure there are enough terms about Tolkien to merit the category. - -sche (discuss) 08:34, 4 September 2014 (UTC)
That's not what I was after, Wikitiki. I know how to manually add a category to a page. I wanted to edit this so that Category:en:J. R. R. Tolkien would be a parent category of Category:English terms derived from Tolkien's legendarium (and Category:fr:J. R. R. Tolkien a parent category of Category:French terms derived from Tolkien's legendarium, and so forth). -Cloudcuckoolander (talk) 21:27, 4 September 2014 (UTC)
If we do that, we would end up with 10 new categories whose only purpose is to hold that one subcategory. I agree with -sche that I'm not sure a category about Tolkien is warranted. —CodeCat 21:40, 4 September 2014 (UTC)
The purpose of this category is to allow Tolkien-related and Tolkien-derived terms to be slotted into relevant categories in the topical categorization system, like Category:British fiction and Category:Fantasy. There just isn't a convenient name used to refer to the Middle-earth mythos as a whole. -Cloudcuckoolander (talk) 21:55, 4 September 2014 (UTC)
I don't know what I'm doing wrong here. I'm ending up with a module error. -Cloudcuckoolander (talk) 22:09, 4 September 2014 (UTC)
Figured it out. Had to edit the module (is that the correct term?) for people, not culture. -Cloudcuckoolander (talk) 22:16, 4 September 2014 (UTC)
Tolkien and Carroll are not British fiction, literature or fantasy. They are authors. —CodeCat 22:23, 4 September 2014 (UTC)
That's splitting hairs. If you think Category:Tolkien legendarium or something similar would be a better category name, you could propose a rename at WT:RFM. But I don't see anything problematic with the current title. It's simple and does its job. -Cloudcuckoolander (talk) 23:05, 4 September 2014 (UTC)
Going to manually add all Tolkien-related and derived terms to Category:en:J. R. R. Tolkien as an alternative to my original proposal. -Cloudcuckoolander (talk) 23:33, 4 September 2014 (UTC)
I do not agree with that change. —CodeCat 00:49, 5 September 2014 (UTC)
I've now nominated Category:Authors for deletion. I kindly ask you not to make any further changes until that discussion has run its course. —CodeCat 00:56, 5 September 2014 (UTC)
Wiktionary is a collaborative project. It isn't your place to dictate where I can and cannot contribute. -Cloudcuckoolander (talk) 01:35, 5 September 2014 (UTC)
I would hope that someone interested in writing a dictionary would understand the difference between "kindly ask" and "dictate". —Aɴɢʀ (talk) 13:56, 5 September 2014 (UTC)
Prefacing a demand with "kindly" doesn't make it polite. Quite the opposite, actually. It's sarcastic and patronizing. -Cloudcuckoolander (talk) 17:43, 5 September 2014 (UTC)

Category:Wiktionary protected edit requests[edit]

The category contains some open requests, in particular MediaWiki talk:Gadget-LogoTiles.css. (I hope I followed the correct procedure; I tried several linked from Wiktionary:Request pages but couldn't find any.) --Nemo 09:36, 6 September 2014 (UTC)

Actually, that category has only been created this year. Normally we handle these requests here, at the GP (we have very few of them anyway). I guess we should not really have {{Edit protected}}, for the same reason we have no real {{helpme}}. Keφr 10:04, 6 September 2014 (UTC)
Thanks for fixing. I've redirected the template here and added this page to Wiktionary:Request pages, I hope it works. --Nemo 05:37, 8 September 2014 (UTC)
Very bad idea. This way, when someone from TOW comes and uses the template out of habit, they will transclude the whole Grease pit page and after saving tell themselves "WTF just happened?". Better to just adapt {{helpme}} a bit. Also, GP is not really a "request page" — it is a general-purpose technical forum. Keφr 16:15, 8 September 2014 (UTC)
Well that section is called "Other places to congregate". Technical requests go here and that's the page where one can be expected to look for the information. --Nemo 05:10, 9 September 2014 (UTC)

Module:ar-translit -- how can I shoehorn module-specific documentation?[edit]

The module Module:ar-translit uses generic documentation for transliteration functions. However, it currently takes two extra parameters, which I'd like to document. Is there a way to stick some such customized documentation in the template call that creates the documentation? If not, perhaps someone (@CodeCat:?) could look into fixing this? Thanks very much! Benwing (talk) 09:38, 6 September 2014 (UTC)

Appendix:Arabic Frequency List from Quran[edit]

The subpages have been showing up intermittently in Category:Pages with module errors because {{l}} now transliterates, so the {{xlit}} makes 2 transliterations per line and the page tends to run out of script execution time. Could someone who knows what they're doing remove the autotranslit column? I ran into text-direction issues that scrambled things when I converted between formats.

It may actually be possible to consolidate further, since the Arabic text in all three Arabic columns seems to be identical (@Atitarev: should be able to confirm). If it is, then it would be best to have the lemma column changed to use {{l}} and the other two Arabic columns removed. Thanks! Chuck Entz (talk) 00:15, 7 September 2014 (UTC)

I did exactly this. Benwing (talk) 11:26, 7 September 2014 (UTC)
Thank you! No more module errors on those pages. Appendix:Arabic Quranic Verbs has similar problems, but I'm not sure it can be fixed the same way. Chuck Entz (talk) 14:34, 7 September 2014 (UTC)
I edited the verb pages to remove the unvocalized column and link the vocalized column but that doesn't eliminate the module errors entirely. Is there no way to mark an individual page as needing more time to run? If not maybe we will end up having to break the 1-1000 page into two (1-500, 501-1000). Benwing (talk) 23:02, 7 September 2014 (UTC)
As far as I know, there isn't. It seems to be close: the parser profile shows it consistently using about 10.3 out of the allowed 10 seconds. The best solution would be to fix it by streamlining your transliteration code, but if that's not be possible, breaking the page up into shorter pages would be a good idea. There's nothing magical about 1000 lines per page, and it's much too big to really navigate through, anyway. We've been having several long and heavily-templated pages showing up with this error every few days, but those clear up with a null edit (I suspect running of processes by system people or heavy usage are temporarily slowing the system down). This one can sometimes be cleared to the point that no module errors show on the page, but not to the point that it disappears from the maintenance category. Chuck Entz (talk) 14:12, 10 September 2014 (UTC)
I'm not sure if it's possible to fix up the transliteration code that much. The problem may have happened when I added code to return nil upon encountering unvocalized text, which requires a bunch of additional pattern subs. But this is good functionality to have; otherwise you end up with incorrect transliterations. So maybe it should just be split in two. Benwing (talk) 19:09, 10 September 2014 (UTC)
Why does returning nil cause "a bunch of additional pattern subs"? --WikiTiki89 02:28, 11 September 2014 (UTC)
Because of the additional checks necessary to determine whether a word is properly vocalized. Benwing (talk) 20:29, 11 September 2014 (UTC)
If you do it right, you would transliterate and check at the same time and it should be pretty fast. Of course Lua makes it difficult to "do it right", due to its lack of native support for Unicode characters. Anyway, I misunderstood you. I thought you meant that returning nil itself causes "a bunch of additional pattern subs" in the calling module. --WikiTiki89 14:10, 12 September 2014 (UTC)
Hmm, that is a possibility. Some of the subs are shared between transliterating and checking for nil, and some aren't. For example, once the exceptional cases are handled, transliteration just maps all the remaining characters to Latin equivalents regardless of the exact sequence of consonants and vowels, but checking for nil needs to check to make sure the ordering is correct. Benwing (talk) 20:07, 12 September 2014 (UTC)

┌─────────────────────────────────┘
I split the verb page in two. Hopefully this will eliminate the errors. Benwing (talk) 14:48, 13 September 2014 (UTC)

Workshop: Greek and Latin in an Age of Open Data[edit]

This event, at the University of Leipzig in December, may be of interest: Workshop: Greek and Latin in an Age of Open Data. It would be good to have somebody there to represent and speak about Wiktionary and Wikidata. Pigsonthewing (talk) 15:59, 7 September 2014 (UTC)

undocumented template: anchor[edit]

Template:anchor

  1. has no documentation
  2. and seems to have some problems in its implementation

Furthermore, it's had these problems for 5½ years. Can someone(s) competent, as I am not, please take care of these? Thnidu (talk) 16:18, 7 September 2014 (UTC)

@Thnidu: There are 64 pages which transcludes the mentioned template, in which 21 pages are in the main namespace or appendix namespace. Moreover, {{jump}} contains more function and is more useful than the mentioned template, and most pages use {{jump}} instead of {{anchor}}. Therefore, I think that this template is not even necessary. --kc_kennylau (talk) 17:20, 8 September 2014 (UTC)
Does {{jump}} work from links from other wikis? The specific page which anchors are needed for is biscuit, which Wikipedia is going to (or already does) link to different sections of like this. - -sche (discuss) 19:23, 8 September 2014 (UTC)

Broken sort[edit]

When using {{der3}} I found that Ancient Greek entries wouldn't sort correctly; for example entries starting with β would come before ἀγ would come before δ.

After some digging ({{der3}} calls Module:columns calls table.sort) I've found that Scribunto appears to somehow override the > operator so that it'll interpret á/ä/ą/etc. as "a" (instead of sorting them by Unicode value as usual); however letters with Ancient Greek diacritics (ἀ/ᾳ/ἁ/ᾶ) are treated as an empty string. I don't know how to fix this, or even where the relevant code might be. If anyone could solve this problem, or even point me in the right direction, that would be great. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 17:38, 7 September 2014 (UTC)

Echo and watchlist[edit]

Special:Notifications & Special:Watchlist substantially overlap in functionality, except the former also contains extra (some non-public) events and doesn't provide with passive usage options (means to turn off web-nagging or email-nagging and to just keep visiting the page whenever I'm free), while the latter doesn't provide with options of active web-nagging notifications (but already provides email interface). Partly, in my personal view, the Echo/Notifications project was driven by low usability of watchlist; [2] comes to mind. It's also perhaps worth noting that Echo users aren't exposed to Special:Notifications unless thy have JavaScript disabled — in which case it's their only means of reading the notifications.

I'd like to get this done:

  1. Merge these two pages into one.
  2. To remedy large inflow of information, introduce multiple levels of importance of the web-nagging notifications (red for mentions, orange for thanks, blue for new watchlist items, etc and configurable in your settings).

Thoughts on both, please? --Gryllida 02:24, 9 September 2014 (UTC)

This is something you should propose at MediaWiki. Wiktionary has not control over it. --WikiTiki89 02:34, 9 September 2014 (UTC)
We indeed lack control, but I'd like to see whether we'd like to see this change before I go and make it happen. The purpose of this question is to determine peoples' opinions. -Gryllida 22:18, 9 September 2014 (UTC)
Well then you're asking the wrong question in the wrong place. The WT:Beer parlour would be the right place for making decisions. The Grease pit is for technical questions, implying that you have questions about how to do this. --WikiTiki89 13:09, 10 September 2014 (UTC)

New errors on Arabic pages[edit]

Please bear with me. I just redid {{ar-verb}} so it automatically infers radicals from the page name and automatically generates the correct verb parts (as much as this is possible). In the process this has flushed out some existing errors of various sorts and I need to fix them one by one. Benwing (talk) 20:40, 10 September 2014 (UTC)

Template:sv-noun[edit]

This template does not categorize into Category:Swedish lemmas, but presumably it should. —Aɴɢʀ (talk) 21:46, 12 September 2014 (UTC)

Fixed. —CodeCat 21:59, 12 September 2014 (UTC)

How do you indicate the argument frame of a verb?[edit]

The verb باحث in Arabic has the approximate meaning of discuss, but it is a form III verb, and like other such verbs, it takes a person as a direct object (who you're discussing with), and the topic of discussion appears after the preposition فِي () "in". I have tried to indicate that as follows, but I don't really think this is right, and it looks ugly:

  1. to discuss with (someone) (a question (with فِي ()))

In linguistic terms, what I'm trying to describe is the argument frame of the verb. In my dictionary, it appears as follows:

to discuss (ه with s.o.) (فِي a question)

where the ه (a letter "h") is a standard Arabic dictionary abbreviation for a direct object that's a person. However, I'm not sure if this formatting makes sense for Wiktionary. (Oddly, the standard abbreviation for a direct object that's a thing is ه‍, which is also a letter "h" but in its combining form.) Benwing (talk) 05:55, 13 September 2014 (UTC)

This is a problem in many languages, and has been discussed before: Wiktionary:Beer parlour/2014/February#French Verb Usage With Prepositions
I created {{+preo}} and {{+obj}} to deal with this problem (both are implemented using Module:object usage); see the backlinks for some examples. The templates are somewhat experimental, and I never really thought about applying them to RTL languages. Here is how they would be used like:
  1. to discuss [+ (direct object) = with someone] [+ فِي (indirect object) = the question]
Or something similar. The styling should be definitely changed to something more readable, but I have no real idea how. Keφr 07:07, 13 September 2014 (UTC)
The way I like to handle this is to add two or three examples after the definition/translation, and also include a Usage notes section for clarification. —Stephen (Talk) 07:27, 13 September 2014 (UTC)

Breves in Ancient Greek[edit]

According to the A.A.G. page and this conversation, breves and macrons in A.G. should be marked in the pronunciation, headword, and inflection tables, but not in the entry name. When placing macrons in inflection tables, the automatic linking will replace an , , or with each's non-long form, but this is not the case for breves. As such, an inflection table with breves will link to a page with a breve in the title. Is there a reason breves have not been added into automatic linking, and if not, could an admin add them? —JohnC5 (Talk | contribs) 07:39, 13 September, 2014 (UTC).

For Latin, the assumption is that a vowel lacking a macron is short. I think we should do it the same way for Ancient Greek. —CodeCat 19:54, 13 September 2014 (UTC)
The argument was made that many beginning A.G. dictionaries do not contain macrons and breves, and so a lot of entries with unmarked vowels are ambiguous as to whether they are short or just not added correctly. Regardless of whether we decide to use breves, which I favor, doesn't it still make sense to add breve removal to the automatic linking so as to stop the linking problem in the future? —JohnC5 (Talk | contribs) 08:04, 13 September, 2014 (UTC).
Breves are not currently stripped for Latin, as we don't include them to begin with. The practive for Ancient Greek and Latin should really be the same. So if we should include breves for Ancient Greek but not Latin, I wonder why? —CodeCat 19:29, 15 September 2014 (UTC)
Atelaes makes the case (in his post timestamped: 21:02, 19 June 2007 in the conversation linked to by User:JohnC5 above) rather well for why we should use brachiae in describing Ancient Greek:
  • "[Y]es we are indeed using breves in this dictionary…. Here's the reason: most of the Ancient Greek entries do not have any macrons or breves. So, a blank vowel needs to be assumed ambiguous. Thus, a blank vowel cannot be assumed to be short. Thus, breves must be allowed."
That makes sense to me, and I agree with him. Whether to use breves in Latin is another question; I don't necessarily agree with your assertion that "[t]he practi[c]e for Ancient Greek and Latin should really be the same."
I support extending macra-stripping to brachia-stripping for Ancient Greek. — I.S.M.E.T.A. 00:51, 16 September 2014 (UTC)
I don't understand your reasoning. If most Ancient Greek entries don't have macrons, then we should add them where needed. That's not a reason to add breves. —CodeCat 01:12, 16 September 2014 (UTC)
To quote that same post by Atelaes:
  • "[W]e have to allow for editors to input entries with ambiguous vowel lengths when they don't have access to that information…, or for the myriad of A. Greek words which we simply don't yet know what the vowel length is." [my emphasis]
 — I.S.M.E.T.A. 01:24, 16 September 2014 (UTC)
Why wouldn't that apply to Latin too? —CodeCat 01:30, 16 September 2014 (UTC)
I suppose it would, but so what? — I.S.M.E.T.A. 01:31, 16 September 2014 (UTC)

┌─────────────────────────────┘
I believe it should, frankly. Then again, the situation for Latin may be different due to markings or corpus availability. In all other respects I support per Atelaes. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 02:19, 16 September 2014 (UTC)

@ObsequiousNewt: I'm inclined to agree with you and CodeCat, but my point is that this is a discussion about Ancient Greek specifically, and not a discussion about our general policy with regard to all extinct languages with phonemic vowel quantity and orthographic ambiguity with regard to vowel quantity. In the same way that the proposal to strip brachiae from Ancient Greek links has been extended to the stripping of breves from Latin links, it could be extended to the stripping of breves from Old English links (for Latin and Old English are, after all, both "extinct languages with phonemic vowel quantity and orthographic ambiguity with regard to vowel quantity"). Let's not be too hasty. If this change to our practice concerning Ancient Greek is agreeable to everyone, it can then, later be cited as a precedent in the argument in favour of marking short vowels in Latin using breves (and therefore stripping them from Latin links). — I.S.M.E.T.A. 14:21, 16 September 2014 (UTC)
Agreed. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 14:29, 16 September 2014 (UTC)
I still oppose the use of breves to mark short vowels, in any language. They make words look very messy and hard to read, and in certain fonts and resolutions they even look (almost?) indistinguishable from macrons. Macron-vs-no macron is much easier to distinguish than macron-vs-breve. —CodeCat 15:00, 16 September 2014 (UTC)
@CodeCat: In my experience, macra and breves are easily distinguishable — far more so than, say, tildes and double-acutes ( ˜ · ˝ ) or breves and háčky ( ˘ · ˇ ). But in any case, there's far more trouble with distinguishing some of the Ancient Greek diacritics that are part of its actual orthography, namely the oxia, baria, psile, and dasia ( ´ · ` · ᾿ · ῾ ). Distinguishability, in the case of Ancient Greek, really isn't a problem for macrae and brachiae, because if your font's confusing those two, you haven't got much of a hope distinguishing the obligatory diacritics. — I.S.M.E.T.A. 15:36, 16 September 2014 (UTC)
  • As a discussion about what should be done rather than how it should be achieved, this does not belong to Grease Pit. --Dan Polansky (talk) 17:50, 16 September 2014 (UTC)
Fine. Am I right that all that needs to be done is to tweak Module:languages/data3/g, changing this:
m["grc"] = {
entry_name = {
from = {"ᾱ", "ῑ", "ῡ"},
to this:
m["grc"] = {
entry_name = {
from = {"ᾰᾱ", "ῐῑ", "ῠῡ"},
– yes? — I.S.M.E.T.A. 18:44, 16 September 2014 (UTC)

@Carriearchdale, DelianDiver, Dimboukas, Furius, Guovssahas, @Jaxlarus, Jmolina116, Omnipaedista, Paul Pela, Salmoneus.Aiolides; @Declan Clam, Espoo, Johanna-Hypatia, Leonariso, Medellia, MGorrone, Nyelvérzék, Oberlinclassicist, @Paepaok, PierreAbbat, Stelio, Svlioras, Znex, Λεξικόφιλος, Ο Ελληνόαυστραλός βοηθός: As members of Category:User grc-3 and -2, I figured I should ping you all so that you can have your input. — I.S.M.E.T.A. 21:00, 21 September 2014 (UTC)

I'm no expert on the long and the short of α, ι, υ; what I read is prose. But I do know a fairly long minimal pair. Συναλιζόμενος occurs in Acts 1:4. According to an appendix in the AENT, with a long α it means "gathering with" (And gathering with [them], he told them...), but with a short α it means "eating salt with" (I don't see "eating" and suspect it's "salting with", but have no occurrence in context). PierreAbbat (talk) 05:03, 22 September 2014 (UTC)

It doesn't have to mean "eating salt with". It can also mean "eating with". This example is a bit odd, because no one can agree on the exact meaning: apparently all three interpretations have problems. Yes, there's a third interpretation: as a variant of a verb meaning "to stay with". Still, the question here isn't whether length should be indicated, but whether it should be indicated by macron vs. absence of macron or macron vs. breve. Chuck Entz (talk) 05:31, 22 September 2014 (UTC)
I agree with not marking short vowels with breve. This is only ever done for extreme and deliberate clarification of a vowel length. An unmarked vowel should be assumed to be short, and long vowels should be marked with macra. Any ambiguous vowels, which are rare, should be doubly marked (such as ᾱ̆ – note these may not show up well with some fonts). This is the way I tend to mark vowels myself in both Greek and Latin. It removes the need to mark all vowels and makes the language look cleaner and easier to read, and I believe it is the norm nowadays as well. -Jmolina116 (talk) 13:23, 23 September 2014 (UTC)
I support marking ambiguous vowels with macron plus breve. —CodeCat 17:06, 23 September 2014 (UTC)
I would interpret ᾱ̆ as meaning "this form is attested with both long and short α", not "it is uncertain whether the α in this form is long or short". —Aɴɢʀ (talk) 18:27, 23 September 2014 (UTC)
I think it just means "ambiguous vowel length", i.e. either of those two explanations. I don't really know if there is any real way to distinguish between those two, and to my knowledge no grammars or dictionaries do. In actual texts (both Greek and Latin), neither breve nor macra are included, and one just has to figure out which it is (although it is usually irrelevant). In many dictionaries, such as the Lewis and Short for Latin and the Middle Liddell for Greek, macra and breve are only used to disambiguate vowel qualities that are deemed not to be "obvious", for example the υ in συν- is never marked in any compounds as it's always short. I disagree with this method because it assumes a certain level of knowledge of the user. They also do not mark vowels in closed syllables as these syllables are already heavy and the vowel's length is irrelevant for metrical purposes. I also disagree with this as it assumes that meter is the only reason one would want to know vowel length, and there are plenty of other scholarly reasons for wanting to know the length of the so-called "hidden vowels". I think most of us here agree that we should indicate as much information of the vowel quality as possible and let the user decide what they deem to be relevant and irrelevant information. The reason I mention this is to point out that sources and texts vary in their methods of marking vowel length. Textbooks do as well: the Hansen & Quinn leaves short vowels unmarked and marks long vowels with macra; the Athenaze never marks vowel length with macra or breve. I don't know of any sources who mark both short and long vowels and leave unmarked vowels for the far less frequent ambiguous vowel lengths, but I would like to know if anyone knows a text that does. Even so, my reasoning for not marking it is the convenience of not having to mark every vowel in most words. It might also be worth mentioning that marking vowels with both a length mark and with other diacritics is not easy to do in Unicode and doesn't always show up well, so I would suggest minimizing those cases to as few as possible. Sorry for the lengthy response. –Jmolina116 (talk) 02:57, 24 September 2014 (UTC)
Having said that, I'm still in favor of autoreplacing breve-ed vowels with unmarked vowels, just in case they are ever typed as such. If they all get replaced by unmarked vowels assumed as short, then it won't be an issue, but it's better to make sure we're not linking to blank pages where pages do exist. –Jmolina116 (talk) 00:01, 24 September 2014 (UTC)

Playing audio repeats the first bit on the second play.[edit]

I don't know if this is a firefox issue or a windows 8.1 issue. I click play and it repeats the first parts so, for example, kiwi sounds like k-kiwi. If I reload then it will play one time correctly. Could someone tell me what direction to go for a fix? Thanks.

It's not a Windows issue- I get the same thing on my Mac (Firefox 16.0.2), though I have yet to hear it on Safari (5.0.6). It also seems to vary from clip to clip: on the page for kiwi, the Dutch clip never does it, but the Canadian French one does. Chuck Entz (talk) 21:18, 13 September 2014 (UTC)
Thanks Chuck. The Dutch clip is also doing it, but but because there is some dead space at the front it is just repeating the background noise. You can kind of hear a sh sound. Gbleem (talk) 22:54, 13 September 2014 (UTC)
Same issue here, and I use neither OS. I also get the same problem on w:. MediaWiki bug, I guess. Keφr 05:21, 14 September 2014 (UTC)

WOTD maintainer?[edit]

Hi everyone, I got a message from the toolserver list that mentioned my ancient WOTD tool (that was turned off in 2009?) is currently getting the most "404 - Page not found" errors. That is, something like 2403 page hits per day.

Can someone please identify the best redirect to be used there? Thanks in advance. --Connel MacKenzie (talk) 23:15, 13 September 2014 (UTC)

There was a WOTD tool? (Also, hi. Do you mind being de-checkusered?) Keφr 05:25, 14 September 2014 (UTC)
I’m not sure what you’re asking, Connel, but, as I understand it, the toolserver tools are being migrated to Labs (tools.wmflabs.org). You probably already knew that, but just in case you didn’t. —Stephen (Talk) 14:39, 16 September 2014 (UTC)

Template:br-noun[edit]

Hi. Can someone please fiddle with Template:br-noun to allow multiple plurals to be shown: for example koad, which has a couple of plurals. I attempted it, but am utterly inept at templates. --Type56op9 (talk) 09:24, 17 September 2014 (UTC)

This and this seem to have fixed that; however, I don't understand how that f2accel= stuff works, so I might've broken something with that... :-S  — I.S.M.E.T.A. 09:48, 17 September 2014 (UTC)
@I'm so meta even this acronym: It's explained on the documentation for {{head}}. Basically, each number f1, f2, f3 etc. corresponds to a pair of positional parameters following the part-of-speech category parameter. Like so: {{head|lang|category|1|1|2|2|3|3|4|4|5|5|...}}. That means that if you insert a new pair in the middle, like you did, then you have to increase the numbers of all the f-parameters following it by one. I've done that now. —CodeCat 21:34, 21 September 2014 (UTC)

Visual Editor[edit]

Is there a reason why Visual Editor is not available as a beta feature here? There are some things for which I have found it very useful. Cheers! bd2412 T 14:57, 17 September 2014 (UTC)

  • I oppose introduction of Visual Editor into English Wiktionary in any form other than as an opt-in. Furthermore, I think this is a Beer parlour subject, since it deals with what should be done rather than how. --Dan Polansky (talk) 18:04, 17 September 2014 (UTC)
    • So what you're really saying is that you support its introduction as an opt-in, except that "support" is probably some kind of swear word to you. —CodeCat 18:36, 17 September 2014 (UTC)
      • Nice one. But I guess if there is a proposal, I will oppose it too (even an opt-in), not on bureaucracy grounds, but because 1) it will encourage creation of manually-formatted entries by clueless users (i.e. '''paradise''' (''plural'' '''[[paradises]]''') plus manually added categories), which are error-prone and not malleable to mass conversions like adding lemma categories; and 2) it does not make it any easier to use the preferable method of formatting and categorising entries here, which is through templates. VE is fine (at least in principle; the actual implementation is rather obnoxious) for relatively free-form articles like there are on Wikipedia, but not for rigidly-templated Wiktionary entries. If we want to make a WYSIWYG editor, it should be WT:ELE-aware, and should use and understand templates transparently. Keφr 19:29, 17 September 2014 (UTC)
      • No, CodeCat. "support" is not a swearword. I support that your bot gets the bot flag removed, I support that you are desysopped, and I support that you are banned from Wiktionary. Other than that, plenty of my "support" votes are found in various Wiktionary votes. --Dan Polansky (talk) 05:19, 18 September 2014 (UTC)
        • Well, if you put it that way, then sure, you support a lot of things. Mostly that nothing here should change, ever. Keφr 05:42, 18 September 2014 (UTC)
          • Check the past votes before you post yet another inaccuracy. --Dan Polansky (talk) 05:51, 18 September 2014 (UTC)
  • I agree that this introduction of new default features is not a GP matter. I strongly oppose any implementation of new default features of any kind without BP discussion. DCDuring TALK 19:04, 17 September 2014 (UTC)
    • I believe BD was merely asking a question, not making a formal proposal. Beta features are not enabled by default anyway, except for users who explicitly enabled that. And VE is still in testing stages. Keφr 19:29, 17 September 2014 (UTC)
      • Based on past experience, anything less than clearly expressed opposition to undesirable possible actions can be taken as implicit support. Sow the wind, reap the whirlwind. DCDuring TALK 19:57, 17 September 2014 (UTC)
        • To be clear, I would like the option of using Visual Editor here, as an opt-in only tool. I quite frankly loathed it when it was first introduced, but have played around with it a bit and found that it is a very fast way to make WYSIWYG edits, particularly when you are working on long pages and want to be able to tell the red links from the blue links while you work. bd2412 T 03:00, 18 September 2014 (UTC)
      • Merely asking a question? In Wiktionary:Requests_for_moves,_mergers_and_splits#Rhymes_pages_from_using : as_the_separator_to_using_/, an editor merely asked a question: "Why keep the hyphen?" No one responded. Later, the hyphen got removed without any further discussion by CodeCat. I support that CodeCat is banned. --Dan Polansky (talk) 05:19, 18 September 2014 (UTC)
  • I changed my mind; I oppose introduction of Visual Editor in any form or manner, even as an opt-in. I recall how I gave in and allowed the introduction of LiquidThreads in a vote, and am I sorry that I did; the amount of harm the abomination made in multiple talk pages is significant. --Dan Polansky (talk) 05:19, 18 September 2014 (UTC)
    • I am sorry to hear that. Where can I see that harm? Though I fail to see how VisualEditor and LiquidThreads are related, especially that "opt-in" means different things for the two. Keφr 05:42, 18 September 2014 (UTC)
      • Your edit summary (diff): "spreading FUD as usual". No other comment from me to your post. --Dan Polansky (talk) 05:51, 18 September 2014 (UTC)
        • I will take that as an agreement with that assessment of you. Keφr 06:12, 18 September 2014 (UTC)
          • Dan, whatever disagreements you have had with CodeCat and others over these procedures have not involved me. Please let me have this tool. Cheers! bd2412 T 13:50, 18 September 2014 (UTC)
            • bd2412, let me state that I hold you in high esteem, and that I am sorry that your proposal got mixed up with inflammatory posts by other editors. --Dan Polansky (talk) 07:44, 20 September 2014 (UTC)
              • Much appreciated. bd2412 T 15:18, 20 September 2014 (UTC)
Vote, then? I wouldn't object to opt-in, but I don't want to see it as a default unless/until it has undergone huge amounts of work to tailor it to Wiktionary's specific needs! Equinox 13:54, 18 September 2014 (UTC)
  • I have no desire whatsoever for VE as a default here (it has been pointed out that at present it is awful for templates); I would like to have it in the toolbox as an opt-in. That's all I ever wanted here. bd2412 T 13:59, 18 September 2014 (UTC)
    • I struck my opposition to an opt-in; changed my mind to neutral. Though I still fail to see the benefit of it and I would not recommend that it be used by newbies. Keφr 08:04, 19 September 2014 (UTC)
I would only support a very difficult opt-in. Such as a modification to Special:MyPage/common.css or Special:MyPage/common.js. That way, only users who really, really want it can have it. --WikiTiki89 17:42, 18 September 2014 (UTC)
  • I support the introduction of VE, at least as opt-in. —Mr. Granger (talkcontribs) 22:33, 18 September 2014 (UTC)
  • Comment: I have asked the VE people whether they could enable VE with futher restrictions, for example as an admin-only tool, or as a tool for users whitelisted through a process similar to whitelisting for AWB, and was told that they can not. The most restrictive option they offer is the opt-in for registered users. I think that they could give us more restrictive access to it if they wanted to put in a modicum of effort. Therefore, although I believe that this restriction is enough to prevent misuse, I can live without it, and will not push for it over community objections. bd2412 T 15:18, 20 September 2014 (UTC)

Template deletion[edit]

I created a template documentation with a misspelt name just now — Template:RQ:Blwnds_TLdgr/documentation — and I've cleared it out but don't know how to delete it. Would someone please delete it, or tell me how to. Sorry for the blunder. — ReidAA (talk) 01:15, 19 September 2014 (UTC)

Yes check.svg Done. — Ungoliant (falai) 01:19, 19 September 2014 (UTC)
{{delete}} is intended for the job of drawing attention to something that (almost) certainly should be deleted without a {{rfd}} vote. DCDuring TALK 01:22, 19 September 2014 (UTC)
Do you mean that if I had just put {{delete}} in the emptied documentation then it would have automatically been notified to someone authoritative? Thanks for the prompt response (and deletion). — ReidAA (talk) 01:51, 19 September 2014 (UTC)
Yes, even if it hadn't been emptied. DCDuring TALK 04:03, 19 September 2014 (UTC)

Noun5, really ?[edit]

Hi,

I am surprised to find an article anchor named "Noun5". I see in m:Help:Link#Anchors that anchors names are positional names, which, I guess, implies that adding a new section named "Noun" before the one with anchor name "Noun5" would make the "old Noun5" become "Noun6", and "Noun5" anchor would move to a new content.

It would be a lot more useful to include at least the language name in the anchor name, for example "EnglishNoun". And why not the whole hierarchy, for example "EnglishEtymology2Noun".

At the moment I feel that linking to a wiktionary article subsection is pretty dangerous.

Regards.

This is why we (should) avoid linking to subsections other than languages. —CodeCat 16:09, 19 September 2014 (UTC)
Since our entry structure isn't recognized by the wiki software, as long as the headers are done via wiki syntax, there's no way to guarantee the anchor automatically generated for non-unique headers, and only the language headers are unique. The workaround is to use a template that creates an additional anchor to link to. Aside from {{anchor}}, There's also {{senseid}}, which has more functionality and is better documented. Chuck Entz (talk) 17:21, 19 September 2014 (UTC)
There is something else that might work. We can use Javascript to modify various elements on a page, so that they have the right ids for linking to. —CodeCat 18:18, 19 September 2014 (UTC)
It would be nice to be able to do something hierarchical like pan#English.Etymology 1.Verb. --WikiTiki89 18:26, 19 September 2014 (UTC)
Do all users have access to JS? Are there version problems? Do we have the ability to do it in a way that failed gracefully if a user didn't have JS or the version was wrong or old? DCDuring TALK 18:37, 19 September 2014 (UTC)
JS has been around for decades now, so it's pretty much universal. —CodeCat 19:02, 19 September 2014 (UTC)
Everyone has JS, but a some people very few people disable it for who knows what reasons. JS errors are invisible, but they often interrupt the rest of the JS, causing a chain of lost functionality. --WikiTiki89 19:05, 19 September 2014 (UTC)
And I suppose we only do relatively standard JS. DCDuring TALK 20:05, 19 September 2014 (UTC)

What the...?[edit]

How did Talk:Broken/rhymes\x3aEnglish\x3a-e\xc9\xaa\xca\x83\xc7\x9dn get created from [[Talk:rhymes:English:-eɪʃǝn]]? At least it looks like that's what happened, since the edit history includes a move by the conversion script to lowercase with the comment "[[Talk:Rhymes:English:-eɪʃǝn]] moved to [[Talk:rhymes:English:-eɪʃǝn]]", and there were no further moves. Chuck Entz (talk) 20:46, 19 September 2014 (UTC)

\x3a == '0x3a' == ':', it's just broken encoding. DTLHS (talk) 20:49, 19 September 2014 (UTC)
I've deleted it now. —Aɴɢʀ (talk) 20:49, 19 September 2014 (UTC)
I figured out that much- but how did that happen in the first place? Chuck Entz (talk) 21:00, 19 September 2014 (UTC)
What also confuses me is why your links above don't work. --WikiTiki89 22:42, 19 September 2014 (UTC)
I'm guessing that the change in syntax for the Talk namespace is involved with both somehow- perhaps the former syntax is left unparsed for some reason, and the mystery page is one that got lost in the transition. You might also look at this prefix search, which brings up a few more. Chuck Entz (talk) 23:13, 19 September 2014 (UTC)

{{ja-altread}}[edit]

See 一日千秋. I want to have no space in the katakana and a space in the romaji, but this would cause it to be added to a tracking category. --kc_kennylau (talk) 15:29, 20 September 2014 (UTC)

User:Visviva/Elsewhere[edit]

IMHO, User:Visviva/Elsewhere is an excellent page, spotting what we lack that other Wiktionaries have. Since the last time it was created, most red links have been turned blue, which is always a Good Thing. Would anyone be able ro regenerate it? --Type56op9 (talk) 10:33, 21 September 2014 (UTC)

@Type56op9: User:DTLHS/elsewhere DTLHS (talk) 04:46, 23 September 2014 (UTC)

Burmese characters[edit]

What it looks like now

I have multiple Burmese-compatible fonts installed on my computer. I used to be able to see Burmese characters everywhere on Wiktionary without any problem. For the past several weeks, though, all I see is boxes in page titles and in the edit field, though the characters still appear correctly in the main body of entries. Any ideas why this is happening and how I can get the Burmese characters back everywhere I need them. Editing Burmese entries is very frustrating when all I see in the edit field is little boxes. —Aɴɢʀ (talk) 19:06, 21 September 2014 (UTC)

A picture being worth a thousand words, I've added a picture. Forgot to mention I'm using Firefox on Windows 7. —Aɴɢʀ (talk) 19:12, 21 September 2014 (UTC)
Same results on IE, but characters do display correctly on Chrome. —Aɴɢʀ (talk) 19:16, 21 September 2014 (UTC)
@Angr: Headers use serif fonts now, whereas the main-body text still use sans serif fonts; might that have something to do with it? — I.S.M.E.T.A. 20:45, 21 September 2014 (UTC)
Maybe, but playing around with the default serif fonts in my Options doesn't help. Even changing the default serif font to a Burmese font didn't work. —Aɴɢʀ (talk) 21:09, 21 September 2014 (UTC)
Also the link to Burmese Wiktionary under "In other languages" on the lefthand side has boxes rather than characters, and that's a part that normally has sans-serif. —Aɴɢʀ (talk) 21:10, 21 September 2014 (UTC)
Also, even in the main text body characters appear correctly only if they're tagged as Burmese by being inside {{l}}, {{m}}, {{lang}}, etc.  Otherwise, it's boxes. —Aɴɢʀ (talk) 21:13, 21 September 2014 (UTC)
What happens if you replace {{lang|my|...}} with <span lang="my">...</span>? —CodeCat 21:14, 21 September 2014 (UTC)
Then I get boxes, not characters. —Aɴɢʀ (talk) 21:53, 21 September 2014 (UTC)
Then it's the alternative fonts applied through script classes and Lua autodetection that is making the text visible to you. I'm guessing that if you wrap it in <span class="Mymr">...</span> then it will display correctly. —CodeCat 22:13, 21 September 2014 (UTC)
Yep, that works. So how do I fix it? —Aɴɢʀ (talk) 22:41, 21 September 2014 (UTC)
I don't think there is an easy way that would fix this in all cases. It comes down to the fonts used. We can change the fonts used in page title headers, and maybe in edit boxes too. But of course that would be a rather major change, and even then it would be impossible to guarantee that everyone has that font, nor that the font can display every single possible character to begin with. For the edit box, the wiki specifies no font, so the default monospace font in your browser is used. If you change that font, it may fix it, but that's only going to work for your own computer, not the site in general.
The wiki software allows us to override the displayed page title. This is already used in a few cases, like on prefix and suffix categories (just go to the category for a non-Latin script suffix and you may notice it). This means that it's theoretically possible for a template to apply script detection and the appropriate script classes/fonts to the title itself. But to do that, we'd have to include that template on every single mainspace page. So it can be done, but I don't know if it's worth the effort. —CodeCat 22:48, 21 September 2014 (UTC)
The above solution with including a template would only work when the page is viewed of course, not when it's edited. But if we don't want to include a template on every page, an alternative could be to add this functionality into {{head}}. Every page contains this template, so it can do this too. I'm not sure what would happen when there are multiple instances of {{head}} on the page; it's possible the software will protest and show an error if a page attempts to override the page title more than once. —CodeCat 22:53, 21 September 2014 (UTC)
At this point, I'm content to fix it only on my own computer. But going to my browser options and changing the setting for serif font and/or monospaced font to a Burmese-compatible font doesn't even fix the problem. —Aɴɢʀ (talk) 22:54, 21 September 2014 (UTC)
Then I'm not sure what would work. I'm sorry. —CodeCat 22:55, 21 September 2014 (UTC)
Is there any way for his common.js to switch things? Chuck Entz (talk) 03:12, 22 September 2014 (UTC)

I have similar problems with Burmese characters after moving to Windows 7 on one of my computers. --Anatoli T. (обсудить/вклад) 02:30, 22 September 2014 (UTC)

For me, this started happening long after I switched to Windows 7. And the fonts do still display correctly on Chrome, but I usually use Firefox. I guess I'll just switch over to Chrome whenever I want to edit Burmese. —Aɴɢʀ (talk) 18:24, 22 September 2014 (UTC)
Probably related: Oriya script is not showing up. - -sche (discuss) 14:55, 27 September 2014 (UTC)
I don't know Oriya, but in that particular case it looks like diacritics might have been added in the wrong order. —Aɴɢʀ (talk) 15:41, 27 September 2014 (UTC)

𢞅[edit]

{{vi-hantutab}} fails to process character 𢞅 at 𠊛𢞅 and nothing is displayed. Pinging @Wyang:. --Anatoli T. (обсудить/вклад) 02:29, 22 September 2014 (UTC)

@Wyang: I see 𠊛𢞅 {{vi-hantutab}} have been removed. Are etymologies for người and yêu incorrect? If it's chữ Nôm, can the characters be still shown for etymologies, even if they are native Vietnamese, if they are correct? What about the entry 𠊛𢞅? --Anatoli T. (обсудить/вклад) 02:53, 22 September 2014 (UTC)
{{vi-etym-sino}} and {{vi-hantutab}} are only for Hán (Sino-Vietnamese) words. The word is not of Sino-Vietnamese origin, which is why I removed the {{vi-etym-sino}} template from người yêu. As far as I know, no multisyllabic Nôm words are included. If they are to be included, special templates have to be created, and citations would be compulsory. Wyang (talk) 23:35, 22 September 2014 (UTC)
Thanks. I agree that we need other templates for native Vietnamese or Nôm characters. Would you say 𠊛𢞅 should be deleted? It doesn't seem citable. --Anatoli T. (обсудить/вклад) 23:43, 22 September 2014 (UTC)
I would say delete, since it is uncited. A major problem with including Nôm words is that the currently digitised Nôm texts are most unsearchable. Available digitised historical texts online I know of include
  1. Nôm: the Tale of Kiều and two other texts (Chinh Phụ Ngâm Khúc and Lục Vân Tiên) by the Nom foundation,
  2. Hán/Nôm: Dự án số hóa kho tàng thư tịch cổ văn hiến Hán-Nôm
  3. Hán/Nôm: National Library of Vietnam
Of these, only the first is searchable. I found one citation of người yêu in the 1871 version of the Tale of Kiều: Người yêu ta xấu với người (𠊛腰些醜貝𠊛). Wyang (talk) 00:06, 23 September 2014 (UTC)
Thanks. I have deleted 𠊛𢞅 (before your last post) but it would be a pity if there ARE nôm texts but they are just not searchable. Please check the entry nôm, which has the sense "Sino-Vietnamese", which seems wrong. --Anatoli T. (обсудить/вклад) 00:22, 23 September 2014 (UTC)

References:The Bokmål Dictionary[edit]

I have a problem with certain words from the above reference being misread (by the template software?). It usually happens when two vowels are next to each other as in the case of beboer. In this case 'oe' is being read as 'ø', and the word is therefore not being recognised by the dictionary. It can also happen with 'aa', which is read as 'å'. In fact any Bokmål words containing the characters å, æ and ø are converted to 'aa' 'ae' and 'oe' respectively by the template software, but the dictionary usually copes with that. I think the same may happen with Nynorsk. Can a cure be found for this problem? Donnanz (talk) 12:18, 24 September 2014 (UTC)

It looks like the site itself is doing the conversion, prompted by the parameter "&alfabet=o". Is there a reason you include that? Chuck Entz (talk) 12:40, 24 September 2014 (UTC)
Hmm, not necessarily. If I go directly to the dictionary website and type in "beboer" it is read as "beboer" by the dictionary. I think the problem is at this end. Donnanz (talk) 12:47, 24 September 2014 (UTC)
A further test. You get the message "Vi har dessverre ingen informasjon om ordet "bebør" ...", but if you click on the Bokmål button the word comes up. A wee bit weird. Donnanz (talk) 12:57, 24 September 2014 (UTC)
If you look at the URL generated by the template, it has "oe": "http://www.nob-ordbok.uio.no/perl/ordbok.cgi?OPP=beboer&bokmaal=+&ordbok=bokmaal&alfabet=o". If you take out the "&alfabet=o", you get "http://www.nob-ordbok.uio.no/perl/ordbok.cgi?OPP=beboer&bokmaal=+&ordbok=bokmaal", which works. I suspect the "&alfabet=o" is for the purpose of accommodating those who can't easily produce the special characters on their keyboards. Chuck Entz (talk) 13:18, 24 September 2014 (UTC)

I think it's fixed now. The short story of the problem was that the dictionary site used to have a tricky character encoding (that doesn't seem to be the case any longer; though this change would not have had any effect on the template the way it was designed). --Njardarlogar (talk) 14:18, 24 September 2014 (UTC)

Ah, wonderful! Thanks very much! Donnanz (talk) 15:43, 24 September 2014 (UTC)

User problem with hidden quotations[edit]

See this BP comment. As I understand it the user did not see anything that gave him a sufficient hint that there were quotations for the definitions at the entry looked at. I found nothing at all remarkable in the formatting of the entry or its appearance on my screen. I put up some questions in case the user follows up on his posting. If the questions are completely irrelevant or misleading please strike them through. DCDuring TALK 18:20, 25 September 2014 (UTC)

Template:head linking things on either side of mid-dots[edit]

Possibly due to the changes which were made to Template:head/Module:headword a while ago (mentioned e.g. here), which expanded the set of 'probably multi-part' items which the template automatically linked the presumed parts of, terms like mo·s now erroneously link to "mo" and "s" — the mid-dot in fact indicates vowel length in Menominee and several other languages. Terms like al·legoria are also erroneously split. How should this be fixed? I would suggest that the template/module be modified to treat a mid-dot as an indication of a morpheme break only for certain listed languages that use it for that purpose, or vice versa (to not treat it as a morpheme break only for certain listed languages that use mid-dots for other purposes) based on whichever list would be shorter. - -sche (discuss) 04:09, 29 September 2014 (UTC)

I think the first way would be shorter. I don't know of any language other than Old Irish that uses the raised dot at a morpheme break, and even for Old Irish we only use the raised dot as part of the head= display, not in entry titles. And even if Old Irish did use the raised dot for entry titles, and we had entries like do·beir instead of dobeir, I still wouldn't want the headword line to display that as do·beir. —Aɴɢʀ (talk) 14:15, 29 September 2014 (UTC)

Lettering question[edit]

Hi,

How do you change the lettering? Thanks. —This comment was unsigned.

That depends what you're trying to do. You can make text italic by putting it inside double apostrophes ''like this'' and you can make it bold by putting inside triple apostrophes. —Aɴɢʀ (talk) 14:09, 29 September 2014 (UTC)
And you can change the font, and font size, using CSS. MediaWiki:Common.css sets the default fonts for various things, you can use your Special:MyPage/common.css to set different fonts for yourself. - -sche (discuss) 18:00, 29 September 2014 (UTC)

Deprecated JavaScript methods will be removed from MediaWiki next week[edit]

This was posted on w:WP:VPT#Many_deprecated_JavaScript_methods_will_be_removed_from_MediaWiki_next_week. I just checked and didn't find anything on this site that used any of the functions that are being removed, so it looks like we're in the clear. - -sche (discuss) 18:09, 29 September 2014 (UTC)

This was in the Tech News announcement just above this, but I thought it could do with a little more publicity. The following JavaScript methods and parameters will be removed from MediaWiki 1.25, which means that they will no longer be available on Wikipedia after 9 October:

  • mw.user.name() method.
  • mw.user.anon() method.
  • mediawiki.api methods' "ok" and "err" callback parameters.
  • mediawiki.api.category "async" parameter.
  • jquery.json module.

See the announcement on Wikitech-ambassadors for more details and for alternative code. []Mr. Stradivarius ♪ talk ♪ 10:29, 29 September 2014 (UTC)

A lot of scripts were cleaned up a couple of months ago, but it would be good to have these remaining ones addressed.
We need a template that says something like All your scripts are going to break! for critical announcements.
Also, for those of you who are active at other projects (other languages and/or non-Wikipedias, please spread the word. This has been announced repeatedly for months, but it's still going to catch some people by surprise. Whatamidoing (WMF) (talk) 17:03, 29 September 2014 (UTC)

Standardised interwiki prefixes now available[edit]

Just a heads up to let you know that a bug filed by Conrad Irwin back in 2009, Please add ISO code interwikis for non-standard language codes has now been (at least partially) resolved. This means that the following ISO language code interwikis now function correctly:

  • vro:, pointing to fiu-vro: (although there is currently no Wiktionary edition in this language)
  • cmn:, pointing to zh:
  • lzh:, pointing to zh-classical: (although there is currently no Wiktionary edition in this language)
  • yue:, pointing to zh-yue:
  • rup:, pointing to roa-rup:
  • gsw:, pointing to als: (although there is currently no Wiktionary edition in this language)
  • be-tarask:, pointing to be-x-old: (although there is currently no Wiktionary edition in this language)
  • sgs:, pointing to bat-smg: (although there is currently no Wiktionary edition in this language)
  • egl:, pointing to eml: (although there is currently no Wiktionary edition in this language)

Hopefully this reduces the amount of special casing that is required in places like Module:wikimedia languages/data.

For some yet-to-be-determined reason, a few ISO standard prefixes (such as nb: and nan:) are still not functioning correctly. I'm going to continue to look into this. This, that and the other (talk) 01:47, 30 September 2014 (UTC)

If someone removes these from the modules, remember that the linking is two-way. The data entries for the main languages also need to be edited. —CodeCat 02:00, 30 September 2014 (UTC)
It was agreed in BP that yue: can point to zh:. The Cantonese Wiktionary doesn't exist. If any doubt, I'll search for the discussion (it was the same page where it was suggested to point nn: to no:). --Anatoli T. (обсудить/вклад) 02:32, 30 September 2014 (UTC)
Also, I suggest be-tarask: to point to be:. Taraškevica spellings are older or alternative forms of Belarusian, e.g. сьнег (older form, Taraškevica) = снег, etc. And as was said above, be-x-old: doesn't exist. --Anatoli T. (обсудить/вклад) 02:37, 30 September 2014 (UTC)