Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:Bug reports)
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 +/-


August 2014[edit]

Pages Running Out Of Time and Memory[edit]

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

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

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

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

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


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

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

Creating an entry for the Unicode replacement character[edit]

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

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


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

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

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

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

Duplicate mineral elements - fixable by bot?[edit]

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

Module:etymology language/data[edit]

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

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

A Peculiar Edit[edit]

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

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

Module:ru-verb help needed[edit]

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

        local no_iotation = args[no_iotation]; if no_iotation == "" then no_iotation = nil end
        if no_iotation then
                present_je_c(forms, stem, no_iotation)
                present_je_c(forms, stem)

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

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

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

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

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

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

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

I handle all of this. You can

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

This is used by four primary templates:

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

These templates are thoroughly documented.

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

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

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

Stray word "valid"[edit]

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

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

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

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

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

Polysynthesis help[edit]

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

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

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

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

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

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

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

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

In WT:Coding conventions it says

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

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

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

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

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

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

Language links[edit]

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

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

[ [ ar:word ] ]

[ [ da:word ] ]

[ [ fr:word ] ]


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

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

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

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

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

New entries by language[edit]

  1. 25 October 2014: αρτοπώλισσα
  2. 25 October 2014: αρτοπώλης
  3. 25 October 2014: κέρατο
  4. 24 October 2014: κρεμιέμαι
  5. 24 October 2014: κρεμάω
  6. 24 October 2014: κρεμώ
  7. 24 October 2014: εξαρτώμαι
  8. 24 October 2014: εξαρτιέμαι
  9. 24 October 2014: εξαρτώ
  10. 22 October 2014: καράφλα
  11. 22 October 2014: φαράκλα
  12. 22 October 2014: παραμύθι
  13. 21 October 2014: κάμποσος
  14. 20 October 2014: Υ.Γ.
  15. 20 October 2014: υπογραμμιστής
  16. 20 October 2014: λαγούμι
  17. 20 October 2014: υπερκείμενος
  18. 20 October 2014: υπαρξιακός
  19. 20 October 2014: παρθενικός
  20. 19 October 2014: υδρολίσθηση

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

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

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

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

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

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

RQ Template[edit]

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

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

Category:English words prefixed with auto-[edit]

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

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

Why are long pages slow to load?[edit]

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

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

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

Module errors on Old Church Slavonic translations[edit]

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

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

Red link headline in abbreviations[edit]

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

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


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

Template:character info adding bogus script cats[edit]

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

September 2014[edit]

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

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

You won't find much in MediaWiki because those were written by people here at Wiktionary. I suppose there might be documentation somewhere of the Wikimedia infrastructure that the JavaScript code is manipulating, but it wouldn't explain what we're doing with it. Chuck Entz (talk) 03:47, 1 September 2014 (UTC)
Right, I get that those were written here but I assume the documentation should be common to both projects. Is there any JavaScript documentation here on Wiktionary? Benwing (talk) 05:53, 2 September 2014 (UTC)
Why even have WT:Scribunto here anyway? For the most part, it seems to duplicate content over at mw:Extension:Scribunto/Lua reference manual. Keφr 06:39, 3 October 2014 (UTC)
Please don't delete it. It has lots of important introductory info not found in the MediaWiki Lua reference manual, and more importantly, it's here on Wiktionary. Someone who goes looking for info on Lua will likely try WT:Lua, which is a link to WT:Scribunto, and they will get a nice intro page on Lua, as expected. It's far less obvious to go look on the MediaWiki pages, even less obvious that you have to look under "Extension:Scribunto". Someone who's interested in Lua scripting will probably have heard something about scripting being in Lua but it's unlikely they'll have heard of Scribunto as such. Certainly, I found the docs in exactly this fashion. If there were a WT:Javascript page, it would be a huge help. Benwing (talk) 07:20, 3 October 2014 (UTC)

