text:
Wiktionary:Grease pit/2014/October

User:Ruakh/Tbot.js
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. . 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 += '==lookup==\n\n'; To: wikitext += '==getByCode==\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 js, while JavaScript uses comments like this js or like this js. 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
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 ).

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 ; 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
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
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  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  becomes what is displayed. —CodeCat 21:16, 5 October 2014 (UTC)

another bug in Module:headword; please give me write permission to fix it
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
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 s, which is tedious. — Keφr 14:52, 5 October 2014 (UTC)
 * Not if you use or . —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
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)

SuggestBot?
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?
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
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)
 * 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?
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?

Thanks.

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

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

Module:la-headword
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 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 . 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, and I still have , , and to do. — I.S.M.E.T.A. 16:29, 12 October 2014 (UTC)

Some "transliteration needed" false positives
Chuck Entz (talk) 00:36, 12 October 2014 (UTC)
 * 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
 * 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)
 * 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 using  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 . Chuck Entz (talk) 01:59, 12 October 2014 (UTC)

Search results
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  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
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. 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 . 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
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:

"Pronunciation?"

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)

"

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)

 * [[Image:Arrowred.png|15px]] 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,  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:

French

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 's would render the 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)
 * 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)

"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, , 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 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
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  as a line near the top of every .js page, and   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 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   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 Coding conventions. I will only note the js 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
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) 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 "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)

Watchlist
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)
 * "" in Special:Preferences 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. --Redrose64 (talk; at English Wikipedia) 22:23, 21 October 2014 (UTC)

amortajadas and probably hundreds of others
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 should be migrated to Module:form of or something. User:CodeCat? — Keφr 10:46, 25 October 2014 (UTC)

Wikisaurus
(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?
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)
 * I have created . 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.71.178.188.4 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.
 * 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, and  for the conjugations of ,  and . — Ungoliant (falai) 15:07, 28 October 2014 (UTC)

search error
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)

archal
I just change the plural of to, because  is giving it the automatic plural ! 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
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)

 * ✅ 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.
 * Firefox 33.png
 * Chrome 38.png
 * IE 10.png
 * 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)

title: Wiktionary:Grease pit/2014/October


text:
Wiktionary:Grease pit/2014/November

American Sign Language Letter Images Showing at Full Size
As an IP noted at Talk:C, the "100px" parameter in Image wikilinks wrapped in seems to be ignored, so the image of the finger-spelled "C" fills the page. Chuck Entz (talk) 17:13, 1 November 2014 (UTC)
 * Fixed; the section-linking code was parsing the link wrongly and corrupting the size specifier. I fixed the parsing code; though we should probably suppress section linking altogether for File-namespace links (and probably some others). — Keφr 20:08, 1 November 2014 (UTC)

