Wiktionary:Grease pit/2013/May

---

Currently, when a word is plural and also has a gender, this script generates things like {{head|xx|yyy|g=f|g2=p}}. In other words, it splits the gender in two, treating plural as a gender of its own. This has always been the normal behaviour and normal practice, but now there are also dedicated templates for this, {{f-p}} and so on. I created them in anticipation to the adoption of the replacement, Module:gender and number, which indicates genders in this fashion to avoid ambiguity (Specifically: Does f|p mean feminine and/or plural, or feminine plural? If we use f-p to mean the latter, then f|p is unambiguous.). However, although I was able to fix the translation editor, this script still creates entries the "old" way. And I'm not sure what to do to change it, because it still really confuses me every time I try to change anything. Can someone else help out please? —CodeCat 23:12, 3 May 2013 (UTC)[reply]

Am rather sick of removing links from {{trans-top}}, can we implement delink to it? It's Lua-based so I guess it should be quick, right? Mglovesfun (talk) 20:39, 4 May 2013 (UTC)[reply]

 Done. See User:Mglovesfun/sandbox, code seems to work for all link generating templates and not just square brackets. Mglovesfun (talk) 09:42, 7 May 2013 (UTC)[reply]

I've made a simple Sinhalese (Sinhala) transliterator. It does a very simple conversion but not too accurate. E.g. transliteration of සිංහල (siṁhala): {{#invoke:si-translit|tr|සිංහල}}: (currently produces "si ̃hl")

