Wiktionary:Grease pit

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


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; [1] 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)
I believe you would need to put them in brackets. Compare the preceding sort-key line. (So it would say from = {"[ᾰᾱ]", "[ῐῑ]", "[ῠῡ]"},) ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 02:10, 27 October 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)
  • Ahem, has this gone onto the back burner? Donnanz (talk) 11:19, 31 October 2014 (UTC)
    It was unclear from your original request whether you wanted this to be the new default or whether you just wanted it for yourself. If you want it for a new default, it should go to the Beer Parlor as it is not a merely technical matter. DCDuring TALK 11:54, 31 October 2014 (UTC)
    I would like it to be possible for everyone to hide the entry templates on a temporary basis, via "hide" and "show" boxes. So if you want to refer this to the Beer Parlour, that's OK by me. Donnanz (talk) 12:08, 31 October 2014 (UTC)
    That's different. DCDuring TALK 12:19, 31 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)

Arrowred.png "Rubbish" aside, at least some of us editors appear to be keen on having better visibility for entries that are missing various kinds of data. I understand that there is resistance to the idea of adding {{rfp}}, {{rfe}}, etc. all over the place. I can empathize with that concern, in part because visual clutter is bad for usability. As an alternative idea for improving this kind of visibility for editors without changing the entries themselves (at least visually), is there any easy way of generating lists of terms in XX language that are missing headers YY, ZZ, and WW? In addition, is it possible to get a list of terms in XX language that are missing AA, BB, and CC templates? Finding what terms have any given template is extremely easy, but finding terms that don't have that template is a bit of a challenge. Right now, all I can think of to do this would be to analyze a database dump -- which isn't very user-friendly (where "users" in this context refers to us editors). ‑‑ Eiríkr Útlendi │ Tala við mig 17:26, 30 October 2014 (UTC)