Cyrillic Uyghur
Can someone please suppress Cyrillic in Module:ug-translit? Or write another function for it? See Khorgas. قورعاس and Қорғас. --Anatoli T. (обсудить/вклад) 00:08, 10 November 2014 (UTC)
 * I changed the transliteration module so that it returns nothing if the script is not Arabic. It needs an extra function for Cyrillic still, but someone else will need to do that. —CodeCat 00:29, 10 November 2014 (UTC)
 * Thanks. If someone adds a framework for it (the logic), I can fill the table with transliteration symbols. Uyghur_Cyrillic_alphabet. --Anatoli T. (обсудить/вклад) 00:38, 10 November 2014 (UTC)
 * Is the transliteration just by each letter individually? As in, there are no pairs of letters (or similar) that must be transliterated separately? —CodeCat 00:48, 10 November 2014 (UTC)
 * I've set it up now. —CodeCat 00:52, 10 November 2014 (UTC)
 * Thanks. They are very straightforward, one-to-one and there are most likely no rules to change transliterations depending on the position of letters, like Russian "е" (e, je, etc.). I'll have a go at it later, if no-one does, just need to map Uyghur Arabic transliterations (which is fully fully phonetic and doesn't use any diacritics unlike Arabic) to Cyrillic, so we have some consistency, e.g. "چ" = "ch" = "ч". --Anatoli T. (обсудить/вклад) 00:58, 10 November 2014 (UTC)
 * . I've added the Cyrillic letters, not sure why there is no Arabic equivalent of Ә. I've asked User:Hahahaha哈, a Uyghur speaker (not sure if they know the mapping between Cyrillic and Arabic). --Anatoli T. (обсудить/вклад) 21:46, 10 November 2014 (UTC)
 * Calling as well, please check if you can. --Anatoli T. (обсудить/вклад) 21:49, 10 November 2014 (UTC)
 * Ә = ه —Stephen (Talk) 03:39, 11 November 2014 (UTC)
 * Thanks, Stephen, I have added ه. --Anatoli T. (обсудить/вклад) 04:57, 11 November 2014 (UTC)
 * Fixed a mismatch. Cyrillic "е" is apparently Roman "ë" (="ې"), e.g. and  "script", "alphabet" (from Russian "язык"?) and Cyrillic "ə" is Roman "e" (="ه"), can't find an example word with "ه". --Anatoli T. (обсудить/вклад) 05:10, 11 November 2014 (UTC)
 * Found a Cyrillic letter, which was missing in Wikipedia. Added "э" as "é". I'm not sure what it should be. --Anatoli T. (обсудить/вклад) 05:22, 11 November 2014 (UTC)
 * Sorry for the late reply. I can't read Cyrillic script. I checked the Arabic part, and found this ["ع"] = "ğ", They don't have this letter in Uyghur Arabic form, the letter "ğ" is the letter "gh" in ULY. The letter "é" is no longer in use, it is "ë" now. --Hahahaha哈 (talk) 04:57, 7 December 2014 (UTC)