Template:character info adding bogus script cats[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Category:Wiktionary protected edit requests[edit]

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

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

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

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

Appendix:Arabic Frequency List from Quran[edit]

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

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

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

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

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

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

undocumented template: anchor[edit]


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

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

@Thnidu: There are 64 pages which transcludes the mentioned template, in which 21 pages are in the main namespace or appendix namespace. Moreover, {{jump}} contains more function and is more useful than the mentioned template, and most pages use {{jump}} instead of {{anchor}}. Therefore, I think that this template is not even necessary. --kc_kennylau (talk) 17:20, 8 September 2014 (UTC)
Does {{jump}} work from links from other wikis? The specific page which anchors are needed for is biscuit, which Wikipedia is going to (or already does) link to different sections of like this. - -sche (discuss) 19:23, 8 September 2014 (UTC)
@Kc kennylau: (I just saw this.) Thanks, but you haven't addressed the absence of documentation. Wikipedia has a fully functional "anchor" template. I've been a W'pedian for many years, so I looked for "anchor" here. Can you, or some experienced Wiktionary editor, at least add a paragraph of documentation to your anchor saying
If you're looking for the Wikipedia anchor functionality, try {{jump}}?
--Thnidu (talk) 01:32, 20 October 2014 (UTC)
@Thnidu: I trust that you can do this yourself. If you would still like assistance, feel free to ask us again. --kc_kennylau (talk) 14:28, 20 October 2014 (UTC)

Broken sort[edit]

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

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

Echo and watchlist[edit]

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

I'd like to get this done:

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

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

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

New errors on Arabic pages[edit]

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


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

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

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

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

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

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

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

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

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

Breves in Ancient Greek[edit]

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

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

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

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

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

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

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

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

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

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

WOTD maintainer?[edit]

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

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

There was a WOTD tool? (Also, hi. Do you mind being de-checkusered?) Keφr 05:25, 14 September 2014 (UTC)
I’m not sure what you’re asking, Connel, but, as I understand it, the toolserver tools are being migrated to Labs (tools.wmflabs.org). You probably already knew that, but just in case you didn’t. —Stephen (Talk) 14:39, 16 September 2014 (UTC)
Stephen, I have been offline quite a while - there's a lot I'm not up to date on. --Connel MacKenzie (talk) 22:20, 30 September 2014 (UTC)
There is a WOTD feature - I do still get the daily e-mail that includes Wiktionary's WOTD along with a bunch of other stuff. The process is automated at the wiki level now - I'm not clear on the mechanism. --Connel MacKenzie (talk) 22:20, 30 September 2014 (UTC)


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

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

Visual Editor[edit]

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

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

Template deletion[edit]

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

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

Noun5, really ?[edit]


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

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

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


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

What the...?[edit]

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

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


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


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

@Type56op9: User:DTLHS/elsewhere DTLHS (talk) 04:46, 23 September 2014 (UTC)
Thanks, by the way. I've gone through some of that list and created some stubs. And linked to that page from Wiktionary:Wanted pages, so perhaps at least one other user will be able to use it. --Type56op9 (talk) 10:06, 1 October 2014 (UTC)

Burmese characters[edit]

What it looks like now

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

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

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

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


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

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

References:The Bokmål Dictionary[edit]

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

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

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

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

User problem with hidden quotations[edit]

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

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

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

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

Lettering question[edit]


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

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

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

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

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

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

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

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

Standardised interwiki prefixes now available[edit]

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

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

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

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

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

October 2014[edit]


Can someone please fix some small problems with the module, please? The language name uses an old way and gives module errors. Ideally, it would be great if it could work for other languages as well, e.g. {{zh-new}}. User:Ruakh is no longer supporting it, as he said. --Anatoli T. (обсудить/вклад) 03:09, 1 October 2014 (UTC)

I'm going to try this change: From:

wikitext += '=={{subst:#invoke:languages/templates|lookup|' + tbotData.lang + '|names}}==\n\n';


wikitext += '=={{subst:#invoke:languages/templates|getByCode|' + tbotData.lang + '|getCanonicalName}}==\n\n';

--Anatoli T. (обсудить/вклад) 03:17, 1 October 2014 (UTC)

Rolled back. It didn't work. The links are no longer green. --Anatoli T. (обсудить/вклад) 03:23, 1 October 2014 (UTC)
Fixed. The reason it didn't work is that you tried to add some comments like this ' comment, while JavaScript uses comments like this // comment or like this /* comment */. The apostrophe is used for strings, not comments. --WikiTiki89 09:06, 1 October 2014 (UTC)
Thanks for the fix! I have just tested it on табуляция. --Anatoli T. (обсудить/вклад) 22:56, 1 October 2014 (UTC)

Can you export format_headword, format_transliteration, format_genders, format_inflections? Or let me do it myself, or something[edit]

I would like to fix things so that Arabic headwords automatically have vowels filled in based on the transliteration. The reason for this is that tons of Arabic words (nouns, adjectives) currently have a transliteration that specifies the vowels, but no headword with such vowels. I've already written the code to actually fill in the vowels, and I already fill in the vowels in plurals (using {{ar-linkify-bold}}).

Perhaps the cleanest solution that requires the least code duplication would be to modify Module:headword itself (and probably also Module:links to do the same trick in links, although it's less common there to have a transliteration). However, I don't have permission to do this as I'm not an admin, and this might be controversial as it would introduce language-specific code into what's currently largely language-agnostic. An alternative is for me to create my own version of {{head}}; to do this and avoid so much code duplication, I would need the above functions exported.

Benwing (talk) 03:42, 3 October 2014 (UTC)

Could this not be achieved by editing the pages themselves, so that the linked term includes the vowels? —CodeCat 12:28, 3 October 2014 (UTC)
The point of doing this is to avoid having to manually edit all the pages.
I oppose this. What you should do instead is run a bot to add the vowels based on the transliteration. --WikiTiki89 14:43, 3 October 2014 (UTC)
I don't have any permissions to run any bots or any experience writing them. Can you do things like get all the pages in a particular category, or all the pages that use a particular template? Benwing (talk) 17:42, 4 October 2014 (UTC)
I would definitely recommend learning how to run a bot. It can make tedious tasks a lot easier. I use Python with pywikibot and mwparserfromhell. It allows all those things and more. —CodeCat 17:57, 4 October 2014 (UTC)
Or you could request someone else to run a bot. The decision should be based on what has the best end result, not on what you are more skilled at doing. --WikiTiki89 21:04, 6 October 2014 (UTC)

Discussion/Talk vs Info Desk vs Tea Room[edit]

1) The blank 'Discussion/Talk' page of every Wiktionary entry has apparently been superseded ambiguously by either an Info Desk or Tea page, with a very poor explanation and cumbersome connection/link or even directions to find the recommended edit page.
"Talk pages of individual entries are not usually monitored by editors, and messages posted there may not be noticed and responded to. You may want to post your message to the Tea Room or Information desk instead."
implies that there is another proper use for the convenient Discussion page, without acknowledging or describing what that might be.
"... may not be noticed and responded to." might mean "might not be noticed and responded to by anyone but subscribers to this entry."
I understand that the purpose of each entry's Discussion page is for the discussion of the critique of the article rather than the definition itself. Although I have seen no rational for the distinction, I presume it is to mitigate against the occasional very long educational debates that may obscure actual structural issues with the article.

2) Any improvements to this ubiquitous 'instruction' would apply across the (many) millions of entries which don't yet have discussion text. The rest (existing discussions) should presumably be moved to comply with this 'instruction'. This issue is apparently only a problem for relatively new users (of which I hope there are & will be many thousands more over the years). It would be nice if a convenient list of the dis/advantages & purposes of the Discussion page, were immediately visible or at the very least, linked in the 'instruction', so all users could maximize the benefit of their time and contributions.