Something I have been considering is to make a complete parser for Wiktionary specifically. There's already mwparserfromhell, but that only does general "flat" token-based parsing and it doesn't know anything about our entry structure. Nonetheless it serves as a useful base to make larger building blocks. It would also be useful for error checking, as any malformed entry (header or template in the wrong place, etc.) could be caught by it. —CodeCat 17:34, 30 October 2014 (UTC)
I haven't read all of the comments above, but the French system is basically to always include an {{IPA}} template (called fr:Template:pron) in every language section. Of course the vast majority don't include a pronunciation! However they (or should I say 'we'; I've been editing there longer than I've edited here) don't (usually) put it in a pronunciation section, so we'd be including extra empty sections where they don't. We could do it purely to get every entry into Category:English entries needing pronunciation (or whatever language) but I think having millions of extra empty ===Pronunciation=== sections outweighs the benefit. But I don't feel strongly enough about it to actually oppose it. Renard Migrant (talk) 17:43, 30 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)
One thing that an extended thesaurus-type presentation could accomplish that would just clutter up a dictionary entry would be to show in close proximity several words which are considered synonyms together with any slightly different meanings or different usage contexts (broadly defined (to include syntactical relationships, time periods, regions, registers) or associations ("connotations" or allusions). Note that this is not what print thesauruses usually do: they offer bare lists that are apparently intended to present possible substitute words or associated words, whose precise differences in meaning and other attribute need to be found or confirmed in a dictionary. IMO Wikisaurus takes an approach that is too similar to those of our Synonyms sections and of print thesauruses. DCDuring TALK 16:47, 26 October 2014 (UTC)

Does This Template Already Exist?[edit]

I would like to ask whether a particular very simple table (table only, no content) already exists. It would look like this Norwegian Inflection table, except simpler: https://en.wiktionary.org/wiki/time#Inflection_2

  • In the top row, it would say "Possession of" instead of "Inflection of"
  • In the second row, the column headers would be only "singular" and "plural" (instead of indefinite singular/def.singular/indef. plural/def.plural)
  • In the third row, the row header would be "1st person"
  • In the fourth row, the row header would be "2nd person"
  • In the fifth row, the row header would be "3rd person"

That's all. Just six table cells that I can fill in for each possessed noun. I would like to use it instead of the bullet list under Inflection on this page: https://en.wiktionary.org/wiki/amunaun Does anyone know if such a table already exists? Thanks. Emi-Ireland (talk) 04:06, 26 October 2014 (UTC)

@Emi-Ireland: I have created {{wau-possession}}. Let us know if anything needs to be changed. — Ungoliant (falai) 14:34, 26 October 2014 (UTC)

You people are really amazing. Thank you SO MUCH! Emi-Ireland (talk) 14:39, 26 October 2014 (UTC) It works perfectly. Really nice and clean. Should I also copy the template to Wauja language templates? Or is it stored in some centralized location? Thanks Emi-Ireland (talk) 20:08, 27 October 2014 (UTC)

Do you mean to Wauja templates for other types of inflection, or to other words that inflect for possession? — Ungoliant (falai) 20:20, 27 October 2014 (UTC)

Yes, I was thinking this would work well for a simple verb conjugation table, which can hold basic conjugation information. This table would also be suitable for personal pronouns. I've coded lots of complex tables in HTML and CSS, so I might be able to get the hang of this. However, when I looked at the template in Edit mode, I saw very clear instructions on using the template (thanks for that), but not the code that generates the table itself. Where is the code that generates the template located? Meanwhile, I will keep reading the Help section on templates. Thanks very much. 13:36, 28 October 2014 (UTC)

What you are actually seeing is the documentation of the template. If you click edit you can see the code ([2]).
If the conjugation of Wauja is very complex, it may be a better idea to make templates that generates the conjugation table based on the inflection paradigm so that you don’t have to type up all the forms manually. For example, in Portuguese we can use {{pt-conj|ach|ar}}, {{pt-conj|com|er}} and {{pt-conj|emit|ir}} for the conjugations of achar, comer and emitir. — Ungoliant (falai) 15:07, 28 October 2014 (UTC)

search error[edit]

Right now if I search on Wiktionary for an entry which does not exist (a red-link entry) I get the following error report: An error has occurred while searching: Search is currently too busy. Please try again later. But this does not come up if I search for something which already has an entry. I tried to refreshing my browser cache to no avail. What's going on? ---> Tooironic (talk) 12:46, 27 October 2014 (UTC)

I get it too. It's OK if you click on a red inflection within an existing entry. I can create an entry that way. Donnanz (talk) 12:54, 27 October 2014 (UTC)
It seems to me that it, if you believe the message, it is highly likely to also occur on some successful searches. A failed search has, on average, more work to do than a successful one. This would be especially true if some portion of our entries were not keyed efficiently and therefore required slower search. Every unsuccessful search would have to search that unkeyed list, but very few successful ones would have to. DCDuring TALK 15:02, 27 October 2014 (UTC)
I thought the problem had been cured, but it's still occurring occasionally, with the same error message. A bug must have developed somewhere. Donnanz (talk) 17:26, 27 October 2014 (UTC)
My searches never turn up anything anymore. If I type in a page name that exists, it goes straight to it. If the page name does not exist, I get no results. It's maddening. Renard Migrant (talk) 18:44, 27 October 2014 (UTC)
Maddening indeed. I got the same error message (written in Norwegian) on Norwegian Wiktionary, looking for radiostyrt. Mind you, I didn't expect the word to be in there. Donnanz (talk) 19:09, 27 October 2014 (UTC)
Could nowikt and enwikt be on the same server group? I didn't get such results on WP. I get all of the results: direct to entry, list of entries with the term(s), and HTTP timeout error, using just basic ASCII characters and near-words. I do seem to get the timeout error very quickly, just a few seconds, so perhaps some timeout limit has been changed, perhaps only on one groups of servers. DCDuring TALK 19:15, 27 October 2014 (UTC)
  • The problem went away for a few days, but now it's back again. Donnanz (talk) 11:17, 31 October 2014 (UTC)


I just change the plural of archal to archaux, because {{fr-noun}} is giving it the automatic plural archaaux! Hopefully this is just a type in Module:fr-headword. Can some correct it? Whatever and wherever it is. Renard Migrant (talk) 18:16, 27 October 2014 (UTC)

I fixed it. It wasn't a typo as much as a thinko, or maybe an off-by-one error. —CodeCat 18:19, 27 October 2014 (UTC)

Extra space at the top[edit]

Can someone get rid of the extra space at the top of qroqqa? This, that and the other (talk) 09:58, 30 October 2014 (UTC)

Yes check.svg Done by moving the word-of-the-day thing underneath the picture. Equinox 14:02, 30 October 2014 (UTC)
That's a workaround, not a fix. I would like to see a fix, because I tried very hard unsuccessfully to figure out what was causing it. --WikiTiki89 16:13, 30 October 2014 (UTC)
  • Not sure if this counts as a fix or a workaround, but I just added a floating div to contain the FWOTD and image. This fixes the layout (removes the whitespace) without changing the order of elements as seen on the page. The underlying problem has to do with how different kinds of HTML block elements interact with each other. ‑‑ Eiríkr Útlendi │ Tala við mig 17:07, 30 October 2014 (UTC)
Huh? I see no weird space in the old version (using latest Firefox, even with Tabbed Languages disabled). Keφr 17:33, 30 October 2014 (UTC)
  • Interesting. Firefox appears to be the "nicer" layout for this. For that old version, Chrome shows a single line of blank space vertically between the language header and the Etymology header. Meanwhile, IE shows a huuuuge amount of blank space, as if the FWOTD and image were left-aligned instead of on the right where they actually appear. I might be able to test in Safari later today, if anyone's interested. ‑‑ Eiríkr Útlendi │ Tala við mig 17:59, 30 October 2014 (UTC)
I've reduced this to a simple test case: see [3].
Firefox 33
Chrome 38
IE 10
There are still a lot of factors in this test case - perhaps somebody can narrow it down further? Keith the Koala (talk) 11:02, 31 October 2014 (UTC)

November 2014[edit]