Searching for green ACCEL links
Is there any way to search for, or generate a list of, entries with green ACCEL links in them? --Type56op9 (talk) 15:03, 11 November 2014 (UTC)
 * Scan Wiktionary for redlinks wrapped in spans with appropriate CSS classes ( or whatever). Using [//dumps.wikimedia.org/enwiktionary/ a dump] may make it easier. — Keφr 17:57, 11 November 2014 (UTC)
 * I have no idea how to use dumps. Perhaps a help page Help:Taking a Wiktionary dump and being creative with it is needed. --Type56op9 (talk) 09:17, 12 November 2014 (UTC)
 * "pagelinks" is a (compressed) text file containing a series of SQL statements which can be imported verbatim into a MySQL database (and maybe others, after some modifications). Then you can use the "all-titles" dump to remove all bluelinks (and links to non-content namespaces) from your database. Then you do sql, giving you a list of pageids of pages containing redlinks. If you expand templates in each (with e.g. mw:API:Revisions) and look for, it means you got something which WT:ACCEL can turn into a greenlink. Probably.
 * Hmm. Quite a lot of work, it seems. If I were to do it, I would probably (ab)use my Admin Powers™ by editing Module:headword to add a tracking template for each accelerated link, and then just pull the list from mw:API:Embeddedin… — Keφr 20:35, 12 November 2014 (UTC)
 * But then you'd have to wait a long time for the changes to show up. A dump is a much better solution. --WikiTiki89 22:06, 12 November 2014 (UTC)
 * With 3M jobs in the queue right now, you might have a point. — Keφr 15:31, 13 November 2014 (UTC)

Ref no references warning banner
It has a mistakes in it, it says to used " is an opening tag, " " is a closing tag. Every opening tag must have a corresponding closing tag. However, when no text needs to be placed between the opening and closing tags, it is redundant to write the tag twice. Thus, " " is a shorthand for " ". --WikiTiki89 05:22, 14 November 2014 (UTC)

Removing diacritics for all regional versions of Arabic, not just Standard Arabic
A number of regional Arabic dialects (aka languages) have entries for words in those languages. E.g. there are quite a number of words in Category:Egyptian Arabic nouns and Category:Libyan Arabic nouns, and they're written in Arabic script. Personally I think the lemmas should be written in transcription since the Arabic script can never be phonologically very accurate for the dialects, and indeed most pedagogical literature uses transcription more or less exclusively. But since we have stuff written in Arabic, we should at least provide diacritic-removal services like we do for Standard Arabic. As it is, you can't e.g. put diacritics in an Egyptian Arabic link without manually specifying the non-diacritic version as another param. I'm proposing that the automatic diacritic removal we do for Standard Arabic should be done for all the Arabic varieties. The full list is here:

This would simply involve copying the  entry in the language table for code   to all the codes given in the list above, possibly with a check that "Arab" is actually one of the allowed scripts. Could someone do this? Thanks.

Benwing (talk) 07:29, 15 November 2014 (UTC)

 * The change is straightforward but a few data modules needs to change. I have just updated Module:languages/data3/a, which happens to have a bunch of Arabic dialects, including Egyptian, Moroccan, for which we have a lot of entries - and . I only changed those with sc=Arab but this may need to change. I also changed User:Conrad.Irwin/editor.js for translations - . Pls check if there are other data modules, like Module:languages/data3/a with Arabic dialects. --Anatoli T. (обсудить/вклад) 11:29, 15 November 2014 (UTC)

 * There is also Shihhi Arabic (ssh) and Chadian Arabic (shu) in Module:languages/data3/s, and Hassaniyya (mey) in Module:languages/data3/m, all with sc=Arab. Juba Arabic in Module:languages/data3/p (a pidgin or creole) has sc=Arab but I think this is a mistake and should be changed to Latin -- Ethnologue says script is Latin, and the one entry we have in the dictionary is in Latin script.

 * According to Ethnologue:
 * Tajiki Arabic (abh), Baharna Arabic (abv), Saidi Arabic (aec), Eastern Egyptian Bedawi Arabic (avl) are listed in Ethnologue as using Arabic script but we have them as sc=None, which should be changed to sc=Arab and the diacritic-removal stuff put in.
 * Ta'izzi-Adeni Arabic (acq), Hijazi Arabic (acw), Najdi Arabic (ars), Sanaani Arabic (ayn) have no writing system listed in Ethnologue and we have sc=None but all are vigorously-spoken languages that serve as regional or national standards, so I suspect they do use Arabic script and I think we should change them to sc=Arab and put in the diacritic-removal stuff.
 * Hadrami Arabic (ayh) has no writing system listed in Ethnologue and we have sc=None. It is vigorously-spoken by a smaller community (300,000 people) than the other two dialects in Yemen. Based on the example of things like Tajiki Arabic and Eastern Egyptian Bedawi Arabic I'd tentatively set it to sc=Arab and put in the diacritic-removal stuff.
 * Uzbeki Arabic (auz) has no writing system listed in Ethnologue and is given as moribund, so I think it should remain as sc=None.
 * For Cypriot Arabic (acy) we have sc=None and Ethnologue has "Arabic script [Arab], no longer in use. Greek script [Grek], no longer in use. Latin script [Latn], revitalization efforts in one town". I would set sc=Latn here.

 * Benwing (talk) 15:33, 15 November 2014 (UTC)

 * You can follow the changes I made to other dialects and update the appropriate scripts and handling of diacritics for them. The translation adding tool should also follow. If you don't have access to the modules, pls make a list of required changes. Provided there are no objections, I'll make the changes. --Anatoli T. (обсудить/вклад) 22:22, 18 November 2014 (UTC)

I can't change the modules myself.
 * Please include diacritic-removal stuff for Shihhi Arabic (ssh) and Chadian Arabic (shu) in Module:languages/data3/s, and Hassaniyya (mey) in Module:languages/data3/m.
 * Please change Juba Arabic in Module:languages/data3/p to have sc=Latn.
 * For Tajiki Arabic (abh), Baharna Arabic (abv), Saidi Arabic (aec), Eastern Egyptian Bedawi Arabic (avl), Ta'izzi-Adeni Arabic (acq), Hijazi Arabic (acw), Najdi Arabic (ars), Sanaani Arabic (ayn), Hadrami Arabic (ayh) please change to have sc=Arab and add the diacritic-removal stuff in. (This is all the remaining Arabic dialects in Module:languages/data3/a other than Uzbeki Arabic and Cypriot Arabic.)
 * For Cypriot Arabic (acy) please change to have sc=Latn.

Thanks.

Benwing (talk) 23:54, 18 November 2014 (UTC)

 * OK, if no-one else does, I'll do it in the near future (there's no urgency as there are not much content in these languages/dialects). --Anatoli T. (обсудить/вклад) 01:43, 19 November 2014 (UTC)

