Wiktionary:Grease pit/2014/July

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← June 2014 · July 2014 · August 2014 → · (current)

---

Loading entry data in JavaScript

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

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. Jamesjiao → ^{T ◊ C} 23:48, 1 July 2014 (UTC)

I was going to complain about {{zh-new}} not working (see this revision of 君主制 (jūnzhǔzhì), 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 翼. Jamesjiao → ^{T ◊ C} 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

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

Bare subpages as destinations for discussion section links?

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

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

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

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

{{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)

 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

I oppose Chinese interwiki warnings as with 赫茲／赫兹 (Hèzī), 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 赫茲／赫兹 (Hèzī) 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

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.
   • This is a simple quote.
   • So is this.
   • 1960, P[elham] G[renville] Wodehouse, chapter V, in Jeeves in the Offing, London: Herbert Jenkins, →OCLC:

     This is a quote with an RQ template.

   • This is a simple quote.
   1. This is a second level sense.
      • This is a simple second level quote.
      • So is this.
      • 1960, P[elham] G[renville] Wodehouse, chapter V, in Jeeves in the Offing, London: Herbert Jenkins, →OCLC:

        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.
   • This is a simple quote.
   • So is this.
   • 1611, The Holy Bible, […] (King James Version), London: […] Robert Barker, […], →OCLC, Genesis 32:38:

     This is a quote with a non-quote-book-using RQ template.

   • This is a simple quote.
   1. This is a second level sense.
      • This is a simple second level quote.
      • So is this.
      • 1611, The Holy Bible, […] (King James Version), London: […] Robert Barker, […], →OCLC, Genesis 32:38:

        This should be a second-level quote with the RQ template.

      • This is a simple second level quote (should be an unnumbered quote of the second level sense).
      • So is this.

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.

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

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

kevlar → Kevlar

x-ray → X-ray

--Catsidhe ^{(verba, facta)} 04:25, 10 July 2014 (UTC)

Template with raw link

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

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

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

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

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

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:

• Wiktionary:Beer parlour/2014/March#Whinge: AbuseFilter #24
• Wiktionary:Grease pit/2014/April#Modified Special:AbuseFilter/24
• Wiktionary:Grease pit/2014/April#Loophole, sort of
• Wiktionary:Grease pit/2013/October#Can't update another User's subpage.

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

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

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

(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

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

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

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?

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

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

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

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  Done by YS-Bot, thanks :) --Kronf (talk) 12:58, 13 August 2014 (UTC)

Orange links in tables of contents

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

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)