It ignores the inherent vowel "a", which is attached to every consonant (like Hindi and other abugida Indic languages). I have asked User:ZxxZxxZ, who has kindly fixed the module for Hindi Module:hi-translit (it still has some flaws, it uses too many "a"'s) but he is unavailable. User:CodeCat is also busy at the moment.

The transliteration rule is simpler in Sinhalese: consonants are transliterated as they are in the table but add an "a" if they are not followed by a diacritic or the the inherent vowel "a" is "killed" by "hal kirīma". So final consonants (unlike e.g. Hindi) still have an "a".

Could someone with a knowledge of Lua fix the module, so that all consonants have an "a" when not followed by a diacritic or "hal kirīma", please? You don't need to understand the Sinhalese script. Diacritics are a bit hard to work with, though. I used SC Unipad (free download) to work with diacritics - it breaks any string into components.

It's not urgent but would be great if someone could make it work, hopefully in a way so that the logic could be reused for other abugida scripts. Even Google Translate can't handle Sinhalese. A minor issue is anusvara, which marks nasalisation, which works similar to Hindi, see Wiktionary:Hindi_transliteration#Nasalisation. I used ̃ as a temporary solution. --Anatoli ^{(обсудить}/^вклад) 06:24, 7 May 2013 (UTC)[reply]

An existing dictionary is being made freely available, and now we need to import its entries into Wiktionary. But how? An example of an entry in XML format is shown at sv:Wiktionary:Teknikvinden#En tillgänglig ordlista i XML-format. It is easy enough to convert that XML to wiki markup. If there is no article, it can just be created. But when Wiktionary already has an article, the result needs to be merged with the existing Wiktionary entry. Are there any good tools or best practices for that? --LA2 (talk) 11:59, 8 May 2013 (UTC)[reply]

Probably bots. — Ungoliant ^(Falai) 14:55, 8 May 2013 (UTC)[reply]

Are you proposing adding these to the English wiktionary? I can take a look at it. DTLHS (talk) 02:10, 13 May 2013 (UTC)[reply]

In this case, all definitions are given in Swedish, so an import to Swedish Wiktionary is the primary goal. What I'm looking for is experience of merging such databases into Wiktionary. It might be easy to translate all definitions to English, for import here, and then we'd have the problem of merging the resulting list into English Wiktionary. But if nobody has ever done such a thing before, I'll have to develop my own methods from scratch. --LA2 (talk) 20:56, 14 May 2013 (UTC)[reply]

Why does {{etyl|kld|-}} generate Gamilaraay, a black link, instead of a link to w:Gamilaraay language? It certainly is not a well-known language. DCDuring TALK 20:31, 8 May 2013 (UTC)[reply]

A "black link"? You mean just a word written in black with no link at all? Because a while back the decision was made never to link language names regardless of how well known the language is deemed to be. —Angr 21:33, 8 May 2013 (UTC)[reply]

I'm actually wondering whether we shouldn't link the language all the time. I have occasionally come across etymologies that feature a language I haven't heard of, and a link to its definition would have been convenient. —CodeCat 21:46, 8 May 2013 (UTC)[reply]

I stole a line of code from Ruakh (I think from User:Ruakh/common.css) to always make them linked. I'd happily have that code work for everyone. Mglovesfun (talk) 13:57, 9 May 2013 (UTC)[reply]

I don't think CSS can make links out of nowhere, though. It must have been a JavaScript, but that doesn't seem like a proper solution to apply to the whole wiki. —CodeCat 14:11, 9 May 2013 (UTC)[reply]

It's in Wiktionary:Per-browser preferences, and yes, it depends on JavaScript. I've previously raised the possibility of turning it on for everyone (which wouldn't depend on JavaScript), and no one objected, but then I never actually got around to making the change. (Mea culpa.) If you are inclined to do so, please do! —Ruakh_TALK 05:19, 13 May 2013 (UTC)[reply]

I am not a programmer, so I do not know if it is a bug. In thermos, the translation section is strange. When I entered a Uyghur word, instead of the correct چايدان (ug) (chaydan), it shows چايدان (ug) (chaydan){{#switch:ug|ru= ({Turkish --Hahahaha哈 (talk) 14:57, 10 May 2013 (UTC)[reply]

I suspect it was this edit to {{t}} that has caused the trouble. —Angr 15:09, 10 May 2013 (UTC)[reply]

I seem to have fixed it, but would appreciate a double-check from people who are better at templates than I am. —Angr 15:15, 10 May 2013 (UTC)[reply]

I'm not really sure what motivated this sudden addition of even more parameters to this template. Their explanation was "it's to solve the long-standing problem where you can't associate several orthogonal chinese/japanese/korean variants to the same transliteration in a single entry" but I never considered that to be a problem. Has it been a problem for anyone else? And in any case, I really don't agree with their solution - two more parameters. Especially with Lua, we don't need these kinds of solutions at all, we can do better. —CodeCat 01:20, 13 May 2013 (UTC)[reply]

All additions are sudden. I've been annoyed by this missing functionality for a decade. Are you suggesting non-sudden additions such as submitting single character changes one by one? Or is "sudden" some kind of rhetoric or weasel word?

When you say you never considered the ugly workarounds for using {{l}} with Chinese, Japanese, and Korean a problem, does this mean that you have been using {{l}} with these languages at all?

In my talk page you used the terminology "does more harm than good" but you haven't touched on that topic here.

At last some sensible talk. I'm very much in favour of Lua solutions but I haven't started Lua hacking yet. As a programmer, I consider a lot of template stuff to be ugly hacks that could be elegantly solved in Lua, though I am a bit worried about people that want to parse our dump files to use our data in their own projects.

Is there a general consensus to halt all development on templates and move to Lua? I'd love to hear about it.

By the way I'm very keen to have a much less "turn taking" chat about all this stuff in the IRC cannel, #wiktionary on irc.freenode.net — hippietrail (talk) 01:31, 13 May 2013 (UTC)[reply]

It’s not sudden when you discuss the change with the community. — Ungoliant ^(Falai) 01:37, 13 May 2013 (UTC)[reply]

What I mean is that nobody else has ever had this problem, or at least not that I am aware. The current solution is to use two instances of the template; has that given any problems at all? What I meant by "more harm than good" is that it's better to discuss possible approaches to the problem rather than just picking one that might in the end not be very workable at all. The last thing {{l}} needs is more parameters; it and many other templates are already rather complex because they seem to be designed to cater to every possible situation. {{l}} isn't even the worst case, {{term}} is far worse with its lit= and pos= parameters. There is a general tendency to be like "this template doesn't do quite what I need... let's add another parameter!", but without much regard for whether it makes sense. Short term goals give long term problems. —CodeCat 01:37, 13 May 2013 (UTC)[reply]

I consider using two instances of the template to be a problem. I'm sure I'm not the only one that's been annoyed by that though I'm not sure why you might expect to be aware of it. Two instances of the template mean neither the wikitext, the HTML, nor the DOM associate the text as a cohesive unit for anybody trying to use our data. For human users there is confusion over whether to add the transliteration or other parameters to each instance, just the first, just the last, whether to put one inside parentheses, etc. At least one alternative template has been created to work around this for the Korean language, {{ko-inline}}. I'm not sure if you were or should've been aware of that template. I'm personally not sure whether there are other such workaround templates for Chinese, Japanese, or any other language. I wouldn't be surprised and I wouldn't be surprised if they all work differently and render differently and that the same people rarely use more than one of them. A consistent solution would be best.

I also dislike that we have these complex templates. In the early days I argues against using more of them but I lost the argument and became one of the ones implementing templates, way back when, though I haven't hacked them for some time now. Where they have been put into long-standing use though it's better to have capable templates.

I think you have to justify your stance that more parameters is inherently bad. Why is having more "the last thing it needs"? I actually don't find this template very complex, it's mostly inline where many other templates suffer from deep nesting.

I've already mentioned several times that I've been annoyed by this missing functionality for a decade so I find your use of the terminology "short term goals" to be quite ingenuous and you haven't elucidated what these "long term problems" are.

So let me put it to you: are you aiming to simplify templates by removing parameters that have "too many"? or are you advocating halting any further development of templates? Or do you have a Lua proposal to replace this template?

One more important question: Do you believe templates are to give editors less typing, or to bring uniformity to Wiktionary, or both? I personally feel that standardization is best for templates and I've seen them move that way. Parameters with the same name and same function have spread though there are still exceptions for instance.

irc://irc.freenode.net/wiktionary / irc://#wiktionary@irc.freenode.net — hippietrail (talk) 02:01, 13 May 2013 (UTC)[reply]

• @Hippitrail, might I suggest that you use / tweak {{ja-l}}, if your concerns are specific to Japanese? This offloads much of the problem from the much-used (and thus somewhat more complicated-to-change) {{l}}.

If you're looking for something that could be used for Chinese and / or Korean as well, perhaps use the code from {{ja-l}} to create {{cmn-l}} and {{ko-l}}? Cheers, -- Eiríkr Útlendi │ Tala við mig 03:31, 13 May 2013 (UTC)[reply]

As I mentioned there is already {{ko-inline}}. Are you really saying that having one template per language with unrelated names and dissimilar usage is a good thing? They certainly impair discoverability. Would you advocate that general purpose templates generally should be avoided in favour of developing separate templates for each language that users must learn? Surely uniform template names, uniform template parameters, uniform template use across languages is going to lower the barrier to entry. Does anybody know if there is a Chinese-specific equivalent to {{l}}, {{ko-inline}}, and {{ja-l}} - or for any other language for that matter? If disparate template names for individual attempts at solving the same problem is a good thing, how do we find those templates for the language we are not familiar with? — hippietrail (talk) 06:44, 13 May 2013 (UTC)[reply]

There seems to be a category for templates such as these, Category:Internal link templates - I've gone ahead and added the Korean and Japanese templates to it, I encourage anybody else to add such templates to the category that they know of or discover. — hippietrail (talk) 06:52, 13 May 2013 (UTC)[reply]

For consistency with all the other language-specific {{l}} templates, shouldn't {{ko-inline}} and {{ja-l}} be renamed {{l/ko}} and {{l/ja}}, or at least have redirect from those titles? Actually, upon preview I see we already have {{l/ja/Jpan}}; do we really need both that and {{ja-l}}? —Angr 12:15, 13 May 2013 (UTC)[reply]

The {{l/ja}} template should be a subset of {{l}}. Specifically, it should be possible to replace {{l/ja}} with {{l}} at any time without breaking anything. —CodeCat 14:17, 13 May 2013 (UTC)[reply]

• @Hippietrail, the issues you're dealing with (as best I understand them) involve special considerations required for CJK languages, and not for any others. Rather that your changes to {{l}} in an attempt to code in these considerations have apparently caused some kind of problem, it might make sense to instead have some other related template that builds in these considerations. If you can code something that plays well for all CJK languages, then great; if C or J or K has some specific coding need that makes things difficult, then create something specific for that one. I'm not a big fan of one-size-fits-all, because invariably it doesn't.

{{l}} is complex, and used far and wide, so any changes made to that must not adversely affect those entries using {{l}}. Moreover, perusing the source for {{l}}, it looks like this template would be significantly more processor-intensive than {{ja-l}}. There are various reasons that could warrant creating a different template to handle different specific needs.

Whether that template is called {{ja-l}} or {{l/ja}} or {{cjk-inline}} or what have you, is a different matter entirely, and not one I have any strong opinions about. (Though CodeCat's point about {{l/ja}} certainly makes sense.) Cheers, -- Eiríkr Útlendi │ Tala við mig 20:56, 13 May 2013 (UTC)[reply]

I've accumulated a text file with all the character sequences necessary to generate all possible lemma forms used by Perseus for their Liddell, Scott & Jones Greek Lexicon. Eventually I plan to try my hand at Lua programming with a module to replace most of the innards of the {{R:LSJ}} with code that translates the headword of a Greek entry directly to the format Perseus expects, without requiring editors type the sequence in by hand.

In the meanwhile, though, it occurred to me that the encoding they use, w:Beta Code, would make a very handy alternative input method. Beta code was designed to represent all the characters in the Greek polytonic script- including accents, breathings, iota-subscripts, macrons, breves, and other diacritics, in any combination- using only sequences of characters found on every standard keyboard. It's used by the w:Thesaurus Linguae Graecae project, so you know it has to be pretty complete.

For example, the Ancient Greek noun εἰδωλολάτρης (eidōlolátrēs, “idol-worshipper”) can be entered using "ei)dwlola/trhs", and Ἑβραῖος (Hebraîos) using "*(ebrai=os" Once you learn the conventions, it's relatively easy to type in any Greek word without using menus, palettes, etc. Many of the characters used overlap with wiki syntax, but it shouldn't be hard to keep the Beta Code input from contaminating the wikitext. There are also Beta Code versions for other scripts such as Hebrew, but I haven't used them and can't vouch for their usefulness.

I don't have the necessary knowledge of Javascript or of our user interface to create it myself, but I thought I would mention it in case anyone who does might feel so inclined. There's a pretty comprehensive manual linked to from the WP page which should have all the information you need. Thanks! Chuck Entz (talk) 02:15, 13 May 2013 (UTC)[reply]

You might want to mention this to the developers of the jQuery IME (mw:Milkshake). --Yair rand (talk) 03:03, 13 May 2013 (UTC)[reply]

For starters, I applaud this effort. It would be nice to not have to figure out the code. For what it's worth, if I were to take on this project, I would use javascript, and have it pull up the pagetitle, convert it into beta code, find the edit window, find the empty template, and insert the code into it. This is probably because I'm comfortable with JS, and have no experience with Lua. In any case, I support whatever approach works, and am happy to provide any assistance that I can. -Atelaes λάλει ἐμοί 01:02, 15 May 2013 (UTC)[reply]

Hi there. Way back in October I nominated w:A leopard doesn't change its spots article for deletion, and the result of the discussion was transwiki to Wiktionary. The problem is that the transwiki tag (This page will be copied to Wiktionary using the automated transwiki process) has been on the article ever since, and no transwiki has taken place. I was told at the Village Pump that it is in fact not an automated process, and that it needs to be imported by admins over here. Although there is already a page for it over here, what happens next? Richard BB (talk) 08:50, 14 May 2013 (UTC)[reply]

I'd say replace it with w:Template:Wiktionary redirect. Since Wiktionary already has a page for it, we don't need the transwiki. I really wish people at Wikipedia would check whether something is present at Wiktionary before knee-jerk-reacting "Transwiki to Wiktionary" at AFD discussions. Wiktionary isn't Wikipedia's trashcan. —Angr 12:29, 14 May 2013 (UTC)[reply]

Of course Wiktionary isn't bound by the result of a Wikipedia AFD. Given the poor quality of the page in question and that we already have it under a more correct title, either delete it or soft redirect. Mglovesfun (talk) 08:30, 15 May 2013 (UTC)[reply]

I'm trying to help a dictionary project find some technical help in adapting MediaWiki for their use. They specifically asked if I knew anyone with experience on Wiktionary. I know that User:Conrad.Irwin has some knowledge, but instead of spamming him (and a few other likely looking candidates here), I thought I would just ask: Is anyone interested in a small gig like this? (Appologies if this is inappropriate for here.) -- ☠MarkAHershberger☢(talk)☣ 00:33, 15 May 2013 (UTC)[reply]

I've programmed as a sideline for 35 years (Fortran, BASIC, C (not C++), Turbo Pascal) - but I'll still have the odd syntax problem with Lua! Please can someone tell me why function p.test1 in Module:User:Saltmarsh doesn't work. thanks — Saltmarsh^{απάντηση} 05:46, 15 May 2013 (UTC)[reply]

What about it doesn't work exactly? —CodeCat 10:27, 15 May 2013 (UTC)[reply]

I received a "script error" message. — Saltmarsh^{απάντηση} 15:58, 15 May 2013 (UTC)[reply]

el-translit’s tr function receives a frame as a parameter, not a string. — Ungoliant ^(Falai) 11:46, 15 May 2013 (UTC)[reply]

Thanks - onwards and upwards! — Saltmarsh^{απάντηση} 15:58, 15 May 2013 (UTC)[reply]

I created a couple of special redirects that were deleted. It was suggested on my talkpage that I come here to see what folks thought about their utility. You can read about the issue on my talkpage, but essentially, the idea is to track usage of links from Wikipedia to Wiktionary. Currently, most links from WP to WT are via template, and there seems to be no direct way to track number of clicks on that kind of interwiki template. My solution was to create special redirects on WT: i.e., have "brand new (redirect)" redirect to "brand new", and then create a link from the Wikipedia page to the special redirect. In a month, we could look at the traffic stats for "brand new (redirect)", compare it to the stats for "brand new", and know how many people looked up "brand new" via Wikipedia versus other sources. The special redirects are designed to be few in number, temporary in nature (no more than a couple of months just to get the needed data), and essentially invisible to the reader. I know that redirects are highly unfavored at WT, but I thought this might be a worthwhile use of them. Thoughts? Dohn joe (talk) 17:58, 15 May 2013 (UTC)[reply]

Does MediaWiki not have web traffic statistics with referrer info? —Michael Z. 2013-05-15 18:46 z

Good question. I've never dealt directly with MediaWiki. How would I go about doing so? Dohn joe (talk) 19:05, 15 May 2013 (UTC)[reply]

I would certainly like to know about the results of such research for a goodly sample of entries. DCDuring TALK 19:12, 15 May 2013 (UTC)[reply]

Here are some links, but I can’t figure out where the logs are:

• http://stats.wikimedia.org/
• mw:Analytics/Wikistats
• mw:Analytics/Wikistats/TrafficReports

 —Michael Z. 2013-05-15 20:16 z

Even if the logs were available, they don't track every hit. Only about one per 1000 hits are logged. -- 24.229.66.193 23:31, 15 May 2013 (UTC)[reply]

I see no harm in creating a limited number (which could be as high as a hundred, IMO) of such special redirects. I also see little benefit, but since others do see benefit, I say: sure, go ahead. - -sche (discuss) 03:15, 16 May 2013 (UTC)[reply]

I've re-created the special redirect to big as a test case. Dohn joe (talk) 20:19, 11 December 2013 (UTC)[reply]

With Lua it seems like it should be possible to merge these templates into a single template: {{temp|trans-table|(translations go here)}}. This would allow us to automatically do various kinds of validation (language matching, nesting, etc) and cleanup, and it would eliminate the need to manually balance the columns. Thoughts? DTLHS (talk) 20:07, 15 May 2013 (UTC)[reply]

If this is being revised, why not use CSS column-width, and dispense with all of the unnecessary tables and brute-force column balancing? —Michael Z. 2013-05-15 20:19 z

That seems like the right tool for the job. DCDuring TALK 20:08, 16 May 2013 (UTC)[reply]

See {{trans-table}}. This still requires (a) the correct styles / classes (common.css) to be added, (b) Conrad Irwin's auto translation script to be modified, and (c) bot conversion if we want to switch to this. Alternatively we could just apply the new style to {{trans-top}} and blank {{trans-mid}}, which would require no bot edits. The advantage of having everything in a single template are the eventual Lua parsing capabilities, as described above. DTLHS (talk) 02:02, 17 May 2013 (UTC)[reply]

You can see an example at User:DTLHS/sandbox (with User:DTLHS/common.css). Unfortunately I don't know how you would prevent nested translations from being split across columns, which seems like a deal breaker. DTLHS (talk) 21:02, 18 May 2013 (UTC)[reply]

Cannot get this to work- the column-break-inside property isn't supported by most browsers. Using display: table; fixes the column breaks but makes it impossible to use bullets. Anyone have any other work arounds? DTLHS (talk) 23:44, 18 May 2013 (UTC)[reply]

Is the problem with translations like Mandarin and Hungarian in your example, where there is a dl inside a ul? We could use proper markup instead of this nonsense.—Michael Z. 2013-05-19 21:30 z

Thanks. What would be the proper markup? This is what is used in all entries to nest translations, so it would take some work to fix. DTLHS (talk) 21:50, 19 May 2013 (UTC)[reply]

Well, just an asterisk for nested UL is probably better than the fake DL, and more consistent for editors. Presentation could remain the same with .translationcolumns li li { list-style-type: none; }

Better markup might be a real DL, which could also be styled to look exactly like the current version. I suspect editors may be uncomfortable with the unconventionally correct use of wikitext to create markup, though:

; Armenian
 : նախ (hy) (nax)
 : սկզբում (hy) (skzbum) 
; Chinese
 :; Mandarin
  :;: 起初 (cmn) (qǐchū)
; Czech
 : zpočátku (cs)
 : nejprve (cs)

 —Michael Z. 2013-05-19 22:04 z

It works for me in Safari/Mac and Chrome/Mac. It looks like adding page-break-inside: avoid; makes it work right in Firefox 20.0. I guess the problem is in MSIE <10[1] and Mozilla<20.[2] Dunno about Opera.

The way it breaks with your CSS is not a showstopper – the content is still perfectly understandable in cases where the break appears in the wrong place. So I don’t have a problem with using this, since it should be able to work in all current browsers. —Michael Z. 2013-05-19 21:30 z

I'm confused... what did I change in this edit? diff —CodeCat 18:08, 16 May 2013 (UTC)[reply]

Investegating in Python, it seems that you removed the symbol u'\u200e', which supposedly is the left-to-right mark, which I also identified another one of. --Njardarlogar (talk) 18:18, 16 May 2013 (UTC)[reply]

It seems that SemberBlottoBot has created that entry. I wonder why it is inserting such invisible characters... —CodeCat 18:22, 16 May 2013 (UTC)[reply]

I can't see the change that the edit made. Where exactly is the strange character (between what other characters)? SemperBlotto (talk) 07:14, 17 May 2013 (UTC)[reply]

Use keyboard cursor to find it. They are after "e" in "piquenique". --Z 07:32, 17 May 2013 (UTC)[reply]

How strange. Nothing obvious in the code, and it doesn't seem to be happening now. See amabilidades for a similar entry just created. SemperBlotto (talk) 07:46, 17 May 2013 (UTC)[reply]

How is the input handled? I'd guess that the character entered that way. No, it doesn't seem to be happening any longer; I've checked a lot of random entries. --Njardarlogar (talk) 14:12, 17 May 2013 (UTC)[reply]

I've compiled a list of 2004 (!) entries with this character in the text. Easy enough to fix but we should really figure out where these are coming from. Is there any circumstance in which this is valid? DTLHS (talk) 21:10, 20 May 2013 (UTC)[reply]

As per the section somewhere below this one, Prosfilaes introduced a symbol with this new page, using User:Yair rand/newentrywiz.js. Checking the source code of the active version at that point in time reveals no such symbol, and I don't find it in quinceañera, either. --Njardarlogar (talk) 17:41, 21 May 2013 (UTC)[reply]

Strange. We need Sherlock Holmes to sort it out for us. --Z 18:31, 21 May 2013 (UTC)[reply]

I don't think there is, there are preferable, higher-level ways to deal with text direction, in HTML. One should not put those unicode characters in page's code, unless when we need to change the direction in edit mode as well (using the characters is the only way to do this, in this case). --Z 18:25, 21 May 2013 (UTC)[reply]

Agreed, but the LRM shouldn't always be removed: often it should be converted to ‎ until our templates actually use the "higher-level ways". (One example is that I insert ‎ between anagrams in a comma-separate anagram list in a RTL language's entry. There are other examples also where the LRM should be included by some means.)​—msh210℠ (talk) 18:24, 22 May 2013 (UTC)[reply]

Another strange edit: diff. Any idea what happened? —CodeCat 13:32, 22 May 2013 (UTC)[reply]

Apparently the same thing. Before:

character  byte       UTF-32   encoded as     glyph   name
        0          0  000061   61             a      LATIN SMALL LETTER A
        1          1  000072   72             r      LATIN SMALL LETTER R
        2          2  00006B   6B             k      LATIN SMALL LETTER K
        3          3  00200E   E2 80 8E               LEFT-TO-RIGHT MARK
        4          6  00007C   7C             |      VERTICAL LINE
        5          7  00006C   6C             l      LATIN SMALL LETTER L
        6          8  000061   61             a      LATIN SMALL LETTER A
        7          9  00006E   6E             n      LATIN SMALL LETTER N
        8         10  000067   67             g      LATIN SMALL LETTER G
        9         11  00003D   3D             =      EQUALS SIGN
       10         12  00200E   E2 80 8E               LEFT-TO-RIGHT MARK
       11         15  000065   65             e      LATIN SMALL LETTER E
       12         16  00006E   6E             n      LATIN SMALL LETTER N
       13         17  00007D   7D             }      RIGHT CURLY BRACKET
       14         18  00007D   7D             }      RIGHT CURLY BRACKET
       15         19  000020   20                     SPACE
       16         20  000061   61             a      LATIN SMALL LETTER A
       17         21  00006E   6E             n      LATIN SMALL LETTER N
       18         22  000064   64             d      LATIN SMALL LETTER D

After:

        0          0  000072   72             r      LATIN SMALL LETTER R
        1          1  00006B   6B             k      LATIN SMALL LETTER K
        2          2  00200E   E2 80 8E               LEFT-TO-RIGHT MARK
        3          5  00007C   7C             |      VERTICAL LINE
        4          6  00006C   6C             l      LATIN SMALL LETTER L
        5          7  000061   61             a      LATIN SMALL LETTER A
        6          8  00006E   6E             n      LATIN SMALL LETTER N
        7          9  000067   67             g      LATIN SMALL LETTER G
        8         10  00003D   3D             =      EQUALS SIGN
        9         11  000065   65             e      LATIN SMALL LETTER E
       10         12  00006E   6E             n      LATIN SMALL LETTER N
       11         13  00007D   7D             }      RIGHT CURLY BRACKET
       12         14  00007D   7D             }      RIGHT CURLY BRACKET
       13         15  000020   20                     SPACE
       14         16  000061   61             a      LATIN SMALL LETTER A
       15         17  00006E   6E             n      LATIN SMALL LETTER N
       16         18  000064   64             d      LATIN SMALL LETTER D