Orangelinks gadget not working for me
At spur  and   showed blue, not orange, though there is no Old English section at [[spora]]. Here they look tan in color, which must be the current 'visited-link' color. DCDuring TALK 15:54, 19 November 2014 (UTC)
 * I see orange links above. —CodeCat 15:56, 19 November 2014 (UTC)
 * So you must not have visited spora. What about [[spora]] at spur? DCDuring TALK 16:10, 19 November 2014 (UTC)
 * I don't see an orange link there, no. —CodeCat 16:12, 19 November 2014 (UTC)
 * I think this is caused by a JavaScript error at [[spur]]. I don't know enough to investigate it. --WikiTiki89 16:15, 19 November 2014 (UTC)
 * OK. The page seems to have mostly garden-variety templates and other formatting, so it might recur elsewhere. DCDuring TALK 16:27, 19 November 2014 (UTC)
 * Ugh. I broke it. I have restored it to a working version. Ironically, I was trying to debug a defect which seemingly only I keep hitting… (I have some idea why, but I am yet to discover the specifics.) — Keφr 18:23, 19 November 2014 (UTC)
 * Thanks, it works for me now. Hope you can solve your problem. DCDuring TALK 19:11, 19 November 2014 (UTC)

Duplicate TLFi
has 'helpfully' added to all French lemmas. The problem: this include French lemmas that already had it! For example this edit to pionnier. Could anyone rectify this?

The second problem, where the TLFi link links to a nonexistent page is harder to fix and that's definitely beyond me. The first one I could fix just not yet. Renard Migrant (talk) 15:09, 20 November 2014 (UTC)
 * Can I just check that no-one's done this? I was going to do it tomorrow. Renard Migrant (talk) 18:07, 24 November 2014 (UTC)

Text editors
I've used Textpad as an editor for some 20 years, it does almost everything I need: sorting, multiple files (openable in one operation as a "workspace"), macros, find/replace (which handles /n, /t etc), and syntax highlighting, (there may be others). BUT it won't handle more than one "character set" - ie if I'm using Greek characters (η, ή etc) it handles Roman letters in the same file - but not if they're accented (é, etc).

