Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
Jump to: navigation, search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

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

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

Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

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

Grease pit archives edit
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017


Contents

June 2017

Template:IPA letters - rhoticity[edit]

Template:IPA letters produces ɑː for the letter R. This should, I suppose, be ɑː(ɹ) or suchlike. Equinox 01:01, 2 June 2017 (UTC)

Only if Wiktionary adopts Wikipedia's trans-dialectal (diaphonemic) transcription system. Up till now, we haven't (though I suppose rhymes pages use some sort of diaphonemic system, or choose a particular dialect). The transcription of the above-mentioned vowel would be /ɑː(ɹ)/ for RP,/ɑɹ/ for General American, and /ɐː(ɹ)/ in Australia and New Zealand. — Eru·tuon 16:54, 2 June 2017 (UTC)
I've updated it. The other pronunciations, like /əʊ/, are also British, so this was obviously intended to be ɑː(ɹ). Ideally it would be updated to give multiple dialects' pronunciations, possibly through the use of separate Template:IPA letters/en-US and Template:IPA letters/en-UK subpages and through accepting en-US and en-UK as codes. - -sche (discuss) 18:21, 3 June 2017 (UTC)

Terms derived from Chinese[edit]

Why are the various "terms derived from Chinese" categories (e.g. CAT:Irish terms derived from Chinese) not subcategories of the corresponding "terms derived from Sinitic languages" categories (e.g. CAT:Irish terms derived from Sinitic languages)? Can and should it be fixed? —Aɴɢʀ (talk) 12:24, 2 June 2017 (UTC)

Chinese is a synonym of the Sinitic languages. —CodeCat 12:43, 2 June 2017 (UTC)
Then why do we have both? —Aɴɢʀ (talk) 13:26, 2 June 2017 (UTC)
The Chinese category is used when someone hasn't specified which Chinese language something is derived from, while the Sinitic languages category is an umbrella category in which the categories for particular Chinese languages are placed. It is illogical to have both, though, because they're synonymous... — Eru·tuon 16:51, 2 June 2017 (UTC)
Then I'd say we should merge them to "Chinese". —Aɴɢʀ (talk) 11:00, 3 June 2017 (UTC)

Oldest tagged RFVs[edit]

The lists of "Old tagged RFVs" atop the RFV pages are displaying "No pages meet these criteria." They should be fixed, since they're the main way we come to notice tagged-but-not-listed RFVs. As a separate matter, maybe a cleanup bot could periodically list unlisted RFVs... it wouldn't have to run often / represent a major time investment; even once every few months would work. - -sche (discuss) 18:11, 3 June 2017 (UTC)

It is now working for English. The problem is in the split of the RfV page and associated elimination of a single category for all RfVs. This approach never worked for RfV items that didn't have an RfV template.
The non-English RfV category has only subcategories, for each one of which we could have an oldest RfV list. There are solutions. One class of solutions would require a new category, eg, for all non-English RfVs, or new categories, eg, for all languages in a given family or in a given script or differentiated by nature of attestation. Another might be some dump-based solution. It is beyond my paygrade to even participate seriously any further in the discussion. DCDuring (talk) 19:04, 3 June 2017 (UTC)
  • @Daniel Carrero, was this you? —Μετάknowledgediscuss/deeds 14:04, 5 June 2017 (UTC)
    Thanks, DCDuring, for identifying the problem and solving it on the English page. There are two simple ways the remaining problem could be addressed. All RFVs could double-categorize into both the language-specific category and a general category of all RFVs (like the one they previously went into). This would have benefits besides just finding Oldest tagged RFVs (the same benefits as the per language categories: it'd be there if someone wondered what terms needed verification, if they wanted to help cite them; for many languages and RFVs). The other approach, which is not mutually exclusive, and which is more useful for this specific issue, is to have non-English RFVs double categorize into a "RFVs (non-English" category, to feed the Oldest list at the non-English page. If it would be too difficult to implement the idea of categorizing all non-English RFVs, or conceptually untidy/undesirable I could just add an "all RFVs" category. - -sche (discuss) 15:38, 5 June 2017 (UTC)
    I fixed Wiktionary:Requests for verification/Non-English. See if you like this approach or if you would change something. --Daniel Carrero (talk) 15:45, 5 June 2017 (UTC)
    Your solution seems to require constant maintenance, obliging people to notice and update that template whenever a term in a new language is RFVed (or do I misunderstand?). But one point of the Oldest Tagged list is to catch cases that people don't notice have been RFVed. So, I suggest we use one of the two double-categorization approaches I outline above. (Potentially perhaps your template could be updated to fetch the contents of Module:languages'(s) data modules and check every language's RFV category, so as to catch whenever a code is added, whenever a new in a new language is RFVed, etc, but that seems like a very unnecessary and probably expensive use of Lua for something {{rfv}} could do by just automatically inserting a certain category.) - -sche (discuss) 19:38, 5 June 2017 (UTC)
    I see. What about using "CategoryTree"? I added an example here in the discussion now. This way the list would still be organized by language, and it would be updated in real time as new language categories are created. It would be nice if we could use JavaScript to replace "Requests for verification in Volapük entries" by just "Volapük", and do the same for all languages. --Daniel Carrero (talk) 20:31, 5 June 2017 (UTC)
    @Daniel Carrero: I've created a JavaScript function that does that; see User:Erutuon/scripts/sandbox.js. It does make the list much easier to read. — Eru·tuon 20:52, 5 June 2017 (UTC)
    @Erutuon: Thanks! I added the categorytree in WT:RFD, WT:RFC and WT:RFV. Do you think you could update the JS code to do the same for the other two? Note that RFD and RFC also have a "language code missing" category at the start, but RFV doesn't (because you can use RFD and RFC in entries without a language code, but you can't use RFV without a language code without triggering a module error).
    Your code worked when I added it to User:Daniel Carrero/common.js, but I basically don't understand anything of JS and I don't know if we need to edit somehow MediaWiki:Common.js to implement it properly for everyone to see. --Daniel Carrero (talk) 21:22, 5 June 2017 (UTC)
    @Daniel Carrero: Yep, I've modified it to do the same for RFD and RFC categories. The "language code missing" category could perhaps stand to be shortened, but I'm not sure what to shorten it to. — Eru·tuon 21:30, 5 June 2017 (UTC)
    Oh, the code is working now. Maybe we could replace "Requests for (deletion, cleanup) with the language code missing‎" by just "language code missing". I also implemented a page count in all the categories. Do you think you could use JS remove the "0 c," from all the categories? A category like Category:Requests for deletion in Lithuanian entries obviously doesn't have any subcategories. --Daniel Carrero (talk) 21:42, 5 June 2017 (UTC)
    The sandbox script now removes the useless "0 c, ". It will probably do that to any category tree generated in the same way as the one above, though it doesn't do anything on category pages like Category:English nouns; those must use different classes. — Eru·tuon 22:53, 5 June 2017 (UTC)
    Thanks, it's working perfectly. --Daniel Carrero (talk) 23:07, 5 June 2017 (UTC)
  • To retain some focus on problematic older entries, perhaps each language with more than, say, 20 entries in one of the categories, could use the "oldest" listing, using the approach now used in RfV/English. DCDuring (talk) 23:24, 5 June 2017 (UTC)
    I believe it's not to possible to use "categorytree" to focus on the older entries anymore, because of the change in categories. Technically, all the "older" entries in Category:Requests for verification in English entries are the ones that were added when I created the new category in May 18 2017. --Daniel Carrero (talk) 03:58, 6 June 2017 (UTC)
    Well, right now all the entries in each category were added at about the same time (when you created the categories, as you said), but several months from now, when old RFVs have been dealt with and new ones have come up, it will once again be possible to sort (a category) by age, won't it? - -sche (discuss) 15:59, 7 June 2017 (UTC)
    That is correct. --Daniel Carrero (talk) 16:02, 7 June 2017 (UTC)
I consider it suboptimal that I have to click to expend each language's category to see its entries; however, assuming that the sum of all those language categories contains all of the entries which would be contained in a (list of the oldest RFVs in a) single category of all non-English RFVs similar to the one we previously had (which was for all RFvs, before WT:RFV was split by language), this is adequate; thank you for your help. I do still think we could benefit from restoring a general category for all RFVs to double-categorize into, so that the oldest ones (independent of language) can be found. (Likewise for RFCs and RFDs.) - -sche (discuss) 15:59, 7 June 2017 (UTC)
I'm pretty sure we could leave the list completely un-collapsed by default, but assuming we want that, I'm not sure how to do it.
Here's an idea for a different categorization approach, though it would require constant maintenance. Wikipedia has cleanup categories organized by date, such as w:Category:Articles with unsourced statements from February 2017. I guess we could have categories for each year (the month is not necessary because we don't have that many requests to deal with, I guess) If we created categories like Category:Requests for verification from 2017 (and even Category:Requests for etymology from 2017, Category:Requests for pronunciation from 2017, you get the point) maybe some bot could constantly add the correct year in entries and automatically create new categories each year? I could help by making {{auto cat}} usable in these categories. I could also fill the categories by checking the current entries with RFVs and perhaps other types of request. --Daniel Carrero (talk) 16:16, 7 June 2017 (UTC)

Bug in inserting IPA characters[edit]

