Wiktionary:Grease pit/2014/October

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← September 2014 · October 2014 · November 2014 → · (current)

---

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. {{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';

To:

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

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

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 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

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 {{#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

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)

@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?

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 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

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

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

I think the time may have passed when that screen was a default useful for the project. Can we find out how often it is used and how often the product is speedily deleted?

In any event I would guess that Javascript could hide it. DCDuring TALK 12:22, 14 October 2014 (UTC)

Quick note, a simple workround: put #searchmenu-new-preload { display: none; } in your Special:MyPage/common.css to hide it for you. Dakdada (talk) 12:37, 14 October 2014 (UTC)

Thanks, I needed that. DCDuring TALK 13:35, 14 October 2014 (UTC)

broken entry

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

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)

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:

(deprecated template usage) [etyl] 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 {{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)

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 //<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)