I've been looking for another editor, can anyone recommend one (simple off the shelf (free!), not requiring "plugins" ? I've been trying Notepad++, but syntax highlighting for wiki files is difficult to sort out (Textpad makes it easy) Np++ uses XML files - with syntax and terminology I don't understand (I do html but don't wish to to master XML). Thanks — Saltmarsh απάντηση 16:00, 20 November 2014 (UTC)
 * The problem is not so much the text editor, but the font and encoding. You need to make sure the encoding is some form of Unicode. Also, most simple text editors only use one font at a time and unless it supports everything you need, you will have display issues. --WikiTiki89 17:02, 20 November 2014 (UTC)
 * Where I work, we're on Windows, and we routinely apply the Arial Unicode MS font to text to ensure that 1) all characters are displayed properly, and 2) that we don't have unnecessary internal markup where fonts change because the language changed. FWIW.  ‑‑ Eiríkr Útlendi │ Tala við mig 18:32, 20 November 2014 (UTC)

 * Thanks, but I'm afraid its not that simple, displaying in Athena Unicode doesn't make the problem go away. I think it's to do with the number of bits used to store each character. Textpad lets you choose which font you want displayed, but you have to opt for a script (Western|Greek|Baltic|central European|...) Western-script will give abcdef and áä éë (but not Greek alphabet) Greek-script will give abcdef and αβγδεέ (but not accented western chars) — Saltmarsh απάντηση 19:40, 20 November 2014 (UTC)

 * I'm not familiar with Textpad, but what you describe as "script" sounds an awful lot like the character encoding. Specific character encodings like Western, Greek, Baltic, or Central European only display those specific characters.  Try using Unicode instead.  Unicode has been developed precisely to overcome the problem you describe -- it's a single character encoding that defines characters for (ideally) all languages.  ‑‑ Eiríkr Útlendi │ Tala við mig 20:21, 20 November 2014 (UTC)
 * Technically Unicode is a character set, not an encoding. The encoding is UTF-8 (or UTF-16, UTF-32, UCS-2 but those are less popular as file formats). —CodeCat 20:59, 20 November 2014 (UTC)
 * UTF-16 is still more common on Windows. No one ever uses UTF-32 except as an intermediate encoding. --WikiTiki89 15:32, 21 November 2014 (UTC)
 * @CodeCat, thank you, yes, my sentence got things confused.
 * @Wikitiki89, I thought UTF-8 was more common? Then again, I work mostly with the combination of English and Japanese, so that might have something to do with it.  Also, at work, we have some older tools that can only properly handle UTF-16LE (little-endian).  ‑‑ Eiríkr Útlendi │ Tala við mig 19:17, 21 November 2014 (UTC)
 * UTF-8 is more common in general, especially on the web, but specifically not on Windows, which uses UTF-16 as the native and default encoding for many things such as the command prompt. I don't think the combination of English and Japanese has anything to do with it, since that would work perfectly fine in encoding.

 * I sometimes use SC UniPad . Not as great as TextPad or Np++ but it supports a lot of scripts and you can enter them with a big variety of keyboards and character maps or make your own. It's very useful if you want to break up complex characters, separate diacritics. It can decompose Korean hangeul into individual jamo. Great for deciphering scripts you don't know too - it gives you the names of characters and you can see diacritics separately and edit them. It has its limitations - doesn't support ligatures and doesn't have the advanced features of text editors. --Anatoli T. (обсудить/вклад) 21:19, 20 November 2014 (UTC)

 * Thanks folks - I'll continue using Textpad — Saltmarsh απάντηση 06:19, 22 November 2014 (UTC)

2 exceptions for клеветать and жаждать in Module:ru-verb
Module:ru-verb needs some changes, please. I feel less confident now with Lua after not coding for a long time.

клеветать is type "6c" needs a "щ" parameter, like "4a" function, жаждать is "6a" type, it needs to suppress iotation, some functions use "no_iotation" parameter, e.g. "present_je_a" function.

Alternatively, I'll make full conjugation paradigms as for completely irregular verbs but I prefer not to do that. --Anatoli T. (обсудить/вклад) 23:36, 20 November 2014 (UTC)
 * Good try, thanks for helping :). I guess, I'll have to try it myself when I have more time. :/ --Anatoli T. (обсудить/вклад) 12:47, 22 November 2014 (UTC)

Better Handling of Language-Code Errors
Currently, if someone uses a language code we don't recognize, such as sp for Spanish, they get an error message that says: " Lua error in Module: at line : The language code "eng" is not valid ", with a hyperlink to the module where the error was executed.

This doesn't do much for the casual contributor who doesn't know the correct language code or where to find it- telling you that the language code is invalid is better than nothing, but it doesn't tell you how to fix it.