If you edit a page, and then delete a character and then immediately click on one of the IPA symbols under the "IPA and enPR" section at the bottom of the page (at least, this happens with ɛ), it inserts the character one character to the right of where it should be. This happens to me consistently on Chrome under Mac OS X 10.9. It doesn't happen if the last thing you did before clicking on the IPA symbol is to insert rather than delete a character. Do people see this on other systems? Someone should file a Phabricator bug if there isn't one already (I'm still not quite sure how to do that). Thanks! Benwing2 (talk) 19:19, 3 June 2017 (UTC)

Flags for Hijazi Arabic and Najdi Arabic[edit]

See MediaWiki_talk:Gadget-WiktCountryFlags.css#Hijazi_and_Najdi for more details. --Lo Ximiendo (talk) 02:31, 4 June 2017 (UTC)

Citations at citations[edit]

Why do we bother putting {{citations}} at the top of every Citations page? I reckon it should be automatically included in the software. --Celui qui crée ébauches de football anglais (talk) 11:17, 4 June 2017 (UTC)

Well, we still have to specify the language the citations are in, and we need a template to handle that. —Μετάknowledgediscuss/deeds 14:03, 5 June 2017 (UTC)
True. But on a related note which I've mentioned before, why do we put {{reconstruction}} atop most reconstruction pages? Could that be done by a Mediawiki page or JS? Or a bot... - -sche (discuss) 15:44, 5 June 2017 (UTC)
I think we can do that if we install PageNotice extension. - [The]DaveRoss 18:31, 5 June 2017 (UTC)
Well, that sounds like a good idea, then. Before we set up a vote on installing that extension, does anyone have any comments / see any obvious problems? - -sche (discuss) 19:42, 5 June 2017 (UTC)

rel-top columns messed up the 2015 NORM vote[edit]

For the record, the recently-added automatic columnization (?) of {{rel-top}} messed with this 2015 vote: Wiktionary:Votes/pl-2015-11/NORM: 10 proposals.

All the collapsed parts of the vote are formatted as two columns now. They were normal text without columns before. --Daniel Carrero (talk) 12:21, 5 June 2017 (UTC)

Deletion of {{script}}[edit]

Why was {{script}} deleted? I think it would be really useful to be able to type {{sc|Mani}} and get Manichaean. Yes, I'm aware that {{sc}} is currently for {{smallcaps}}. @CodeCat, Daniel Carrero? --Victar (talk) 03:12, 6 June 2017 (UTC)

Why would that be useful? It isn't a significant change in character count, it isn't likely to change frequently over time, why not just type the name of the script? - [The]DaveRoss 18:43, 6 June 2017 (UTC)

Memory Weirdness at [edit]

How is it that this diff pushes the memory usage from 44.6 MB to over the 50 MB limit? If I edit and preview the section containing the template, I see "Lua memory usage 7.95 MB/50 MB" in the parser profiling data table. If I then remove that template and preview again. I get "Lua memory usage 7.01 MB/50 MB".

.84 MB≠5.4 MB+ Chuck Entz (talk) 03:48, 6 June 2017 (UTC)

Weird. I even added as an exception in Template:redlink category and then did a "hard purge" on the diff, but this did not stop the memory errors. --Daniel Carrero (talk) 03:54, 6 June 2017 (UTC)
Well, that template uses Module:zh-cat, which uses Module:zh; perhaps the problem lies there. Perhaps it would help if Module:zh were split into smaller modules. — Eru·tuon 15:47, 6 June 2017 (UTC)
Never mind; Module:zh would already be invoked in any Chinese entry. — Eru·tuon 15:49, 6 June 2017 (UTC)
I went through many of the Chinese modules and removed global variables. I hoped that it would help with the memory error, but apparently not. — Eru·tuon 18:26, 6 June 2017 (UTC)

Header vs headword-line POS mismatch[edit]

I wrote some probably inefficient, possibly horrifyingly inelegant, case sensitive regex which I used to search the most recent database dump and find 1666 entries where the part of speech header gave one part of speech but the headword-line template gave another. I cleaned up many pages which matched this same regex in 2014, so it appears we're seeing an edit or two a day (on average) introducing a header-headword POS mismatch. Would it be worthwhile to have an edit filter check for this in real-time? Would it be overly expensive? My regex can probably be improved upon; perhaps it can be made case-insensitive by adding = at the start of each header and by ignoring entries with nonstandard spaced headers (=== Noun ===), although the current approach also catches cases of "Proper Noun". It does not find all cases of mismatch, just common ones. (A related but separate approach would be to monitor for edits that introduce a header without also introducing a corresponding headword-line template.) If the filter works, it could even be updated to warn users against the edits. - -sche (discuss) 16:55, 7 June 2017 (UTC)

As to the regex, the header part could easily be simplified: Noun(===| ===|====| ====)Noun ?====?. So could the language code part: (..|...)[^\|]+. (That would also allow it to catch the exceptional codes from Module:languages/datax.) — Eru·tuon 17:14, 7 June 2017 (UTC)

Wikidata not working?[edit]

To try out, I queried a single Wikidata item at Module:User:CodeCat. However, I get an error "attempt to index field 'wikibase' (a nil value)". I thought Wikidata access was enabled for Wiktionary already? —CodeCat 17:29, 11 June 2017 (UTC)

See phab:T159316. Wikidata is expected to work sometime, but it's not working yet. --Daniel Carrero (talk) 17:43, 11 June 2017 (UTC)
Ah, so we only have to wait for someone to enable it then? —CodeCat 17:46, 11 June 2017 (UTC)
I believe the next step of the big Wikidata plan is to enable custom interwikis. This is phab:T158323. The interwiki thing will be enabled on June 20th as said in Wiktionary:Beer parlour/2017/June#Enable sitelinks on Wikidata for Wiktionary pages (outside main namespace).
Apparently this has to be done first, before implementing normal Wikidata queries ("arbitrary access") as described in phab:T159316. I don't know when they'll do it, but it's marked "ready to go". --Daniel Carrero (talk) 17:53, 11 June 2017 (UTC)

Template:place problem with Parijs[edit]

I just converted the entry Parijs to use {{place}}, but now the category Category:nl:Cities in France has disappeared from the page. It is the capital city of France, so isn't it also a city in France by definition? —CodeCat 18:05, 11 June 2017 (UTC)

It's a known bug (Template_talk:place#Capital_cities). The whole thing needs to be rewritten. DTLHS (talk) 18:13, 11 June 2017 (UTC)

Requested change to Template:trans-top[edit]

Partially related: Template talk:trans-top#link to wikidata item

Right now, on the first line, there is this:

{{#switch:{{{1|}}}||Translations to be checked=|id{{=}}"Translations-{{anchorencode:{{{1}}}}}"}}

I'm requesting that this be changed to:

{{#ifeq:{{{1|}}}|Translations to be checked||{{#if:{{{id|{{{1|}}}}}}|id{{=}}"Translations-{{anchorencode:{{{id|{{{1}}}}}}}}"}}}}

This change will allow the id= parameter on translation tables, so that each table can be matched to the corresponding senseid on an individual sense. It will create an anchor on the page with the format Translations-{{{id}}}, so that the translation table can be directly linked to. It is probably desirable to, eventually, remove {{{1}}} from the anchor (if no id is present), so that only ids are used as anchors and not glosses. Moreover, it would be nice if there was a small link to the corresponding senseid in the top bar. —CodeCat 11:51, 12 June 2017 (UTC)

Done. It is probably good to have a separate |id= parameter. — Eru·tuon 19:38, 13 June 2017 (UTC)

preg_match_all equivalent[edit]

Basic question. What's the equivalent to preg_match_all in Lua? I was hoping that I could create a table/array like so: mw.ustring.match(content, "\n=+[^=]*=+[^=]*"). --Victar (talk) 14:32, 12 June 2017 (UTC)

@Victar: There isn't any equivalent. But I created the function matchToArray in Module:string, which hopefully will work for that purpose. — Eru·tuon 17:48, 12 June 2017 (UTC)
Either that or if you plan to do something to each match that doesn't require an index of which number match it was, you can use a for loop with mw.ustring.gmatch. — Eru·tuon 18:12, 12 June 2017 (UTC)
@Erutuon: Thanks again! Man, you think that would be a basic function in Lua. --Victar (talk) 18:19, 12 June 2017 (UTC)
@Erutuon: I'm pretty sure I'm asking for the impossible, but I'm trying use this to create an array entry of section on a page: local content = require("Module:string").matchToArray(content, "\n=+[^=]*=+[^=]*"). I need this part, [^=]* to match all and stop at 2 repeating ==. I thought maybe [^={2}]* or .*(==), not no luck. Again, I assume this is impossible, but I thought I'd ask. --Victar (talk) 03:38, 13 June 2017 (UTC)
@Victar: If you want to stop at just two equals, I think .-==[^=] would work. .- is a non-greedy quantifier, equivalent to JavaScript .*?. — Eru·tuon 03:44, 13 June 2017 (UTC)
@Erutuon: \n=+[^=]*=+.-==[^=] is better, but it's stealing the first ='s and letter of the next section. You can find my test here. --Victar (talk) 04:43, 13 June 2017 (UTC)
@Victar: Well, I found a solution that grabs the content of the Descendants section. Was that what you wanted to do, or did you want to grab the whole rest of the language section below the Descendants header? — Eru·tuon 04:54, 13 June 2017 (UTC)
@Erutuon: I need to grab the section header and the content until the next section header. --Victar (talk) 04:58, 13 June 2017 (UTC)
@Victar: You can move the parentheses to capture whatever you want. — Eru·tuon 05:03, 13 June 2017 (UTC)
@Erutuon: Cool, but the problem with matching content that I'm not including is that is taking it from the next array item, which is causing every other to be skipped. --Victar (talk) 05:09, 13 June 2017 (UTC)
@Victar: Ouch. I can't think of a way to fix that, except by coming up with an entirely different approach to finding the Descendants section. — Eru·tuon 05:15, 13 June 2017 (UTC)
@Erutuon: If I just wanted to grab the Descendants section, that would be a breeze, but I'm trying to do something like GET KEY_1 of MATCH for "{{senseid|xxx}}" THEN FIND MATCH for "Alternative forms" with KEY_2 +/-2 from KEY_1. --Victar (talk) 05:35, 13 June 2017 (UTC)

Automatic Palindromes and नून[edit]

The automatic palindrome categorizer is good, but seems to be incorrect for abugidas. नून (nūn) isn't a palindrome, because backwards it would be ननू (nanū). Things like ननून, नूनू, प्रतंप्र, etc. would be considered palindromes. DerekWinters (talk) 19:24, 12 June 2017 (UTC)

Is there a rule that can be added to Module:palindromes/data to fix it? DTLHS (talk) 19:28, 12 June 2017 (UTC)
I think the reason why it's considered a palindrome is that नून consists of three characters, न ू न, and Module:palindromes determines palindromes based on individual characters, not combinations of letter and diacritic. It can be made to find letter plus diacritic combinations instead. (More technically, it has to put letter plus diacritic combinations into slots in the table that it uses, rather than individual characters.) — Eru·tuon 19:41, 12 June 2017 (UTC)
That's a language-independent process though, isn't it? If we know in advance which characters need to combine. Can we use our Unicode database for this? —CodeCat 19:45, 12 June 2017 (UTC)
It might be possible, but it would be more complicated than simply doing it for one script where there's a relatively small number of combining diacritics. With one script it would be fairly simple to make a pattern to search for letter–diacritic combinations, whereas the full list of Unicode combining characters would be huge and might require a more complicated function that uses the is_combining function in Module:Unicode data. — Eru·tuon 20:37, 12 June 2017 (UTC)

more pages exceeding the memory limit[edit]

fire now runs out of memory, following the addition of two Tamil translations. This lends support to the point, also made by some on Phabricator, that our auto-transliteration modules seem to be among the main culprits behind the errors. (They demonstrably are culprits behind a large chunk of the errors that plagued water.) As more and more pages run out of memory, perhaps we should rethink whether translations really need to provide transliterations. - -sche (discuss) 06:08, 13 June 2017 (UTC)

I'd rather move the translations to a subpage /translations than remove transliterations, which are very helpful. However, even that solution will run into problems in the future, when the translations themselves go over the 50MB limit. — Eru·tuon 06:57, 13 June 2017 (UTC)
@Erutuon In that case, how about /translations (A) for languages, whose names start with the letter A (for example, Arabic); /translations (B) for language names starting with B, and so forth. --Lo Ximiendo (talk) 07:04, 13 June 2017 (UTC)
If I remove any 2 translation languages with transliterations then the page renders fine. It seems that most weird transliteratins are Korean and Thai. If I remove Korean translations then it's fine. If I fill the Korean transliteration in the translation template then it still uses 4 modules for Korean and it breaks. There is something inefficient there calling modules that it really don't use at the end. If that is fixed then a bot could subst missing tr parameters avoiding large upload of translit modules. The cons is to refresh them after an update in translit modules. --Vriullop (talk) 09:14, 13 June 2017 (UTC)
I think we should stop using modules for static text which is unlikely to change much or often, like transliterations. Make the script code and transliteration into parameters and only call the module when there is no value provided. As Vriullop says, a bot can do the work to keep them up to date. - [The]DaveRoss 11:15, 13 June 2017 (UTC)
Module:links generates a transliteration whenever a transliteration module is available, in order to compare manual to automated transliterations, so providing a manual transliteration actually uses slightly more memory. This problem of escalating memory usage is fairly recent- a matter of a few months- so we should look at changes made this year to see if any of them have side effects on memory usage. Chuck Entz (talk) 13:01, 13 June 2017 (UTC)
It may do that, it doesn't need to do that. - [The]DaveRoss 14:04, 13 June 2017 (UTC)
I second that: checking transliterations is obviously too taxing. Ideally the transliterations for a word should be created once and stored in the page (or in the Future: in Wikidata). It can be automated (by bot or with a gadget or an extension). — Dakdada 15:06, 13 June 2017 (UTC)
I agree we should stop using modules to automatically provide transliterations in translations (if not also in links), and "subst" them in by bot. (@Dakdada, accessing Wikidata is expensive and relatively slow, so that would not improve things over what is currently done, and might make things worse. And, of course, transliterations vary between wikis. It would be better to store transliterations directly on the page.) So, we need to (1) rewrite {{t}} to stop expensively checking the auto-translit against the manual translit, and (2) "subst" the auto translits into all entries. - -sche (discuss) 15:46, 13 June 2017 (UTC)
Saying "use a bot" to solve all our problems is intellectually lazy. Whose bot? How often is it expected to be run? What happens if the bot runner leaves the project or dies? How will the bot code be updated if we decide to change a formatting detail? DTLHS (talk) 15:51, 13 June 2017 (UTC)
For translations, I would think that a bot could run once to subst all existing {{t}}s, and then perhaps the translations-adder script could be changed to fetch and add (spelled out) the transliteration that the automatic transliteration module provides. Perhaps we should require the code of the bot to be available, something we did not require of some previous AutoFormat-esque bots whose users subsequently became much less active or were globally banned.
But even just step 1, rewriting {{t}} so that it does not compare a manual transliteration to the automatic one, together with the addition of manual transliterations to the {{t}}s in the entries that are currently broken, would fix most of the breakages we are seeing by stopping the invocation of the expensive translit modules. Even just {{t-simple}}, if it never invokes a transliteration module and only provided a transliteration when one was manually given, ought to work... - -sche (discuss) 16:20, 13 June 2017 (UTC)
Shared bot projects are possible if the toolserver is used. They can be maintained by a group and can be run against either the replica databases or via the API. - [The]DaveRoss 17:03, 13 June 2017 (UTC)
Another test in fire page, on previous version without t-simple: if I remove translations with tr parameter then the page renders fine with Lua memory usage 47.64 MB/50 MB. With current version with some translations changed to t-simple it uses 49.93 MB. To compare manual and auto transliterations is really a waste of resources. It is fine in a language by language basis for checking purpouses but it should be temporary and it should be switched off when the task is finished or nobody is checking it. If the translation-adder script adds tr parameter then maybe a bot is not needed. --Vriullop (talk) 17:06, 13 June 2017 (UTC)

I've added manual transliterations for the Korean and Thai words on the page fire with {{subst:xlit|lang|term}}. Now transliterations are shown, but they don't use any Lua memory. — Eru·tuon 17:10, 13 June 2017 (UTC)

Fantastic. Hmm, would it be possible to update your t-simplifier gadget to convert translations in non-Latin scripts, adding the (manual) translit and script parameters? - -sche (discuss) 19:20, 13 June 2017 (UTC)
Probably. I just haven't done it yet because I imagine it will be complicated. I should, though. Once made, it will simplify things bigly. — Eru·tuon 19:27, 13 June 2017 (UTC)

{{t-simple}} now supports interwiki links. Turn them on with |interwiki=1. — Eru·tuon 19:28, 13 June 2017 (UTC)

Okay, I have an idea regarding the transliteration comparison, mentioned above: how about disabling the transliteration comparison on particular pages that are running into memory errors? So, on water and such pages, {{t}} would only invoke a transliteration module if no |tr= parameter was provided. — Eru·tuon 19:16, 15 June 2017 (UTC)

I prefer a solution which will solve the problem rather than playing whack-a-mole. As a stop-gap I think your solution is reasonable. - [The]DaveRoss 17:31, 16 June 2017 (UTC)
We can add e to the list, as reporting by an IP on the talk page of the March 2017 Grease Pit (for some reason). The longest running template in that case is {{head}} which hasn't been changed lately. - [The]DaveRoss 22:52, 29 June 2017 (UTC)
Also, can someone explain to me the reasoning behind {{zu-letter}} and its ilk? Why do we need to perform an expensive call to the languages module for a template which is always going to refer to a single language? The languages module is at the root of nearly every memory error we encounter here, and it often provides no benefit to offset the problems. - [The]DaveRoss 23:01, 29 June 2017 (UTC)
Based on our own observations and the limited observations of the folks at Phabricator, we know that the functions that provide and check automatic transliterations are (some of) the biggest wasters of Lua memory. Disabling the "checking" that compares manual to automatic transliterations, updating {{t}} to not invoke the transliteration modules at all if a transliteration has been supplied manually, and if possible having a bot (even just as a one-off) subst in automated transliterations for languages where that can be done reliably (i.e. most languages), would save a lot of memory. Perhaps the translation-adder script could be updated to automatically subst: in transliterations, too (via {{subst:xlit}}?). We could also have {{t}} accept langname= and have the translation-adder also subst that in, and have {{t}} not invoke the language modules to ask for langnames when they are manually provided. Basically, make {{t}} more like {{t-simple}}, perhaps eventually combining the two. - -sche (discuss) 19:27, 30 June 2017 (UTC)
I'm not sure if having {{t}} accept the parameter |langname= would use more or less memory, because the module would still create a language object, and the language name parameter, since it would be passed to Module:translations and Module:links, would have to be stored in Lua memory. It would also require us to modify the linking functions or create a new one... — Eru·tuon 22:20, 2 July 2017 (UTC)

Asia in Category:en:Countries[edit]

Why is the entry Asia in Category:en:Countries? It doesn't belong there as far as I can tell, but I can't find where on the page the category is being added to the page. —CodeCat 18:08, 13 June 2017 (UTC)

{{list:countries of Asia/en}} DTLHS (talk) 18:09, 13 June 2017 (UTC)
I've made it no longer categorize if the pagename is "Asia", and re-added the template (after @CodeCat removed it) under Hyponyms. — Eru·tuon 18:19, 13 June 2017 (UTC)
The same is happening to Europe as well. —CodeCat 12:58, 14 June 2017 (UTC)

Auto-expand translation table when linking to its anchor[edit]

The translation table on Republic of Macedonia contains a link to Macedonia#Translations-Q221, which takes you to the right translation table. However, the translation table stays collapsed. Could it be made so that the translation table expands whenever you link to its anchor (if it has one)? —CodeCat 18:10, 14 June 2017 (UTC)

The anchor to Macedonia#Translations-Q221 doesn't work for me (it links further down the page, probably because of things loading in the wrong order) (Chrome). DTLHS (talk) 18:16, 14 June 2017 (UTC)
That happens with fragments in general, very commonly on discussion pages. But if you wait for the page to load and then click the address bar and hit enter, it jumps to the right place for me. —CodeCat 18:18, 14 June 2017 (UTC)

Swahili on Wiktionary[edit]

"Welcome to the English-language Wiktionary, a collaborative project to produce a free-content multilingual dictionary. It aims to describe all words of all languages using definitions and descriptions in English."

Swahili has some words that do not fit into verb, noun, adjective, etc because they are sentences when translated into English, such as 'mtaona' (sic) which means 'you (plural) will see'.

How can we make pages for words such as this? Anjuna (talk) 09:51, 16 June 2017 (UTC)

I believe those are considered "verb forms". —suzukaze (tc) 10:11, 16 June 2017 (UTC)
Yes. It's no different than Latin vidēbitis. —Aɴɢʀ (talk) 12:03, 16 June 2017 (UTC)
I'll also point out the About_Swahili page, which covers some of the nuances with regards to the Swahili language treatment here on Wiktionary. I am not sure it addresses this issue directly, but the "conjugated form" section demonstrates how verb forms should be formatted. - [The]DaveRoss 13:33, 16 June 2017 (UTC)

Thank you all! Yes, I've made a derived verb page. I'll file them all under verb. I'm afraid that some will be taken down, though. They're a little long sometimes. I won't bother to make pages for words with object infixes, such as 'ninakuchukua', literally 'I am taking you', since those words contain the nominative, and the predicate- there are too many combinations.
Anjuna (talk) 00:56, 17 June 2017 (UTC)

How about this one? ataona Is there any more formatting that I must do to make this acceptable?Anjuna (talk) 01:31, 17 June 2017 (UTC)

Put {{head|sw|verb form}} under the Verb header. DTLHS (talk) 01:44, 17 June 2017 (UTC)
Also make sure you check for any irregular forms before you add {{sw-conj}} to a page. DTLHS (talk) 01:49, 17 June 2017 (UTC)

Thank you all so much! I found the verbal derivation. I found it helpful. This section can be deleted now, I suppose. —This comment was unsigned.

I see that many of the questions have already been answered. @Metaknowledge is probably able to help with any questions that remain, such as whether the more heavily inflected forms need to be created or not. - -sche (discuss) 03:17, 17 June 2017 (UTC)
Inflected forms are much lower priority when a language coverage is nowhere near a decent level for a dictionary. Before e.g. a Russian inflected entry for уви́дите (uvídite, you (plural) will see) was created, many lemmas like уви́деть (uvídetʹ) were made. --Anatoli T. (обсудить/вклад) 07:01, 17 June 2017 (UTC)

User:Metaknowledge hasn't replied to me, so, how do I signify negative?

@Science Bird: they replied on their talk page (which is a common practice), have a look there. Also it is helpful if you sign all your comments with four tildes (~~~~) so that everyone knows who is making a statement or asking a question. - [The]DaveRoss 18:48, 21 June 2017 (UTC)

Renaming a senseid?[edit]

Is there a particular way to rename a senseid? Right now, the music sense on house has genre of music as its senseid, but there is also a Wikidata item, d:Q20502. If the senseid is to be changed to match the Wikidata item, how do we deal with all the existing uses of the genre of music id? —CodeCat 16:58, 16 June 2017 (UTC)

The simplest solution would seem to be to allow multiple senseids, so that the one which is intelligible to humans can be kept, and the Wikidata one can be added. - -sche (discuss) 17:01, 16 June 2017 (UTC)
I suppose that would work. Should {{senseid}} take multiple id parameters then? —CodeCat 17:03, 16 June 2017 (UTC)
Yes. (I mean, AFAICT we could just use multiple instances of {{senseid}}, but obviously your suggestion is better.) Some senseids and anchors are linked-to from Wikipedia entries, and others may be linked-to from other off-wiki sites. I'm not entirely opposed to rotting links sometimes, for example if a particular senseid is badly named (very misleading, offensive, etc), in general adding additional IDs seems preferable, with the understanding that there should be no vast proliferation of them (one human-readable ID and one Wikidata ID seems reasonable; five human-readable IDs, if one person wanted orange#the_colour and one wanted orange#the_color, etc, would be too many). - -sche (discuss) 17:52, 16 June 2017 (UTC)
How are we going to make sure that senseids are not changed or removed without links to them being fixed too? — Ungoliant (falai) 17:10, 16 June 2017 (UTC)
We can't, really, unless we have a way to track down all uses of a particular id. —CodeCat 17:11, 16 June 2017 (UTC)
So we're just supposed to accept inevitable link rot? Would anyone else support banning senseids all together? DTLHS (talk) 17:19, 16 June 2017 (UTC)
Not without an adequate replacement. — Ungoliant (falai) 17:20, 16 June 2017 (UTC)
Yes, glosses, which are independent of what they reference. DTLHS (talk) 17:21, 16 June 2017 (UTC)
Senseids are a complement to, not a replacement of, glosses. Even glosses + senseids with link rot is an improvement over just glosses. Glosses form the informational connection between link and definition, while senseids form the software connection. — Ungoliant (falai) 17:27, 16 June 2017 (UTC)
I support only using them if they are reasonably robust. I think the long-term goal is that the editor and back-end infrastructure get to the point that a senseid would be intelligible to humans and also not suffer from the possibility that it becomes out of sync with the unique identifier. Not sure how long that term is though. - [The]DaveRoss 17:23, 16 June 2017 (UTC)
@TheDaveRoss: Would it be possible to make an edit filter that would catch changes of senseids? — Eru·tuon 18:15, 16 June 2017 (UTC)
I think it would be possible, I will take a look. - [The]DaveRoss 18:32, 16 June 2017 (UTC)
Changed my mind. I can make a filter which can detect if a senseid is added or removed, or a line which contains a senseid is changed. Possibly also if the first instance of senseid has been changed. But without flow control I don't think there is a way to see if any instance of senseid has been changed. - [The]DaveRoss 19:32, 16 June 2017 (UTC)

Search results from sister projects[edit]

TOW has just added a nice search feature called "results from sister projects", so that searching Wikipedia also shows results in a sidebar from Wiktionary, Wikibooks, Wikivoyage, Wikiquote, and Wikisource. I wonder if we can get this...? I remember suggesting it a long time ago in response to the argument "we should have entries about TV series because people might not find them on other sites". Equinox 00:36, 19 June 2017 (UTC)

I like it. - [The]DaveRoss 13:27, 19 June 2017 (UTC)

Is my abuse filter not working?[edit]

[1] is supposed to prevent edit summaries of the word "nothing". It has blocked a few edits. How did this one get through? [2] Equinox 17:51, 21 June 2017 (UTC)

You can add whitespace to the end of the edit summary and it will be stripped in the history, but your edit filter won't recognize it. I'm guessing that's what happened. DTLHS (talk) 18:02, 21 June 2017 (UTC)
Converting the rule to regex could probably deal with that. — Eru·tuon 18:26, 21 June 2017 (UTC)
Aha. I have changed it to ^\s*[Nn]othing\s*$. Hope that's correct. Equinox 18:33, 21 June 2017 (UTC)
If they aren't editing a section (unless sections are automatically stripped?). To account for that, it would have to be something like ^\s*\/\*.*?\*\/\s*[Nn]othing\s*$ (though there could be errors, because I'm not sure what version of regex is used). — Eru·tuon 18:36, 21 June 2017 (UTC)

Lua error: attempting to index upvalue 'm_data'[edit]

Many of the templates (of various kinds) on the page for the Malay/Indonesian term burung kakaktua are showing this error:

Lua error in Module:script_utilities at line 167: attempt to index upvalue 'm_data' (a boolean value).

Each of the templates looks fine to me individually when I look at it in edit mode. Other Malay/Indonesian words look fine. --46.226.49.232 11:33, 22 June 2017 (UTC)

This happens sometimes. Someone made an error when changing the code in one of the modules and then it was fixed, but there are so many entries using the module that it takes a while for the system to update all of them. If you find any more like that, simply edit the entry and save/publish it without making any changes (what we call a "null edit"). This will make the system apply all the edits waiting for that entry and bring it up to date. If that doesn't solve the problem, then something still needs to be fixed and you can let us know here. Thanks! Chuck Entz (talk) 13:43, 22 June 2017 (UTC)

Language name to ISO converter[edit]

I just discovered that the language name to ISO code converter that I used to be able to see in the sidebar is no longer showing up for me in either Firefox or Chrome, although it is still selected in my per-browser preferences. Any idea why this might be? It does warn that it's one of the potentially buggy gadgets, but it was also working before... Andrew Sheedy (talk) 03:34, 23 June 2017 (UTC)

See also links from Cyrillic е to ё[edit]

I recently noticed that зелений (zelenyj) didn't have a see-also link at the top to зелёный (zeljónyj). I'm surprised a bot didn't add it, and wanted to check that this was just an anomaly. — Eru·tuon 17:42, 23 June 2017 (UTC)

@Erutuon: But one has a soft ending, the other a hard one. --Barytonesis (talk) 17:43, 23 June 2017 (UTC)
Ohh... duh. Well, they both have hard endings, actually, just spelled in different alphabets. — Eru·tuon 17:44, 23 June 2017 (UTC)
I hadn't even noticed one was Ukrainian, not much better... --Barytonesis (talk) 17:48, 23 June 2017 (UTC)
The see-also links are mostly added by hand anyway. There was one bot that briefly added some, but it missed a lot. I just recently added {{also|weder}} to the top of Weder, for example. —Aɴɢʀ (talk) 06:54, 24 June 2017 (UTC)
@Angr: (Belated response.) I remember seeing bots add these links before, but I haven't noticed they stopped, probably because I hid bot edits in my watchlist. — Eru·tuon 06:41, 8 July 2017 (UTC)

Affix sense differentiation[edit]

Several affix entries include two or more (often completely unrelated) meanings, yet the words they derive are all categorized together:
e.g. modesty and messy both fall under [[Category:English words suffixed with -y]], with no mention of how -y was used in two completely different fashions.
I'm fairly new in this discussion page, so I can't say for certain this hasn't been discussed before, but I would like to hear if anyone else is... well, kinda bothered by this. – GianWiki (talk) 15:20, 24 June 2017 (UTC)

I agree it's not ideal. Another good example is e-. Are there any practical ways to get around this? Equinox 15:22, 24 June 2017 (UTC)
You can add a gloss, for example merger. DTLHS (talk) 15:29, 24 June 2017 (UTC)
Better still, use a senseid. —CodeCat 16:29, 24 June 2017 (UTC)
As is currently done with Category:English words suffixed with -y (diminutive)‎. — Eru·tuon 17:46, 24 June 2017 (UTC)

Category:head tracking/no lang category[edit]

I seem to remember someone bringing this up before, though I don't remember the outcome: this tracking category currently has 33,393 entries in it- most of which seem to be Serbo-Croatian and proto-languages. I believe the reason for the latter is a statement in the block of code in Module:headword#full_headword that generates the category:

if not mw.ustring.find(cat, "^" .. data.lang:getCanonicalName()) then

I'm sure there are efficiency/speed benefits to converting the language name into a pattern this way, but it seems to me like any language name with pattern characters in it such as "-" would give unexpected results. Is there any way to use an escaped version of the language name instead? Or maybe we should skip language names with characters like "-" in them?

If there are reasons not to fix this, the question then becomes: how can you use a tracking category with 99% false positives? I ran into a couple of Latin entries in the category that seem to have some other problem (Alba Pompeia, for one), but looking through 33,393 entries for similar cases seems pointless (there is Special:WhatLinksHere/Template:tracking/headword/no lang category/lang/la, though, if you know you want to look specifically for Latin entries).

Of course, I'm not well-versed enough in Lua to write even the simplest of code, so I may not be understanding this correctly- but I figure it's worth bringing up, anyway. Thanks! Chuck Entz (talk) 01:37, 26 June 2017 (UTC)

Looking further, I notice that there are 53,191 entries in Category:Serbo-Croatian lemmas, so a simple language-name explanation (literally) doesn't add up. After a quick look through the tracking category, I notice that there don't seem to be any verb or adjective endings- perhaps it has something to do with the code for nouns in function export.noun of Module:sh-headword? There seem to be a good number of Esperanto terms in the tracking category, as well, as well. Chuck Entz (talk) 02:26, 26 June 2017 (UTC)
For some reason, the category name Serbo-Croatian lemmas doesn't get processed by the code mentioned above. In adsorpcija, the category name that put the entry in Category:head tracking/no lang category was Serbo-Croatian feminine nouns, not Serbo-Croatian lemmas. (I printed out the offending category name in the Lua log.) So perhaps only the S-C entries that have categories besides the lemma category ended up being put in the tracking category, or categories besides the lemma and basic part-of-speech category. — Eru·tuon 03:30, 26 June 2017 (UTC)
I think you're right that the problem was due to the minus-hyphens in the language names. I pattern-escaped the language name, then tested the entry adsorpcija; this removed it from the category. — Eru·tuon 03:22, 26 June 2017 (UTC)
I took a look at abateco, an Esperanto noun. It was in the tracking category because the Esperanto headword module Module:eo-headword put the category Category:Missing Esperanto noun forms into the table of categories supplied to Module:headword. I solved that problem by having Module:eo-headword put that category in a separate table. That should begin emptying Esperanto entries from the tracking category. — Eru·tuon 05:05, 26 June 2017 (UTC)

Misspelling kinda[edit]

Hello! In many languages I've found words that haven't been misspelled but rather missconjugated. In Swedish the verbs skära and bära are both strong verbs but many wrongly conjugate them as weak ones hence skärde, skärt, skärd, skärda, bärde, bärt, bärd and bärda. Is there a template for missconjugations? If there isn't one I think it would be good to have one since a misspelling isn't really what it is. I see that most English examples (fighted, swimmed, shooted) seem to have just been labeled (nonstandard) as if it isn't incorrect, just not as common. Should the Swedish verb forms also be labeled (nonstandard) or what does the guidelines say?Jonteemil (talk) 02:00, 26 June 2017 (UTC)

nonstandard is for terms that are generally considered incorrect: “Not conforming to the language as accepted by the majority of its speakers.” — Ungoliant (falai) 03:33, 26 June 2017 (UTC)

Template:RQ:King James Version[edit]

Could somebody please fix this template? It was broken after Template:RQ:Authorized Version was redirected here. See for example Nathan. There is no advice on how to write biblical books that contain numbers (2 Samuel, 2-Samuel, whatever)? Also the links don't work, or link to the wrong place and ":" after the old template produces an empty line. A user complained in March 2016 on the template talk page but nothing has been done.--Makaokalani (talk) 13:57, 28 June 2017 (UTC) Pinging @Smuconlaw. --Makaokalani (talk) 14:12, 6 July 2017 (UTC)

Actually, it was broken before I redirected the template; I never noticed that the problem mentioned on the template talk page in 2016 hadn't been fixed. Anyway, I think I've fixed the template now – try it out. — SGconlaw (talk) 17:24, 13 July 2017 (UTC)

July 2017

Puzzling error in template[edit]

{{itc-conj-3rd}} displays the 3pl pres. subj. pass. as *-ām(e?)n(ai?), like the 2pl, instead of as the correct *-āntor. However, looking at the source code, I can't figure out what's going wrong. --Florian Blaschke (talk) 23:17, 2 July 2017 (UTC)

Fixed, I think. --Barytonesis (talk) 23:24, 2 July 2017 (UTC)
Thank you, that seems to have done the trick! I should have looked at the beginning of the code, realised that the template is calling another template and looked there! D'oh. --Florian Blaschke (talk) 00:45, 5 July 2017 (UTC)
It's common for inflection tables to be made of two pieces, one to show the table, and another to provide the contents. —CodeCat 00:48, 5 July 2017 (UTC)

Request for CSS help[edit]

Can anyone come up with a CSS rule that allows content in <hiero> tags to be displayed inline? The tag generates a table that can be wrapped with a div element. The rule needs to allow the table to be on a line with preceding and following content and not affect subsequent lines. DTLHS (talk) 00:08, 4 July 2017 (UTC)

Isn't it already inline? Like
Sn
n M1
this. —suzukaze (tc) 00:54, 4 July 2017 (UTC)
I wonder how do you get it inline. All other wikis I tested do not display it inline. --Vriullop (talk) 10:42, 15 July 2017 (UTC)
I'd like to also be able to control the image sizes. DTLHS (talk) 00:55, 4 July 2017 (UTC)

Below is the thing that isn't displaying inline. I'm experimenting with it at the moment. — Eru·tuon 03:32, 4 July 2017 (UTC)

Egyptian:
V17 w A3

 f (zꜣw)

1. I looked into the image sizes and I don't think it's possible with CSS. Maybe with JavaScript, by manually changing image dimension attributes.
2. <div>s are not inline by nature; you have to tell them to be inline!
Egyptian:
V17 w A3
 f (zꜣw)
(Without the <div> on the outside, it seems like the MediaWiki software puts "f (zꜣw)" in its own <p>.) —suzukaze (tc) 03:53, 4 July 2017 (UTC)

An additional problem is hiero included in head template. Appart from the need of solving hiero line breaks, for example the gender in ꜥwꜣy, the page appears in Special:LintErrors/misnested-tag, see link https://en.wiktionary.org/w/index.php?title=%EA%9C%A5w%EA%9C%A3y&action=edit&lintid=634632. The misnested tag is strong tag surrounding headword with a hiero table. --Vriullop (talk) 10:13, 15 July 2017 (UTC)

Passing sortkey generation to a dedicated sorting function (recorded in Module:languages/data2)[edit]

for languages with difficult scripts (e.g. Tibetan, Chinese, etc.) - could this be implemented? Wyang (talk) 22:30, 4 July 2017 (UTC)

How large are the sortkey functions going to be? Is this going to increase the number of pages that run out of memory? DTLHS (talk) 22:37, 4 July 2017 (UTC)
The Tibetan one will be like Module:bo-translit, and the Chinese one Module:zh-cat. Wyang (talk) 22:39, 4 July 2017 (UTC)
It might not be a problem at the moment, because the pages running out of memory tend to be titled with Latin script, and the sortkey functions will probably be running on pages with non-Latin scripts. — Eru·tuon 23:30, 4 July 2017 (UTC)
We've had some Chinese entries running out too. —CodeCat 13:38, 6 July 2017 (UTC)
The harm is minimal compared to the benefit of having properly sorted entries in all the categories of that language. At the moment Category:Tibetan lemmas is basically unusable. I might write Module:bo-sort etc. soon. Wyang (talk) 02:18, 7 July 2017 (UTC)
Only hanzi entries have been running out. I think that those could benefit from DEFAULTSORT implemented inside {{Han char}} or something, using the radical sort (魚02). —suzukaze (tc) 02:30, 7 July 2017 (UTC)
@Wyang: Since I've just made it possible for Module:languages to use a sortkey-generating module for Vietnamese, the same can be done for Tibetan, Chinese, and other languages. I am sure it will increase the memory load, but having entries properly sorted is worth it.
I also like @Suzukaze-c's idea of using a default sortkey. When I had Module:vi-sortkey log the entry title and the resulting sortkey, I saw multiple entries in the Lua log and realized that the module was running several times in a given entry. That's wasteful. (I don't know if it increases memory usage, but it would definitely increase processing time.) If the module can run just once, that would be great. Obviously, in entries with titles in Latin script with diacritics and with several different languages on the page, that isn't possible, but maybe it is with Tibetan, Chinese, and other scripts. — Eru·tuon 06:00, 23 July 2017 (UTC)
Thank you! Wyang (talk) 06:06, 23 July 2017 (UTC)

Clipping of a foreign word[edit]

See maître d'#Etymology. Is there any way to get the word "French" deitalicized, or is there a better way to use both {{clipping}} and {{der}} to show that this is a clipping of a foreign word? We don't have an English entry for maître d'hôtel, so I'm not sure the unclipped form is used in English. —Aɴɢʀ (talk) 10:29, 6 July 2017 (UTC)

Fixed. Wyang (talk) 10:34, 6 July 2017 (UTC)
Thanks! —Aɴɢʀ (talk) 16:53, 6 July 2017 (UTC)

Module:links[edit]

Could someone please add a restriction to Module:links (mw.title.getCurrentTitle().nsText ~= "Category") so that Category:Terms with manual transliterations different from the automated ones is not flooded by Arabic root categories? Thanks. Wyang (talk) 10:29, 6 July 2017 (UTC)

Done. DTLHS (talk) 18:11, 6 July 2017 (UTC)
Thanks. Wyang (talk) 23:07, 6 July 2017 (UTC)

Cantons of Luxembourg category[edit]

Would somebody be able to create the categories Category:en:Cantons of Luxembourg and Category:lb:Cantons of Luxembourg please? I've created entries for all twelve of the cantons in both languages, so it would make sense to categorise them as such. I tried making the category pages using {{topic cat}} (based on Category:en:Cantons of Switzerland) but got an error. Thanks, BigDom 18:09, 6 July 2017 (UTC)

Done. DTLHS (talk) 18:12, 6 July 2017 (UTC)
Thanks. BigDom 18:36, 6 July 2017 (UTC)

Search oddity[edit]

Why doesn't "hordeic acid" show up on the first page of search results for "hordeic"? It seems more relevant than the suggested horde etc. Equinox 18:26, 6 July 2017 (UTC)

Another example: a search for "graphity" doesn't find "quantum graphity" on the first page, but does find many far less relevant entries. Equinox 20:20, 12 July 2017 (UTC)
I agree. Additionally, when you press enter in the search box on the search page, it defaults to the first suggestion, rather than to what you typed in the box. That shouldn't happen unless you've explicitly selected something. --WikiTiki89 21:01, 12 July 2017 (UTC)
I raised this on Wikipedia (same search engine, same behaviour) and was pointed to Help:Searching#Stemming. It is necessary to place a search term in quotation marks to prioritise exact matches. I don't think this is ideal for us. Equinox 13:46, 13 July 2017 (UTC)
I wonder if Cirrus search can be tuned locally to change that behavior, I am guessing it would require an extension. You are right that this is not optimal for our project. - [The]DaveRoss 17:15, 13 July 2017 (UTC)
I have a different complaint: when searching the transliteration of a Russian word, I usually get everything except the lemma that has that transliteration. For instance, when searching "ruka russian", I get the nominative plural руки (ruki) as the first result, several other inflected forms, and some other entries that mention рука́ (ruká), but not рука́ itself. It's quite bizarre. Ideally, рука́ (ruká) would appear as the first result when searching "ruka russian", or at least before all of its inflected forms. I'm not sure if that's possible to program into the search engine, though. — Eru·tuon 18:44, 13 July 2017 (UTC)
I share Equinox's and Wikitiki's specific objections. Wikitiki's problem bothers me more. I have learned to put MWEs in between quotation marks by default. DCDuring (talk) 21:39, 13 July 2017 (UTC)
Cirrus Search is very highly configurable. You should file a Phabricator task and see if they can adjust the algorithm for this site. The search team is usually pretty responsive to such requests. This, that and the other (talk) 22:10, 13 July 2017 (UTC)

Script classes on automatically generated category pages[edit]

Up till now, categories that are created by category boilerplate templates would not have script classes applied to their links. Now it is possible, if you add a language code and script code to the table in Module:utilities/data. Hypothetically, this could be moved to the language data modules, but that would make it harder for people to edit.

I created this capability because I was frustrated that categories like Requests for etymologies in Ancient Greek entries weren't displaying with my preferred Ancient Greek font.

I considered simply having the catfix pick the first script for the language, but that would create problems for languages like Serbo-Croatian that are commonly written in two scripts. — Eru·tuon 21:16, 6 July 2017 (UTC)

I also added a display title to page titles in affix categories: so, for instance, the title of Category:Ancient Greek words prefixed with εὐ- displays as Category:Ancient Greek words prefixed with εὐ-, and that of Category:Proto-Indo-European words suffixed with *-sḱéti displays as Category:Proto-Indo-European words suffixed with *-sḱéti.

This is a natural extension of the earlier change, discussed at Wiktionary:Grease pit/2017/May § Display of vertically written languages (Mongolian, Manchu) and Wiktionary:Grease pit/2017/May § Apply a font to cuneiform page titles, in which script tagging was added to some entry titles using Module:headword. — Eru·tuon 05:14, 9 July 2017 (UTC)

Linking of individual words in the headword line[edit]

Usually when a headword consists of multiple words, each one is automatically linked in the headword line, e.g. at ethnic cleansing, ethnic and cleansing are linked separately without {{en-noun}} explicitly doing so. However, {{de-noun}} appears not to do that: at ethnische Säuberung the two words are not linked separately. Of course I could go in and add |head=[[ethnische]] [[Säuberung]] to force it, but I'd rather it did it automatically. Can someone please edit Module:de-headword to fix this behavior? Thanks. —Aɴɢʀ (talk) 09:31, 7 July 2017 (UTC)

Fixed. Module:de-headword was coded to use the page name as the default headword, instead of leaving it empty so that Module:headword could generate its own. —CodeCat 15:27, 7 July 2017 (UTC)
@CodeCat: Your fix just broke all the templates that use |head=. —JohnC5 17:24, 7 July 2017 (UTC)
I just removed the default headword, which seems to fix the problem. — Eru·tuon 18:06, 7 July 2017 (UTC)

Extend mention template to include language name display?[edit]

Can we extend {{mention}}, or provide a new template with this functionality, that allows you to easily mention a word with the name of the language displayed, as {{inherited}} and others do? Sometimes it would be handy to be able to write {{x|vi|gà}} and get "Vietnamese ". There could be a parameter, or an additional template, that suppresses/omits the link to the language article on Wikipedia. --Florian Blaschke (talk) 06:20, 8 July 2017 (UTC)

{{cog|vi|gà}} = Vietnamese --Daniel Carrero (talk) 06:21, 8 July 2017 (UTC)
I know, but {{cog}} has a specific purpose (displaying cognates) and behaviour (adding categories, IIRC, like {{etyl}} does?). I'd like something I can use anywhere. --Florian Blaschke (talk) 06:25, 8 July 2017 (UTC)
OK, I just saw it doesn't add categories, so it technically works as the desired all-purpose mention-plus-language-name template, but it still feels like a kludgy misuse to use {{cog}} when you merely want to mention a word without implying anything about cognacy. --Florian Blaschke (talk) 06:31, 8 July 2017 (UTC)
@Benwing2 created {{noncog}} for this purpose. It is currently exactly the same as {{cog}} in the Lua functions it uses and the output it yields, but has a different name. (I would like a different, more intuitive name, but don't have any good ideas. Either that or a parameter could be added to {{m}} to display the language name, but people might object to that and it might add Lua memory on the high-memory pages.) — Eru·tuon 06:38, 8 July 2017 (UTC)
Please do not use cog directly if the context does not expect a cognate word. What's the context you want to use cog?--Dixtosa (talk) 06:40, 8 July 2017 (UTC)
That's the point, I do not want to use cog when the context doesn't fit. @Erutuon, Benwing2: Thanks! How about "ml" ("mention with language name")? Whatever its name, {{noncog}} could definitely use a parameter that suppresses the Wikipedia link. --Florian Blaschke (talk) 10:06, 11 July 2017 (UTC)
Doesn't {{borrowing}} do what's requested? If not, couldn't a similarly constructed template do what's being asked and categorize appropriately? DCDuring (talk) 12:05, 11 July 2017 (UTC)
I don't know if I like the name {{ml}}, but I can create a module function that does that. [Edit: Done.] — Eru·tuon 22:45, 11 July 2017 (UTC)
I created {{langname-mention}}. It's a long name, but you can create {{ml}}, or something else, as a redirect if you want. By default, Wikipedia linking is turned off. This behavior can be reversed if desired, but I'm not sure what the parameter to turn off Wikipedia linking should be: |nowiki=1 would be confusing. — Eru·tuon 23:18, 11 July 2017 (UTC)
Thank you! How about |nowplink=1? That said, I think making the default behaviour no link is good, because the languages in mentioned words are typically not that obscure, or are proto-languages without dedicated Wikipedia articles.
{{langname-mention}} is really a long name and neutralises the point of the template. If you have reservations about {{ml}}, can you think of any better name? Or anyone else? By the way, are one-letter template shortcuts reserved in any way? If I went on to create {{x}}, {{y}} or anything like that, would anyone mind? Oh, I just saw that we have {{t+}}, which makes me wonder about {{m+}} as a shortcut. What do you think of that idea? --Florian Blaschke (talk) 08:36, 12 July 2017 (UTC)
@DCDuring: The template is also or even mainly intended for discussions about words outside of articles. Sometimes you can also use this is etymology sections, however, for example when mentioning a parallel example for a semantic change, where there is no formal connection at all, or when an etymological link has been suggested but is dubious or has been refuted. --Florian Blaschke (talk) 08:41, 12 July 2017 (UTC)
It seemed to me that all that is required is a different template name that uses the same engine as {{cog}}. It seems even a template-level redirect would work. If the requirements subsequently diverge, that should be easy to manage then. DCDuring (talk) 08:57, 12 July 2017 (UTC)
True. I wonder if it wouldn't make sense to fold {{cog}}, {{noncog}} and {{langname-mention}} into a single template ({{langname-mention}} sounds like the best title for it to me), with redirects to it, given that they don't seem to display significantly different behaviour (the only minor exception being that {{langname-mention}} doesn't link the language name by default, currently, but this difference is subject to revision and best handled with a parameter anyway). --Florian Blaschke (talk) 20:53, 14 July 2017 (UTC)
Or, in fact, go back to my initial suggestion to let {{mention}} handle it all by introducing |langname=1 and |Wikipedia=1 parameters, with {{cog}}, {{noncog}} and {{m+}} all redirects to {{mention}} with langname set to display the name. --Florian Blaschke (talk) 21:01, 14 July 2017 (UTC)
{{cog}} and {{noncog}} add class="etyl" to the language name. I'm not sure the purpose of that, but it is probably unnecessary on talk pages. Hence, to merge these two templates with the new one, we either have to remove this class from the two templates or remove it from the new one.
On the whole, I'm hesitant to remove the template {{cog}}, because it is potentially useful to have cognates be formatted with a different template: we can add CSS classes to distinguish cognates from other words mentioned in etymologies, add categories for words that have a certain word mentioned as cognate, add categories for words that have a cognate in a given language, or whatever else. If the templates are merged, no special treatment of cognates is possible. However, I'd be fine with merging {{noncog}} into {{langname-mention}}. — Eru·tuon 17:02, 15 July 2017 (UTC)
It would help to know what the original purpose of class="etyl" is. I agree that it's unnecessary for plain mentions, whether on talk pages or in etymology sections. I don't know for sure if it's a good idea, because I'm not a tech wiz, but to me merging {{noncog}} into {{langname-mention}} sounds sensible. What do you think about {{m+}} as a shortcut? --Florian Blaschke (talk) 11:33, 20 July 2017 (UTC)
OK, I've created the redirect. Test: Vietnamese , Proto-Indo-European *ḱwṓ. Excellent! --Florian Blaschke (talk) 10:38, 21 July 2017 (UTC)
That redirect should be fine. If someone wants to create a different augmented version of {{m}}, it will have to have a different name. — Eru·tuon 17:21, 21 July 2017 (UTC)

Can someone please add "Arab" as a script for xqa in Module:languages/data3/x (اِكّٖى)[edit]

Wyang (talk) 08:59, 9 July 2017 (UTC)

Yes check.svg DoneEru·tuon 10:09, 9 July 2017 (UTC)

Issues with {{lang|ar}} and rtl formatting[edit]

If I understand properly {{lang}} is supposed to correct for all script formatting issues but I'm noticing some problems in mobile safari (iOS) using Arabic.

  1. In desktop view it seems to do everything right except that characters are rendered in independent form. So for example فعل would appear as ف‌ع‌ل which is annoying.
  2. In mobile view it doesn't have this problem but it fails to set the whole block to rtl. So for example مرحبا.‏ appears as مرحبا‎. with the period on the wrong side.

I'm also wondering if it makes sense to add these non-printing bidi control characters to the special character menus for rtl scripts (which shouldn't really be necessary if {{lang}} is working). On a somewhat unrelated note does anyone know if there's a way to user sandbox a template or how should one go about testing templates? Radixcc 📞 17:43, 9 July 2017 (UTC)

(edit conflict) The text directionality markers can be added automatically by Module:script utilities (which creates the content for {{lang}}, and is used by other templates that output text in a specific language, such as {{m}}, {{l}} and {{ux}}). I had the module do this at one point, but then undid my change because I thought it wasn't necessary. I can add that feature again, if it would help to make right-to-left scripts display correctly in mobile view. — Eru·tuon 17:47, 9 July 2017 (UTC)
Okay, I've done that. Could you check again and see if the display problem remains? — Eru·tuon 18:11, 9 July 2017 (UTC)
Unfortunately it still looks the same to me. Here's what I get [3]
Radixcc 📞 19:44, 9 July 2017 (UTC)
That's weird. You put the &rlm; at the end and it displays correctly for you, and I put it at the beginning because I thought it had to go before the right-to-left text. I must be understanding how the right-to-left mark works. — Eru·tuon 20:03, 9 July 2017 (UTC)
There are two ways to do it and they use different characters. The RLM (right to left mark) is just an invisible RTL character. If you are in LTR mode as is usual with English and you have a sequence like (R = RTL, L = LTR type characters) R3R2R1 then you type a L1 and end there, you end up with R3R2R1L1. But if you then type a R4, the L1 is now surrounded on both sides by R characters which pushes it into the RTL subsequence. So you then get R4L1R3R2R1. So for example you can force the correct sequence by adding another random R character like مرحبا.ء but you don't really want that extra ء to display so you replace it with the the &rlm; which is an RTL character but doesn't display.
The other way to do (which I think you were trying to do) it is to use the RLE character which actually switches the span directionality to RTL until a PDF character is encountered which restores the previous bidi mode. Basically the "mark" characters dont switch the bidi mode, but the "embedding" characters do. — Radixcc 📞 21:13, 9 July 2017 (UTC)
Ahh, thanks for the explanation. That makes it much more clear to me what the right-to-left mark actually is. And yes, the RLE and PDF characters sound like what I thought the RLM and LRM were. — Eru·tuon 21:19, 9 July 2017 (UTC)
(edit conflict) @Radixcc: Okay, I've added a final right-to-left mark after a final punctuation mark (if there is one). That should give the same result as the version that displayed correctly in your sandbox. — Eru·tuon 21:16, 9 July 2017 (UTC)
Ok that does seem to work. After digging around a bit though it seems like the more correct HTMLish thing to do might be to enclose everything in the template output in <span dir="rtl" /> or something with a CSS style of "direction: rtl;" but in practice the main problem seems to be with final punctuation marks (mostly . and !) so the final RLM will probably solve most cases. Maybe this is already done for the desktop view but I haven't gotten on to a real computer to look at the HTML.... Anyway, thanks! — Radixcc 📞 22:03, 9 July 2017 (UTC)
@Radixcc: The CSS style direction: rtl; is added to all right-to-left scripts by MediaWiki:Common.css, but unfortunately this stylesheet is not used in the mobile version of the site. So far, nothing has been done to fix that. — Eru·tuon 22:06, 9 July 2017 (UTC)
@Erutuon: Ok started talk page asking if I could go ahead and do this. MediaWiki talk:Mobile.cssRadixcc 📞 01:39, 10 July 2017 (UTC)

Sessions Not Persisting[edit]

My enwiktionarySession cookie is set to expire as soon as I've logged in, so every request after logging is only performed as a guest user. --173.226.71.162 14:56, 10 July 2017 (UTC)

It is weird and I do not know the cause but anyways, try these:
  1. update your browser
  2. change startup behaviour on the browser to "Continue where you left off"
  3. use Google Chrome.
Are you getting logged out immediately from other projects like Wikipedia too? --Dixtosa (talk) 16:11, 10 July 2017 (UTC)
Have you actually inspected the cookies to see when they are set to expire, or are you describing the effect? Are you on Firefox and do you use many Wikimedia sites on a regular basis? - [The]DaveRoss 17:32, 10 July 2017 (UTC)

CAT:E[edit]

{{lb}} (Module:labels) broke I think. —Aryaman (मुझसे बात करो) 17:13, 10 July 2017 (UTC)

@ErutuonAryaman (मुझसे बात करो) 17:15, 10 July 2017 (UTC)
Symptom: glosses are showing as red text: "Lua error in Module:labels at line 152: attempt to concatenate field 'display' (a nil value)". Equinox 17:17, 10 July 2017 (UTC)
I reverted my edit, then repaired it. The module errors should begin disappearing. I really need a test page for Module:labels.... — Eru·tuon 17:24, 10 July 2017 (UTC)

Oldest pages ordered by last edit[edit]

This box appears on category pages, but the contents in my experience are never accurate when the category contains more than ten entries. On the other hand the box containing "Recent additions to the category" is accurate in my experience. If "Oldest pages ordered by last edit" can't be rectified, can it be removed? I wouldn't mind at all if that happened. DonnanZ (talk) 12:28, 12 July 2017 (UTC)

I wouldn't mind either. --Barytonesis (talk) 21:03, 12 July 2017 (UTC)
For many categories the page is accurate. It may have to do with when the category was created or whether it is filled by operation of a template. If the display offends and is grossly inaccurate, pluck it out. I find the Translingual ones useful. DCDuring (talk) 22:18, 12 July 2017 (UTC)

Someone seems to have improved it, but one problem caused by the boxes is that they usually prevent a category page from forming two columns, unless a spacer is inserted, creating a gap which is not always desirable. DonnanZ (talk) 08:58, 13 July 2017 (UTC)

Does widening the window help? I was very happy getting a bigger (mostly wider) screen a couple of years ago. Samsung et al now sell "ultrawide" monitors, which tempt me. DCDuring (talk) 17:06, 13 July 2017 (UTC)
I have an 18.5" monitor, which I thought was big enough, but I tried reducing the zoom from 150% to 100%, and category pages then appear with two columns. The downside is that the print is too small to read comfortably - I prefer 150% zoom. Oh well, I'll have to live with it. DonnanZ (talk) 18:27, 13 July 2017 (UTC)
I have the same kind of issues. For a while, with two windows side-by-side on my ~25" monitor, in each window I could both read text and have frames that allowed for editing and display of multiple columns. I'm seriously considering the "ultrawides" now. DCDuring (talk) 20:44, 13 July 2017 (UTC)

Would it be possible to provide a show/hide facility for these boxes? It seems to be a good idea. DonnanZ (talk) 07:24, 15 July 2017 (UTC)

@Donnanz: I don't know how to make a JavaScript function to show or hide the boxes, but I could add a CSS class to the rows of the table to allow you to hide the oldest additions (or newest additions, or both) by adding code to your Special:MyPage/common.css. That would turn it off for all category pages, and you couldn't turn it on without editing your CSS page again, though. — Eru·tuon 23:08, 15 July 2017 (UTC)
@Erutuon: Don't worry if it's too difficult, I thought something like that used for derived terms templates could be used. DonnanZ (talk) 06:27, 16 July 2017 (UTC)

Sorting of "Oldest pages" seems to have gone haywire again, it's definitely not stable. DonnanZ (talk) 23:14, 23 July 2017 (UTC)

Broken table[edit]

This didn't work properly; the boxes aren't aligned. Could someone fix it? --Barytonesis (talk) 21:21, 12 July 2017 (UTC)

Yes check.svg DoneEru·tuon 21:29, 12 July 2017 (UTC)

"Terms with IPA pronunciation" categories being subcategories of entry maintenance categories[edit]

What's the rationale for this? Should it be changed? Wyang (talk) 01:28, 13 July 2017 (UTC)

I think it should probably be changed. Same with Category:English terms with usage examples. --Daniel Carrero (talk) 01:34, 13 July 2017 (UTC)
I was wondering about this myself just the other day! :) I agree it should probably be changed, because these seem like "user-facing" categories, for readers to use, not internal maintenance categories. The pronunciation categories could go in Category:Terms by phonemic property by language, maybe? Or its parent, Category:Terms by lexical property subcategories by language? I don't know. - -sche (discuss) 01:59, 13 July 2017 (UTC)
It is a maintenance category, it has nothing to do with phonemic properties or lexical properties. A Wiktionary entry having an IPA transcription is not a property of a word, it's a property of the entry itself. —CodeCat 12:01, 13 July 2017 (UTC)
But why is it a maintenance category? Maintenance categories keep entries that require some sort of cleanup. It would make more sense to have a category for pronounceable entries that don't an IPA pronunciation. Why do we need to categorize entries that do have an IPA pronunciation at all? —Aɴɢʀ (talk) 13:47, 13 July 2017 (UTC)
Maintenance entries aren't just for cleanup, but for all maintenance. This particular category maintains a list of entries that have IPA. —CodeCat 15:40, 13 July 2017 (UTC)
maintenance: "Actions performed to keep some machine or system functioning or in service". If no action needs to be performed to keep Wiktionary functioning or in service, no maintenance (and thus no maintenance category) is required. —Aɴɢʀ (talk) 15:56, 13 July 2017 (UTC)
As I implied above, I agree that the IPA categories are not about maintenance. When Wiktionary is "done" (which would be never, apparently), all true maintenance categories will be empty, and all the pronunciable entries will be in the "entries with IPA pronunciation" categories, which will basically become redundant to a list of all entries of each language. --Daniel Carrero (talk) 16:22, 13 July 2017 (UTC)
Exactly. The IPA category is a list of all entries that already have IPA, thus leaving the remainder as those that need IPA. —CodeCat 16:29, 13 July 2017 (UTC)
But if the whole idea is finding the entries that lack IPA, you won't find them just by navigating the category. Wouldn't you have to use some external tool to do it? And can't you parse dumps or something to do it without the category?
Also, if an entry only has IPA marked for one specific country or dialect, it would probably need IPA for the other countries or dialects. So the set of entries having IPA intersects with the set of entries needing IPA. --Daniel Carrero (talk) 19:10, 13 July 2017 (UTC)
I also think that both these categories (IPA pronunciation and usage examples) don't really make sense in "entry maintenance". I mean, what maintenance needs to be done with those entries because they have IPA? I think we should have a separate umbrella category for categories for entries that contain a particular type of information: "Entries by the type of information they contain"? — Eru·tuon 17:11, 13 July 2017 (UTC)

Bot request: "bor" template[edit]

The proposal 1 of Wiktionary:Votes/2017-06/borrowing, borrowed passed.

It is about the template {{bor}} ({{borrowed}}, {{borrowing}}, {{loan}}, {{loanword}})

What is the best way to implement that project? I suppose a bot can't do everything, but perhaps it can do at least this:

  1. If the etymology section contains only "{{bor|xx|yy|word}}." (with or without a dot in the end), change it into "Borrowed from {{bor|xx|yy|word|notext=1}}."
  2. Change all other instances of "{{bor|xx|yy|word}}" into "Borrowing from {{bor|xx|yy|pizza|notext=1}}"
  3. Change all instances of "{{bor|xx|yy|word|nocap=1}}" into "borrowing from {{bor|xx|yy|pizza|notext=1}}"
  4. All entries with "borrowing" that can't be edited by bot may have to be edited manually to change it to "borrowed" or whatever makes sense in the entry.
  5. Naturally, don't touch any entries that already have "notext".
  6. After all instances of bor use "notext", the template/module can be edited to remove the default text altogether, and the "notext" can be removed from all instances of {{bor}}.

Feel free to use these categories to navigate the entries.

--Daniel Carrero (talk) 01:02, 14 July 2017 (UTC)

I am about to leave on vacation, but if nobody has taken care of this in a week or so I can probably work on it. - [The]DaveRoss 02:18, 15 July 2017 (UTC)
I would propose doing step 1 first, and then re-evaluating what is left. In particular, I'm not sure if step 2 is necessary. —CodeCat 18:01, 21 July 2017 (UTC)
I would be fine with that. --Daniel Carrero (talk) 10:36, 23 July 2017 (UTC)

Changes to affix categories[edit]

Yesterday, I modified the structure and breadcrumbs of the affix categories. I shortened the breadcrumbs that are redundant, and added intermediate breadcrumbs. The overall layout is affix » POS or affix » affix (ID) » POS. (Here POS is shorthand for a part of speech that is not the default "words". For an example, see below.)

As for category structure, I've put non-"words" POSes under the corresponding "words" category, and non-"words" POSes that have an ID under the corresponding category without the id. (The latter is not reflected in the breadcrumbs.)

category breadcrumbs
earlier version current version
Category:English words suffixed with -er Words by suffix » Words suffixed with -er Words by suffix » -er
Category:English words suffixed with -er (action noun) Words by suffix » Words suffixed with -er (action noun) Words by suffix » -er » -er (action noun)
Category:English adjectives suffixed with -en Words by suffix » Adjectives suffixed with -en Words by suffix » -en » Adjectives
Category:English adjectives suffixed with -en (made of) Words by suffix » Adjectives suffixed with -en (made of) Words by suffix » -en » -en (made of) » Adjectives

I think this structure makes more sense. If there are widespread objections, my edit can be reverted. — Eru·tuon 22:49, 14 July 2017 (UTC)

Italics vs plain text as contrast in CSS[edit]

Taxonomic names are supposed to contrast with the surrounding text in the sense that, if the matirx text is plain, then the taxon should appear in italics and, if the matrix text is italic, then the taxon should appear plain. Many of our templates seem to have formatting that overrides any plain wikiformatting that I can apply to conform to the standard. I have guessed that it is the use of CSS that has this result. How can I force the formatting taxons are supposed to have, preferably without having to use ad hoc CSS or set a parameter in a template each time. Even worse, arbitrary "tidying" of the various templates may force revisiting each instance or class of instances of correct taxon formatting. DCDuring (talk) 14:35, 15 July 2017 (UTC)

It is apparently possible to do this with the not: property ([4]) DTLHS (talk) 15:58, 15 July 2017 (UTC)
Thanks. I'll be getting into those out-of-my-depth waters shortly. DCDuring (talk) 17:07, 15 July 2017 (UTC)

Bot request: null edits in ~12,000 categories[edit]

Can someone please do null edits in the ~12,000 categories listed in Category:Pages with module errors?

Apparently they had some problem that someone already fixed. --Daniel Carrero (talk) 07:38, 17 July 2017 (UTC)

Running. --Thibaut120094 (talk) 09:28, 17 July 2017 (UTC)
And done. --Thibaut120094 (talk) 16:06, 17 July 2017 (UTC)

Search problem[edit]

I'm trying to find all pages which end with the character ά. But when I search intitle:*ά, I only get a few pages, not all of which end in ά. Does anyone know what I'm doing wrong? —CodeCat 18:36, 18 July 2017 (UTC)

You may be hoping for more than our search can deliver. I don't think that "*ά" is supported, though "ά*" is. DCDuring (talk) 19:25, 18 July 2017 (UTC)
But that's not the whole problem. DCDuring (talk) 19:31, 18 July 2017 (UTC)
You can use User:Dixtosa/SuffixIndex to find all pages which end with the character ά. I tried and it returned 1245 results. --Daniel Carrero (talk) 19:34, 18 July 2017 (UTC)
From w:Help:Searching#Syntax: "The two wildcard characters are * and \?, and both can come in the middle or end of a word". So, Special:Search/intitle:α*ά works but it is only a partial search for endings. --Vriullop (talk) 08:21, 19 July 2017 (UTC)
@Dixtosa That tool is very nice, I only have one request: that the results actually link to the Wiktionary pages. —CodeCat 08:55, 19 July 2017 (UTC)

Frequency list[edit]

User:Rajasekhar1961 is looking for a Telugu word-frequency list. I've searched but could not find one. There is a Wikimedia page about Telugu dumps at dumps.wikimedia.org, but I can't make sense of it. Is there something on that page that User:Rajasekhar1961 could perhaps use? Is there any way to extract a frequency list from such a dump? —Stephen (Talk) 22:16, 18 July 2017 (UTC)

I could extract words from the text of the articles, if that's what you want. I don't think it would be very representative of the language as a whole though. DTLHS (talk) 22:18, 18 July 2017 (UTC)
It sounds like it would be useful. Since I could not find any Telugu frequency list, I don't think we can be choosy. —Stephen (Talk) 22:25, 18 July 2017 (UTC)
Wiktionary:Frequency lists/Telugu DTLHS (talk) 22:45, 18 July 2017 (UTC)
Thank you very much for your timely help DTLHS sir. This greatly helps me in prioritizing my work in Wiktionary.Rajasekhar1961 (talk) 12:48, 19 July 2017 (UTC)

Cannot see "show" label in expandable items[edit]

When I open a page with expandable areas, like Translations or Declension I most times don't see "show" labels.

And, when editing, in the special caracters setion I see not the combobox for choosing the sets and pressable buttons, but a full list of character sets with unpressable characters.

Both issues appear only when I'm logged in. --Wanjuscha (talk) 11:45, 19 July 2017 (UTC)

Seems like the maddening, intermittent, recurring problem of not all of the Javascripts being run completely. I've not heard of a definitive solution. DCDuring (talk) 19:22, 19 July 2017 (UTC)
That often happens to me, though it's become less common (except when I press the back button to go to a page with expandable content). — Eru·tuon 19:25, 19 July 2017 (UTC)
I think this is a problem that relates to Wikimedia software updates, your Operating System updates, and your browser updates. Are you using the Firefox browser? If yes, you should try this: Look at the top of your screen and you should see the symbol Ξ, which opens your Firefox menu. Click on that, then click on OPTIONS, PRIVACY, HISTORY, "USE CUSTOM SETTINGS FOR HISTORY", and under "ACCEPT COOKIES FROM SITES", click "KEEP UNTIL" and change it to "I CLOSE FIREFOX". Close Firefox and restart it. Note: this will delete your cookies and you will have to log onto the sites again that you use, such as Wikipedia, Youtube, etc. The next time that you turn your computer off and then reboot, you can return to Ξ and change "I CLOSE FIREFOX" back to "THEY EXPIRE". This should fix your problem. —Stephen (Talk) 19:29, 19 July 2017 (UTC)
I did so. No use. --Wanjuscha (talk) 21:46, 21 July 2017 (UTC)
There is one other thing that I can think of. Recently I started having problems again, and deleting my cookies did not help. I have always used the MONOBOOK skin (PREFERENCES, APPEARANCE, SKIN), so I changed to the VECTOR skin. That fixed my problems. —Stephen (Talk) 12:14, 22 July 2017 (UTC)
I still get the problem in Vector sometimes. Underlying problem might be too much reliance on JS that is not professionally written. DCDuring (talk) 18:12, 22 July 2017 (UTC)

This action has been automatically identified as harmful, and therefore disallowed.[edit]

I got this message: "This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: JSky". What exactly happens here? What rule did I abuse? What is JSky? ばかFumikotalk 07:32, 20 July 2017 (UTC)

It looks like User:Chuck Entz is working on a way to counteract this guy, but something went wrong. —suzukaze (tc) 07:35, 20 July 2017 (UTC)

Importantion of categories to Wikidata[edit]

Dear Wiktionarians,

I am importing some 10000 categories from Wiktionary to Wikidata. Just a heads up! [[User:PokestarFan|<font face="Tahoma" color="purple">PokestarFan</font>]] [[User Talk:PokestarFan|<font face="Tahoma" color="blue">(talk)</font>]] [[Special:Contributions/PokestarFan|<font face="Tahoma" color="green">(My Contribs)</font>]] (talk) 21:21, 22 July 2017 (UTC)

For what purpose? DTLHS (talk) 21:23, 22 July 2017 (UTC)
@DTLHS: The goal of Wikidata is to provide data on everything. Categories are included as part of that data. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 21:40, 22 July 2017 (UTC)
That's not an answer. Will we be able to use this for category interwikis? We have way more than 10,000 categories, so which categories are being imported? DTLHS (talk) 21:44, 22 July 2017 (UTC)
@DTLHS:Yes, that is exactly why categories are imported. I plan to import every single category into Wikidata. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:20, 22 July 2017 (UTC)
Could you clarify what importing categories to Wikidata means? — Eru·tuon 21:25, 22 July 2017 (UTC)
@Eruton: It means making an item for every page in wiktionary that is a category (in the category namespace). PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 21:40, 22 July 2017 (UTC)
@PokestarFan: Ahh! Is that related to adding interwikis for categories? — Eru·tuon 23:35, 22 July 2017 (UTC)
Didn't we already do that a month or so ago? —CodeCat 10:40, 23 July 2017 (UTC)
@CodeCat: Well it wasn't throughly done yet. I still have like several tens of thousands of categories. This is only step 1, with categories. Step 2 with all words will begin at a later date. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 13:09, 24 July 2017 (UTC)
I don't really know what you mean by "Step 2 with all words", but it sounds like the distasteful Wikidata plan that does not have consensus around here... —Μετάknowledgediscuss/deeds 13:16, 24 July 2017 (UTC)
I don't think it matters what we think of how Wikidata is using "our" data, because it isn't ours. OTOH, we don't have to use "their" data until it is clearly advantageous to this project and we can use it however we want. DCDuring (talk) 14:10, 24 July 2017 (UTC)
Well, we want them to use our data in such a way that it is mutually beneficial, rather than competitive. —Μετάknowledgediscuss/deeds 14:37, 24 July 2017 (UTC)
A month ago it was ready. Since then bots are moving interwiki links to Wikidata. See among others Special:Contributions/JAnDbot and d:Special:Contributions/JAnDbot. Not sure how many links may still remain. Users, like myself, have been resolving interwiki conflitcs, merging Wikidata items and adding missing links. It is not really done at all. --Vriullop (talk) 16:19, 24 July 2017 (UTC)

Proto-Tani[edit]

Could an admin add sit-tan-pro, Proto-Tani, to MOD:languages? It is the reconstructed ancestor of the Cat:Tani languages. —Aryaman (मुझसे बात करो) 21:58, 23 July 2017 (UTC)

Yes check.svg Done. Also adding Proto-Tani as ancestor of those Tani languages that don't already have an ancestor. — Eru·tuon 22:17, 23 July 2017 (UTC)
@Erutuon: Thanks! Can you add tbq-pro as an ancestor of Proto-Tani? —Aryaman (मुझसे बात करो) 02:47, 24 July 2017 (UTC)
Yes check.svg Done; I gather the canonical name should be Proto-Tibeto-Burman. — Eru·tuon 03:04, 24 July 2017 (UTC)
Facepalm. Misread the request. Moved Proto-Tani to the Tibeto-Burman family. — Eru·tuon 03:55, 24 July 2017 (UTC)

Coptic ⲉⲓ[edit]

Traditional Coptic sort order treats ⲉⲓ as equivalent to ⲓ (particularly given that ⲉⲓ in Sahidic corresponds to ⲓ in Bohairic); could an admin add

   sort_key = {
                from = {"ⲉⲓ"},
                to   = {"ⲓ"}},

(with the tabs fixed) to Coptic in Module:languages/data3/c? Thanks. — Vorziblix (talk · contribs) 23:15, 24 July 2017 (UTC)

Added. DTLHS (talk) 23:22, 24 July 2017 (UTC)
Thanks! — Vorziblix (talk · contribs) 23:26, 24 July 2017 (UTC)