(could not find a sensible way to make this take less space.) Keφr 14:23, 22 May 2013 (UTC)[reply]

How did you generate that information? —CodeCat 14:25, 22 May 2013 (UTC)[reply]

I use uniname. Keφr 14:30, 22 May 2013 (UTC)[reply]

An easier way is using a unicode to HTML convertor like this, the character is encoded as &#8206; and &lrm; in HTML. For example {{term|percontation mark|lang=en}} (from diff) gives {{term|percontation mark‎|lang=‎en}}. --Z 14:40, 22 May 2013 (UTC)[reply]

Here's what it looks like in Python, by the way (the first \ufeff stems from UTF file encoding): u'\ufeff====Usage notes====\n* Possible {{l|en|calque|calques}} of {{term||punctus percontativus|lang=en}} include {{term|percontation mark\u200e|lang=\u200een}} and {{term|percontation point|lang=en}}; both are attested in isolated uses (2005, 2010), but neither has gained any currency.' (using a simple .__repr__()) --Njardarlogar (talk) 16:34, 22 May 2013 (UTC)[reply]

• The invisible character seems to appear near special characters like | } ] '. Could making a typo result in a keyboard shortcut for this invisible character? E.g. Ctrl-LeftShift / Ctrl-RightShift seem to change the text direction in some programs/browsers/platforms. -- Curious (talk) 21:01, 22 May 2013 (UTC)[reply]

  That was my first thought but... There are many shortcuts for LRM, they vary depend on the OS, software, and configuration. (BTW, Ctrl + Left/Right Shift does change text direction of input, but putting LRM/RLM characters is another thing) Including Shift (don't remember if there was L Alt or Ctrl, too) + Backspace, a key near | and }. But this shortcut (as well as many others) works in bidi keyboards, while many of these LRMs are the result of edits of people who speak/write in LTR languages. Moreover, this case was bot's edit (the code must be OK since it works fine in other entries), and in the case Njardarlogar mentioned above, no keyboard was involved. It's weird. --Z 06:51, 23 May 2013 (UTC)[reply]

Lately I've been interested in a group of less common languages written in the Cyrillic script from the Caucasus and around Mongolia.

I've noticed that some of them have {{xx-noun}} templates but some of them do not.

I'm interested in making the missing templates but since all of the languages seem to have different "source code" I'm wondering if there's a model I should copy. I don't mind even standardizing the existing ones. Do we have a policy on this?

... or are we planning to move more towards Lua? — hippietrail (talk) 06:27, 17 May 2013 (UTC)[reply]

Lua is definitely recommended, if you're able to do it. You can look at Module:nl-headword or Module:ca-headword for some examples. —CodeCat 14:27, 17 May 2013 (UTC)[reply]

But be sure to add in automatic transliteration. Take a look at Category:Transliteration modules and if none of the languages there have the same transliteration system, make a new one with the same format. —Μετάknowledge^{discuss/deeds} 00:05, 18 May 2013 (UTC)[reply]

Thanks. I'll start looking into it in a few hours. — hippietrail (talk) 02:48, 18 May 2013 (UTC)[reply]

Not necessarily a standard way as languages vary. I'd consider Template:tyv-noun a very good place to start, changing the language name and codes where necessary, and adding anything that's needed (gender, plural, genitive, etc.). Mglovesfun (talk) 10:48, 18 May 2013 (UTC)[reply]

I would at least change the headword line to use <strong class="headword"> and remove the deprecated sg= parameter. —CodeCat 12:21, 18 May 2013 (UTC)[reply]

I have recently been trying to add stroke orders to pages such as 岁. The conclusion I must draw from the number of stroke order-free pages I have come across is that there are a lot of Commons Bw.png stroke order images that are not being used on Wiktionary, whereas they could be.

Since the Commons files all have a standard naming format, would it be possible for someone to create a bot that would do the following for each member of Category:Han_characters?

1. Check whether it had a ==Translingual== header.
2. Check whether it had a Bw.png stroke order file on Commons (the files' names are all made according to a particular pattern; see e.g. 乙 and File:乙-bw.png).
3. If it exists, check whether said Bw.png file is already used on the Wiktionary page (possibly via {{stroke order}}).
4. If the Wiktionary page already uses a Bw.png file, do nothing.
5. If there is no Commons Bw.png file to speak of, do nothing.
6. If there is a file on Commons, it isn't yet being used on Wiktionary, and there isn't a Translingual header, create the header and put {{Stroke order}} underneath it.
7. If there is a file, it isn't yet being used, and there is a Translingual header, check whether the header is already using some other stroke order image (as at 乙).
8. If it is, do nothing.
9. If it isn't, add the Bw.png file to the Translingual section.

Thanks. It Is Me Here ^{t / c} 16:02, 17 May 2013 (UTC)[reply]

Any suggestions on how the bot can recognize "whether the header is already using some other stroke order image"?​—msh210℠ (talk) 18:28, 22 May 2013 (UTC)[reply]

Maybe the bot could check whether the page's Translingual section contains an image that's a member of commons:Category:Order.gif stroke order images or commons:Category:Red.png stroke order images? It Is Me Here ^{t / c} 21:03, 23 May 2013 (UTC)[reply]

My specific interest is in finding instances of species: and wikispecies: in principal namespace (and secondarily Appendix space) for the purpose of replacing such links with {{taxlink}} so the taxonomic names became candidates for entry. Is there a way to do this from a search screen whenever I need it or does this need to be done by processing the dump? DCDuring TALK 23:46, 19 May 2013 (UTC)[reply]

There may be a way to do it from the search screen, but processing the dump periodically is easy enough. I've created Wiktionary:Todo/Direct links to Wikispecies. I note that if I just search the site (not the dump) for "wikispecies" using the normal search screen, I find a lot of entries which say "see wikispecies" without any link at all, which seems pointless... see e.g. Zygaeninae, where the "see wikispecies" is redundant to the {{wikispecies}} box. - -sche (discuss) 20:00, 29 May 2013 (UTC)[reply]

I use various searches to try to locate references to taxonomic names in entries and clean other things up as I go, at least when I have the energy for it. Yes, I guess I should clean those "See wikispecies" things up systematically. But the "See also" sections that have those words often should be reheaded as "Hyponyms", ie, species in a genus entry. The See is intended to direct the user to a project that has a good list of species. A really good job would make a determination whether we should have our own Hyponyms listing of species or a link to WP or Wikispecies based on the relative quality and quantity of their species listing. This is a little time-consuming but we only have about 9,000 taxonomic name entries, so it is not too hard to imagine cleaning them all up. It is a great deal harder to find all the uses of taxonomic names in all entries in all languages. So far I've found about 5,000, mostly using ordinary search and "what links here". The only language that has been rather easy is Finnish (tip of the hat to Hekaheka). DCDuring TALK 00:13, 30 May 2013 (UTC)[reply]

I have edited [[Zygaeninae]] as best I can, with all the features I sometimes include. Note that I have retained a duplicate link to Wikispecies under Hyponyms. DCDuring TALK 00:32, 30 May 2013 (UTC)[reply]

•  Done Thanks. DCDuring TALK 13:27, 30 May 2013 (UTC)[reply]

I'm trying to create a module to return the definitions of a page from the title (Template:defs, Module:defs). Note the output:

{{defs|supporteuses}}: Template:defs

I assume that {{:{{{1}}}}} isn't getting evaluated for some reason- any way to fix this? DTLHS (talk) 00:16, 20 May 2013 (UTC)[reply]

I'm not sure why it's not working, but it's probably not the best way of going about it anyway. Rather than transcluding a page and passing it as an argument, Lua can just retrieve the page content using mw.title. --Yair rand (talk) 00:27, 20 May 2013 (UTC)[reply]

Right, that works but unfortunately templates aren't being evaluated (probably some kind of recursion protection). Oh well. DTLHS (talk) 00:43, 20 May 2013 (UTC)[reply]

FWIW, the first time I looked at this page, the bit after the colon was supporteuses. Now, it's a red Script error. - -sche (discuss) 00:33, 20 May 2013 (UTC)[reply]

This template contains <font style="font-size:125%">, which breaks the page’s HTML because it is obsolete, and should be removed or replaced. I don’t know enough about the template to fix it.

Doesn’t the script template {{Hans}} already enlarge the font (via a declaration in MediaWiki:Common.css)? Or if this is supposed to replace the headwords’ usual bold emphasis, then we should replace it with a <strong> element, and style it appropriately in the style sheet:

strong:lang(cmn) { font-weight: normal; font-size:125%; }

 —Michael Z. 2013-05-20 01:52 z

• I just commented out the offending <font> tag pair. If that doesn't break anything, we can remove it entirely. If it does break anything, we should just change the tag text from font to span, no? -- Eiríkr Útlendi │ Tala við mig 17:06, 21 May 2013 (UTC)[reply]

Well, if this is, as I suspect, being enlarged as a substitute for the usual headword bolding, then a better way to do it would be to simply make it <strong lang=zh-Hani> and handle the styling in the style sheet with strong:lang(zh) { font-weight: normal; font-size: larger; }. There are other headword templates that should be treated the same. This would allow standardization of the HTML, central control by the style sheet, and overriding in user style sheets. —Michael Z. 2013-05-21 17:42 z

Why aren't we using dfn? strong doesn't make sense to me... we are not emphasising on anything. --Z 18:12, 21 May 2013 (UTC)[reply]

Depends on where this style applies. If it applies to the headword line, as Michael suspects, then it is being emphasised, much like Latin-script headwords are emphasised by bolding. (dfn wouldn't make sense applied to the headword line, IMO.) If it applies to definitions, then dfn would seem better... - -sche (discuss) 19:47, 21 May 2013 (UTC)[reply]

dfn would be ideal, but we aren’t using it because our combination of templates and their resulting markup doesn’t allow us to meet the requirement that “The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element.”[3] It is not unreasonable that a headword “represents strong importance for its contents.”[4] —Michael Z. 2013-05-22 02:36 z

Would it be possible to write a module that detects script? I wonder if it could just check the first character of a string, and then use Latn as a default for anything like 1 or !. Mglovesfun (talk) 08:30, 20 May 2013 (UTC)[reply]

It's already written. It's unused, though. --Z 08:33, 20 May 2013 (UTC)[reply]

What exactly would it be needed for? —CodeCat 12:16, 20 May 2013 (UTC)[reply]

It is needed for terms in languages which are written in more than one script. --Z 14:37, 20 May 2013 (UTC)[reply]

But for such languages, we can do a little better. After all, we already store a list of possible scripts, so a detection function wouldn't need to try all possibilities, only those that are used for that language. For example, a detection script for Serbo-Croatian would only need to try Latin and Cyrillic. —CodeCat 14:39, 20 May 2013 (UTC)[reply]

That's what the current code is doing, see lines 50-56. --Z 14:43, 20 May 2013 (UTC)[reply]

What does your script do if there are characters in the word that don't belong to any script? Like spaces, punctuation or even combining diacritics? And what if it finds more than one script? —CodeCat 14:45, 20 May 2013 (UTC)[reply]

Spaces, punctuation, and Latin 0-9 digits (since they are used in several other scripts as well) are ignored. It detects based on the first characters, i.e. for "abcابپت" it returns "Latn". For anything else returns nil. --Z 14:51, 20 May 2013 (UTC)[reply]

I've added a few scripts I felt like adding - Armenian, Bengali, Burmese, Devaganari, Georgian, Greek, Khmer, Lao, Sinhalese, Thai (using SC Unipad word processor). Not sure what it's going to be used for but would like to add CJK script detection, not sure if it's possible. The codes are obviously shared by these scripts. For Korean individual jamo the range is "ᄀ-ᇹ", for hangeul it's U+AC00–U+D7AF. --Anatoli ^{(обсудить}/^вклад) 03:11, 22 May 2013 (UTC)[reply]

This could be very helpful for a language like Sanskrit, which is written in more scripts than {{choose}} allows us to specify at {{sa/script}}. —Angr 14:32, 22 May 2013 (UTC)[reply]

The /script templates will soon be deleted anyway. Lua doesn't have a limit. —CodeCat 16:40, 22 May 2013 (UTC)[reply]

What is wrong with the formatting of this entry? The linked-to word exists here, but is shown in black with no wikilink. SemperBlotto (talk) 15:22, 20 May 2013 (UTC)[reply]

Needed lang=en. — Ungoliant ^(Falai) 15:32, 20 May 2013 (UTC)[reply]

Weird. I tried that (look at the history) and got a red script error. SemperBlotto (talk) 15:35, 20 May 2013 (UTC)[reply]

It wasn't the missing language. It was another one of those invisible characters. —CodeCat 15:36, 20 May 2013 (UTC)[reply]

I've recently started adding quotations to Wiktionary that I extract from whatever I happen to be reading when the impulse to contribute strikes. It's an interesting learning experience.

With quotations being displayed to the reader as an option, their use to confirm a meaning and to demonstrate its possibly changing use over time seems to me to have very great potential attraction for readers. Also, quotations can and usually do offer readers a link to the document or article they come from. This is an added attraction, and the overall attraction will increase as quotations accumulate, provided they don't bloat within any single meaning.

In adding quotations, though, I've noticed that the treatment of examples varies widely. Sometimes they are included as part of the meaning, sometimes as following lines of text (usually in italics), and sometimes as brief quotations without or without attribution.

I would suggest that examples be coded in a fashion similar to that of quotations (maybe prefixed by #=), and that their display be made optional in the same fashion that quotations are. One great advantage of this (once the majority of current examples are converted) is that more meanings will be visible at the same time for readers with both examples and quotations hidden. Then a reader can get at examples and/or quotations for an individual meaning of particular interest.

#= doesn't mean anything in MediaWiki markup as #* (currently used for quotes) and #: (currently used for examples) do. —Angr 15:32, 21 May 2013 (UTC)[reply]

Is it possible to have the Finnish language section automatically expanded in the mobile view? ~ heyzeuss 18:55, 21 May 2013 (UTC)[reply]

What do you mean by expand exactly? —CodeCat 18:57, 21 May 2013 (UTC)[reply]

In mobile view, all sections of wiki pages are collapsed by default. --Z 19:10, 21 May 2013 (UTC)[reply]

Hm, do personal user scripts and styles exist for mobile? I don't think so. --Yair rand (talk) 19:32, 21 May 2013 (UTC)[reply]

Can we add a JSON module for lua on en.wiktionary? There are a bunch of free modules here but I'm not sure which have compatible licenses. DTLHS (talk) 23:54, 22 May 2013 (UTC)[reply]

What would that do exactly? —CodeCat 00:04, 23 May 2013 (UTC)[reply]

It would parse JSON strings. I guess it can wait until I have a complete example of what I want to do up. DTLHS (talk) 00:46, 23 May 2013 (UTC)[reply]

See bugzilla:45470. No "I want this too!" comments please, but feel free to CC yourself on that bug report. :) --AKlapper (WMF) (talk) 11:29, 30 May 2013 (UTC)[reply]

Could someone please update this? Cheers. Mglovesfun (talk) 10:41, 23 May 2013 (UTC)[reply]

Done. DTLHS (talk) 20:57, 23 May 2013 (UTC)[reply]

I just noticed this category on fshij. I'm guessing it's an unintended side effect of edits to {{rfscript}}... - -sche (discuss) 20:21, 23 May 2013 (UTC)[reply]

I think it is a result of a relatively recent change to {{term}} and a bad category name in {{term}} or something called by it. DCDuring TALK 20:51, 23 May 2013 (UTC)[reply]

The entry se is not showing the first 30 language sections, even though they are listed at the top. ~ heyzeuss 08:10, 24 May 2013 (UTC)[reply]

They all show up for me. Do you use Tabbed Languages? (I don't.) - -sche (discuss) 08:24, 24 May 2013 (UTC)[reply]

I use tabbed languages, and they all show up for me. Try hitting http://en.wiktionary.org/w/index.php?title=se&action=purge and see if that helps. —Angr 09:14, 24 May 2013 (UTC)[reply]

Could someone fix these entries (or an updated list of entries which link to Wikipedia the way Volkshochschule does) by bot? Remember that there are a few variations ([https://en.wikipedia.org/, [http://en.wikipedia.org/, [//en.wikipedia.org/). Full-URL links to WP should be replaced by [[w:foo|and-optionally-bar]] or {{w|foo|and-optionally-bar}}. - -sche (discuss) 18:42, 24 May 2013 (UTC)[reply]

Also, is there any reason not to use an edit filter to block the edition of such full-URL links to 'pedia? - -sche (discuss) 18:46, 24 May 2013 (UTC)[reply]

They should be blocked in the main namespace, but not other namespaces (if possible, not even on main-namespace-associated Talk: pages), since it might be useful to link to a diff from such a page... but surely not from an entry. - -sche (discuss) 20:51, 14 July 2013 (UTC)[reply]

{{look}}

There are currently about three thousand Latvian adjective entries (listed here) which look like this, that is, which conflate two homographs under the same header. This is bad form. Could a bot replace

|adj}}\n\n\{{head|lv|adjective

with

|adj}}\n\n===Adjective===\n{{head|lv|adjective

on all those pages? - -sche (discuss) 18:29, 25 May 2013 (UTC)[reply]

There are a few Italian ones like capobanda as well. —CodeCat 18:32, 25 May 2013 (UTC)[reply]

The Italian example looks fine to me. The masculine form of the noun has a plural and the feminine form of the same noun is invariant. The Latvian examples refer to forms of different adjectives conflated together.SemperBlotto (talk) 18:37, 25 May 2013 (UTC)[reply]

But the feminine noun has a different meaning from the masculine noun. —CodeCat 18:40, 25 May 2013 (UTC)[reply]

Um, no. SemperBlotto (talk) 18:49, 25 May 2013 (UTC)[reply]

Are you saying they are interchangeable synonyms? —CodeCat 19:01, 25 May 2013 (UTC)[reply]

(deprecated template usage) capobanda has two definitions - bandmaster or ringleader. Either may be masculine or feminine. It's a single word and the entry has a single headword. What's the problem? SemperBlotto (talk) 07:03, 26 May 2013 (UTC)[reply]

What you seem to imply is that the word has different inflections depending on whether the meaning is a male or a female. So they are two headwords, not one, with distinct meanings. —CodeCat 12:36, 26 May 2013 (UTC)[reply]

I think it's problematic as I don't know what the inflection is. Is it either masculine or feminine, and either plural the same or capibanda (irrespective of gender for both plurals)? Mglovesfun (talk) 17:41, 27 May 2013 (UTC)[reply]

{{look}}

Setting aside the Italian entries, because they are very different and possibly correct as-is, can someone process the Latvian entries? - -sche (discuss) 20:53, 14 July 2013 (UTC)[reply]

Something's wrong with the initialism template, IMHO; see the PMB page for example, it displays with errors in my browser (red "script error" signs; brackets and stuff visible etc.) ---CopperKettle (talk) 02:37, 26 May 2013 (UTC)[reply]

See {{initialism}}. Apparently, it's deprecated. User: PalkiaX50 ^{talk to meh} 02:40, 26 May 2013 (UTC)[reply]

I made it default to English again. Fixed the problem for me. — Ungoliant ^(Falai) 02:46, 26 May 2013 (UTC)[reply]

I noticed the problem in a Spanish entry (which even specified {{initialism|lang=es}} and was still failing messily), though I can't recall which one. It is just another reason to replace that template with an actual part of speech whenever you see it... - -sche (discuss) 03:04, 26 May 2013 (UTC)[reply]

I've been fixing these steadily as they appear in Category:Pages with script errors. A lot of entries had missing language codes or used names instead of codes. —CodeCat 12:33, 26 May 2013 (UTC)[reply]

I noticed that some, like CN, are using the template as a usage context instead. I'm not sure what to do but we can't support both types of usage at the same time. Either {{initialism}} is a context template, or it isn't. So this might be a good time to orphan all the deprecated uses. —CodeCat 13:21, 26 May 2013 (UTC)[reply]

I've decided to move the template to {{initialism-old}} so that it no longer conflicts with usage as a context label. I'm updating the uses now. —CodeCat 14:12, 26 May 2013 (UTC)[reply]

PMB as a specific example is a noun and should be formatted as such. Initialism is really its etymology, though since the etymology and definition would then be the same, this is (in my opinion) a good case for {{context|initialism}}. Mglovesfun (talk) 21:05, 26 May 2013 (UTC)[reply]

I just fixed a bunch of the same problems with {{acronym}} and {{abbreviation}}. The problem seems to be that there's no flexibility: the language code has to be a positional parameter (lang= doesn't work), but wrapper templates such as {{informal|acronym}} may need the positional parameter so they can pass it on to the other template, presumably as a positional parameter. There were a couple of cases with wrapper templates where it seemed to be fixed (at least it wasn't puking its guts out in technicolor, as before), but it still put itself in the Script Errors category. Chuck Entz (talk) 05:51, 27 May 2013 (UTC)[reply]

we need acronym-old and abbreviation-old then. Mglovesfun (talk) 10:20, 27 May 2013 (UTC)[reply]

Even if the templates did accept lang= as a parameter, they would still not work as context templates. So if someone were to type {{context|abbreviation|Internet}} it would not show "Internet". Templates need to work in a special way in order to be usable as context templates. —CodeCat 12:15, 27 May 2013 (UTC)[reply]

I've moved them; now no uses of abbreviation, acronym or initialisms in headers. Still used under the new name initialism-old (and so on), and those should be eventually orphaned but there are so many of them and they are still being used, it may never happen. Mglovesfun (talk) 14:29, 27 May 2013 (UTC)[reply]

I'm going to implement the reforms I first proposed in 2010 (looking at the template's talk pages) perhaps as early as tomorrow. But since I can't write modules they will be in the 'template' language. If anyone would rather write a module (or expand an existing one) then go ahead. The idea is to unify all the functions {{fr-noun}}, {{fr-noun-unc}} and {{fr-noun-inv}} into fr-noun, and {{fr-adj-mf}} into {{fr-adj}}. So fr-noun will have a switch for gender then one for type (- for uncountable, inv for invariable, otherwise display a plural, plural code to remain unchanged) and for fr-adj, I would suggest {{fr-adj|mf}} for masculine and feminine adjectives. It's what {{frm-adj}} does, but {{ca-adj}} use {{ca-adj|type=mf}}, which in my mind at least uses extra keystrokes with no overall benefit. Mglovesfun (talk) 16:51, 27 May 2013 (UTC)[reply]

Actually, {{ca-adj}} uses Lua now and it's {{ca-adj|mf}}. —CodeCat 17:01, 27 May 2013 (UTC)[reply]

Well, do you fancy it? Frankly I have more confidence in you doing a good job than I do in me. Mglovesfun (talk) 17:38, 27 May 2013 (UTC)[reply]

Learning Lua is a good skill especially as we begin to use it more and more. Module:ca-headword is a good start for Module:fr-headword, and you might be able to figure out what it does, and adapt it to French (which shouldn't be too hard, as they have similar grammar). If anything is unclear or if you want to make sure something is ok, you can ask me or others for help. —CodeCat 12:19, 28 May 2013 (UTC)[reply]

{{abbreviation-old}} does not accept "|lang=", and a bot went around replacing {{abbreviation}}; several other templates as well (such as {{initialism}} pointed out above) why are the templates incompatible with "|lang=" ? Shouldn't all the single-language templates be compatible with "|lang=" ? -- 65.94.76.126 07:37, 28 May 2013 (UTC)[reply]

My guess is that there's aren't 'broken' but CodeCat removed the lang function, as she's into that. Mglovesfun (talk) 10:51, 28 May 2013 (UTC)[reply]

The templates always supported the first parameter in addition to lang=, and most uses already used that parameter. I just converted the remaining few. I can add it back if you really want to, but I think it's ok as it is. —CodeCat 12:16, 28 May 2013 (UTC)[reply]

There's an agreement not to use these templates anyway; just orphaning them will take years, as a bot can't work out the part of speech and therefore the appropriate template; it has to be done by hand. Mglovesfun (talk) 12:33, 28 May 2013 (UTC)[reply]

On the one hand, it could be good for them to (re-)support a lang= parameter until they can be orphaned. It's intuitive to add lang= to things to declare their languages. I don't recall ever seeing a use that wasn't bare {{abbreviation}} (i.e., I never saw lang= or the first parameter used to declare a language), but when I noticed they had started throwing script errors, my first thought was to try adding lang=.

On the other hand, because the goal is to orphan and delete them, it may be good to make them hard to use. - -sche (discuss) 18:37, 28 May 2013 (UTC)[reply]

There was some talk that templates like {{l/en}} might be deprecated already in favor of a faster Lua version of {{l}}. I've stopped adding language specific l templates. Should I have? Mglovesfun (talk) 14:35, 28 May 2013 (UTC)[reply]

There is no problem in adding them, as long as they remain backwards compatible with {{l}}. We can always replace them back again when it comes to it. —CodeCat 14:49, 28 May 2013 (UTC)[reply]

Is it possible at all to make a Lua version of {{l}} that is faster than the language specific ls? They are pretty optimised, having only one operation and not transcluding anything. — Ungoliant ^(Falai) 15:01, 28 May 2013 (UTC)[reply]

I doubt it, mainly because there'd always be a need to import the module as well. —CodeCat 15:05, 28 May 2013 (UTC)[reply]

With language-specific l templates each template must be loaded separately, as opposed to a unified l template which only needs to load once, and the language module also only needs to load once, I think. So, maybe? --Yair rand (talk) 16:46, 28 May 2013 (UTC)[reply]

Aren't the "ifexist" tests the source of the performance problem rather than the loading? DCDuring TALK 19:33, 28 May 2013 (UTC)[reply]

Is there an actual need for language-specific l templates? -- Liliana • 16:12, 28 May 2013 (UTC)[reply]

I seem to think there was one appendix that many users couldn't load until it switched from l to a language specific template. Mglovesfun (talk) 16:32, 28 May 2013 (UTC)[reply]

Yes; Appendix:Swadesh lists for Slavic languages was difficult or impossible to edit until it started using the language-specific templates. Most pages don't transclude {{l}} hundreds or thousands of times, but the ones that do are much more usable when they use the language-specific daughters of {{l}}. —Angr 16:43, 28 May 2013 (UTC)[reply]

Evidently, our Module:languages isn't optimal yet. For one, the language family information could be outsourced to another module, as that doesn't actually seem to be needed in very many cases (mostly only in categories, I think?). This would allow pages to load a bit faster. -- Liliana • 16:46, 28 May 2013 (UTC)[reply]

Module:languages really isn't a problem in this case. It's only loaded once per page, so its efficiency is not relevant for how many calls to {{l}} there are on the page. —CodeCat 16:48, 28 May 2013 (UTC)[reply]

Loading doesn't take long, yes, but it still needs to be parsed for every invocation, and that takes a while. -- Liliana • 17:01, 28 May 2013 (UTC)[reply]

As far as I know, it's only parsed once as well; the data is kept in memory. —CodeCat 17:02, 28 May 2013 (UTC)[reply]

As long as it is loaded by mw.loadData, that should be correct. —Michael Z. 2013-05-28 17:31 z

I've noticed over the past couple of weeks that audio files are no longer playing for me, whether here or on Commons. Has there been a change to the audio player in this time, and has anyone else had problems? I'm having the same problems whether I use Safari/Mac or Firefox/PC. The files won't start playing at all. --EncycloPetey (talk) 13:22, 29 May 2013 (UTC)[reply]

How did you ever get the audio working in Safari/Mac at all? The Xiph QuickTime component (updated in 2009) just plays silence. —Michael Z. 2013-05-29 17:37 z

No idea. It all worked fine up until recently. Now, the files won't even begin to play for me. And, as I said, the problem is not limited to my Mac. --EncycloPetey (talk) 04:24, 30 May 2013 (UTC)[reply]

I have no trouble playing audio files on Firefox on Windows 7. —Angr 09:30, 30 May 2013 (UTC)[reply]

Exact version info for tested browsers would be welcome, plus operating systems. --AKlapper (WMF) (talk) 11:30, 30 May 2013 (UTC)[reply]

I'm using Safari 6.0.3 in Mac OS X (10.8.3).

I was able today to get a single Audio file to play (the US pronunciation of hello), but it took about 30 seconds of waiting for the little spinning color wheel, then I got a warning about allowing the application to run and had to accept the risk, at which point the latter half of the file played. I had to replay the file to hear the whole thing. After finishing play, the player image did not reset, so it had to be clicked twice to play the file again. I then tried to play the UK version of the same word, and my browser locked up. After a minute, I had to force my browser to close. --EncycloPetey (talk) 22:29, 5 June 2013 (UTC)[reply]

Safari 6.0.4/Mac OS X 10.8.3, no Flash – until recently, these used to act like they were playing through, but no sound would come out. As of today, I notice that the interface looks slightly different, lacking the volume bars. Now the play triangle changes to a pause symbol, but the timer does not advance and “playing” never finishes. Still no sound. —Michael Z. 2013-06-05 22:54 z

Firefox 21/Windows7: No real problem, though the UK pronunciations are significantly less audible. DCDuring TALK 00:27, 6 June 2013 (UTC)[reply]

After updating to the 25th version of Java and the latest Safari/Mas OS version, I finally was able to get audio files to play, although not without additional headaches. I had to "Allow" the Java applet, which took a couple of minutes' wait while the little color wheel span, and then had to agree to permit play again after a second dialogue box gave we a security warning. Not a very friendly approach, but at least I can play audio files again. I just wonder whether I'll have to go through that process every month when I have to log in again fresh. --EncycloPetey (talk) 01:25, 20 June 2013 (UTC)[reply]

Quite a bit of spam is in the form of sneaky links that are added to user pages. I wonder if we can block them by simply disallowing any edits by non-admins from containing "http://" on a user page? —CodeCat 01:05, 30 May 2013 (UTC)[reply]

That's too general. There are legitimate external links of that sort, such as external links to useful resources for editing. --EncycloPetey (talk) 04:25, 30 May 2013 (UTC)[reply]

I think it would be reasonable to block a new user's first edit if it contains an external link. Equinox ◑ 04:33, 30 May 2013 (UTC)[reply]

That would be possible to do with the abusefilter, but I suspect that first edits containing external links on user pages might sometimes be innocent. --Yair rand (talk) 04:37, 30 May 2013 (UTC)[reply]

Well, we can tag them and see, and block them if your suspicion doesn't hold up (though I, too, think it will hold up).​—msh210℠ (talk) 18:31, 31 May 2013 (UTC)[reply]

A lot of these have very similar structure. A number of lines separated by "br" html tags (describing the person), then a line asking you to visit their blog etc. It looks like they are being generated semi-automatically. I have done a quick search for anyone offering a service to promote blogs on Wiktionary, but have not found such a thing as yet. SemperBlotto (talk) 07:50, 30 May 2013 (UTC)[reply]

Those are all created by spambots. They're strictly for putting the links where Google will see them and camouflaging them so they won't get deleted as fast. The other elements are assembled randomly by an algorithm and the "blog" or "home page" is some random web site that the spammer is trying to move up in Google's page ranking. Chuck Entz (talk) 13:24, 30 May 2013 (UTC)[reply]

OK, here's an example. User:Viennea's first edit was the creation of their userpage, which includes a link to youtube. I haven't clicked the link so I don't know what's there, but in general how do I tell the spam from the good-faith links without clicking on the links? (Obviously I don't want to click on a spam link.) —Angr 14:26, 30 May 2013 (UTC)[reply]

That was User:Viennea's only edit, as far as I can see. The user page should be deleted as spam or self-promotion. SemperBlotto (talk) 14:34, 30 May 2013 (UTC)[reply]

But should Viennea be indef blocked? An obvious spammer would be. —Angr 15:01, 30 May 2013 (UTC)[reply]

I don't think so. He has made nearly 800 edits on German Wikipedia. Perhaps me means to edit here some time. Who knows? SemperBlotto (talk) 15:08, 30 May 2013 (UTC)[reply]

Thanks for looking on other projects. Since the youtube link is the same one as at her German Wikipedia userpage, I was so bold as to click it. It's just José Feliciano singing about Vienna, no spam. So I don't feel inclined to delete the userpage myself, but rather to take this an example of a new user whose first edit is to create their own user page with an external link on it, and who nevertheless is acting in good faith. —Angr 15:27, 30 May 2013 (UTC)[reply]

It is still reasonable to block a new user's first edit, if it has an external link. We can put up an apologetic message, saying that this is to stop spambots (just like a CAPTCHA at signup); they would understand. A real user could wait and add their link later. A bot would not know. Equinox ◑ 17:09, 30 May 2013 (UTC)[reply]

Given the unflagging volume of these foul bots I would like to re-urge this issue. Equinox ◑ 14:50, 17 June 2013 (UTC)[reply]

The last recommendation seems reasonable. How does it get implemented, ie, who? DCDuring TALK 14:59, 17 June 2013 (UTC)[reply]

Any admin, by using Special:AbuseFilter. --Yair rand (talk) 16:35, 17 June 2013 (UTC)[reply]

This Equinox quote sounds reasonable to me: "It is still reasonable to block a new user's first edit, if it has an external link." --Dan Polansky (talk) 19:03, 17 June 2013 (UTC)[reply]

I'd like to qualify that and say that it has to be an edit to their user space (user or user talk), and not necessarily just the first edit but maybe the first five? —CodeCat 19:21, 17 June 2013 (UTC)[reply]

Re the original proposal: rather than blocking non-admins, block users who haven't been autoconfirmed. Re this proposal (block adding a link in the first five edits): sure, if that's doable. - -sche (discuss) 20:21, 17 June 2013 (UTC)[reply]

What next? Do we need a vote of some kind? Equinox ◑ 22:45, 21 June 2013 (UTC)[reply]

I don't think so, we need an admin to do it, but I don't know how. What language do abuse filters use? Mglovesfun (talk) 10:28, 22 June 2013 (UTC)[reply]

This language. Keφr 05:50, 23 June 2013 (UTC)[reply]