3) Perhaps this discussion should be duplicated/linked on some Tea Room meta-page.
--Wikidity (talk) 00:56, 4 October 2014 (UTC)

please fix Module:headword to link multiword heads when head= is given[edit]

There's code in Module:headword (in format_headword) to automatically add links to each word of a multi-word page name, but it doesn't do this when an explicitly specified value is given using head=. This is important for Arabic because head= is used to specify the vocalized equivalent of a page name. You can work around this by manually adding the links, but I see no reason why this can't be done automatically. Can someone fix this? Or alternatively, can I be given permission to edit Module:headword so I can fix it myself? Thanks. Benwing (talk) 06:52, 5 October 2014 (UTC)

This should not be done, because the head= parameter is also used to suppress automatic linking. With your suggestion, there would be no way to do this anymore. —CodeCat 12:29, 5 October 2014 (UTC)
Hmmm, that means that head= has two different and potentially clashing uses, which is kind of ugly. Seems it would be better to have a separate param to suppress auto linking, maybe? Benwing (talk) 21:10, 5 October 2014 (UTC)
Not really. The purpose is very clear: it overrides the default. Whatever you specify under head= becomes what is displayed. —CodeCat 21:16, 5 October 2014 (UTC)

another bug in Module:headword; please give me write permission to fix it[edit]

If you have two heads, both are displayed, but the transliteration is only for the first one, whereas it should show the transliteration of both, separated by "or", just like for the heads themselves. I'd like to have write permission on this module so I can fix bugs like this (and the one below, about cat2= and cat3=). Thanks. Benwing (talk) 09:14, 5 October 2014 (UTC)

I've done this now. —CodeCat 14:42, 5 October 2014 (UTC)
Thank you! Benwing (talk) 21:16, 5 October 2014 (UTC)

yet another bug in Module:headword[edit]

Only cat2= and cat3= are supported. No reason not to support at least up to cat9=. I feel this restriction acutely in some of the Arabic headword templates, and for this reason I have to manually insert the categories. Benwing (talk) 09:19, 5 October 2014 (UTC)