I would suggest that we should at least refer them to WT:LOL, with extra credit for a clickable link to it. Can we do this? Chuck Entz (talk) 00:23, 22 November 2014 (UTC)
 * I don't think you can put links in module errors. They interfere with the link that shows the error details. —CodeCat 00:43, 22 November 2014 (UTC)
 * "Interference" seems to be exactly what Chuck wants, if I understand him correctly. I'm not sure what the nature of the 'interference' you invoke actually is: does it cause the servers to crash? blank users screens? break the internet? defund the Bank of International Settlements? Can't errors be trapped? DCDuring TALK 01:00, 22 November 2014 (UTC)
 * Try it and see. And errors can be trapped but I don't see much point in doing that in this case. —CodeCat 01:27, 22 November 2014 (UTC)
 * The reason I said "extra credit" was because I suspected that was the case. I still think we should at least figure out a good way to tell contributors where they can get correct language codes. Chuck Entz (talk) 22:03, 22 November 2014 (UTC)
 * It's possible to catch errors, and show a more informative message for certain errors. But we can't pick and choose which errors to catch and which to let through; either we catch them all, or none. Catching all errors would not necessarily be desirable, because there are many cases where the actual module error message is more helpful than anything we could come up with. —CodeCat 00:16, 25 November 2014 (UTC)

 * We could mention WT:LOL in the error message, but I suspect that sending lots of casual users to that very resource-intense page would be bad for the site's servers. - -sche (discuss) 01:03, 25 November 2014 (UTC)

A Little Module Oddity
and showed up for the first time in Category:Pages with module errors in the past day or so: It looks like the huge number of transclusions in the documentation page are pushing the Lua execution time past its limit.

What I don't understand is why this only happens when the documentation is transcluded into the template page, but not when you view the documentation page itself. Previewing both the template and documentation pages in edit mode shows the documentation using 2.353 seconds, but the template using 29.579 seconds (commenting out  drops Lua usage to zero, so there's nothing in the template itself that could account for it). Even stranger, all the items in the Lua Profile for the template don't add up to 10 seconds- let alone 29.579. That leaves two-thirds of the Lua time usage unaccounted for. The memory usage is 2.87 MB and 3.66 MB, with highest expansion depths of 22 and 24, so it doesn't look like those would explain it. Null edits on both haven't changed anything.

What's going on here? Chuck Entz (talk) 05:24, 22 November 2014 (UTC)
 * This happened ever since Kephir converted to use Lua. —CodeCat 14:03, 22 November 2014 (UTC)
 * Is it because the non-Lua part of the template expansion is now part of the Lua execution time? Would it be possible for the module to just export wikitext and let the expansion happen afterwards? Or have separate invocations for the part before the documentation-page transclusion and the part after, so the documentation-page expansion doesn't have to be done by Lua?
 * I realize this is mostly due to the complexity of Daniel Carrero's template code, and to the abnormally-large number of template calls in the documentation pages, but it does show that there's added overhead here. Chuck Entz (talk) 21:56, 22 November 2014 (UTC)
 * I wonder why Lua even has its own execution time limit. They should really get rid of that and just use a page-wide limit. —CodeCat 22:04, 22 November 2014 (UTC)
 * I guess converting the pt-verb/pt-conj templates to Lua would help with the overhead and make it more maintainable in general ? It looks like it would be a bigger job, but hard for me to estimate, I'm new here. Jberkel (talk) 15:21, 30 November 2014 (UTC)
 * Absolutely. And the key to peace in the Middle East is getting Muslims and Jews to get along with each other... ;)
 * The problem is that Daniel Carrero's code is notoriously impenetrable- I've described it before as a cross between spaghetti and an Escher engraving. Names like "do work" for major components of the code are a sure sign of poorly-thought-out structure and disregard for maintainability. It would be easier to have someone who knows Portuguese verbs well to just look at the output and create something new from scratch. Chuck Entz (talk) 16:05, 30 November 2014 (UTC)
 * Ungoliant? — Keφr 18:34, 30 November 2014 (UTC)
 * I was working on a Lua module for Portuguese conjugation, but gave up when CodeCat and you started complaining about the amount of data modules (even though the amount of data module would be fewer than the current amount of data templates necessary...) — Ungoliant (falai) 21:01, 30 November 2014 (UTC)
 * That? I posted it on 21st of September, while your last edit to a subpage of Module:pt-verb (still nonexistent as of yet) was on 14th of September. I would guess you had stopped working on it for a while before.
 * Though I remember my thought back then was that given that these data modules are quite small, and we could not see any actual logic behind them (i.e. no code which would actually get input from a user and assemble conjugation tables), I figured that these should probably be consolidated into a single data module. — Keφr 23:32, 30 November 2014 (UTC)
 * My approach would be the following: parse the existing templates with conjugation data into a data structure (with the help of an external script) then serialise the conjugation data back to a Lua table (could just be one file, but will be large, see Module:User:Jberkel/pt-verb-table), then write the module logic which reads the data and generates the HTML tables. Jberkel (talk) 01:18, 1 December 2014 (UTC)
 * I had a look at the templates, you're right, it probably needs a complete rewrite. Are there any examples of well-written inflection/conjugation modules out there? Jberkel (talk) 20:36, 30 November 2014 (UTC)
 * I wrote most of Module:ar-verb (Arabic) and Module:fro-verb (Old French), and I think they're fairly well written, although they may be daunting because of size; both languages have quite complex verb conjugations, and there's a lot of stuff in there to handle them. Easier for you might be Module:it-conj, which is fairly well written and close in language as well. Benwing (talk) 08:09, 1 December 2014 (UTC)
 * Thanks for the pointers, I think I've got a handle on it, almost there. Famous last words. Jberkel (talk) 14:24, 1 December 2014 (UTC)
 * OK, here is a first version: pt-conj-test. Let me know if anything is broken. Jberkel (talk) 15:30, 3 December 2014 (UTC)

