Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:GREASE)
Jump to: navigation, search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

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

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

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

Permanent notice

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

Grease pit archives edit


January 2017

New template to replace magic words[edit]

Template:ISBN I have copied over w:Template:ISBN and w:Module:Check isxn from en.wp. Magic words as links are being phased out and although we don't have to replace all instances of them now, they will all be removed from MediaWiki in 2017. See mw:Requests_for_comment/Future_of_magic_links. We currently have over 27,000 entries in Category:Pages using ISBN magic links. A similar situation exits on a smaller scale for PMID and RFC. —Justin (koavf)TCM 03:26, 1 January 2017 (UTC)

Is it confirmed that this is actually going to happen? DTLHS (talk) 03:30, 1 January 2017 (UTC)
@DTLHS: Per mw:Help:Magic links, it's already disabled by default. It's my understanding that it will be removed entirely barring something extraordinary. Either way, it's probably useful to have a local version of the templates or use m:interwiki map links. (Note that pmid was recently added for this reason.) —Justin (koavf)TCM 03:43, 1 January 2017 (UTC)

en-PP doesn't work with head parameter[edit]

See in Abraham's bosom. Equinox 05:14, 2 January 2017 (UTC)

Fixed (it was using 1 as a head parameter, but both should work now). DTLHS (talk) 06:14, 2 January 2017 (UTC)

Phags-Pa script[edit]

Could someone make Phags-Pa display vertically as Mongol script does? Crom daba (talk) 05:28, 2 January 2017 (UTC)

Done (do we need the webkit and moz prefixes now or has writing-mode been fully implemented?) DTLHS (talk) 06:12, 2 January 2017 (UTC)
Unfortunately I'm only vaguely familiar with css/Unicode implementation of Phags-Pa, so I cannot answer that question meaningfully. However, I can confirm that the text displays as it should now, thanks! Crom daba (talk) 19:09, 2 January 2017 (UTC)


Could someone please have a look at {{calque}}? When applying it at king cake, I cannot get a gloss to appear, whether I put it in the fourth parameter position or use |gloss=. The documentation page seems out of date, as using |etyl t= generates an error. Thanks. — SMUconlaw (talk) 07:14, 2 January 2017 (UTC)

I can't figure it out either, and the documentation is definitely out of date. Calques are handled by Module:etymology/templates now, but I can't figure out how. Writing {{calque|en|fr|-|nocap=1}} {{m|fr|galette des rois||[[galette]] of the [[king]]s}} will work properly, but it seems clumsy. @CodeCat, can you help? —Aɴɢʀ (talk) 10:14, 2 January 2017 (UTC)
Looking at Module:etymology/templates makes me think that {{calque|en|fr|galette des rois||[[galette]] of the [[king]]s|nocap=1}} is supposed to work, but I'm not familiar with Lua. — SMUconlaw (talk) 13:59, 2 January 2017 (UTC)
You need to use etyl lang= when using etyl t=, no idea why this was implemented like that yet, but it works if you do it like that. Crom daba (talk) 17:13, 2 January 2017 (UTC)
Thanks. I do hope the template can be regularized and the documentation updated, though. — SMUconlaw (talk) 19:06, 2 January 2017 (UTC)
I had a similar problem in etymology sections of the Russian names of grammatical cases – for instance, винительный(vinitelʹnyj, accusative). I entered glosses into {{calque}} using the |t= parameter, but they didn't display. I added that parameter in the calque function of Module:etymology/templates, but that didn't do anything, since something has to be changed in the calque function of Module:etymology too. — Eru·tuon 23:06, 8 January 2017 (UTC)
It works now, now I just need to figure out how to make a tracking category for deprecated usage and change it, having two 'compat' variables can't be good. Crom daba (talk) 03:14, 10 January 2017 (UTC)
Turns out we already have a tracking template for this: Special:WhatLinksHere/Template:tracking/calque/etyl.
I removed all uses of deprecated lang=, but etyl lang= is too numerous, someone will have to do it by bot. Crom daba (talk) 09:52, 10 January 2017 (UTC)
@Crom daba, Erutuon: what changes have been made to {{calque}}? Could someone please update the documentation as well? Also, @Benwing2, perhaps you could help with the bot work? Thanks. — SMUconlaw (talk) 13:43, 19 January 2017 (UTC)
If someone describes exactly what the bot needs to do, I'll look into implementing it. Benwing2 (talk) 13:46, 19 January 2017 (UTC)
I've updated all the usages featuring the deprecated lang= parameter and subsequently removed the compatibility with it in the module. The next step is to change all usages featuring etyl lang= and compound parts like in this diff (I've made a tracker for this here), ultimately making {{calque}} similar to {{borrowing}} and {{inherited}} whose implementations could then be better integrated for a more maintainable code. Crom daba (talk) 14:10, 19 January 2017 (UTC)
@Smuconlaw: I went and updated the documentation. I think it's accurate now. — Eru·tuon 20:08, 19 January 2017 (UTC)


Would an administrator please review and process the edit request on MediaWiki talk:ExtractFirst.xsl? Didn't know where else to post this. Xaosflux (talk) 00:00, 3 January 2017 (UTC)

Done. DTLHS (talk) 00:03, 3 January 2017 (UTC)

Etymology-only language whose parent is also an etymology-only language[edit]

At neenish tart I find that {{etyl|de-AT-vie|-}} displays correctly as "Viennese German", but {{cog|de-AT-vie|-}} creates a module error "attempt to index local 'parent' (a nil value)". I suspect that's because Module:etymology languages/data lists the parent of de-AT-vie as de-AT, which is itself an etymology-only language with de as its parent. The easy way to fix this would be to simply change the parent of de-AT-vie to de, but I wonder if it wouldn't be preferable to allow {{cog}} to accept etymology-only languages with etymology-only parents. —Aɴɢʀ (talk) 17:22, 3 January 2017 (UTC)

I'm not sure if that's the same problem, but at Albania I tried to change the part "From {{etyl|gkm|la}} {{m|grc|Ἀλβανία}}" to {{bor|la|gkm|Ἀλβανία}}, which didn't work because gkm (Byzantine Greek) is an etymology-only language. That doesn't really make sense. Why not allow this? --Florian Blaschke (talk) 17:35, 15 January 2017 (UTC)
Works fine for me. Did someone fix it in the meantime? Crom daba (talk) 00:59, 18 January 2017 (UTC)

Fixed your problem @Angr. Crom daba (talk) 01:13, 18 January 2017 (UTC)

Thanks, Crom daba! —Aɴɢʀ (talk) 11:54, 18 January 2017 (UTC)

Need for Template:der4-u[edit]

We have {{der3-u}}, which is very useful, but I think an additional template {{der4-u}} would be useful in cases like this one. DonnanZ (talk) 15:17, 8 January 2017 (UTC)