I don't think it's much of a problem to manually insert categories in headword templates. —CodeCat 13:30, 5 October 2014 (UTC)
But then you have to wrap it in namespace-checking {{#if:}}s, which is tedious. Keφr 14:52, 5 October 2014 (UTC)
Not if you use {{catlangname}} or {{categorize}}. —CodeCat 15:15, 5 October 2014 (UTC)
What's the point of having cat2= and cat3= at all if we're only going to allow two of them? It should be trivial to fix this to allow more of them. If you don't want to bother doing this, why not remove cat2= and cat3= entirely instead of leaving a crippled interface in? Benwing (talk) 21:12, 5 October 2014 (UTC)
That's a good point I suppose. But it makes me wonder why these additional parameters were originally added to the template, and why the choice was made at the time to include only 2. My guess is that they're only intended to be used for additional categories that pertain directly to the part of speech. For example, to have the main part of speech as "nouns" and to add "diminutive nouns" as a second. —CodeCat 21:15, 5 October 2014 (UTC)
Probably just coding laziness, esp. since presumably this was originally coded using template hackery. Doing template hackery is so painful that coders routinely hardcode all sorts of arbitrary limits that shouldn't be there -- 2 of this, 3 of that, 5 of this, etc. Benwing (talk) 21:18, 5 October 2014 (UTC)
I can add support for more categories, but I don't think they should be used for anything other than additional POS categories. So putting something like "slang" would not be right IMO. —CodeCat 21:36, 5 October 2014 (UTC)

Entry templates[edit]

I created a new entry template for Hungarian nouns. How can I see it on the list of entry templates without changing the language preference? Currently, I see the Spanish and Swedish templates below the English ones. I'd like to keep English as the language of the interface. --Panda10 (talk) 13:18, 5 October 2014 (UTC)


Wikipedia's SuggestBot just gave me neat suggestions about what articles I might be interested in contributing towards. I have since added some of those to a "to-do list" in my userspace.

So, I'm wondering...

Does Wiktionary have a "SuggestBot" or something similar? Tharthan (talk) 21:04, 5 October 2014 (UTC)

Bad "transliteration needed" messages?[edit]

I made a change to Module:headword so that it tags and categorises entries that are not in Latin script, and which have no transliteration provided and none could be generated either. This seemed like a useful change, but apparently it's showing up in a few places where it's not wanted. I made exceptions for Chinese and Translingual. But I'd like to make sure there are no other cases of this. Could problems be reported here please? —CodeCat 00:00, 6 October 2014 (UTC)

Japanese needs an exception too. It has automatic transliteration. See 消音器. --Anatoli T. (обсудить/вклад) 01:55, 6 October 2014 (UTC)
It's not transliteration technically, as it's displayed as an inflection. So you're right. —CodeCat 02:08, 6 October 2014 (UTC)
I've added the exception to Module:headword for ja following what you did for zh and mul. --Anatoli T. (обсудить/вклад) 02:17, 6 October 2014 (UTC)

Importing offline dictionary[edit]

I was wondering if there are any automation tools/bots in existence that could import an offline dictionary file into wiktionary, supposing the formatting consistent and the license as CC. Me and a few friends are working on compiling a smallish dictionary for Oriya (Odia) in ABBYY's DSL format. I believe it'd be immensely useful if it could be imported into wiktionary. Coldbreeze16 (talk) 22:49, 7 October 2014 (UTC)

I'd be happy to work on it- do you have any sample entries? DTLHS (talk) 04:15, 8 October 2014 (UTC)
Thank you, and yes. http://pastebin.com/raw.php?i=fE52kQy9 That's a sample. A few words will be left undefined because source word list is EOWL and we don't have the resources to define every word in it (1,30,000 words). Coldbreeze16 (talk) 11:05, 8 October 2014 (UTC)
@Coldbreeze16: Hm, any chance of getting it in a more convenient format? Or do you have any tools for converting to xml / json / etc? DTLHS (talk) 19:49, 9 October 2014 (UTC)
Certainly! There's a standardized (partially) xml dictionary format called xdxf which offers a converter tool. Here's a snippet from the start of letter 'B'. http://pastebin.com/raw.php?i=QVb2P1DZ Coldbreeze16 (talk) 16:35, 10 October 2014 (UTC)

Permission to run a bot?[edit]

I'd like to run a bot to fix up the parameters of various Arabic headword and link entries. There are a few tasks, e.g.

  1. Vocalizing unvocalized Arabic-script words based on the transliteration.
  2. Removing redundant transliterations.
  3. Removing various parameters from augmented verb headwords, because they're ignored (all relevant info can be auto generated given the numbered verb form).

I've never run a bot before but I have experience with Python, and I have some code from CodeCat that should help running the bot. I've converted the vocalization code in Module:ar-translit into Python and it works.

What needs to happen for me to get this set up and have the permissions enabled?


Benwing (talk) 10:41, 8 October 2014 (UTC)

WT:BOT. --WikiTiki89 11:31, 8 October 2014 (UTC)


Hello all. I have just edited the Lua module Module:la-headword in an attempt to add the optional function of listing a second genitive form, which is needed in the particular case of poppyzōn and which is useful generally. AFAICT, it hasn't introduced any errors and, for the most part, it works as intended. However, there is an undesirable comma between the first genitive form and the following "or" which I don't know how to get rid of. Could a more Lua-capable editor check my edit for any unforeseen errors and further edit the module to remove that offending comma, please? — I.S.M.E.T.A. 09:39, 10 October 2014 (UTC)

I fixed it. The "or" is only used by the template {{head}}. Internally in Lua, it's just a list. —CodeCat 11:20, 10 October 2014 (UTC)
Thank you very much. I clearly have a lot to learn; Lua's pretty impenetrable for me ATM. — I.S.M.E.T.A. 21:55, 10 October 2014 (UTC)
This is more a matter of our own modules than Lua itself. Module:headword's documentation is a bit out of date after several recent changes, and I need to update them but motivation is hard. :( —CodeCat 21:57, 10 October 2014 (UTC)
You are kind, but I think you underestimate my coding incompetence! :-S Re documentation-writing motivation, I hear you; I only just got round to writing documentation for {{R:OLD}}, and I still have {{R:Gaffiot}}, {{R:Niermeyer}}, and {{R:Reaney & Wilson}} to do. — I.S.M.E.T.A. 16:29, 12 October 2014 (UTC)

Some "transliteration needed" false positives[edit]

Some entries have"Romaji"/"Rumi spelling"/"Latin spelling"/"Latin form" parameter
  1. code: bbc Category:Toba Batak terms needing transliteration
  2. code: bug Category:Buginese terms needing transliteration
  3. code: cia Category:Cia-Cia terms needing transliteration
  4. code: cjm Category:Eastern Cham terms needing transliteration
  5. code: ryu Category:Okinawan terms needing transliteration
  6. code: tgt Category:Central Tagbanwa terms needing transliteration
  7. code: tly Category:Talysh terms needing transliteration
Issues with Punctuation/Symbols in non-Latin scripts
  1. code: en Category:English terms needing transliteration
  2. code: shn Category:Shan terms needing transliteration
  3. code: tl Category:Tagalog terms needing transliteration
  4. code: za Category:Zhuang terms needing transliteration

Chuck Entz (talk) 00:36, 12 October 2014 (UTC)

I'm not really sure how we could neatly solve those last 4... —CodeCat 00:40, 12 October 2014 (UTC)
sc=Latn overrides the request, but may cause display issues. — Ungoliant (falai) 01:01, 12 October 2014 (UTC)
tr=- works too. But you'd have to do it for every entry. —CodeCat 01:03, 12 October 2014 (UTC)
That's probably the answer for the last 4: there's just a small, poorly delineated subset of many character sets that has no transliterations. The same holds for ideographic characters in cuneiform and hieroglyphs, too. It's not a huge number, so entering things by hand should work. Chuck Entz (talk) 01:17, 12 October 2014 (UTC)
Those are fixed. The English Braille ones were actually caused by {{meta-punctuation mark}} using {{head}} with no provision for a tr parameter. I added "|tr=-" and all of those disappeared from the category within seconds of my null edit to {{en-punctuation mark}}. Chuck Entz (talk) 01:59, 12 October 2014 (UTC)

Search results[edit]

Would it be possible to "hide" the entry templates that appear in "Search results" so that you can see what appears underneath more easily? For example: https://en.wiktionary.org/w/index.php?search=oppvaska&title=Special%3ASearch&go=Go . Donnanz (talk) 11:59, 14 October 2014 (UTC)

I think the time may have passed when that screen was a default useful for the project. Can we find out how often it is used and how often the product is speedily deleted?
In any event I would guess that Javascript could hide it. DCDuring TALK 12:22, 14 October 2014 (UTC)
Quick note, a simple workround: put #searchmenu-new-preload { display: none; } in your Special:MyPage/common.css to hide it for you. Dakdada (talk) 12:37, 14 October 2014 (UTC)
Thanks, I needed that. DCDuring TALK 13:35, 14 October 2014 (UTC)

broken entry[edit]

Discussion moved from Wiktionary:Tea room/2014/October.

the entry ad appears blank (in all wiktionaries). or is it just me? --Ninud (talk) 12:06, 15 October 2014 (UTC)

You're right, this is strange. --WikiTiki89 12:24, 15 October 2014 (UTC)
I have no problem seeing it using either Firefox 16.0.2 or Safari 5.0.6 (Mac). What browser are you using? Chuck Entz (talk) 12:38, 15 October 2014 (UTC)
I'm using Google Chrome and I have Adblock Plus enabled, which I now realize may have something to do with the problem. --WikiTiki89 12:41, 15 October 2014 (UTC)
I have confirmed that Adblock Plus is in fact the problem, since after disabling it the page displays correctly. I wonder how we can get around this problem. --WikiTiki89 12:44, 15 October 2014 (UTC)
I was going to make a pun earlier about "adblockers", but bit my tongue. It would seem that truth is stranger than fiction! Seriously, though: Wiktionary has something to set off every text-based filter ever devised- should we even try to work around them? Chuck Entz (talk) 13:36, 15 October 2014 (UTC)
oh, adblock was blocking ad ^^ thx guys --Ninud (talk) 14:25, 15 October 2014 (UTC)
It is actually blocked in every language. We have the same issue on fr: on the same page fr:ad, see fr:Wiktionnaire:Wikidémie/août_2014#ad_est_tout_blanc. Someone said he created a bug report, but I don't know where. Dakdada (talk) 14:28, 15 October 2014 (UTC)
Go to ad, click on the ABP button on your browser or otherwise fire it up. There's an option to "report a problem on this page". DCDuring TALK 15:24, 15 October 2014 (UTC)
There is no such option for me (in Google Chrome). The only options are "Enabled on this site", "Block element", and "Ads blocked" ("0 on this page", which is strange since the whole page is blocked). --WikiTiki89 15:57, 15 October 2014 (UTC)
Ok my report links to https://easylist.adblockplus.org/blog/2011/04/03/mediawiki-headers-and-ids. The problematic filter seems to be ##.page-ad. Dakdada (talk) 16:35, 15 October 2014 (UTC)
They didn't make it easy to report the issue for me either. In any event I've disable it for Wiktionary. DCDuring TALK 17:14, 15 October 2014 (UTC)
My ABP button has the option "Disable on this page only", which worked for me on [[ad]]. Apparently Adblock Plus isn't aware of the use-mention distinction. —Aɴɢʀ (talk) 18:41, 15 October 2014 (UTC)

Pronunciation requests[edit]

I believe that we should change the entire "request for etymology/pronunciation" system. It shouldn't regularly be a "request". It should be like this:

Like the French Wiktionary has:


Beside words with incomplete pronunciation.

I think we should have something like that for every term that would need a pronunciation, and then have a category per language of all of the terms with pronunciations that are not added. A no-pronunciation-marker should be used when a term does not have an IPA, regardless of whether it has an audio clip, hyphenation, homophones, rhymes, or whatever else. Of course, for things like archaic terms we shouldn't have pronunciations for those, but it may be a good idea to mark these entries to let people know that their pronunciations are N/A. Just an idea, and it would help the site a lot.

Same thing for etymologies when they are missing.

Also, most etymologies, per the Wiktionary system, should have "From" at the beginning, and all etymologies need a period at the end of the sentence. I don't like seeing this: "

(section) Etymology (/section) mis +‎ -calculation "

Anyway. So we should have bots put all these markers into the entries if we ever consider this idea.

My overall idea is: Have missing pronunciation not be a request, but rather treated as a need for (almost) all entries.

What do you guys think? Good idea, or bad idea? Rædi Stædi Yæti {-skriv til mig-} 20:16, 17 October 2014 (UTC)

Arrowred.png Generally, a resounding yes about missing pieces -- I think this is a great idea. I consider JA entries to be deficient until they have an etymology, pronunciation, POS and definitions, and where applicable, {{ja-kanjitab}} and usage notes. References are big plus.
Pronunciations and etymologies should be something that we consider as a requirement for every entry, or at least every lemma entry. Beyond that, I would be in favor of coming up with some system of categorizing all elements required for each language's entries, and categorizing all entries that are missing any of these elements. ‑‑ Eiríkr Útlendi │ Tala við mig 05:00, 19 October 2014 (UTC)
One thing I forgot to mention is that if we would use a system like this, we'd need to remake the rfe and rfp templates. We'd have to shorten the boxes so that they wouldn't take up so much space on entries. It would be great if we just had etymology incomplete to look something like this:

The etymology for this term is incomplete. If you are familiar with the etymology, please click here.

without a box and just the text. Maybe a small image too, but mainly the text is what I am worrying about.

We should make a similar template for pronunciation.

The reason I say incomplete is because a lot of entries may have *incomplete* etymologies or pronunciations. For instance, a term may have rhymes but no IPA (which is common on Wiktionary actually). An example of an incomplete etymology, which I also see a lot, is someone just putting:


as the etymology.

Anyway, you get that idea. We would probably also want to find some automated way to add the incomplete pronunciation templates, because there will be a lot of editors who may forget to put the templates, especially newer editors.

Also, @Eirikr, I'm also very highly supporting the idea of adding pronunciations for non-lemma forms also. Someone may want to see the pronunciations of those also, especially if someone is not familiar with the language and only wants to know the pronunciation of that particular non-lemma form; even if it is for English itself. Rædi Stædi Yæti {-skriv til mig-} 07:02, 19 October 2014 (UTC)
  • I oppose this rubbish now as before. --Dan Polansky (talk) 07:59, 19 October 2014 (UTC)
  • Would you elaborate? It's not clear to me either why you think this is rubbish, or what "before" you are referring to. ‑‑ Eiríkr Útlendi │ Tala við mig 08:02, 19 October 2014 (UTC)
    • This was discussed before. I oppose having empty pronunciation sections across the dictionary; that is an obvious rubbish and there is nothing to discuss, IHMO. Rædi Stædi Yæti is a troll or a semi-troll anyway, judging from multiple aspects of their editing behavior. By the way, pink 3D-rendered arrow to start a response is a rubbish as well. --Dan Polansky (talk) 08:11, 19 October 2014 (UTC)
    • Re: "Pronunciations and etymologies should be something that we consider as a requirement for every entry, or at least every lemma entry": What a horrible piece of rubbish. The minimum content is definition, nothing else. Pronunciations are trivia, not serious lexicographical content. Requiring etymologies and pronunciations as a minimum would bring the expansion of useful content of Wiktionary to a halt. For instance, SemperBlotto would be unable to enter all the Latin content that he did. Try processing the dump to see how many lemma entries have both etymologies and pronunciations. --Dan Polansky (talk) 08:32, 19 October 2014 (UTC)
      • Re "Pronunciations are trivia, not serious lexicographical content". Why do you spend time editing a dictionary when you so clearly have no interest in lexicography? Pronunciations are most definitely NOT trivia; they are the most essential part of any lexical entry, because written language is subordinate to and derived from spoken language. In fact, written language is not actually language any more than a painting of a pipe is a pipe. Written language is nothing but a convenient way of representing language, which (with the exception of sign languages) is spoken. As long as the pronunciation is known (which of course it isn't for many extinct languages), it is an indispensable part of the lexical entry—for nonlemmas as well as lemmas. Nevertheless, having ===Pronunciation=== sections with nothing in them is pointless, and having a bot flood them all with {{rfp}}'s would render the {{rfp}} tag and the corresponding categories meaningless. Etymologies, on the other hand, are a different kettle of fish. They're interesting and should be included whenever they're known, but there should be no implication that they're a required component of an entry. Even in well studied languages like English, etymologies are often unknown, and for less well studied languages the research has often not been done. Editors should never be made to think, even indirectly, that they have to include etymological information, because that would encourage them to engage in their own etymological speculations. Our etymologies should always be backed up (or at least backable-up in principle) by scholarly research; when that is lacking or when the user doesn't have access to it, it's better to omit etymological information altogether. —Aɴɢʀ (talk) 12:47, 19 October 2014 (UTC)
        For phonologically transparent languages like Czech word pronunciation is mostly irrelevant (you learn it together with the alphabet). For phonologically opaque languages like Russian and English it's much more important. Also, spoken language is only a minor subset of written language (lots of words are basically never spoken). I also suspect that most (>50%) of the communication today is done through written language exclusively. Almost everyone today is reading several times more words than they're talking/hearing... --Ivan Štambuk (talk) 17:20, 19 October 2014 (UTC)
        There are also words that are spoken but almost never written. And I am sure that people still talk more than they write and listen more than they read. --WikiTiki89 13:19, 20 October 2014 (UTC)
        For every developed language spoken vocab is at least an order of magnitude lesser than written vocab. Spoken words that have never been written only exist for minor languages with few native speakers, where literacy is an issue. Average person reads text at least 2-3 times faster than they can speak, so even though they spend more time communicating verbally, at the end of the day much more is absorbed by reading. Furthermore, spoken language is of very limited lexicon, and in terms of distinct words communicated over some period, written language wins hands down. Most of English pronunciations for obscure words are hypothetical since probably none of the editors has heard them spoken, or is likely to do so. Advent of personal digital assistants capable of speech processing is unlikely to reverse the trend. --Ivan Štambuk (talk) 17:56, 20 October 2014 (UTC)
        Aren't the words, which we seldom hear spoken, still pronounced in our minds? Pronunciations are important, especially for words we don't hear. E.g. there are borrowings from Chinese pinyin and people often wonder how to say them (even if there are variants and no established standard). --Anatoli T. (обсудить/вклад) 22:47, 20 October 2014 (UTC)
@Angr: The notion that language being primarily spoken makes pronunciation "the most essential part of any lexical entry" (boldface mine) can hardly get more bizzare, IMHO. It suggests that an entry with a pronunciation but no definitions and example sententences is better than an entry with no pronunciation but extensive definitions, example sentences and translations into dozens of languages. That, to me, seems patently absurd. As for the manner of argument you have chosen: even in dictionaries that provide pronunciation, readers do not have indexing and searching by pronunciation; rather, indexing and searching is by the written forms of words. Even in the age of computers, most dictionary users do not know how to mark up pronunciation, so they cannot enter pronunciation markup into a search field and hope to find what they were looking for. I rest my case that it is the headword with definitions that is the sole essential part of any entry. As for those who believe that it is urgent that each English lemma has a pronunciation markup, they are free to bind their resources to add it, not the resources of other editors. --Dan Polansky (talk) 10:18, 25 October 2014 (UTC)
Disagree about "From" in every etymology. It's unnecessary and I faintly resent people adding it to mine. (I mean, an etymology by definition is where a word is from. We don't put "Sounds like" at the start of pronunciation lines, or "Means" at the start of sense lines.) Equinox 10:11, 22 October 2014 (UTC)
There is always an implied "is" (or "was"):
  • "bed" is /bɛd/
  • "bed" is a piece of furniture for sleeping on.
  • "bedroom" is bed + room
  • "bed" is from Old English bedd
In the last example, the implied "is" is not enough. --WikiTiki89 10:58, 22 October 2014 (UTC)

Dewikifying JS[edit]

I run into cases from time to time where the system has parsed wikitext in Javascript files, with resulting oddities showing up in Special:WantedCategories, Special:WantedTemplates, etc.

While this is only a minor annoyance, the solution is very simple: we should make it standard practice to put //<nowiki> as a line near the top of every .js page, and //</nowiki> as a line at the bottom. As comments, these won't affect Javascript execution, but will keep the system from interpreting the pages as wikitext.

This presupposes, of course, that there isn't a better way to do this- but we should do something just to be on the safe side. Chuck Entz (talk) 21:56, 18 October 2014 (UTC)

Well, we could ask the developers at bugzilla: to stop preprocessing and parsing JavaScript files to find links. However, there might be opposition to this, since this feature has at least one useful use case: it can be used to track users of custom scripts. If someone puts
importScript('User:Kephir/gadgets/xte.js'); // [[User:Kephir/gadgets/xte.js]]
in their Special:MyPage/common.js, it will put their common.js on the backlinks list of the script. Which may be useful sometimes.
But as for the original suggestion, I have no objections. I think you can add it to Wiktionary:Coding conventions. I will only note the // </nowiki> is not actually necessary. Omitting it does not cause any errors and I doubt anything will change in that regard. Keφr 11:52, 19 October 2014 (UTC)

Accessibility issue with quotations link[edit]

Discussing Wiktionary at the Oxford Wikimedia meetup, it has been pointed out that the "quotations" link to the right of an entry (e.g. at hoaxical#Adjective) is too small to be read by people with poorer than average eyesight. I'm told that the WCAG is that text should not be smaller than 85% of the normal font size. Assuming the standard text size is 11pt this means the font size should not be lower than 9.35pt but the quotations link is 8.25pt, and so should be increased. See also Wikipedia's accessibility guidelines.

By all means have a preference to make it smaller, but it needs to be large enough by default for users who are not logged in. Thryduulf (talk) 13:23, 19 October 2014 (UTC)

See w:MOS:ACCESS#Text "in no case should the resulting font size drop below 85% of the page fontsize". --Redrose64 (talk; at English Wikipedia) 08:50, 20 October 2014 (UTC)


Is it just me or is the Watchlist now displaying every edit to a watched page as opposed to the most recent edit? I think I might like this new feature, but I'm also curious whether there is an option to disable it temporarily or anything like that. --WikiTiki89 20:44, 21 October 2014 (UTC)

Never mind, it only did that once and when I refreshed, it went back to normal. This is strange... --WikiTiki89 20:45, 21 October 2014 (UTC)
"Expand watchlist to show all changes, not just the most recent" in Special:Preferences#mw-prefsection-watchlist controls this, I believe. Keφr 20:47, 21 October 2014 (UTC)
Yep, thanks! I didn't realize that was an option. So if I have it enabled in prefs, is there a way to temporarily disable it without changing my prefs (similar to the "hide minor edits", etc. options)? --WikiTiki89 21:33, 21 October 2014 (UTC)
It suddenly happened to me too. I think that option went from being off as default to being on as default. —Aɴɢʀ (talk) 22:07, 21 October 2014 (UTC)
See w:WP:VPT#Meta-Wiki watchlist... a bug?. --Redrose64 (talk; at English Wikipedia) 22:23, 21 October 2014 (UTC)

amortajadas and probably hundreds of others[edit]

The page amortajadas currently looks very ugly. I'm guessing there was a change in a template, but I can't track it down. Any ideas? --Type56op9 (talk) 09:52, 25 October 2014 (UTC)

Fixed. It seems {{es-verb form of}} should be migrated to Module:form of or something. User:CodeCat? Keφr 10:46, 25 October 2014 (UTC)


(NOTE: I'm not sure if this should go in the Beer Parlour or here, so feel free to move it if it is improperly placed.)

I'm not suggesting that we move Wikisaurus or anything like that, but I do have a question:

What was the reasoning for having Wikisaurus be but a limb of Wiktionary, when (in many real life cases) thesauri are often seperate publications from dictionaries? Tharthan (talk) 13:12, 25 October 2014 (UTC)

In print, dictionaries and thesauruses have vastly different organizational needs. If dictionaries had room for it, they would all have a thesaurus in the appendix. We, however, are not limited by space. One of our problems is that we have to approaches to being a thesaurus: we have the WT:Wikisaurus and we have the mainspace ====Synonyms==== and ====Antonyms==== sections. Ideally (in my opinion), we'd be able to get rid of Wikisaurus by including everything in mainspace. This doesn't really belong at either the GP or the BP, but I'm not going to bother moving it to the WT:ID. --WikiTiki89 13:25, 25 October 2014 (UTC)