Module:tagged but not listed
I made a module which scans RFX categories for pages which are not listed on their corresponding RFX pages. Outrageously ugly hack, but it seems to work well enough. Discuss. — Keφr 15:56, 24 November 2014 (UTC)

 * It sounds quite useful. - -sche (discuss) 01:04, 25 November 2014 (UTC)

 * The  hack is going to break on December 10th. The Vietnamese Wiktionary is using this same trick for its main page at the moment, so I filed T76844 to request that DynamicPageListEngine be installed there as a cleaner way to process DPL output. Perhaps the same should be done for this wiki. – Minh Nguyễn  💬 09:49, 5 December 2014 (UTC)
 * Yes, please. (Mxn: making a after you already signed your post does not work. See mw:Help:Echo.) — Keφr 11:23, 5 December 2014 (UTC)

Editing an Appendix
I would like to correct the transliteration of one of the Bulgarian numerals in Appendix:Cardinal numbers 0 to 9. Unfortunately one can't edit it by clicking on "edit". How is this done? --Kreuzkümmel (talk) 17:09, 24 November 2014 (UTC)
 * Words are automatically transliterated based on the language given. One of the words was tagged as Belarusian by mistake, so it was transliterated as if it were Belarusian. I fixed that now. —CodeCat 17:16, 24 November 2014 (UTC)

Manual translit is being ignored
On page Appendix:Proto-Indo-European/ph₂tḗr, the manual translit param  for Telugu is getting ignored in favor of the auto translit pitṛlu. (I have no idea if the manual translit is even correct -- I suspect it may not be -- but it's what was present before in parens after the entry.) Benwing (talk) 06:21, 25 November 2014 (UTC)
 * That's an expected behaviour. Manual translit is suppressed. Telugu is 100% phonetic, at least in terms of transliteration. --Anatoli T. (обсудить/вклад) 07:38, 25 November 2014 (UTC)

"D" button in Recent Changes not working
The red "D" accelerator button (to delete an entry directly from Recent Changes) doesn't seem to work any more. It says "notoken: the token parameter must be set". Equinox ◑ 14:39, 28 November 2014 (UTC)

Categorization of lb-adj
Somebody ought to place the template into Category:Luxembourgish headword-line templates, but I'm not sure how that works. --Lo Ximiendo (talk) 09:43, 28 November 2014 (UTC)
 * Done. —CodeCat 13:15, 28 November 2014 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Wiktionary:Grease pit/2014/November