Why can't these templates automatically decide how many columns to use? —CodeCat 16:55, 8 January 2017 (UTC)
They could... what thresholds would you recommend for the number of columns? DTLHS (talk) 16:56, 8 January 2017 (UTC)
Four is usually adequate, five looks too crammed I think, but would be the absolute limit. DonnanZ (talk) 17:13, 8 January 2017 (UTC)
I meant, what thresholds for the number of entries in the list should a theoretical automatic template use to decide the number of columns. DTLHS (talk) 17:22, 8 January 2017 (UTC)
Ah, that's a tricky question. The list for yrke has over 100 entries and is still lengthy, so changing from 3 to 4 columns with about 40-50 entries I guess. From 2 to 3 columns with about 10-15 entries would be about right. Thanks for the template, I've got some work to do this evening! DonnanZ (talk) 17:41, 8 January 2017 (UTC)
It would probably also depend on how long the words are, and whether they have transliterations. That is important for Ancient Greek, in which words can be long and they always have transliteration. If a module could count the number of characters in the output of Module:links, then perhaps the number of columns could be based on that somehow. Then again, I have no idea if this is possible. — Eru·tuon 23:02, 8 January 2017 (UTC)
There's also the CSS column-count attribute- I don't know if there's a technical reason we couldn't just use that to balance the columns. DTLHS (talk) 23:04, 8 January 2017 (UTC)
A fixed column count won't work if the screen isn't wide enough to fit all the columns onto. —CodeCat 23:07, 8 January 2017 (UTC)
Apparently there is a column-width property as well. If you set that, then it automatically uses as many columns as can fit on the screen. It's still not ideal, because on a wide screen a list of 10 items might be spread over 10 single-item columns, which is pretty awful too. Ideally, there'd also be a minimum height: fill up the first column, then overflow to the second once the first exceeds the minimum height. Repeat this until all columns are full, and only then, if there are still more items, should the columns be made taller and rebalanced as necessary. —CodeCat 23:11, 8 January 2017 (UTC)
I think the French Wiktionary already uses column-width FWIW. —suzukaze (tc) 23:14, 8 January 2017 (UTC)
Can you give an example of a large list on fr.wiktionary that is split into columns? —CodeCat 23:28, 8 January 2017 (UTC)
fr:manger. —suzukaze (tc) 00:02, 9 January 2017 (UTC)
From what I can see, there is no minimum height, so you can end up with one item in each column. This appears several times in "manger", with very short columns. I'm not sure if there is a way around this, the column-fill property doesn't seem to be a solution. Now if only min-height worked with columns... —CodeCat 00:10, 9 January 2017 (UTC)
There's a third property, column-fill: auto, which makes the first column fill before the second, then the third, etc. There are some downsides with this too, though. Firstly, it seems to only work in Firefox. Secondly, it requires specifying a maximum height for the list, so that the algorithm knows when to start filling the next column. Thirdly, if there's too many columns, they continue off-screen rather than making the list taller, since the height is a hard limit (and min-height doesn't work). —CodeCat 23:32, 8 January 2017 (UTC)

Module:hyphenation and automatic syllable counting[edit]

An editor added an automatic syllable counting feature to Module:hyphenation which is great, but there needs to be a way to either suppress (e.g., with |nocat=1) or manually override (e.g., with |syllables=3) the category generated because (1) the feature doesn't work properly when an entry has two or more words (e.g., venire facias de novo); and (2) there may be instances where the preferred hyphenation does not accurately indicate the number of syllables (e.g., symbolism). Please see the discussion at "Module talk:hyphenation#Automatic syllable count". Thanks. — SMUconlaw (talk) 17:15, 8 January 2017 (UTC)

It would be better to base syllable count on IPA transcriptions. @CodeCat and I have made a module that does this – Module:syllables – but no one has integrated it into Module:IPA yet. — Eru·tuon 22:57, 8 January 2017 (UTC)
I agree. I don't know who activated the syllable count in Module:hyphenation – any idea? Perhaps we should turn it off first, and work on your Module:IPA project? Who can assist with this? — SMUconlaw (talk) 16:12, 9 January 2017 (UTC)
@Smuconlaw: It seems that @IvanScrooge98 recently activated this feature in mod:hyphenation for English with this edit. This certainly is not correct as English hyphenation does not always represent English syllabification but is actually an unrelated set of rules for typography. We should definitely turn this off. —JohnC5 21:39, 9 January 2017 (UTC)
Thanks. I reverted that edit for the time being. — SMUconlaw (talk) 07:54, 10 January 2017 (UTC)
Oh, I obviously didn't mean to cause any problems. Thanks for reverting my edit. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 13:25, 10 January 2017 (UTC)

Module:IPA and Module:syllables[edit]

@Smuconlaw: @CodeCat and I posted about the syllable-counting function earlier, but nobody seemed to be interested in helping. I am not sure who to ask: perhaps @DTLHS, who seems to understand module code well, though he hasn't edited Module:IPA yet? — Eru·tuon 21:10, 10 January 2017 (UTC)
@Erutuon Which function from Module:syllables should I be using? DTLHS (talk) 21:40, 10 January 2017 (UTC)
And should I enable it for English only or for all languages? DTLHS (talk) 21:41, 10 January 2017 (UTC)
Module:syllables was never really "finished off" and brought into a ready-to-use state. I have no reason to think it won't work, but there's several different functions still in there for testing out different approaches and displaying testcases. —CodeCat 21:54, 10 January 2017 (UTC)
OK, let me know when it's finished. DTLHS (talk) 21:59, 10 January 2017 (UTC)
@DTLHS: I'm a little more optimistic about the module than @CodeCat; I think the function getVowels, which CodeCat created, is ready for deployment in at least the languages that currently have their diphthongs defined in the module. It should only be applied to for phonemic transcriptions, which are likely to be better regulated than phonetic transcriptions. My functions are unlikely to yield anything and could be deleted or moved. — Eru·tuon 22:41, 10 January 2017 (UTC)
Now added. DTLHS (talk) 22:59, 10 January 2017 (UTC)
@Erutuon Could you keep an eye on the various syllable categories that will now be filling up? I've already noticed some mistakes like "abstractional" being marked as having 3 syllables (although it could be a mistake in the transcription). DTLHS (talk) 23:04, 10 January 2017 (UTC)
Also NCAA has 13 syllables for some reason. DTLHS (talk) 23:06, 10 January 2017 (UTC)
More oddities: adore, abear, abler, bacteria, avocation, Liberia, Nigeria, February, gargantuan. DTLHS (talk) 23:12, 10 January 2017 (UTC)
Hmm, the problems with abstractional, adore, and some of the others are due to the transcriptions (which in the case of abstractional could be respelled as ab-STRAK-shnull; in the case of adore, the diphthong /oə/ the non-General American transcription /əˈdoə/ is being interpreted as two-syllable /o.ə/, giving a three-syllable count). For NCAA, I suspect the problem is that the module is somehow counting the syllables inside the various templates that make up {{IPA letters}}. There should probably be a parameter for turning off syllable-counting: |syllab=-, perhaps. Or I could edit the transcription of adore to add a nonsyllabic diacritic (/oə̯/). — Eru·tuon 23:46, 10 January 2017 (UTC)
Sometimes a variant ending is given without repeating the entire transcription- not sure what the best way to deal with that would be. DTLHS (talk) 00:08, 11 January 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Some thoughts:

  • The syllables should be automatically counted based on the first full IPA transcriptions provided, ignoring variant syllables.
  • Syllables should be counted for separate language variants, for example, Received Pronunciation and General American. It is possible that pronunciation differences may lead to different syllable counts for the same word. In this case, it would make sense for the module to categorize the word as having, for example, both three syllables and four syllables.
  • The module should be able to deal with multiple-word entries, such as venire facias de novo (nine syllables altogether).
  • Consider whether it is desirable to (1) allow manual suppression of syllable counting using |nocat=1; and (2) allow manual overriding of the syllable counting using |syllables=3 if the module is generating an erroneous result (and probably automatic tracking of such cases in a category so that either the entry or the module can be fixed, if necessary).

SMUconlaw (talk) 06:37, 11 January 2017 (UTC)

The module is now counting the syllables in the complete transcriptions in venire facias de novo correctly, since it is transcribed as having ten syllables. There was an unrecognized diphthong in the earlier transcription, /ʌɪ̯/ which I should probably add to the module, since it's used by the OED. — Eru·tuon 07:30, 11 January 2017 (UTC)
Thanks! The syllable counting still seems a bit erratic, though. I was looking at "Category:English 10-syllable words", but don't carboxymethylcellulose and psychoneuroimmunology have only eight and nine syllables respectively? Also, perhaps the categories should be renamed "Category:English 10-syllable terms" as our entries often consist of more than one word. — SMUconlaw (talk) 07:55, 11 January 2017 (UTC)
Psychoneuroimmunology is now categorized correctly after I added the alternative transcription /ʌɪ/ to Module:syllables, but carboxymethylcellulose has a really odd transcription: /ˈkær.bɒks.ɪi.mɛɵ.əlˌsɛl.jʊ.ləʊz/. /ɪi/ and /ɛɵ/ added two extra syllables. The transcription was added by @Thryduulf, and I remember seeing another like it before. Fixed the transcription, and now it's counted as having 8 syllables. — Eru·tuon 08:41, 11 January 2017 (UTC)
Oh, and you're right, the categories should certainly say terms and not words! — Eru·tuon 08:42, 11 January 2017 (UTC)

I found a solution to the partial transcription problem. I changed the function in Module:syllables to return nil if there is a hyphen at the beginning or end of the transcription, but it results in a module error since Module:IPA still tries to add the category, so I will have to revert it. Can be reinstated once Module:IPA is made to recognize it. — Eru·tuon 07:21, 11 January 2017 (UTC)

@Erutuon Made you a template editor. DTLHS (talk) 16:27, 11 January 2017 (UTC)
@DTLHS Thanks! I'll try to use the ability responsibly. — Eru·tuon 20:40, 11 January 2017 (UTC)
Note the existence of Category:English 0-syllable words (and other languages). DTLHS (talk) 17:11, 11 January 2017 (UTC)

@Erutuon, note this version of knuckle sandwich. I think the module may need tweaking so that it only counts the syllables in the first parameter of each {{IPA}} template on each line, ignoring subsequent parameters or {{IPA}} templates. — SMUconlaw (talk) 16:54, 15 January 2017 (UTC)

I guess I don't agree with only syllable-counting the first transcription. If there are multiple pronunciations, and they have different syllable counts, the word should be placed in multiple categories. Now February has a lot of variant pronunciations, so it's categorized as four-, three-, and two-syllable. The standard pronunciation would be four-syllable, and the two-syllable pronunciation is probably considered incorrect and cannot be recommended to a second-language learner who wants to sound intelligent. Yet since Wiktionary has entries for common misspellings, it makes sense to show mispronunciations and categorize words by the syllable count in those mispronunciations, not just the syllable count of the more correct pronunciation.
However, we need a solution for that edit in knuckle sandwich, where an alternative transcription of one of the constituent words of the compound was having its syllables counted. I'll have to think more about that. — Eru·tuon 17:46, 15 January 2017 (UTC)
Good point. If it is impossible to distinguish between transcriptions that should be counted and those which shouldn't be, you may just have to allow editors to manually suppress counting of certain transcriptions by adding a parameter, or manually edit transcriptions (like I did in this case) to stop them from being counted. — SMUconlaw (talk) 18:10, 15 January 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Erutuon, just wanted to bring to your attention mundialization and receptacle, where the module is incorrectly counting the syllables (five instead of six, and three instead of four) despite syllable markers being added. It seems that /-ʃn/ and /-kl/ are giving the module problems. — SMUconlaw (talk) 07:14, 22 January 2017 (UTC)

@Smuconlaw The module isn't very sophisticated in syllabifying, so it only recognizes syllabic consonants if they have the syllabicity diacritic: / ʃn̩/ instead of / ʃn/. It would be neat if we could input a totally unsyllabified transcription and have it calculate the possible number or numbers of syllables, but that will require a more complex set of rules. — Eru·tuon 07:50, 22 January 2017 (UTC)
Thanks, I just learned something new from you! Could you document this and any other relevant information at {{IPA}}? Thanks. — SMUconlaw (talk) 10:03, 22 January 2017 (UTC)

Template:reply to[edit]

I just noticed that while {{reply to}} generates a final colon as expected, using the redirect {{ping}} causes the colon to be omitted. What gives? --Florian Blaschke (talk) 19:08, 10 January 2017 (UTC)

Oh, I see the problem. {{ping}} is actually a separate template, while {{Ping}} with upper case is a redirect. That's confusing. Instead, {{ping}} should be a redirect too. --Florian Blaschke (talk) 19:10, 10 January 2017 (UTC)

External links with accents[edit]

These used to work and I don't know what happened: see the link at xiïta or verosímil compared to colze or portavoz -- okay actually neither of the Spanish ones is working so...huh. Ultimateria (talk) 20:54, 10 January 2017 (UTC)

@Ultimateria: DRAE doesn't have an entry for "xiïta" which is a Catalan term anyway. If the "id" is changed to "w" in the URIs, it works correctly for verosímil, though. —Justin (koavf)TCM 20:59, 10 January 2017 (UTC)
Oh god this is what I get for using keyboard shortcuts haha. As for verosímil, I don't know why it wasn't working 5 minutes ago and now it is. Thanks! Ultimateria (talk) 21:08, 10 January 2017 (UTC)
@Ultimateria: This is why. For some reason, the RAE assigns another id to word, so that the same content is available at both http://dle.rae.es/?w=veros%C3%ADmil and http://dle.rae.es/?id=beuYWd7 and the former redirects to the latter. I guess I can understand why they would want unique URIs for non-ASCII terms but why "hola" needs two forms I don't know. Glad I could help~ —Justin (koavf)TCM 04:20, 11 January 2017 (UTC)

more intuitive templates[edit]

We should make all templates more intuitive. F.ex. the head template is so hard to use or so defective that whoever has edited lying so far, including me, was incapable of adding the only information users are looking for when they look it up: whether it is the correct spelling of the present participle of only one of the two homographs and homophones lie.

At the very least, the entry should have this information in two different entries. Now it is even more misleading by having an example for only one of these two verbs. --Espoo (talk) 00:18, 11 January 2017 (UTC)

What would you ideally like the page to look like? DTLHS (talk) 00:30, 11 January 2017 (UTC)
First easy explanations of only the important features, followed by details farther below. And in this case, also an easy explanation for adding links to different homographs in the etymology and head templates. I couldn't find any info on this and therefore had to remove the templates. --Espoo (talk) 00:41, 11 January 2017 (UTC)
Actually, first I would say human readable entries. I am appalled to see MewBot (and probably others) replacing {{label|... with {{lb|... since it clearly indicates the mindset of the developers/maintainers of the template infrastructure is focused on manually typing in abbreviated and obfuscated jargon rather than maintainable content. - Amgine/ t·e 05:56, 13 January 2017 (UTC)
The substitution of {{lb}} for {{label}} seems exactly the opposite of how we could educate new users about the intent of template.
At the time of initial entry an experienced user should be able to save keystrokes by typing "lb".
At the time of editing a new user should have more self-evident template names to speed natural learning.
A bot could and should help us achieve both desiderata by expanding the terse to the full form. Is doing the opposite supposed to reduce the storage requirements for en.wikt? I don't see any other advantage to it. Some ideal JS system might be able to achieve the same result with only terse template names, but full displays, but we don't have that system and we don't seem to have many users with the time, skills, and inclination to develop such a system. What we have is a system of templates that seems designed to intimidate any new user with its terseness. This seems to defeat our wikiness, which is the main competitive advantage we have over our commercial competitors as a monolingual dictionary. DCDuring TALK 19:24, 13 January 2017 (UTC)
And yet we have more contributors than ever in the past. Some actual evidence that new users are intimidated by templates is required. DTLHS (talk) 19:30, 13 January 2017 (UTC)
The point has been made that the new contributors are doing translations. My concern is with en.wikt as a monolingual dictionary. The quality of our English entries will not be sustained without many English language editor willing and able to improve definitions. I fear that the uneven, too often poor quality of our English entries will not sustain good translations. DCDuring TALK 00:02, 14 January 2017 (UTC)
What does that have to do with templates? Improving basic English entries is a highly technical and time consuming task, regardless of the data structures behind the entry, and requires experienced editors familiar with lexicography. I do not think that random IPs are going to contribute much in this area. DTLHS (talk) 00:12, 14 January 2017 (UTC)
I believe that any needless obscurity in the wikitext, such as {{lb}} instead of {{label}}, serves to discourage new contributors, who may or may not have registered, from contributing. I assert to that the quality of many of our definitions is such that many could be improved even by "random IPs". There is plenty of work for the more experienced editors to clean up entries which "random IPs" identify as lacking something by their efforts to add or revise definitions. {{m}}, {{l}}, and some others are similarly excessively cryptic. DCDuring TALK 00:43, 14 January 2017 (UTC)
Since we're asserting things without evidence, I assert that we should change our logo to a picture of a cat and make all our text red and with a font size of 60 points in order to attract new contributors. DTLHS (talk) 00:50, 14 January 2017 (UTC)
The Grease Pit is virtually a user-fact-free zone. There is virtually no element of our current layout, template design, category structure etc. that is supported by evidence, though some items are not controversial. The fact is that we have operated with the only effective input being from experienced editors (except when that too is ignored). What evidence we get of new-user dissatisfaction is at best anecdotal and of discouragement virtually non-existent. It would be a miracle if that fact were not to lead to a Wiktionary editing interface and design designed principally to suit the preferences, taste, and whims of the active experienced editors. DCDuring TALK 15:35, 14 January 2017 (UTC)
There's evidence like this. Just as we use spelling errors to tell us about ancient pronunciation, we may learn something from formatting errors. Chuck Entz (talk) 17:06, 15 January 2017 (UTC)
Such evidence is strictly anecdotal. We don't compile it in a useful way. My imagination fails me when it comes to collecting data by which how we can improve our understanding of the process by which we attract and retain new contributors. DCDuring TALK 20:50, 15 January 2017 (UTC)
It is easy to add a feature to replace short template names to full names in the editing box for users, and again replacing them with the original (short) form when saving the page, but are we sure that full template names make the page code more readable? For example, changing "l" to "link" would make the page even more unreadable without much benefit, unless you also add names for unnamed parameters, which would make the page quit unreadable. Changing "label" to "lb" may be not very necessary as it is not used frequently unlike m and l and saving keystrokes is not a priority there. What would you do about {{head}}? Users need to see the docs, I can't think of any alternative way. We can show users a full form asking them to enter data for templates which have a lot of parameters, like what en.wp does with its citation templates, but that's also time-consuming for editors. --Z 08:16, 14 January 2017 (UTC)
Thanks for giving the matter serious consideration. You may be right.
I still wonder how we could make our templates, especially the commonly used ones, more accessible and, especially, make their functions more intelligible. I don't think that Wiktionary:Templates, even after correction, updating, and addition of missing material addresses the need for giving less experienced and devoted editors some means to grasp what the templates are supposed to accomplish. I am pretty sure that the most common way of learning here and generally is to imitate something that seems to work, but documentation is also sometimes useful. We have documentation that, when done well, meets the needs of experienced editors and others facing situations new to them. One thing we don't have is documentation that provides an overview that would help with selection of templates for different purposes or parts of an entry. Such documentation and links thereto from edit windows might help users accept and learn our practices, at least the rational ones. DCDuring TALK 15:35, 14 January 2017 (UTC)
I think the biggest problem for newbies is reaching template documentation, it simply wouldn't occur to most people to type in "template:..." into the search bar. If we had a way to display documentation as a pop-up in the edit window I think it would go a long way. Crom daba (talk) 03:01, 15 January 2017 (UTC)
WikEdit on Wikipedia has the feature where you control–click on a template name to open up the template page. That would be sort of useful, though people would have to know how to use it. — Eru·tuon 05:03, 15 January 2017 (UTC)
As useful as such a means of access might be for someone like me, learning or relearning the workings of a template or template feature that I rarely use, something a little more obviously available would be useful for new users, especially unregistered users. For registered users we could at least provide them with a welcome message in principle with links to documentation helpful to them. I don't think our welcome message (Wiktionary:Welcome newcomers?) does this very well. DCDuring TALK 13:13, 15 January 2017 (UTC)
Looking back on my experience, when you're a new user, every template is a template you rarely use. I don't think anyone is interested in reading 1000 words of documentation to learn about the entry layout or whatever, you mostly just copy stuff from other pages and then try messing around with it, breaking something in the process because you didn't find the relevant template documentation. Crom daba (talk) 14:47, 15 January 2017 (UTC)
Of course this applies only to those newbies that start looking at the code at all, we could probably attract some folks by having more gadgets which allow contributing without looking at the code. Crom daba (talk) 14:47, 15 January 2017 (UTC)
The latter is what seems to have worked for translations, which seems to be the area generating the most activity from new contributors. The structured nature of the potential translation contributions must make it easier to have such relatively intuitive gadgets. And the contributors seem to be motivated to advocate for their culture by adding translations. How many are as motivated to add synonyms for each sense of a polysemic English term or fill in other gaps in our English sections? DCDuring TALK 15:06, 15 January 2017 (UTC)
Links to templates used can be found at the bottom of the page when you preview an edit. Previewing should be encouraged as much as possible, because it gives a better ability to try things and see how they work without making a mess. Chuck Entz (talk) 17:06, 15 January 2017 (UTC)
That's certainly useful, even indispensable, but is it sufficient to help rank newbies? I think not. DCDuring TALK 20:50, 15 January 2017 (UTC)
Agreed. But my point is: why are we ignoring the practice of developers? There is a mantra that to be maintainable - by many different people with differing degrees of familiarity with the over-arching code project - use descriptive (and if possible standardized) names for variables, for methods, use plenty of white space to make things simple to interpret, do one thing on a line, etc. The same should be true for wiki entries. Saving keystrokes now costs time later. By all means use gadgets and bots to simplify data entry, which means you do not need to save keystrokes because the gadget does it. - Amgine/ t·e 05:30, 16 January 2017 (UTC)
You make a very good point. Rather than having shortcut redirects to templates, we could offload this to JavaScript which could automatically expand the shortcuts when the user types them. —CodeCat 16:55, 16 January 2017 (UTC)
Many templates, such as the inflection table templates, don't even have documentation in the first place, even though they're hardly intuitive. Very annoying even for experienced contributors like me. Constant changes over the years in how Wiktionary works don't help, either. I remember that Dbachmann was very interested in contributing, but found all the technical mumbo-jumbo off-putting, and when even someone like him complains about excessively high obstacles for would-be contributors, it means things are bad. --Florian Blaschke (talk) 21:18, 17 January 2017 (UTC)
Here's an example. Folks, I'm a moderately experienced, geeky but not hardcore tech-wiz user. I'm your target group. Listen to me, ffs! Here's the data you are looking for! For somebody who isn't a hardcore tech-wiz, undocumented inflection templates are a nightmare! --Florian Blaschke (talk) 19:25, 23 January 2017 (UTC)

OK, it seems the page codes are not easy enough for new contributors to work with, apparently because our pages heavilly use templates and referring the newbies to boring help pages introducing so many templates each with boring documentation pages doesn't work in Wiktionary.

Making only the mames of the templates longer and more descriptive may not solve everything. We can use longer terms for the templates and their parameters in the code, and replace any shortcut with its full form when saving the page. But this make the code less readable, at least when you do this to templates like l and t which may be used so many times in a given page (as opposed to headword template) and also because some of them have many parameters, so it would be time-consuming to read such code. Moreover, you would still need to teach the newbies the shortcuts or else editing may become as time-consuming if we do that to templates like l and t.
We can create mini-docs for templates like m, l, t, inh, borrowed, head, etc. and display them when the new users click over the the templates' names in the edit box. We can tell them about this feature just above the edit box. The mini-docs may contain a short description, an example or two, and link to the full documentation. We can have multiple usage examples or even multiple mini-docs for a given template so that our smart JS tool show one of them depending on the situation (language, PoS, etc.). I think this is particularly useful for the headword template.
Similarly, I suggest showing pop-up help pages as the user hover/click on a section or its header. As already mentioned by other users, new contributors prefer to learn mostly through editing and not opening and reading the help pages. In such pop-up help pages, we can tell them about a selection of templates that are widely used in that section. They will try it, and while trying a given template, the interface would offer them more relevant information (the template's mini-docs).
For some templates we can make their usage more intuitive by making the code and the output more and more similar, for example using "{{Inherited from|el|grc|term}}" instead of "From {{inh|.....}}".

--Z 18:16, 18 January 2017 (UTC)

@ZxxZxxZ: This seems like the right idea. I would think that a single short page with the most common and important templates and the most commonly used positional and named parameters for English L2 sections would be of significant help to many newbies. I am not so sure that etymology templates are vital for newbies. Perhaps a subpage for them, adding {{suffix}}, {{prefix}} and {{compound}}, would be an alternative. Templates such as {{sense}}, {{qualifier}} ({{q}}), and perhaps {{accent}} ({{a}}) should be on a similar subpage if not on the main short page. The documentation {{t}} needs to be linked to on that page, not explained beyond saying that it is solely for translations which can be added more simply using the gadget.
I don't think that some redundancy or even duplication would be bad if they would enable some users to find all that they needed for some tasks on a single page.
With what you seem to be proposing, long template names would offer less advantage and may well be a net disadvantage for almost all users. I would appreciate having links to the templates and/or CSS, module, JS, or other code that you use so I could perhaps do something similar with the taxonomic name templates. DCDuring TALK 19:54, 18 January 2017 (UTC)
I will be working on this proposed JS tool in the future. -Z 16:47, 2 February 2017 (UTC)

I didn't want to interrupt this discussion because it was obviously interesting and important to those who participated, but it talked about completely different problems than those in my OP. --Espoo (talk) 23:34, 20 January 2017 (UTC)

In part, the divergence of the discussion from your question is because of the title, the lead sentence, and the fact this is posted in GP. To the extent you are interested in changing entry layout, a more suitable venue would be WT:BP. To the extent you are interested in [[lying]], WT:TR would be better. The answer to the question "What would you ideally like the page to look like?" was probably intended to elicit your desired version of [[lying]]. DCDuring TALK 01:03, 21 January 2017 (UTC)

Categories for x-syllable terms[edit]

As Smuconlaw said above, it would be better if categories for syllable count were titled in the format English 2-syllable terms instead of English 2-syllable words, because many entries (for instance, venire facias de novo) contain multiple words, and there are also entries for bound morphemes (-ed) and clitics (-’s). I understand that the categories for number of syllables involve Module:category tree/poscatboiler/data/words by number of syllables, and presumably this should be moved to Module:category tree/poscatboiler/data/terms by number of syllables, but I do not know what else would be involved in a change like this. I imagine there are many categories that will have to be moved as well, which should be done by bot.

Would everyone agree with a change from words to terms in syllable-count categories? — Eru·tuon 22:08, 13 January 2017 (UTC)

  • Symbol support vote.svg Support! — SMUconlaw (talk) 13:05, 14 January 2017 (UTC)
  • Symbol support vote.svg Support --Daniel Carrero (talk) 13:08, 14 January 2017 (UTC)
  • Symbol oppose vote.svg Oppose. I don't think we should be categorising multiword terms by syllable count at all. —CodeCat 14:09, 15 January 2017 (UTC)
    • What about compounds such as the above-mentioned knuckle sandwich that are really a single word written as two? — Eru·tuon 17:55, 15 January 2017 (UTC)
      • Aren't those still "terms"? — SMUconlaw (talk) 18:11, 15 January 2017 (UTC)
        • Right, but I'm asking CodeCat for clarification on what multiword means. — Eru·tuon 18:46, 15 January 2017 (UTC)
          • The definition Wiktionary uses is anything with a space in between. —CodeCat 19:54, 15 January 2017 (UTC)
            • So you mean that single-word entries should be counted, but multiple-word entries should not be? Well, it's conceivable that knowing how many syllables there are in a multiple-word entry might be useful for someone composing poetry ... but of course I have no idea how often poets use the Wiktionary. — SMUconlaw (talk) 11:02, 16 January 2017 (UTC)
              • @Smuconlaw: Of course, this is a chicken-and-egg problem where no one could or would use Wiktionary for writing lyrics or poetry if we don't have those features. We should strive to have the most comprehensive dictionary in the world: etymologies, rhymes, appendices, thesaurus, definitions of all terms for all languages, etc. —Justin (koavf)TCM 17:45, 16 January 2017 (UTC)
  • I agree with CodeCat. — Ungoliant (falai) 17:54, 1 February 2017 (UTC)

Bug (ungrammatical text) in Alerts dropdown[edit]

It says "Your reverted." instead of "Your edit was reverted." This used to be correct, but it looks as though someone (presumably a developer outside of Wiktionary?) has broken it. Equinox 02:53, 17 January 2017 (UTC)

Is it fixed for you now? I think I found the message, but when I tested before changing it worked as expected. - TheDaveRoss 16:38, 17 January 2017 (UTC)
Yes (though the older message still exhibits the problem; I assume it was generated and permanently saved in that form). Equinox 16:41, 17 January 2017 (UTC)

Bug in rhyme-adding script?[edit]

Go to Rhymes:English/ɛstə(ɹ) and, using the automatic buttons, attempt to add wester. Unlike other words, this one fails with "ERROR:TypeError: Cannot read property 'parentNode' of undefined". (Actually, it seems to have worked, but my screen gave the error and did not visually add the word.) Equinox 23:48, 17 January 2017 (UTC)

There's also another bug: it doesn't use {{l}}. —CodeCat 00:04, 18 January 2017 (UTC)
Where is the rhyme adding script actually located? DTLHS (talk) 00:14, 18 January 2017 (UTC)
I followed a link after adding a rhyme, and came to the talk page User talk:Conrad.Irwin/editor.js, which mentioned rhymes. But the corresponding js page doesn't use the word "rhyme", though, so maybe the JS for the rhymes adder is located somewhere else. — Eru·tuon 04:49, 18 January 2017 (UTC)
  • A newer but not heavily tested version of the script is at here. It has at least one active user.--Dixtosa (talk) 06:22, 18 January 2017 (UTC)
    How do I install the script? — Eru·tuon 21:54, 18 January 2017 (UTC)
    • @Erutron: Go to Special:MyPage/common.js and you can either copy and paste the content or you can use importScript('User:Dixtosa/rhyme.js');. The first method is a little easier but the latter method is better because if Dixtosa changes his script then yours will update as well. —Justin (koavf)TCM 22:07, 18 January 2017 (UTC)
      • Note that you should also disable the old script in preferences 》 gadgets 》 "disable rhymes adder"--Dixtosa (talk) 23:15, 18 January 2017 (UTC)
        • To avoid the current situation in which a userspace page is used for integral parts of Wiktionary, can we get some kind of pledge that the script will be made "official" and moved to a more appropriate name when it's deemed good enough? —CodeCat 23:49, 18 January 2017 (UTC)
          • There's nothing wrong with a few people knowingly using a script that is in my userspace, especially without admin privileges that make it an annoying process to support a script that I am not allowed to edit. Anyways, I and the script are ready to for the deployment. --Dixtosa (talk) 15:05, 19 January 2017 (UTC)
            • The "template editor" user right should fix that. —CodeCat 15:08, 19 January 2017 (UTC)
              • No it does not. --Dixtosa (talk) 17:09, 22 January 2017 (UTC)

Make the edit box smaller II: electric boogaloo[edit]

In November [1] I was told how to make the edit box smaller. It's now gone back to its old size, and that setting has vanished from the preferences page. What?! How do I make it right again? Why do people break stuff all the time. jesus. Equinox 00:14, 20 January 2017 (UTC)

Add this to your css (adjust the width and height as you like them): #wpTextbox1 {width: 50em; height: 4em; }. DTLHS (talk) 00:19, 20 January 2017 (UTC)
Sweetness. Thanks! Still curious why the "official" feature was removed though. Equinox 00:25, 20 January 2017 (UTC)
I think it was also removed from Wikipedia. Annoying. — Eru·tuon 05:30, 25 January 2017 (UTC)

Graph of recent visits on main page[edit]

Semper added it recently; I'm not so sure I like having it there, but if we are to have it there, can someone please figure out how to format it more nicely so there isn't a big chunk of whitespace? —Μετάknowledgediscuss/deeds 00:54, 20 January 2017 (UTC)

Yup, there's some improvements that can be made. See also the discussion at Wiktionary talk:Main Page#Recent visits graph where additional points have been raised. — Kleio (t · c) 02:03, 20 January 2017 (UTC)
  • Does anybody actually support having it there? Given that I only see complaints, and that it seems a mite unprofessional, perhaps we should remove it. —Μετάknowledgediscuss/deeds 03:30, 20 January 2017 (UTC)


I want to add to Appendix:Variations of "p" the symbol for the antiproton - a letter "p" with a bar on top. How do I do it without using <math>? SemperBlotto (talk) 06:31, 20 January 2017 (UTC)

P + combining overline, (as in [2]). Another possibility is p + combining macron, (like [3] and [4]), but Wikipedia suggests the longer overline is a better representation of a vinculum, and the overline does seem to be slightly more common in the digitized journal articles that Google searches find. - -sche (discuss) 10:23, 20 January 2017 (UTC)
I think the overline is too long. --Octahedron80 (talk) 10:31, 20 January 2017 (UTC)
I think the overline looks better, and is less likely to be confused with the p̄ found in the scholarly transliteration of Hebrew. —Aɴɢʀ (talk) 10:55, 20 January 2017 (UTC)
I suppose we should have a hard or soft redirect from whichever line we don't use to the one we do use, when we create entries (since there are online versions of presumably printed and CFI-meeting journal articles using each encoding). Is anything symbolized by "i bar" or "j bar" where the overline might look excessive? Btw, there's an alternative notation (used in e.g. Paul Allen Tipler, Gene Mosca, Physics for Scientists and Engineers, volume 3, ISBN 1429201347), where a proton is p⁺ and an antiproton is p⁻, and likewise a positron can be e⁺ instead of ē. One source uses , but Scientific Style and Format: The CBE Manual for Authors, Editors, and Publishers says this is an error and a superimposed tilde symbolizes a supersymmetric particle instead. - -sche (discuss) 21:57, 20 January 2017 (UTC)

Is it the question mark[edit]

I'm having problems invoking the template {{...}} in the entry for unmanliness. Is the problem the question mark in the parameter? Could someone attend to this issue? --EncycloPetey (talk) 22:15, 21 January 2017 (UTC)

No, it's the br tags. I don't think the template was designed to handle them. DTLHS (talk) 22:20, 21 January 2017 (UTC)
Thanks! --EncycloPetey (talk) 23:19, 21 January 2017 (UTC)
By the way, why do you want to include the quote in {{...}} if you're not showing it on the page? DTLHS (talk) 23:20, 21 January 2017 (UTC)

New X-SAMPA to IPA template[edit]

I was frustrated by how clunky it is to use {{x2i}}, so I created {{X2IPA}}. Like {{x2i}}, it converts X-SAMPA to IPA, and must be substituted, but it takes the exact same parameters as {{IPA}}. (This cuts down on the clunkiness of putting a separate template in every parameter in which you need to convert X-SAMPA symbols.) Hopefully others will also find it useful. — Eru·tuon 00:59, 22 January 2017 (UTC)

Thank you. I wasn't sure anyone but me even used {{x2i}}. It will still be useful to use it inside {{rhymes}} and {{IPAchar}}, though. —Aɴɢʀ (talk) 14:40, 22 January 2017 (UTC)
Angr: Hmm, I just created {{x2ipachar}}, the same thing as {{X2IPA}} except it transforms into {{IPAchar}} when substituted. I'll look into making a Rhymes template too. — Eru·tuon 20:07, 22 January 2017 (UTC)
@Erutuon: If you like, but I don't see that {{x2i}} is so clunky that it can't be used for {{rhymes}}. I also use it in reconstructions like *gʷʰen- by typing {{m|ine-pro|*g{{subst:x2i|_w_h}}en-}}. —Aɴɢʀ (talk) 20:18, 22 January 2017 (UTC)
@Angr: Well, it's not very difficult to make now that I have made the other convenience templates, so now we have {{x2rhymes}}. It would be neat to have a convenience template for PIE too. — Eru·tuon 20:30, 22 January 2017 (UTC)
PIE isn't the only language that uses IPA characters, though. Lots of proto-languages do, as do a tolerable number of attested ones. —Aɴɢʀ (talk) 20:40, 22 January 2017 (UTC)
{{x2i}} serves as a good way to type the superscripts, but not for other proto-characters, like subscript numbers, macrons, hooks, and acute accents. It would be neat to have a shortcut template for them. — Eru·tuon 21:00, 22 January 2017 (UTC)

Using Javascript to set preferences of romanisation/script/etc., and switch between different versions of the same page using different romanisations/scripts[edit]

Is this possible, either on an across-site or a page-specific level? Examples are (1) hiding Latin-script forms for Serbo-Croatian entries, or Traditional Chinese forms of examples in Chinese entries; (2) using a specific romanisation scheme to romanise foreign words, hiding all the other romanisation schemes.

If this is possible, where can I find some documentation on the gadgets that may be used / some similar code?

Thanks! Wyang (talk) 07:41, 22 January 2017 (UTC)

Obviously, I don't know how it works, but a site-level functionality is indeed possible; you can toggle between Latin and Cyrillic views over at w:sh:. —Μετάknowledgediscuss/deeds 00:59, 27 January 2017 (UTC)


There's a bug in Template:quote-journal that, I assume, makes the current year show as when the quote is from. Look at this recent example of a change I made and study it very closely. Clearly, it should show 2012, but it shows 2017. I'd imagine there are hundreds of similar mistakes throughout the pages, but admittedly a great percentage of them may be of my doing for not knowing enough about the templates I was using. I hope there's a quick fix, coz I don't edit templates. --Quadcont (talk) 13:19, 22 January 2017 (UTC)

@Smuconlaw Do you understand why this happens? DTLHS (talk) 16:35, 22 January 2017 (UTC)
I wasn't able to replicate the error. When I look at the version of the entry when it was first edited by Quadcont, the date shows correctly as 18 April 2012 as indicated in the template and not 2017. Similarly, if I remove the comma that Quadcont added in the second edit, the template still correctly displays 18 April 2012. — SMUconlaw (talk) 16:53, 22 January 2017 (UTC)
This is the diff with the error. DTLHS (talk) 16:54, 22 January 2017 (UTC)
Sorry, I just realized that too. The quote family of templates uses the magic word #time to format dates, and #time will display the current year if it is omitted. For some reason, it seems as though {{quote-journal}} or {{quote-meta}} is treating a date with a comma like "18 April, 2012" as lacking a year. Removing the comma fixes the problem. I'm afraid I have no idea why. @CodeCat and @Erutuon, can you help? — SMUconlaw (talk) 17:14, 22 January 2017 (UTC)
Is it possible to make it throw an error instead of silently failing? DTLHS (talk) 17:19, 22 January 2017 (UTC)
Do we have an algorithm for detecting a comma in a string? If so I could incorporate that into the templates. But it's not supposed to be an error; it's supposed to work. For example, {{#time:'''Y''' F j|18 April, 2012}} works fine. We need to try and work out why templates like {{quote-journal}} are not passing text after a comma on to {{quote-meta}}. [Sorry, this is wrong. See below.] As far as I am aware, commas are not prohibited as parameter values. — SMUconlaw (talk) 17:28, 22 January 2017 (UTC)
Yeah the comma isn't the problem: "12 January, 2012" will display 2017 while "January 12, 2012" will display 2012. The parser function uses PHP's strtotime function which is supposed to raise an error if it can't parse the datestring. Of course it's PHP so it will fail in the dumbest way possible like we're seeing here. DTLHS (talk) 17:38, 22 January 2017 (UTC)
Ah, silly me. It's because strtotime recognizes "18 January 2012" and "January 18, 2012" as valid formats, but not "18 January, 2012". So there isn't anything wrong with the quotation templates. Well, we could get a bot to detect and replace all dates in the format "18 January, 2012", but I'm not sure it is practical to try and detect whether an editor has incorrectly placed a comma after the month. Any ideas about this? — SMUconlaw (talk) 17:45, 22 January 2017 (UTC)
I wonder whether it would be worthwhile do develop our own date parsing function (probably not). DTLHS (talk) 17:59, 22 January 2017 (UTC)
Yeah, not sure that's a good idea. — SMUconlaw (talk) 22:17, 22 January 2017 (UTC)
It seems like this issue would be much easier to fix if the complex template code in {{quote-meta/source}} were replaced with a module. But that would be a great undertaking. — Eru·tuon 22:39, 22 January 2017 (UTC)
We still wouldn't have control over the date parsing code unless we rewrote it ourselves. DTLHS (talk) 22:45, 22 January 2017 (UTC)
Well, the module could find and remove the comma in dates like "18 January, 2012" before passing them to the date parsing function. — Eru·tuon 23:11, 22 January 2017 (UTC)
  • Another bus I found is at head-scratching. They clearly state the date, but there's a cleanup tag "date required". That literally caused me a little bit of head-scratching. --Quadcont (talk) 12:19, 28 January 2017 (UTC)
There was a typo in the template. The parameter |archivedate= was mistyped as |archive=. — SMUconlaw (talk) 14:39, 28 January 2017 (UTC)

Multi-PoS non-lemmas[edit]

I've noticed that a lot of non-lemma forms (in multiple languages) were created a long time ago with only one part of speech in mind, for example, "boxes" created as a noun and neglected as a verb. Can we somehow generate lists of entries that are linked to under different PoS headers that don't include those same headers? English and other, I guess? Ultimateria (talk) 10:40, 23 January 2017 (UTC)

  • If they're for Romance languages, I'm proud to announce that hundreds of those would be my errors. One of the drawbacks of the WT:ACCEL tool is that they only work quickly for one part of speech. --Quadcont (talk) 21:00, 25 January 2017 (UTC)
I don't blame anyone; bots played a big part too. I know it's not a pressing issue, but I would like for us to have even non-lemmas as complete as possible, if anyone would help with the technical side. Ultimateria (talk) 18:09, 28 January 2017 (UTC)

Updating Wiktionary:Feedback/preload[edit]

Hello, could an admin change "Save page" into "Save changes" in this page? — Automatik (talk) 22:50, 23 January 2017 (UTC)

Done. DTLHS (talk) 22:51, 23 January 2017 (UTC)

Automatic categorization from affix templates[edit]

I was starting to manually categorize Ancient Greek nouns suffixed with -ῐ́δης(-ídēs) as patronymics, but then I realized it could be done much more easily with {{affix}} and {{suffix}}. So I added a little code to the affix and suffix functions in Module:compound to add the category if one of the |pos= parameters contains patronym. Now Ἀριστείδης(Aristeídēs) is automatically categorized since its etymology section contains {{suffix|grc|Ἀριστεύς|-ίδης|pos2=patronymic suffix}}.

I added a similar rule for diminutives, but since the diminutive categories contain the part of speech (for instance, Category:Diminutive nouns by language), words will only be categorized if two conditions are met: |pos= parameter in {{affix}} is defined, and the |posN= parameter contains diminutive. — Eru·tuon 02:47, 25 January 2017 (UTC)

I don't like this solution, but I can't think of a better one that preserves this simplicity. --WikiTiki89 23:44, 25 January 2017 (UTC)
@Erutuon Some cleanup needed: see Special:WantedCategories. DTLHS (talk) 17:05, 26 January 2017 (UTC)
The hobbitses have messed up the categorieses, my precious. —CodeCat 17:23, 26 January 2017 (UTC)
That's one of the greatest thingses I've seen on this site. Where down the line did that go wrong? Looking at the templates, I can't really find it. — Kleio (t · c) 17:44, 26 January 2017 (UTC)
Gollum has infected Wiktionary! Where it went wrong is in Module:compound, where -s or -es is added to the |pos= parameter. I added a rule to not add the plural marker if the pos is nouns, verbs, or adjectives. — Eru·tuon 17:49, 26 January 2017 (UTC)
@Erutuon: This change emptied 84 categories under Category:Hungarian words by prefix and I'm not sure what else. How are you planning to fix it? It's quite a bit of work manually.--Panda10 (talk) 18:34, 26 January 2017 (UTC)
They should fill up again by themselves now that this issue has been fixed. DTLHS (talk) 18:36, 26 January 2017 (UTC)
Thanks. I should have read Erutuon's comment more carefully. :) --Panda10 (talk) 18:47, 26 January 2017 (UTC)
@Erutuon: Whatever happened to change "Hungarian verbses" back to "Hungarian verbs", it also seems to have changed "Burmese compound words" to "Burmese compound word", see e.g. စက်ဘီး. —Aɴɢʀ (talk) 19:13, 26 January 2017 (UTC)
@Angr Bleh! My fault, a basic coding error. It's fixed now. — Eru·tuon 19:18, 26 January 2017 (UTC)


For me, {{outdent}} yields a bar that is longer than the indentation of the paragraph. For instance, the following:

Sample text.

──────────────────────────────────────────────────────────────────────────────────────────────────── Is it just me, or is the same true for other people? This doesn't look right.

Or maybe I'm misunderstanding what {{outdent}} is supposed to look like. I think the right arm of it ought to reach the first character in the indented paragraph. So here, it ought to reach to S, but for me, it reaches a point between the m and p in Sample. — Eru·tuon 00:52, 27 January 2017 (UTC)

Not sure – have you checked the behaviour of the template over at the English Wikipedia? It's probably the same. — SMUconlaw (talk) 10:15, 31 January 2017 (UTC)
@Smuconlaw: Actually, it seems to be different: the bar thingy reaches the leftmost character of the paragraph. See w:Template:Outdent/docEru·tuon 18:41, 31 January 2017 (UTC)
Ah, so. Well, feel free to change the template here to match the one at the English Wikipedia (if there is a coding difference). I don't think anyone is going to object. — SMUconlaw (talk) 18:16, 1 February 2017 (UTC)

Unwanted {{lb}} redirect[edit]

Currently, "Lorraine" in {{lb|}} converts to "Lorraine Franconian" with a link to the Wikipedia article, regardless of language (see assise, etymology 2 for an example). Could this be switched so that it only applies to German? Currently, French words cannot accurately be labelled as unique to Lorraine, which is not ideal. Andrew Sheedy (talk) 00:48, 28 January 2017 (UTC)

I've given Lorraine its own label separate from Lorraine Franconian. I didn't see any conflicts with existing usage. DTLHS (talk) 01:14, 28 January 2017 (UTC)
At the moment, there's no way to make a label language-specific. It would be wonderful if that capability were added to Module:labels and its data submodules, but so far no one has done it. — Eru·tuon 01:28, 28 January 2017 (UTC)
One reason why this is needed is that there is a wanted category Category:Romanesco English, added by {{lb|en|Rome}}. If the regional_category for the label Rome in Module:labels/data/regional were made to be language-specific (only applying if the language code is it, perhaps?), this would be fixed. — Eru·tuon 01:31, 28 January 2017 (UTC)

Parameter updates to Template:alter[edit]

I've updated Module:alternative forms, which is used by {{alter}}, so that it uses Module:parameters. And I've made it possible for alternative link text and id to be specified for each of the links, using the parameters |alt1=, |id1=, and so on. — Eru·tuon 21:15, 28 January 2017 (UTC)

I've also just added |tr=. —JohnC5 02:44, 29 January 2017 (UTC)

Buggy behavior in User:Conrad.Irwin/editor.js[edit]

Hello. It seems that {{t+}} is used instead of {{t}} when adding linked translations: ex. I used wikilinks as it's often done for non-idiomatic translations.

In fact the bug appears because in case of a syntax error when sending an API request, the response is different from the one expected when the word is missing: missing word vs. invalid syntax.

Therefore, a possible fix is to take advantage of the fact that, in the API response, the pageid field is always -1 whether the word is missing or the syntax is invalid: [5].

Could an admin implement this fix? Do you need any other information? — Automatik (talk) 23:51, 30 January 2017 (UTC) (updated at 23:00, 2 February 2017 (UTC))

DTLHS: this bug probably appears since this change. Could you take a look at it please? — Automatik (talk) 08:47, 2 February 2017 (UTC)
Yes I'll look at it. DTLHS (talk) 23:03, 2 February 2017 (UTC)
@Automatik Do you have a specific fix that I can add? I looked at the module but I don't really know what I would change. DTLHS (talk) 18:35, 4 February 2017 (UTC)
@DTLHS Actually yes, the edit that I proposed aboved [6] should fix this issue. Cf. lines 2627—2631 of the module. — Automatik (talk) 19:01, 4 February 2017 (UTC)

CSS to regularize spacing between paragraphs in talk pages[edit]

I propose that this CSS property, which was recently added on Wikipedia, also be added on Wiktionary:

.ns-talk .mw-body-content dd {
	margin-top: 0.4em;
	margin-bottom: 0.4em;

It adds spacing between consecutive paragraphs indented by :. Normally, such paragraphs are displayed with no vertical space between them, so often people add an extra line break between them. : is converted to <dd></dd> by the MediaWiki software, with an encircling <dl></dl>. If the colons are separated by only one line break, they are enclosed in the same <dl></dl> tag. Adding an extra newline adds an additional <dl></dl>. I gather (see w:WP:LISTGAP) that this makes it hard for screen readers to read talk pages, since each new <dl></dl> is taken as a new description list.

With this CSS, the following two paragraphs would have the same space between them as unindented paragraphs do, rather than having the same amount of space as two lines in the same paragraph, obviating the need for adding an extra line break.

Some text.
Some more text.

What do others think? — Eru·tuon 08:34, 1 February 2017 (UTC)

The proposal seems fine to me. — SMUconlaw (talk) 13:12, 1 February 2017 (UTC)

February 2017

Table Templates concerning Playing Card Suits[edit]

Could "Template:table:suits" be renamed to "Template:table:French suits"? It's just so it could be distinguished from "Template:table:Spanish suits", which I believe ought to be renamed to "Template:table:Latin suits" per Pagat. (Speaking of table templates, there ought to be two table templates named as follows: "Template:table:German suits" and "Template:table:Swiss suits".) --Lo Ximiendo (talk) 18:57, 1 February 2017 (UTC)


Template:gloss currently produces the following output: (this is an example). Does anyone have an objection to enclosing the gloss in quotation marks [(“this is an example”)] so that it matches other glosses generated by templates such as {{compound}} and {{m}}? (@IvanScrooge98.) —This unsigned comment was added by Smuconlaw (talkcontribs) at 18:24, 3 February 2017‎.

@Smuconlaw: Yes, I object, because {{gloss}} is most often used to provide a disambiguator rather than a true gloss. For example, the definition of njetopyŕ is given as "[[bat]] {{gloss|small flying mammal}}", but bat doesn't actually mean "small flying mammal". Instead, the {{gloss}} tag is there merely to indicate which sense of bat is being referred to. —Aɴɢʀ (talk) 17:19, 5 February 2017 (UTC)
Is that different from a "true gloss"? I wouldn't have thought that the placement of any gloss within quotation marks (as templates like {{m}} do) implies that the gloss is exhaustive. — SMUconlaw (talk) 17:29, 5 February 2017 (UTC)
I guess the crucial difference is that {{gloss}} is usually used after English words, while the t= parameter of templates like {{m}} is usually used after non-English words. In "{{m|dsb|njetopyŕ|t=bat}}", ‘bat’ is a full definition, a full translation, of the dsb word, while in "[[bat]] {{gloss|small flying mammal}}", ‘small flying mammal’ (and even more so in "[[bat]] {{gloss|animal}}"), the so-called gloss is really just providing enough info so the reader knows we're not talking about a baseball or cricket bat. —Aɴɢʀ (talk) 18:37, 5 February 2017 (UTC)

Template:IPA letters gives spurious error in preview[edit]

Template:IPA letters seems to give an "invalid IPA character" error in preview mode, though the saved page works fine. I encountered this when editing BBC. Equinox 12:21, 4 February 2017 (UTC)

{{IPA letters}} uses {{IPA}}, which uses Module:IPA which has a function that finds invalid IPA characters, using the list of valid characters in Module:IPA/data/symbols. I recently added a preview-only message that lists the invalid characters. Till now, the entry would simply be tracked with Module:debug. I'm not sure why the space is being considered an invalid character, because space is in the list of valid characters. Oh, it's because the template uses the HTML entity. I've added a rule to remove the HTML entity, so now the preview message no longer appears. — Eru·tuon 20:16, 5 February 2017 (UTC)
It's now giving an error message for g - plain ordinary English g typed on a keyboard. I know there's a preferred IPA glyph for g, but ordinary typed g should translate into it automatically. -- 10:45, 8 February 2017 (UTC)
The ordinary g has always given an "invalid IPA character" message, and it should, because it shouldn't be used in IPA transcriptions. It should be changed to ɡ wherever encountered inside {{IPA}} or {{IPAchar}} or {{rhymes}}. —Aɴɢʀ (talk) 11:24, 8 February 2017 (UTC)
The module is showing the position of the nonstandard characters instead of showing the characters themselves (see geliştir in preview mode). The error is on lines 137 and 138, result should be replaced with symbol. Redboywild (talk) 12:20, 8 February 2017 (UTC)
At this point, it's showing both the position and the characters themselves. But I'm about to fix geliştir. —Aɴɢʀ (talk) 13:21, 8 February 2017 (UTC)
@Redboywild: Oops. You're right. I've gone and implemented your recommendation. — Eru·tuon 20:21, 8 February 2017 (UTC)
Actually, the solution was somewhat more complicated. But now it works. @Angr, the obsolete or nonstandard characters part of the error message was showing the position, while the invalid symbols error message was showing the characters. Now both show the characters. — Eru·tuon 20:41, 8 February 2017 (UTC)

superhabitable planet[edit]

How does this term get into the category Category:English 7-syllable words? It isn't. SemperBlotto (talk) 18:30, 4 February 2017 (UTC)

I imagine it has something to do with the invalid IPA the creator provided. DTLHS (talk) 18:31, 4 February 2017 (UTC)
The IPA has been fixed by Angr. Erutuon has explained to me that syllables like /bl/ and /kl/ have to be indicated like /bl̩/ and /kl̩/ to be counted as a distinct syllable. — SMUconlaw (talk) 17:35, 5 February 2017 (UTC)

Arabic root cats[edit]

I've made {{ar-root}} automatically categorize entries in categories for root, such as Category:Arabic terms belonging to the root ك ت ب. Now there are lots of redlinked categories in Arabic entries.

Is there a bot that could automatically create the categories? They simply need to have {{ar-root cat}} or {{auto cat}} placed in them. — Eru·tuon 04:58, 5 February 2017 (UTC)

Done. DTLHS (talk) 17:38, 5 February 2017 (UTC)


This German noun is a member of the category Category:German nouns with red links in their declension tables. Not true; the links are green. SemperBlotto (talk) 07:50, 5 February 2017 (UTC)

The links are green because of the entry creation tool. They're red links in the sense that there's no page there, I guess. — Eru·tuon 08:52, 5 February 2017 (UTC)

The “New title” text box in a renaming page disappears[edit]

I cannot easily rename pages probably because of JavaScript for years, only on English Wiktionary. I cannot see the “New title” text box after the renaming page is fully loaded. Why is that?… I always have to hit ESC at the right moment to see it. — TAKASUGI Shinji (talk) 15:51, 5 February 2017 (UTC)

Could you provide a screenshot? DTLHS (talk) 20:17, 5 February 2017 (UTC)
A screenshot of the Wiktionary move page, showing the invisibility of the namespace and title fields.
The same is happening to me. Here's a screenshot. — Eru·tuon 20:24, 5 February 2017 (UTC)
I do not see that (tried Chrome, Edge). Maybe it's different for administrators? What does the HTML say? DTLHS (talk) 21:00, 5 February 2017 (UTC)
<div class="oo-ui-fieldLayout-body"><div class="oo-ui-fieldLayout-header"><span class="oo-ui-labelElement-label">New title:</span></div><div class="oo-ui-fieldLayout-field"><div id="wpNewTitle" aria-disabled="false" class="oo-ui-widget oo-ui-widget-enabled mw-widget-complexTitleInputWidget" data-ooui="{&quot;_&quot;:&quot;mw.widgets.ComplexTitleInputWidget&quot;,&quot;namespace&quot;:{&quot;id&quot;:&quot;wpNewTitleNs&quot;,&quot;name&quot;:&quot;wpNewTitleNs&quot;,&quot;value&quot;:2,&quot;exclude&quot;:[-2,-1,2600]},&quot;title&quot;:{&quot;id&quot;:&quot;wpNewTitleMain&quot;,&quot;name&quot;:&quot;wpNewTitleMain&quot;,&quot;value&quot;:&quot;Erutuon\/sandbox2&quot;,&quot;suggestions&quot;:false}}"><input type="hidden" name="undefined" value="0"><div id="wpNewTitleMain" aria-disabled="false" class="oo-ui-widget oo-ui-widget-enabled oo-ui-inputWidget oo-ui-textInputWidget oo-ui-textInputWidget-type-text oo-ui-textInputWidget-php mw-widget-titleInputWidget"><span class="oo-ui-iconElement-icon"></span><span class="oo-ui-indicatorElement-indicator"></span></div></div></div></div>
Well, here's the HTML, I think, for the part that isn't showing. — Eru·tuon 21:09, 5 February 2017 (UTC)
Any potentially interfering gadgets turned on? --Yair rand (talk) 07:15, 7 February 2017 (UTC)
Doesn't happen for me. Tried disabling all third-party (non-wiki) settings like ad blockers, just in case? Equinox 09:46, 7 February 2017 (UTC)
I’ve confirmed that it doesn’t happen when I turn off JavaScript. — TAKASUGI Shinji (talk) 12:50, 7 February 2017 (UTC)

Problem solved. Thank you all. I turned off “When moving pages, use the namespace-qualified title in the title box, and remove the separate namespace list” in my preferences and it works fine now. (@Erutuon) — TAKASUGI Shinji (talk) 13:43, 7 February 2017 (UTC)

@TAKASUGI Shinji: Ahh, I had that gadget enabled as well. Now that I turned it off, the move page displays normally. — Eru·tuon 18:57, 7 February 2017 (UTC)

Could someone please remove that gadget from the list of preferences until the bug is fixed? I don’t know where the list is. — TAKASUGI Shinji (talk) 23:42, 7 February 2017 (UTC)

I know there are lists of gadgets at Special:Gadgets and MediaWiki:Gadgets-definition, but not sure how gadgets get added to or removed from the list. — Eru·tuon 00:45, 8 February 2017 (UTC)
Removed. — TAKASUGI Shinji (talk) 02:16, 8 February 2017 (UTC)

Anchor gadget[edit]

The anchor gadget (MediaWiki:Gadget-U2693.js) is useful, but could an admin add subst: to the templates so that I don't have to type that in? — Eru·tuon 19:01, 6 February 2017 (UTC)

@Erutuon: What templates are you talking about? You're a template editor, so presumably you can fix them yourself. —Μετάknowledgediscuss/deeds 07:25, 7 February 2017 (UTC)
@Metaknowledge: Actually, it's a (JavaScript) gadget, and template editors don't have the right to edit them. See the link. — Eru·tuon 07:30, 7 February 2017 (UTC)
Oh, that was confusing. What I mean is the gadget produces copyable template code ({{unsigned}}), but it doesn't include the subst: before the template names, so you have to do extra typing after copying the template code. 07:40, 7 February 2017 (UTC)
Makes more sense, but I'm still confused. Why are you subst:ing these templates anyway? AFAIK, that's unnecessary. (Also, I find it annoying that template editors can't edit things other than templates — is it worth making a vote and filing a bug report?) —Μετάknowledgediscuss/deeds 07:58, 7 February 2017 (UTC)
@Metaknowledge: Oh, I was under the impression it had to be substituted. Apparently not, according to the template documentation. Perhaps substituting it is a Wikipedia custom. As to whether template editors should have the privilege of editing JavaScript gadgets – I for one don't have that much JavaScript knowledge, so I'm not sure either way. — Eru·tuon 10:38, 7 February 2017 (UTC)

Languages using punctuation as characters (Nivkh transliteration)[edit]

I've tried writing a Nivkh transliteration module today, but I've come across a problem with its (single quote) character used to denote aspiration, the problem is that our modules (translit, headword) treat it as a word divider causing it to link the two parts of the word separately in headword lines and transliterating the word part by part. Normally this wouldn't cause problems, but in the case of Cyrillic e we need to differentiate between positions following a consonant and beginning a word, as one should be written e and the other je.

Take for an example к’еӄ, its transliteration ought to be k’eq, yet our current setup together with my module can only produce k’jeq.

Does anyone have an idea of how we could achieve this (or a reason for why a solution could be impossible)

Crom daba (talk) 20:26, 7 February 2017 (UTC)

This is a long-running problem which needs a solution for many languages. Compare this diff (the problem can be solved with use of the head= parameter here, but it's still a terrible default for Hän). —Μετάknowledgediscuss/deeds 20:45, 7 February 2017 (UTC)
Yes: don't use the curly apostrophe (U+2019) as a letter. Anytime something apostrophe-looking is used as a letter (in any language, not just Nivkh), we should be using ʼ U+02BC (MO­DI­FI­ER LET­TER APOSTROPHE). If you move к’еӄ to кʼеӄ, it should transliterate correctly. —Aɴɢʀ (talk) 20:46, 7 February 2017 (UTC)
That's a bad solution. Why should we be using a character that people who actually write in the language don't use? —Μετάknowledgediscuss/deeds 20:49, 7 February 2017 (UTC)
Because that's what it's there for. Cases like this are exactly why Unicode has two separate characters, one for the punctuation mark and one for the letter. It's not our problem if other people use the characters incorrectly; we should still use them correctly. We can leave hard redirects from the spellings using the wrong character. —Aɴɢʀ (talk) 21:28, 7 February 2017 (UTC)
People who actually write in the language is a somewhat hypothetical category for Nivkh, I doubt that there's a standard, be it official or conventional, of how computer Nivkh should be encoded. If no one gives a better reason I'll go ahead and start moving pages. Crom daba (talk) 21:32, 7 February 2017 (UTC)

Well, it works now, I've replaced all the apostrophes per Angr's suggestion (thanks), however that wasn't even the problem it was

text = mw.ustring.gsub(text, "([^Ѐ-ӿ])Е","%1Je")

text = mw.ustring.gsub(text, "([^Ѐ-ӿ])е","%1je")

the function of which I don't understand. I've added

text = mw.ustring.gsub(text, "([ʼ’])Е","%1E")

text = mw.ustring.gsub(text, "([ʼ’])е","%1e")

before it and it works now for both apostrophes.

Crom daba (talk) 23:38, 8 February 2017 (UTC)

JavaScript error on search pages[edit]

Hello, this error happens on search pages:

TypeError: mainNode is undefined in MediaWiki:SpecialSearch.js

Looks like the search box has been redesigned recently. The script should be updated, and additional checks added to avoid breakage in case of future DOM changes.

Regards, Od1n (talk) 13:36, 8 February 2017 (UTC)

Here is a fixed version of the script : User:Od1n/MediaWiki:SpecialSearch.js (history). Would an admin deploy it, please? Od1n (talk) 14:28, 9 February 2017 (UTC)
Yes check.svg Done. --Yair rand (talk) 19:30, 9 February 2017 (UTC)

Deprecated ISO 639-3 codes[edit]

It seems that this was missed this year. The following codes have been deprecated by SIL and need to be removed from our language modules:

  • Rennellese Sign Language [rsi]
  • Shinabo [snh]
  • Rien [rie]
  • Lua' [prb]
  • Pu Ko [puk]

As well, there have been several new languages; I'll leave it to interested people to find these out and add them if there's demand. -- Pedrianaplant (talk) 15:38, 8 February 2017 (UTC)

What have these been replaced by? Do you have a link? —Aɴɢʀ (talk) 16:47, 8 February 2017 (UTC)
They were deleted outright; these languages do not exist. The summary for 2016's changes is here: http://www-01.sil.org/iso639-3/cr_files/639-3_ChangeRequests_2016_Summary.pdf -- Pedrianaplant (talk) 16:52, 8 February 2017 (UTC)
I don't believe any of these have any current use in Wiktionary, so they can simply be deleted without any cleanup needed. DTLHS (talk) 16:56, 8 February 2017 (UTC)
We should first see if there's any merit to that though. We may have a different opinion than SIL. —CodeCat 17:02, 8 February 2017 (UTC)
Looking at the first one, that was deleted because it's just a bunch of private signs developed by one deaf person that never managed to develop a grammar structure or a sufficient vocabulary to actually form a language on its own merit. The other four languages could not be discovered by researchers in their respecitve region and are thought to be spurious. -- Pedrianaplant (talk) 17:09, 8 February 2017 (UTC)
After reading the reasons for deprecation for all the languages mentioned, I've deleted all the codes from the language modules. —Aɴɢʀ (talk) 17:14, 8 February 2017 (UTC)

Special:Nuke ("mass delete") is no longer working[edit]

It now has an additional form prompting for the user name, etc. However, the resulting list contains new entries from all users, not just the one I typed in the name box. Equinox 13:06, 9 February 2017 (UTC)

phab:T156949. --Yair rand (talk) 19:33, 9 February 2017 (UTC)

Undo tweaking of Vector top section[edit]

Hello, please undo this change (so basically the Vector.css can be blanked).

Principle of least astonishment (aka. wtf muscle memory I clicked at the wrong place), the top section should not be different from all the other wikis…

Od1n (talk) 15:24, 9 February 2017 (UTC)

I don't think reverting this would be a good idea. Losing the definitions below the fold is a real issue, and we shouldn't waste critical screen space just to keep consistency with other projects. --Yair rand (talk) 19:26, 9 February 2017 (UTC)
1em doesn't change much about the "above the fold" (and the TOC eats all the space, so…). But current tweaks make that top section really narrow.
If you don't want to undo the whole thing, how about changing the offset from 1em to 0.5em? We still gain a bit of space, and it really makes the top section less messy.
Od1n (talk) 19:52, 9 February 2017 (UTC)

Porting and debugging of module[edit]

Hi, I'm trying to port the Module:character info and {{Template:character info/new}} to Swedish Wiktionary (sv:Modul:teckeninfo, sv:Mall:teckeninfo). And have a few questions:

  1. Is it possible to invoke a module from another language Wiktionary? It would be great to automatically get all the updates immediately propagated.
  2. Right now invoking the copied module results in a timeout (see sv:Modul:teckeninfo). Unfortunately I have no idea how to debug this. Any tips on how I can find the errors?

Have a nice day :) –dMoberg 08:42, 11 February 2017 (UTC)

@Moberg: Maybe check if the Swedish Wiktionary has the last version of Module:character info, Template:character info/new, Module:Unicode data and all its subpages, as well as Module:scripts and all its subpages, including Module:scripts/data.
I believe one Wiktionary can't use a module from another Wiktionary (I even tested a bit and failed), but it seems eventually we could move all character names and image links to wikidata:, which I believe can be accessed by other wikis. I don't know how to do that. --Daniel Carrero (talk) 01:50, 13 February 2017 (UTC)
We are missing all the subpages to Module:Unicode_data. How can I copy them? (It feels like loads of work duplication tho :( ) –dMoberg 17:22, 13 February 2017 (UTC)
@Moberg: Module:Unicode data currently has 69 subpages. At least the way the modules are currently implemented, I'm afraid someone really is going to have to copy all of them to other Wiktionaries to use them, like this: Module:Unicode data/images/000 to sv:Modul:Unicode data/images/000, and so on. I don't know if it's feasible to use a bot or AWB to copy these pages.
I agree that this feels like loads of work duplication. (especially as more and more Wiktionaries have to copy the modules, like the Thai Wiktionary already did: th:มอดูล:Unicode_data/images/001) Currently, it seems we didn't install Wikidata access on Wiktionary yet. I created Wiktionary:Beer parlour/2017/February#Proposal: Implementing Wikidata access to suggest installing it, which should make things easier in the future if accepted by the community. --Daniel Carrero (talk) 19:13, 13 February 2017 (UTC)
Yeah I dont really feel like manually copying that amount of pages, with the risk of not getting it to work. I'm rooting for wikidata! :) –dMoberg 21:59, 13 February 2017 (UTC)
Really you should never copy pages wholesale from another wiki, you should import them. That way the edit history is maintained as is required by the licenses. It also has the benefit of doing most of the work for you. - TheDaveRoss 22:05, 13 February 2017 (UTC)
Import seems like a better alternative (although not needed for history keeping?) but still too cumbersome unless there is some way to import all subpages for a page (scripting?). Another problem is overwriting previously imported pages. I really hope this can be moved to wikidata as soon as possible. :) –dMoberg 19:25, 14 February 2017 (UTC)


Hi. I have founded Category:cs:Olomouc but it seems that a new label needs to be added to the template:topic cat. I would like to ask for help with this since I really have no idea how to do it. Thanks. --Jan Kameníček (talk) 12:08, 12 February 2017 (UTC)

Are you sure this needs to be a topic category? Do you want something like Category:New_York_English ? Crom daba (talk) 12:17, 12 February 2017 (UTC)
I was thinking about something like Category:en:London or Category:en:New York City. --Jan Kameníček (talk) 12:27, 12 February 2017 (UTC)
Alright, but I don't think you should make it for a handful of entries.
You'll need to add it at Module:category_tree/topic_cat/data/Earth. Crom daba (talk) 14:01, 12 February 2017 (UTC)
Thank you. I am planning to add more entries soon. --Jan Kameníček (talk) 16:38, 12 February 2017 (UTC)

Fixing category-creation text to mention {{auto cat}}[edit]

@CodeCat CodeCat created {{auto cat}}, which is very handy but isn't mentioned currently in the text at the top of a new-category page. Instead there's a list of the older (non-auto) catboilers. Can someone point me to the relevant page where this text is held? I searched around in the MediaWiki namespace but couldn't find it. Benwing2 (talk) 19:33, 12 February 2017 (UTC)

@Benwing2: I believe you are looking for these pages:
--Daniel Carrero (talk) 02:21, 13 February 2017 (UTC)
@Daniel Carrero OK, thanks. I added {{auto cat}} to Template:categoryboiler. I'm still not sure where the text above it gets set, but I suppose it doesn't need changing. Benwing2 (talk) 02:31, 13 February 2017 (UTC)
Finally, I've been meaning to do this for some time now. Crom daba (talk) 03:11, 13 February 2017 (UTC)

A new Labs Tool to visually explore etymological relationships extracted from the English Wiktionary[edit]

Hi all! I have developed a tool to visualize etymologies. Please check it out at tools.wmflabs.org/etytree. My work is funded by an IEG grant. Please leave your feedback on the interactive tool here. It will help improve it.

a screenshot of the graph for word coffee

It's is impressive how well automatic extraction of data works. This is because Etymology Sections are written using well defined standars. I would like to get some feedback about some difficulties I have encountered while extracting data and some ideas I have about new templates. I wrote some notes here. Please add your comment there if you have any.

Looking forward to your comments! Epantaleo (talk) 16:19, 14 February 2017 (UTC)

This is very interesting. I wonder if you have a list of etymologies that you found were impossible to parse? DTLHS (talk) 16:25, 14 February 2017 (UTC)
@DTLH: I don't have a list but from the visualizations you can clearly see that some of the sections are incorrectly parsed. Some of those mistakes are due to bugs in the code, others are due to imprecise etymological definitions. Consider also that while debugging I have corrected many etymology sections (see my contributions) and after those contributions I still have not updated the database. I still use a database extracted from the December 20, 2016 dump. Epantaleo (talk) 17:01, 14 February 2017 (UTC)
(answered also there in Meta) Awesome. Coincidentally and recently and unknowingly I have just tried to do that with GraphViz and Gephi, but introducing the data by myself. I just tried the uncreated en:wikt:Reconstruction:Proto-Indo-European/paw- (see What links here) < en:wikt:pavor (in order to get data, create the article and fill the gaps). My results are so alike... and you got what I sought so much. I'll try to have some time for more comments.
  • I'd suggest giving the option to choose different graph types (more linear).
  • And apply colours of distance from the lowest node (said knot?).
  • Do this cognates in boxes interrupt parsing? Do you process cognates? Can it find incoherences (two different nodes of the same language pointing into the same descendant)?
  • I also recently discovered template:etymtree]] and Template:findetym: can you feed them (there are less than 100 created)?
  • It could be used for Wikisaurus, as it is even more standardised. Sobreira ►〓 (parlez) 13:36, 17 February 2017 (UTC)


After I did this and this, does the categories Category:Latin defective first conjugation verbs and Category:Latin defective second conjugation verbs update to you with new entries? (this worked with Category:Latin defective fourth conjugation verbs) Sobreira ►〓 (parlez) 12:47, 17 February 2017 (UTC)

  • Works perfectly (46 and 37 pages included respectively): Twas a problem of caché memory. Sobreira ►〓 (parlez) 09:08, 20 February 2017 (UTC)

Template:IPA reports invalid character on umzuzu[edit]

It says that ḿ is not a valid character, but note that this is a syllabic nasal; the word has four syllables, the second and fourth are high toned. Can this be fixed? —CodeCat 23:32, 18 February 2017 (UTC)

The module returns an error because composed letters with acute accents are, properly speaking, not correct IPA: a plain letter with a tone mark diacritic should be used instead. You can enter the tone mark diacritics by placing the X-SAMPA shortcuts (in this case, _H) into {{subst:x2i}}. Or maybe we could add a full set of acute-accented letters into the "valid" list in Module:IPA/data/symbols. But using the correct character is best. — Eru·tuon 23:42, 18 February 2017 (UTC)
I see that the "valid" list in Module:IPA/data/symbols already has a lot of pre-composed characters. So you can add m with acute to the list. — Eru·tuon 23:44, 18 February 2017 (UTC)
Characters are input into Lua as precomposed characters, and are likewise converted to precomposed by the software when output. There are two functions, mw.ustring.toNFC and mw.ustring.toNFD which compose and decompose characters respectively. If the module has trouble handling precomposed diacritics, it should decompose them before doing any processing. —CodeCat 00:14, 19 February 2017 (UTC)
That would be true if the tone diacritics were the same as the plain diacritics, but they are not. m plus combining acute tone mark (0x341) is not converted to m with acute ( 0x1E3F). At least this seems to be true when I enter {{subst:x2ipachar|m_H}} (which yields ḿ): no error message is displayed. — Eru·tuon 00:29, 19 February 2017 (UTC)
The high tone mark is a different character from the plain acute (0x0301)? —CodeCat 00:33, 19 February 2017 (UTC)
Yes, and the low tone mark (0x340) is different from the combining grave (0x300). But now that I look, there are no distinct characters for the rest of the tonal diacritics. That's inconsistent. — Eru·tuon 00:41, 19 February 2017 (UTC)
Ow, my head. Unicode, why are you so broken at times? —CodeCat 00:46, 19 February 2017 (UTC)

Template:obsolete form of is broken[edit]

The parameter |nocap=1 doesn't function anymore. |nodot=1 does still work.
{{obsolete form of|term|lang=en|nocap=1|nodot=1}} becomes obsolete form of term with a capital O and not a non-capital o, and without a dot. -Wilhelm-231 (talk) 08:28, 19 February 2017 (UTC)

I fixed it. It was because the text "obsolete form of" had italics (''Obsolete form of''), which prevented the lcfirst: and ucfirst: magic words from working. — Eru·tuon 23:41, 19 February 2017 (UTC)

Warning: Other pages link to or transclude the page you are about to delete.[edit]

This message turns up when deleting an entry, but I've come to ignore it, because if it's listed on RFV, then there'll be a link to WT:RFV. Is it possible to prevent this warning from appearing when the only links to the page are on WT:RFV, WT:RFD, or WT:RFDO? —Μετάknowledgediscuss/deeds 01:08, 20 February 2017 (UTC)

Ugly charboxes in mobile view[edit]

I'll leave this issue here in case someone's interested. After I was informed about it in my talk page, I was meaning to try to fix it but didn't do it yet.

The character boxes are very ugly when seen in a cell phone, and need some proper CSS formatting.

I'll leave a link to the asterisk entry in mobile view, as an example: https://en.m.wiktionary.org/wiki/*

--Daniel Carrero (talk) 20:47, 21 February 2017 (UTC)

By "ugly", I'm assuming you mean "of inconsistent widths"? ‑‑ Eiríkr Útlendi │Tala við mig 21:41, 21 February 2017 (UTC)
That's right. Yes, thanks for summing it up. Plus I'd like to add "float: right" in all these boxes, because apparently we currently have to scroll past all the boxes to start seeing the actual entry. Maybe the appendix name (like "Basic Latin") could be smaller, too. --Daniel Carrero (talk) 21:45, 21 February 2017 (UTC)
Mobile devices have very little width to work with, so floating things right won't go well for them. —CodeCat 21:59, 21 February 2017 (UTC)
I'm curious, is there any way from the server side to distinguish between tablets (which have more width) versus phones (which are quite skinny)? ‑‑ Eiríkr Útlendi │Tala við mig 00:18, 22 February 2017 (UTC)
I don't know, but at least I see that we have a whole CSS page specific to mobile view: MediaWiki:Mobile.css. Wikipedia has one too: w:MediaWiki:Mobile.css. If hiding content is needed, the Wikipedia page suggests this: "Do not use display:none. Instead edit the template and markup the element you want to hide with the `nomobile` class." --Daniel Carrero (talk) 08:21, 22 February 2017 (UTC)
CSS is capable by itself of using different rules based on the width of the viewport. —suzukaze (tc) 08:29, 22 February 2017 (UTC)
What about making the tables collapsible, instead of making them float to the right? That would make them take up less vertical space, and require less scrolling. — Eru·tuon 22:39, 21 February 2017 (UTC)

For what it's worth it seems like the Mobile CSS is designed to disable "float" and "width". —suzukaze (tc) 05:15, 22 February 2017 (UTC)

Template ux[edit]

The template {{ux}} requires to fill the translation parameter, which is sometimes not possible. May I ask for suggestions how to solve -e#Etymology 2? Thanks. --Jan Kameníček (talk) 21:33, 23 February 2017 (UTC)

@Jan.Kamenicek: For suffixes, you can use {{suffixusex}} instead of {{ux}}. See my recent edits to -e. —Aɴɢʀ (talk) 11:02, 24 February 2017 (UTC)
That is exactly what I was looking for. Thanks! --Jan Kameníček (talk) 11:50, 24 February 2017 (UTC)

Left-to-right mark in Module:headword and Module:usex[edit]

I'm puzzled by the inclusion of a left-to-right mark (&lrm;) in the output of Module:headword and Module:usex. This is unnecessary, since text direction for right-to-left languages is specified in MediaWiki:Common.css. I removed the left-to-right mark from Module:headword (though the edit summary is misleading; Module:script utilities no longer adds text direction markers, because they are unnecessary). It is a small thing to be concerned with, but I will remove it from Module:usex if there isn't a good reason for it. — Eru·tuon 10:26, 24 February 2017 (UTC)

Language-sensitive labeling[edit]

I've added the necessary code to Module:labels and Module:labels/data/regional to allow categories to be restricted to a set of languages. You simply add a list of language codes to the data table, and {{label}} will only add the category to those languages. I've tested it with the label "Koine" (the only one that currently has a "languages" field) and it works: {{label|grc|Koine}} adds a category, while {{label|en|Koine}} does not.

Unfortunately, this does not yet allow the same label to be used by different languages with different content. I can't think of a case where this would be needed, but it should be possible. — Eru·tuon 07:15, 25 February 2017 (UTC)

Okay, an example in which different content for the same label would be useful: Doric, which should refer to Doric Scots when the language code is sco, and to Doric Greek when the language code is grc.

I am thinking that one way to have this feature would be to have a table of language codes, and under each language code, a list of labels associated with that language. If more than one language uses the label, one language's table would contain the label, while others would refer to it. For instance, the label "honorific" would have to be listed under either "zh" (Chinese), or "ja" (Japanese), or "ko" (Korean), or another language, and have the other languages refer to it. This idea would result in more complexity: there would be a table of non-language-specific labels, and another table of language-specific ones.

And I am not sure how the module could return an error if an editor tries to use a label in a language that does not allow it (for instance, using "honorific" in English). — Eru·tuon 00:46, 26 February 2017 (UTC)

I suppose the answer is yet another table of labels with a list of languages in which they can be used: such a table would include a table indexed by "honorific" containing { ["zh"] = true, ["ja"] = true, ["ko"] = true }. — Eru·tuon 00:50, 26 February 2017 (UTC)

A table for "Doric" would contain ["grc"] = true, ["sco"] = true, even though the contents of the Ancient Greek and the Scots label would be different. — Eru·tuon 00:51, 26 February 2017 (UTC)

This sounds like a pretty bad idea. We really don't want to have to list everything for every language, because that would swiftly become unmanageable. —Μετάknowledgediscuss/deeds 01:05, 26 February 2017 (UTC)
@Μετάknowledge: It would be messy to have it all written out, but it could actually be fairly simple if we have functions that do most of the work. — Eru·tuon 01:19, 26 February 2017 (UTC)
But we don't want to have to list out all the languages that use honorifics. We would doubtlessly forget some, and we shouldn't have problems when someone eventually wants to add honorific terms in a new language and can't figure out why it's failing to work. —Μετάknowledgediscuss/deeds 01:51, 26 February 2017 (UTC)
Okay, then that's a bad example. But the feature would definitely be useful for the label "Doric". — Eru·tuon 02:01, 26 February 2017 (UTC)

Labels in Module:labels/data/subvarieties can now be made available by adding a language = "<code>" field. Without the language code, they will be ignored by Module:labels/data (which gathers up all the labels from the submodules). I'm going to move the Ancient Greek labels there. — Eru·tuon 03:22, 26 February 2017 (UTC)

Can somebody please this new topic category?[edit]

Category:ko:Korean letter names. It has become difficult to add new topic cats. --Anatoli T. (обсудить/вклад) 10:12, 25 February 2017 (UTC)

Documentation for "Template:projectlink/Wikipedia"[edit]

Would someone kindly create a documentation page for {{projectlink/Wikipedia}} (to which {{pedia}} redirects)? I cannot figure out from Module:wikipedia, which the template calls, what parameters the template takes. Thanks. — SMUconlaw (talk) 13:54, 25 February 2017 (UTC)