Wiktionary:Grease pit/2017/April

Why is there a trailing ]] at the end of the category description? —Μετάknowledge^{discuss/deeds} 22:08, 1 April 2017 (UTC)

A typo when @Chuck Entz entered the category in Module:category tree/topic cat/data/Food and drink. — Eru·tuon 22:17, 1 April 2017 (UTC)

Thanks for fixing that. In the category modules I always copypaste another section and rewrite it, but I forgot to completely replace the wikilinked word at the end. Chuck Entz (talk) 22:27, 1 April 2017 (UTC)

I was trying to replace a post I made as an IP at WT:RFV but there was an error (my IP hadn't changed between the post and the trying). And even if I tried to add a new post instead of overwriting the old post, there came an error:

"Warning: This action has been automatically identified as harmful. Unconstructive edits will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this action to be constructive, you may submit it again to confirm it. A brief description of the abuse rule which your action matched is: probably vandalism. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit."

When I tried to submit it (cp. "you may submit it again to confirm it"), this error appeared:

"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: probably vandalism".

The same errors appeared when trying to report these errors in the Grease pit (cp. "you may report it on the Wiktionary:Grease pit") or on talk pages, which is why I created this temporary account for the single purpose of reporting these errors. -Tmp-acc-xf (talk) 22:48, 2 April 2017 (UTC)

What was the original IP address? DTLHS (talk) 22:53, 2 April 2017 (UTC)

80.133.99.90.

I also tried to post what I wanted to add, but the same errors appeared as when I tried to post as an IP.

-Tmp-acc-xf (talk) 23:00, 2 April 2017 (UTC)

It looks like one of the spam filters we have decided something in your post was "gibberish" (abuse filter 35 first line- can we make any improvements to this regex based on this example?) DTLHS (talk) 23:07, 2 April 2017 (UTC)

What is was trying to post where three links (two to archive.org) but without the http and www part, each followed by a short quote (1 or 2 sentences). While the first edition I mentioned had "Stlat-ta" another one had "Stlat-a" (two and not three t) with a slightly different text. This would have looked like this:

The edition at has:

The edition at has:

The translation at has:

This was in no way vandalism or spam. In the end I tried to summarize my post with this: "Looks like Paul. ex Fest. doesn't use the word.".
One of the quotes contained multiple dots which might stand for unreadable text, which I quoted with 5 dots following each other. -Tmp-acc-xf (talk) 23:25, 2 April 2017 (UTC)

It's ok, you don't need to justify yourself. This is just a spam filter that got triggered by something in your post. That doesn't mean that your post was actually spam, just that the filter had a false positive. —CodeCat 00:17, 3 April 2017 (UTC)

The layout of nav links that appear on monthly discussion pages has changed recently. I think the previous layout was more compact and I want it back. Am I the only one? --Dixtosa (talk) 19:31, 4 April 2017 (UTC)

Are these the changes? I don't mind them so much, but it might be nice to get them back to two lines tops... - TheDaveRoss 19:35, 4 April 2017 (UTC)

I also think it was fine before. —suzukaze (t・c) 23:20, 5 April 2017 (UTC)

I have reverted the changes. --Dixtosa (talk) 07:57, 9 April 2017 (UTC)

Oh, I didn't notice this post. Huh. I had changed it because it didn't display well for me: the time navigation part was squished up over two lines next to the list of discussion rooms. It was probably related to my screen size. It looks okay on a different screen and browser, though I did like the other layout better. — Eru·tuon 08:47, 9 April 2017 (UTC)

Screenshot showing what I was trying to correct. — Eru·tuon 08:53, 9 April 2017 (UTC)

@Erutuon I added CSS so that each line wouldn't break, is it better now? —suzukaze (t・c) 08:56, 9 April 2017 (UTC)

@Suzukaze-c: Oh yeah, that looks better. I liked the other way, but I can live with it now. Thanks. — Eru·tuon 11:01, 9 April 2017 (UTC)

It seems like we might have a bunch of redlink audio files now since they were renamed on Commons from .ogg to .opus: diff, . (@Yair rand) —suzukaze (t・c) 03:39, 5 April 2017 (UTC)

They kept the old .ogg files as a redirect. So there should be no redlinks. --Panda10 (talk) 21:55, 5 April 2017 (UTC)

I don't think it works: https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=mandylion&oldid=41225527 —suzukaze (t・c) 22:04, 5 April 2017 (UTC)

However, there are pages in Category:Pages with broken file links like 大肚黃 where .ogg needed to be updated to .opus. - -sche (discuss) 22:06, 5 April 2017 (UTC)

I wonder if a bot could check if there is a corresponding .opus file for links in that category and change the links if so. @DTLHS? — Eru·tuon 22:07, 5 April 2017 (UTC)

Unless the category is not catching all of these, there were so few that I opted to just start fixing them manually rather than writing a script to assist. I got about half of them done thus far and will finish up tomorrow probably. There are also a number of missing images and other similar problems in there, so I can hit those as I go. - TheDaveRoss 23:08, 5 April 2017 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @-sche, Panda10, Suzukaze-c, TheDaveRoss: is the renaming of the files causing technical issues? An anonymous user just reported at Wiktionary:Feedback that the English sound file at autochthon no longer works, and indeed I couldn't get it to play, either here or at the Wikimedia Commons. — SMUconlaw (talk) 12:45, 11 April 2017 (UTC)

I have spot checked the ones I have changed and haven't encountered any that were broken. It might be specific to that file. - TheDaveRoss 13:14, 11 April 2017 (UTC)

I did not rename any of the Hungarian audio files from .ogg to .opus. There are about 20 of them created with this method. They are still working fine. --Panda10 (talk) 13:24, 11 April 2017 (UTC)

Anon's problem might be a lack of browser support for .opus files. —suzukaze (t・c) 21:49, 11 April 2017 (UTC)

My browser is also not playing the referenced file, but is playing the others. - TheDaveRoss 21:54, 11 April 2017 (UTC)

I've just added a bunch of language codes to labels in Module:labels/data/subvarieties. So now most of them have a language code, which means they will be accessible in entries.

There are quite a few labels that have the same name in the regional module (Module:labels/data/regional) and the subvarieties module. Currently, the label in the subvarieties module will replace the one in the regional module, because of the way in which the labels are collected by the main data module, Module:labels/data.

Go to Module:labels/documentation#Conflicts for the full list. Below is the current form of the list. It just checks for labels that have the same name; it doesn't check whether they have different content. (One difference is that the subvarieties labels have a language code, while the regional labels don't.)

Correct any errors by editing the label in the subvarieties module. Regional labels with the same name should be deleted from Module:labels/data/regional after the subvarieties label has been corrected. — Eru·tuon 04:49, 5 April 2017 (UTC)

So how do I decide whether something belongs to regional data or subvarieties data? Crom daba (talk) 18:05, 8 April 2017 (UTC)

Regional data is supposed to be language-agnostic. —CodeCat 18:14, 8 April 2017 (UTC)

That is, if it's a regional subvariety of a particular language (say, American English), it should go in the subvarieties module, not the regional one. — Eru·tuon 11:00, 9 April 2017 (UTC)

The module editor is no longer loading on Module:zu-verbs. Can this be remedied please? —CodeCat 19:47, 5 April 2017 (UTC)

If it is any consolation (it is not), the module editor doesn't appear to be working on any module. —JohnC5 20:12, 5 April 2017 (UTC)

Possibly related, I was able to edit modules earlier today but the editor persisently reset from "plain wikitext mode" to that line-numbered mode every time I reopened the editor, e.g. on going to edit a new module or even just "previewing" the module I was editing. I am apparently now able to edit modules normally again. - -sche (discuss) 21:35, 5 April 2017 (UTC)

I've been having this problem regularly for perhaps two weeks now. I've just been reloading or reloading and clearing cache until the editor worked again. It is, however, a problem with all the JavaScript and not just the code editor, because it affected my TemplateScript functions and the CharInsert toolbar as well. — Eru·tuon 22:10, 5 April 2017 (UTC)

I would like an interwiki bot to go through the subcategories of fr:Catégorie:Langues and Category:All languages, and link the ones that are not linked. One possible way of doing this might be to link every not-yet-linked case where fr.Wikt has a category that contains (code <tt>]</tt>) and en.Wikt has one that contains {{langcatboiler|FOO|. Later other wikis' formulaically-named categories might be tackled, but fr.Wikt and en.Wikt are the ones with the most languages and I've noticed a lot of missed interwikis. Later it might be possible to extend the bot to find and link formulaically-named subcategories, like fr:Noms communs en alutiiq = Category:Alutiiq nouns. - -sche (discuss) 05:53, 6 April 2017 (UTC)

I checked on multiple browsers, and the "expand" button appears outside the template itself, next to the definition (in apparently any Chinese entry). Ultimateria (talk) 10:58, 6 April 2017 (UTC)

I was noticing the same thing yesterday, sometimes it is placed where it belongs, other times it can be quite far outside of the box. - TheDaveRoss 11:17, 6 April 2017 (UTC)

Template_talk:zh-pron#Template_does_not_function_properly_in_conjunction_with_template:wikipedia —suzukaze (t・c) 03:22, 8 April 2017 (UTC)

Waiting for someone more technically adept to kindly fix the roaming button. Btw, the whole module should be reformatted and rewritten. Wyang (talk) 06:34, 9 April 2017 (UTC)

I often patrol anon edits on this page . Most of the content is unwanted from my point of view because I'm only interested in pages that are in languages which I know. Would someone be able to program a feature on that page which would allow the user to choose which language entries he wants to see? --Hekaheka (talk) 17:01, 6 April 2017 (UTC)

Wiktionary:Beer parlour/2016/April#Filter watchlists and recent changes by language--Dixtosa (talk) 17:19, 6 April 2017 (UTC)

This now appears when you click links from recent changes. Does anyone know if this has any effect or will have any effect? DTLHS (talk) 21:07, 7 April 2017 (UTC)

I guess it's https://phabricator.wikimedia.org/T158458 . —suzukaze (t・c) 03:57, 8 April 2017 (UTC)

i.e. making sure {{trans-top}}, {{trans-mid}}, and {{trans-bottom}} are all found together in an entry, instead of content like diff and diff or all these entries missing trans-mid. —suzukaze (t・c) 03:25, 8 April 2017 (UTC)

There are a shit ton of these. I guess I'll finally get around to writing a translation table parser / repairer (which is really annoying to try and do). DTLHS (talk) 03:46, 8 April 2017 (UTC)

If we implement my suggestion at Wiktionary:Grease_pit/2017/March#Autobalancing_translation_tables, then there's no need to fix entries missing trans-mid. —Aɴɢʀ (talk) 07:38, 8 April 2017 (UTC)

That would require a more complicated bot rather than a less complicated one (although I am not opposed to your suggestion). - TheDaveRoss 13:17, 8 April 2017 (UTC)

I think Angr's suggestion should be implemented, in any case. And I'm not sure if it would be more complicated; the change would make {{trans-mid}} redundant anyway, so a bot could just remove it. —CodeCat 13:35, 8 April 2017 (UTC)

Once {{trans-top}} is made auto-balancing, all content can be removed from {{trans-mid}} so that it has no effect whatsoever. That way, it doesn't even have to be removed quickly. —Aɴɢʀ (talk) 15:18, 8 April 2017 (UTC)

Sorry, I mistook the method of balancing, it wouldn't increase complication at all. - TheDaveRoss 16:30, 8 April 2017 (UTC)

Wyang (talk) 06:15, 8 April 2017 (UTC)

@Wyang:, did you accidentally turn it off by pressing the <> button on the top left corner of the editor box? — justin(r)leung _{{ (t...) | c=› }} 06:50, 8 April 2017 (UTC)

Refer to #Module editor not working just above. —Μετάknowledge^{discuss/deeds} 06:51, 8 April 2017 (UTC)

@Justinrleung Yes... thanks! That fixed the problem - it's working well now. Wyang (talk) 07:03, 8 April 2017 (UTC)

It's popped up for derived terms at little which I reformatted last night. Metaknowledge edited it afterwards, but I can't spot any obvious error. DonnanZ (talk) 09:27, 8 April 2017 (UTC)

It seems to be in {{der3}}, related to changes in Module:columns. I think I've fixed the problem. — Eru·tuon 10:02, 8 April 2017 (UTC)

Thanks, it's fine now. It must have affected other derived terms sections too. DonnanZ (talk) 10:11, 8 April 2017 (UTC)

I intend to work on the translation adder so that it works with User:Angr's proposal to make it autobalancing. But I don't know how I could test my changes without making them public first. Does anyone know? —CodeCat 17:01, 8 April 2017 (UTC)

I did some reading, and it looks like the easiest way to do this would be for an admin to add User:CodeCat/TranslationAdder.js to the list of gadgets. Then I can enable it and mess with it at will, and other editors can enable it if they wish for testing. So can this be done? —CodeCat 18:52, 8 April 2017 (UTC)

I believe a gadget has to be in the mediawiki namespace. DTLHS (talk) 20:40, 8 April 2017 (UTC)

Can you not load it using your common.js page using mw.loader.load(script)? - TheDaveRoss 11:58, 9 April 2017 (UTC)

Can we apply certain default non-Latin fonts to some character ranges? For example, Korean fonts to Hangul characters, Hani to Han characters, Thai for Thai characters, Deva for Devanagari characters, etc. I'm trying to clean up 하다 (which is a pain), and much of the cleanup is avoidable script formatting. Wyang (talk) 06:49, 9 April 2017 (UTC)

I don't understand the problem; are the font specifications in MediaWiki:Common.css insufficient? —Μετάknowledge^{discuss/deeds} 06:51, 9 April 2017 (UTC)

For example, in this revision, the unformatted Korean characters are in Sans-serif (14px), and every single occurrence of Korean characters needs to be individually formatted to make it appear consistently with the other template-formatted Korean texts (Gulim 15px). Can a default non-Latin font be applied to these non-Latin characters in running text? Wyang (talk) 06:58, 9 April 2017 (UTC)

I imagine that would require a JavaScript function, since there is no way to do that with CSS and HTML. — Eru·tuon 07:22, 9 April 2017 (UTC)

I suppose it's possible if you had CSS like font-family:Arial, Gulim (Arial doesn't have Korean characters and the browser would turn to Gulim next to display text). However, I think it is best if the text is tagged as Korean (lang="ko") using {{l}}/{{lang}}, because browsers and their users are also able to set certain fonts for certain languages (for example, I can tell Firefox to use Dengxian for any lang="zh" text). —suzukaze (t・c) 07:28, 9 April 2017 (UTC)

Well, all Korean characters should be marked as lang="ko" by default, unless they are tagged as other languages for some reason. Hangul only lists Korean as the language using the script (cf. Wiktionary:Requests for verification#All words in Category:Cia-Cia lemmas in hangeul). Wyang (talk) 07:56, 9 April 2017 (UTC)

The tagging is part of the HTML markup. Wiktionary by itself is automatically tagged as lang="en", so lang="ko" must be added separately (which is why {{lang}}) exists. I suppose JavaScript is another option but automatically guessing languages doesn't sound like an easy task. —suzukaze (t・c) 23:19, 9 April 2017 (UTC)

I have only just noticed a sorting problem with {{der3}} and possibly the other variants. It doesn't seem to put hyphenated words and compound words in strict alphabetical order when there are also two-word terms, see little mentioned above. When converting derived terms at heavy to {{der3}}, as it contains many entries with hyphens I decided to use {{der3-u}} instead to get around the problem. DonnanZ (talk) 10:02, 9 April 2017 (UTC)

Fixed. Wyang (talk) 10:15, 9 April 2017 (UTC)

That was quick, thanks. The problem was obviously elsewhere. DonnanZ (talk) 10:23, 9 April 2017 (UTC)

What happens now is Module:columns removes spaces and punctuation marks before sorting the list items. So, heavy drinker and heavy-duty (from heavy) sort as heavydrinker and heavyduty. — Eru·tuon 03:15, 10 April 2017 (UTC)

I have been subscribed to the Wikimedia Tech News bulletin on my talk page for a while now, and there is often useful information to be found there. It is also possible to subscribe a project page so that we can have on delivery here and everyone can watch that page. Is there interest in having such a page on Wiktionary? Should it be the Grease Pit or some specific page (Wiktionary:Grease pit/Tech News)? It is a weekly delivery so I doubt that it would end up flooding this page, and it might be nice to have discussions directly under some of the topics. - TheDaveRoss 19:08, 10 April 2017 (UTC)

What sorts of things do they talk about? --WikiTiki89 19:22, 10 April 2017 (UTC)

You can see the most recent dozen or so on my talk page. In general they talk about changes needed and made to Mediawiki as they apply to Wikimedia wikis, as well as the API, gadgets, back-end architecture, etc. - TheDaveRoss 19:32, 10 April 2017 (UTC)

I think it wouldn't be a bad idea to have a WT:Wikimedia tech news page, perhaps with monthly subpages, otherwise we'd have to clear it when it fills up. --WikiTiki89 19:37, 10 April 2017 (UTC)

They are only weekly, so it wouldn't fill up too fast, but your point is well taken. The delivery is automated, and it looks like you can use magicwords to direct it dynamically. - TheDaveRoss 20:09, 10 April 2017 (UTC)

I like Wikitiki's idea. Other people might be encouraged to post there, to leave the GP for more local bugfixes, etc. —Μετάknowledge^{discuss/deeds} 21:58, 10 April 2017 (UTC)

I created a page and subscribed it (Wiktionary:Wikimedia Tech News) with annualized subpages. - TheDaveRoss 20:09, 17 April 2017 (UTC)

Can someone create a template that converts Roman numerals to Arabic numerals? I'd like to use it in {{quote-meta/source}} and {{cite-meta}} to check for a chapter number that is expressed in Roman numerals. (At the English Wikipedia there is w:Template:Roman that converts Arabic to Roman numerals, but not the other way around.) — SMUconlaw (talk) 19:19, 11 April 2017 (UTC)

@Smuconlaw Module:roman numerals. Valid up to 3999. DTLHS (talk) 20:04, 11 April 2017 (UTC)

@Smuconlaw, DTLHS: I've created a function in the module and the template {{R2A}} to allow the use of the module from a template. — Eru·tuon 21:18, 11 April 2017 (UTC)

Can the module be categorised, please? —CodeCat 21:21, 11 April 2017 (UTC)

Wonderful! Thanks so much, everybody. I have categorized the new templates into "Category:Maths templates". — SMUconlaw (talk) 05:20, 12 April 2017 (UTC)

It has been moved to "Category:Mathematics templates". @Smuconlaw: how are you intending to use these templates? I'm just wondering what further upgrades we can add. I've added uppercase and lowercase matching to {{R2A}} and the ability to output lowercase in {{A2R}}. —JohnC5 14:11, 12 April 2017 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Actually I just had the rather modest goal of allowing our citation and quotation templates to recognize chapter numbers expressed in Roman numerals (see this diff at {{quote-meta/source}}). Compare the following examples:

• 2017, J. Testing, chapter 17, in Just Testing:

  Testing one, two, three.

• 2017, J. Testing, chapter XVII, in Just Testing:

  Testing one, two, three.

• 2017, J. Testing, “Experimenting Here”, in Just Testing:

  Testing one, two, three.

Previously, the template could not distinguish a chapter number expressed in a Roman numeral from a chapter name, and so would display the latter as “XVII” (instead of as chapter XVII). {{R2A}} is currently sufficient for this purpose, but perhaps I can suggest some improvements to it and to {{A2R}}:

• {{R2A}} currently does not check for malformed Roman numerals, for example: {{R2A|VVV}} → {{R2A|VVV}} ; {{R2A|XIM}} → 1009.
• {{A2R}} does not accept numbers containing commas, for example: {{A2R|2,017}} → MMXVII .

— SMUconlaw (talk) 14:29, 12 April 2017 (UTC)

@Smuconlaw: I've fixed the second issue. The first issue would be easy if we had regular expressions instead of patterns, but without that, this issue is much more complicated to fix. —JohnC5 14:50, 12 April 2017 (UTC)

Thanks! Yes, as I said, {{R2A}} works perfectly for present purposes. — SMUconlaw (talk) 14:55, 12 April 2017 (UTC)

Have you people seen Module:foreign numerals? --Vahag (talk) 05:16, 13 April 2017 (UTC)

Is it worth merging the two templates? — SMUconlaw (talk) 13:11, 13 April 2017 (UTC)

@Vahagn Petrosyan: Well that's frustrating/embarrassing. I'll merge these together soon. —JohnC5 15:00, 13 April 2017 (UTC)

water currently begins to have a memory error near the end of the first Translations list. I couldn't figure out anything in the list of required modules on the edit page, or any recent module changes, that would have caused this. There have been changes at Module:columns, but as that module is not invoked on the page above where the memory error occurs, it can't be the reason. — Eru·tuon 21:00, 11 April 2017 (UTC)

There seems to be some element of randomness to how much memory is used at any given time; this has happened before, also apparently without anything have changed to cause it. I suggest in the BP that we move the translations of water. - -sche (discuss) 21:15, 11 April 2017 (UTC)

Lua has automatic garbage collection and therefore slightly unpredictable memory behavior. It would be good to run the page through a profiler to see where the memory is actually allocated/held; I don't have much experience doing this but can give it a go. – Jberkel (talk) 07:33, 12 April 2017 (UTC)

I hope I'm in the right place to ask for help here. I want to start adding Mi'kmaq nouns to Wiktionary and so need a template that would look something like this:

{{mic-noun|animacy|plural|obviative}}

(I don't know how the animacy bit would work as Wiktionary seems only to be set up for European languages with things like gender and case.)

I've read through the template documents but I don't understand coding and the more I read, the more confused I get. Setting up a template seems really complicated. Can anyone help me? Thanks Llusiduonbach (talk) 20:42, 11 April 2017 (UTC)

I've created a basic {{mic-noun}} template with some rudimentary documentation. Is this what you had in mind? Also, should every noun have a plural and obviative form, or are there nouns without them? —CodeCat 21:05, 11 April 2017 (UTC)

@Llusiduonbach ? —CodeCat 16:05, 12 April 2017 (UTC)

Thank you so much! I don't have sufficent knowledge of Mi'kmaq to answer your question, but I assume that all have obviatives but not all have plurals. I may be able to answer your question the more I study. Llusiduonbach (talk) 21:18, 12 April 2017 (UTC)

I've just come across an issue where a noun has two obviatives. Is it possible for the template to deal with nouns that have more than one plural and/or obviative? Llusiduonbach (talk) 21:24, 12 April 2017 (UTC)

In answer to your question, yes, some nouns don't have either plurals or obviatives from what I can see. Llusiduonbach (talk) 21:33, 12 April 2017 (UTC)

I've added the parameters pl2=, pl3=, obv2= and obv3=. If you need more, you can have a look at the template code and I think you can probably figure out the pattern to add them. —CodeCat 21:38, 12 April 2017 (UTC)

Thanks, yes I see. This was the noun withou a plural or obviative. I can't get the tag (?) "inan" to work for it for some reason. Llusiduonbach (talk) 21:40, 12 April 2017 (UTC)

Oops, it should be just in for inanimate nouns. It's fixed now. —CodeCat 21:42, 12 April 2017 (UTC)

Many thanks for your help. I really appreciate it! Llusiduonbach (talk) 21:44, 12 April 2017 (UTC)

I have noticed that writing e.g.

• {{ux|en|fließen}} {{q|Germany, Austria}}
• {{ux|en|fliessen}} {{q|Switzerland, Liechtenstein}}

results in

• fließen
  (Germany, Austria)
• fliessen
  (Switzerland, Liechtenstein)

i.e. the qualifiers appear on separate lines from the usexes. I don't know if there are any cases where it's desirable for content which is intended to show up on the same line as the {{ux}} to be placed outside of the {{ux}} template, but nonetheless it seems undesirable and possibly unintentional for {{ux}} to force such content onto a new line. - -sche (discuss) 07:17, 12 April 2017 (UTC)

Notice how you intentionally used the wrong language code to get this to show up how you think you wanted it? That's a hint toward what the problem is. When you have a properly formatted usage example, meaning with a translation to English, where is this qualifier supposed to show up? Logically, putting it after the {{ux}} template should make it show up after the entire usage example and its translation, which is probably not where you want it. You want it to show up after the original language. I think the best solution would be to build a |q= parameter into the {{ux}} template, or something of the sort. --WikiTiki89 14:38, 12 April 2017 (UTC)

Yup, that makes sense. — SMUconlaw (talk) 14:40, 12 April 2017 (UTC)

OK, I'll add a qualifier parameter to {{ux}}. – Jberkel (talk) 11:02, 13 April 2017 (UTC)

@-sche done, Special:Diff/42696900. – Jberkel (talk) 01:53, 25 April 2017 (UTC)

I noticed that User:TheDaveRoss has been manually going through and properly formatting quotes. I don't know how many other people use the QQ gadget for quotes, but I think it should be updated with proper format. Also, if you search for a common word such as "día", the entire first page of results does not contain a single quotation, just books with the word in the title. I wonder if this can be fixed. Ultimateria (talk) 15:18, 12 April 2017 (UTC)

Kephir, who left some time ago, was the creator of Quiet Quentin; I don't know if anyone else with the ability to improve it is willing to do so. Your second issue is a problem with Google Books itself, and has nothing to do with QQ. —Μετάknowledge^{discuss/deeds} 18:56, 12 April 2017 (UTC)

This is a really minor point, but when one clicks the edit link at "Wiktionary:Sandbox", a strange page notice with the single word "yes" appears above the edit window. Can this be removed or changed to something more meaningful? I can't figure out how to edit the edit notice. — SMUconlaw (talk) 17:59, 12 April 2017 (UTC)

The contents of the edit notice are controlled by this page: MediaWiki:Editnotice-4-Sandbox. It contains a reference to {{sandbox}} which appears to be used by many (including myself) as a place to test templates. We should move the message we want to display from the template page to the editnotice message page so that people don't test with it. - TheDaveRoss 18:34, 12 April 2017 (UTC)

I suspect something got mixed up during the discussion at Template_talk:sandbox. —suzukaze (t・c) 01:51, 13 April 2017 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Suzukaze-c, TheDaveRoss: actually, I tried editing MediaWiki:Editnotice-4-Sandbox but didn't seem to be able to change the contents of the edit notice at Wiktionary:Sandbox. Did I do it correctly? — SMUconlaw (talk) 12:21, 21 April 2017 (UTC)

I don't know why this warren of templates and conditional statements exist, but I just replaced the message with a static version and it worked fine. I think the issue is in one of the #if statements which evaluates to empty when at the Sandbox, if you think they are important feel free to track that down. - TheDaveRoss 12:46, 21 April 2017 (UTC)

@TheDaveRoss: thanks. Yeah, I couldn't figure out what the templates and conditional statements were for either, but didn't want to break anything by just removing them. — SMUconlaw (talk) 20:26, 6 May 2017 (UTC)

It just occurred to me, that transliterations are completely useless for users relying on screen readers to read out words for them. A good screen reader will pronounce foreign words properly, so the transliteration doesn't add anything and might even confuse the user because they will end up hearing the word pronounced twice (possibly incorrectly the second time, too). So how can we make transliterations "invisible" to screen readers so that they just get skipped? —CodeCat 18:49, 12 April 2017 (UTC)

And what will happen when the language is one that the screen reader doesn't know how to read? --WikiTiki89 18:53, 12 April 2017 (UTC)

Would it know how to read the transliteration, then? —CodeCat 18:56, 12 April 2017 (UTC)

It could at least try and read it wrongly. --WikiTiki89 18:57, 12 April 2017 (UTC)

I created this very simple little template to help with making templates. If you give it text with embedded wikilinks, it will return it unchanged. If there are no embedded wikilinks, then it will put square brackets around it. It's essentially what {{l}} does, but suitable for embedding into another template like {{l-self}} without resulting in double-tagging. —CodeCat 22:11, 12 April 2017 (UTC)

I have made {{der-top}}, {{hyp-top}} and {{rel-top}} (and variants with a number) autobalancing, so that they automatically split their content into columns evenly. This means that the -mid templates are no longer needed, and can be removed from entries. —CodeCat 20:39, 13 April 2017 (UTC)

Why not have the column numbers be a parameter? --WikiTiki89 20:42, 13 April 2017 (UTC)

I was going to propose that soon, but I haven't been able to finish this task as some of the templates are protected from editing. Consequently, entries with {{rel-top3}} are currently broken until it's unprotected and I can fix it. {{top2}}, {{top3}}, {{top4}}, {{mid2}}, {{mid3}}, {{mid4}} and {{bottom}} need to be unprotected as well. —CodeCat 20:46, 13 April 2017 (UTC)

@CodeCat: I've unprotected them. Go ahead. --WikiTiki89 20:48, 13 April 2017 (UTC)

Done. Thank you! —CodeCat 20:55, 13 April 2017 (UTC)

Are you going to remove the mid templates with your bot? DTLHS (talk) 20:44, 13 April 2017 (UTC)

I have a script ready to run, is it ok to run it? What we've done so far is easy to reverse, but removing these templates from lots of entries isn't. —CodeCat 21:25, 13 April 2017 (UTC)

We should probably wait a week or so to see if anyone reports any problems. DTLHS (talk) 21:48, 13 April 2017 (UTC)

Or any conscientious/principled objectors *cough*Dan*cough* —CodeCat 21:50, 13 April 2017 (UTC)

But regardless, I agree we should give it some time. --WikiTiki89 22:00, 13 April 2017 (UTC)

There's currently a problem at WT:RFDO#Template:nv-top2, Template:nv-mid2, Template:nv-bottom2. Columned tables in some entries were designed so that there would be a header at the top of each column, and the autobalancing breaks this. I think the solution lies here but I'm not sure how it would best be applied. —CodeCat 21:59, 14 April 2017 (UTC)

I experienced slightly odd behaviour with {{top3}} with 25 entries in Jefferson County, and get the same result if {{mid3}} is removed. However with 17 entries in Union County there's no problem, and I left {{mid3}} out. DonnanZ (talk) 10:04, 16 April 2017 (UTC)

Also with {{top2}} with 9 entries in Benton County balancing 4/5 with or without {{mid2}}. If I insert a fictitious 10th entry it balances 5/5. DonnanZ (talk) 12:19, 16 April 2017 (UTC)

That's an issue of your browser. —CodeCat 12:31, 16 April 2017 (UTC)

Why, do you get a different result? DonnanZ (talk) 12:36, 16 April 2017 (UTC)

No, but the columnisation is done with CSS and CSS is always processed client-side. —CodeCat 12:46, 16 April 2017 (UTC)

It has been a week now. Are the problems mentioned above serious enough to postpone orphaning the mid-templates? —CodeCat 16:12, 20 April 2017 (UTC)

They do the job after a fashion, but balancing of columns is not what I would call perfect. I am convinced more than ever that templates like {{der3}} are the ultimate answer; they can be made to work very well, even with hidden notes and qualifiers. DonnanZ (talk) 12:16, 5 May 2017 (UTC)

I strongly oppose using the {{der3}} method; I much prefer either the markup/style method which CodeCat has suggested or else the old-fashioned balancing we have been doing all along. - TheDaveRoss 12:45, 5 May 2017 (UTC)

Every one to their own. Anyway the mid-templates are superfluous now, so I guess they can be removed, unless there are other objections. DonnanZ (talk) 13:07, 6 May 2017 (UTC)

Can we please create this gadget with the code in User:Wyang/Switcher.js? I would like to try this on {{zh-dial-map}} (displaying and hiding low-frequency labels, etc.). Thanks! Wyang (talk) 00:34, 15 April 2017 (UTC)

@Wyang:  Done —Μετάknowledge^{discuss/deeds} 05:44, 15 April 2017 (UTC)

@Metaknowledge Thanks! It's not working though- see for example User:Wyang/sandbox. Perhaps it needs to be listed somewhere to allow it to be enabled, but I'm not sure. Wyang (talk) 10:58, 21 April 2017 (UTC)

I don't know how it works, but you have to enable the gadget for yourself. —Μετάknowledge^{discuss/deeds} 16:12, 21 April 2017 (UTC)

@Metaknowledge I think all the steps at Wikipedia:Gadget#Installation have to be followed.—suzukaze (t・c) 00:22, 23 April 2017 (UTC)

@Wyang, suzukaze-c (For future reference, that link should actually go to w:WP:Gadget#Installation.) All that I seem to have to do is add it to MediaWiki:Gadgets-definition, but I don't know if there are any dependencies. What is the exact line I should add, and where should it go? —Μετάknowledge^{discuss/deeds} 03:03, 23 April 2017 (UTC)

Why does contro categorise into Category:Italian twice-borrowed terms? Old Italian is an etymology-only language, so can't Italian terms be derived from it? —Μετάknowledge^{discuss/deeds} 05:42, 15 April 2017 (UTC)

Etymology-only languages are always treated as part of their parent language. So as far as our templates are concerned, Old Italian is a form of Italian. This means that if an Italian term is derived from Old Italian, it's essentially derived from itself. —CodeCat 12:37, 15 April 2017 (UTC)

But should that be the case? In principle, even if Old Italian is considered a "dialect" of Italian, shouldn't it be possible to write the modules so that {{der|it|roa-oit|...}} categorizes into CAT:Italian terms derived from Old Italian just as {{der|en|roa-oit|...}} categorizes into CAT:English terms derived from Old Italian? I think that would be beneficial. —Aɴɢʀ (talk) 14:15, 15 April 2017 (UTC)

Yeah, it is obviously better for it to work as one might expect, like Angr described. @Erutuon, maybe? —Μετάknowledge^{discuss/deeds} 18:41, 15 April 2017 (UTC)

Hmm, there is probably a way to fix this. I will look at it when I have time. — Eru·tuon 00:13, 16 April 2017 (UTC)

@Erutuon, a reminder. I'm still hoping someone will fix this. —Μετάknowledge^{discuss/deeds} 03:11, 26 April 2017 (UTC)

@Metaknowledge: Thanks for pinging me; I had forgotten. I've come up with a solution for contro at least. I'm questioning whether it might cause problems in other entries, though. There might be cases in which we might want a word coming from a word in a subvariety of the same language to be categorized as double-borrowed. If so, the solution would have to be more complex. — Eru·tuon 03:43, 26 April 2017 (UTC)

• @Erutuon, Category:Italian terms derived from Old Italian is now showing a module error... —Μετάknowledge^{discuss/deeds} 05:00, 2 May 2017 (UTC)
  • @Metaknowledge: Yeah, I noticed. I'm haven't fixed it (by editing Module:category tree/derivcatboiler) because I'm not sure what should happen: should we, in general, allow words in a language to be derived from a variety of the language? – and how do we distinguish that situation from actual double-borrowed terms? — Eru·tuon 05:32, 2 May 2017 (UTC)

In some cases, people add labels as etymologies; it is good to catch such errors somehow, although I suppose patrolling "Latin twice-borrowed terms" is as much a way to do it as looking for "Latin terms borrowed from Late Latin". - -sche (discuss) 04:51, 6 May 2017 (UTC)

Whereas, this apparently should be (but isn't) in the "twice-borrowed terms" cat. - -sche (discuss) 04:58, 6 May 2017 (UTC)

Related: it would possibly make sense for Category:Spanish terms derived from Lunfardo to work. Likewise, there are a number of German terms, and some Bavarian terms, derived from Rotwelsch, which I would add an etymology-only code for and category if I knew it was desired and would work. - -sche (discuss) 02:54, 14 May 2017 (UTC)

The parameter "|num=sg" doesn't work in quisque in the line {{la-decl-multi|quis<irreg>que|num=sg}} which creates this: Template:la-decl-multi where under "Plural" one can see plural forms which shouldn't be there. The examples at Template:la-decl-multi show that "|num=sg" should work. -80.133.115.30 14:08, 16 April 2017 (UTC)

Is there some new problem with the cookies that Wiktionary uses? The website has suddenly stopped remembering certain states, such as the fact that I have marked notices read, and that I want quotations to be shown by default. I am using Mozilla Firefox 52.0.2. — SMUconlaw (talk) 16:48, 16 April 2017 (UTC)

Yes, there is a long-standing problem with cookies in Firefox that stems back to a change made in a recent Firefox update. The long story is here at Phabricator. There are a couple of workarounds specifically you can increase the number of global cookies and domain-specific cookies which Firefox will retain and that has been fixing the issue for most everyone. - TheDaveRoss 23:41, 16 April 2017 (UTC)

Ah, thanks. The problem went away after I restarted the browser, but if it happens again I'll try the solution mentioned above. — SMUconlaw (talk) 05:59, 17 April 2017 (UTC)

The problem happened again when I tried to add translations to an entry. I followed the advice at the Phabricator and it seems to have worked, though I started with 200 but had to increase it to 500. — SMUconlaw (talk) 18:45, 21 April 2017 (UTC)

This technical discussion was split off of the originally policy/content-based discussion at Wiktionary:Beer_parlour/2017/April#Moving_the_translations_of_water.

Even with the (biggest chunk of the) translations moved off the page entirely, the page is still broken! It makes it as far as the first "Derived terms" section before "The time allocated for running scripts has expired." Whereas, the subpage with the translations on it (newly switched to use a less-module-heavy template) is fine. So something besides (just) the translations is eating up memory. But what? - -sche (discuss) 02:33, 17 April 2017 (UTC)

This is probably related to the new sorting code that {{der4}} uses in Module:columns. DTLHS (talk) 02:29, 17 April 2017 (UTC)

I made an empty edit and the error messages went away (at least for me). — Ungoliant ^(falai) 02:32, 17 April 2017 (UTC)

There's a certain amount of randomness in whether or not Lua runs out of memory, which I think someone said was due to the manner in which garbage collection is done. In any case, I would guess that the removal of the error is a temporary artefact of that, and that it may return. I'll try copying the contents of the page into a bunch of subpages of mine, to see if (and how often) Lua runs out of memory. - -sche (discuss) 02:38, 17 April 2017 (UTC)

If the problem is related to {{der4}} then we should switch that page back to the old method of manually sorted columns, or switch to a CSS solution. I think we should probably avoid using Lua to change the display of contents and either maintain such things by bot or leverage the browser to do it via CSS. Just because it is possible to do something via JS or Lua does not mean that it is the best way, or even a sensible way. - TheDaveRoss 15:30, 17 April 2017 (UTC)

When I moved the translations back into the main entry, it broke again, this time running out of memory at the Middle English section for both Erutuon (see Talk:water) and me. This suggests that the improvements to {{t-simple}} may have helped (the error was previously midway through the translations table), but not enough. - -sche (discuss) 09:58, 25 April 2017 (UTC)

Looks like {{der4}} is the next place to look for problems:

 79.45% 7172.432      1 Template:der4
 12.66% 1142.925    650 Template:l
  1.99%  179.528     81 Template:t+
  1.51%  136.079     53 Template:t
  1.51%  135.997    130 Template:t-simple

While execution time (per call and net) is not a perfect analog for Lua memory issues, it can be a good indicator. - TheDaveRoss 11:09, 25 April 2017 (UTC)

I wonder if turning off sorting in {{der4}} would remove the problem. A bot could do the sorting manually instead. — Eru·tuon 21:51, 25 April 2017 (UTC)

I have changed the template from {{der4}} to {{der4-u}}. DTLHS (talk) 22:07, 25 April 2017 (UTC)

That seems to fix the problem. I guess sorting takes quite a bit of memory. — Eru·tuon 22:11, 25 April 2017 (UTC)

Even with {{der4-u}}, the translations have to be on a separate page, because if I re-add them to the main entry, it runs out of memory at the start of the Limburgish section (see this revision). I suppose I should file a Phabricator bug report: what should it say?

"Many users have confirmed that Lua runs out of memory ("Lua error: not enough memory") on one of en.Wikt's most complete and module-heavy pages, water (see revision history and ), resulting in some sections of the entry needing to be housed on a separate page. Testing suggests there may be an issue with Lua's garbage collection, with a large number of individually not-that-intensive tasks do not release memory when they finish. The issue persists despite simplification of the most common (module-invoking) template (Template:t is now Template:t-simple in many cases) and of the apparently next-most resource-hungry template (Template:der4, now Template:der4-u). Because other entries will one day be as complete as water, this issue will affect more pages if not addressed. If Lua cannot be changed, an alternative bit of assistance would be to help us identify which pieces of code are using the most memory."

? - -sche (discuss) 16:03, 27 April 2017 (UTC)

I filed T165935 about this. - -sche (discuss) 04:33, 21 May 2017 (UTC)

Wiktionary's "you may submit it again to confirm it" doesn't work.
While I tried to add a missing dot to end a sentence, this message appeared:

"Warning: This action has been automatically identified as harmful.
Unconstructive edits will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this action to be constructive, you may submit it again to confirm it.
A brief description of the abuse rule which your action matched is: Adding xxx and nothing else. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit."

And when trying to submit it again, this came up:

"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: Adding xxx and nothing else"

-80.133.118.101 08:48, 17 April 2017 (UTC)

Which entry were you trying to add the full stop to, what was the sentence you were adding to, and were you only trying to add the full stop or the whole sentence? — SMUconlaw (talk) 09:17, 17 April 2017 (UTC)

It was in quisquis. There was a sentence without a full stop and I wanted to add it. While doing it, I also tried to change "quote,<ref>reference</ref>" into "quote,<ref>reference</ref>", that is, I tried to move the comma.
As for the entry, it got fixed now (diff).
As for the message, it's annoying that even the "you may submit it again to confirm it" doesn't work. -80.133.118.101 09:44, 17 April 2017 (UTC)

The message which was served was the generic warning message, and for non-"disallow" filters it is true that re-submitting will work. For filters which both warn and disallow, a specific message is needed which does not indicate that re-submitting will work. I have created such a message for the filter in question. - TheDaveRoss 15:44, 17 April 2017 (UTC)

As can be seen in the image at right, the "more" button to expand the pronunciations displays in the completely wrong location. --WikiTiki89 12:51, 21 April 2017 (UTC)

@Erutuon: I grow weary of dealing with this problem. Shall we just remove the collapsing functionality? I believe this was also a condition @CodeCat had before she would support using a bot to convert all the instances of {{grc-ipa-rows}} to {{grc-IPA}}. —JohnC5 15:08, 21 April 2017 (UTC)

I personally like the collapsibility. --WikiTiki89 15:10, 21 April 2017 (UTC)

I usually like the collapsibility too, but not when it becomes more trouble than it's worth. If things like this are possible, I'd rather get rid of it. —Aɴɢʀ (talk) 15:52, 21 April 2017 (UTC)

Is this the same problem as zh-pron above? —suzukaze (t・c) 18:49, 21 April 2017 (UTC)

So, the issue is that we are manually calculating the width of the table so that the "show" button will sit immediately to the right of the first row. If we could get it to autoscale with css, that would be the best option. — This unsigned comment was added by JohnC5 (talk • contribs).

Try wrapping everything in a div with style="display: inline-block; overflow: auto" and then get rid of the manual width and make any other block div inside it "display: inline-block". --WikiTiki89 22:27, 21 April 2017 (UTC)

@Wikitiki89: I tried that on a user page of mine, and it doesn't seem to give a good result. The unexpanded content gets wrapped. Perhaps it can be fixed, though. See this revision. Feel free to experiment further. — Eru·tuon 19:15, 22 April 2017 (UTC)

The output of Template:mention on Citations:/b/tard is broken: it links to "/b/tard/b", and displays "/b". Note that passing in an unnamed parameter with the correct page name to Template:citation doesn't fix this; while it does correct the displayed text to "/b/tard", it changes the link target to "/b/tard/b/tard" instead. Digging in a bit further I suspect the actual problem is with Module:links/templates, but my command of Lua is nowhere near good enough to debug that without some serious effort on my part, and probably not even with. Dinoguy1000 (talk) 05:19, 22 April 2017 (UTC)

It's not a module problem; you simply need to link to it with a colon in front. I left a note on the talk page some years ago to remind people of this. —Μετάknowledge^{discuss/deeds} 05:52, 22 April 2017 (UTC)

I created the template {{uxi}} as a shorter equivalent of {{ux|...|inline=1}}. I've been meaning to do this for awhile, as inline usage examples are extremely common and it's annoying to have to type so many characters (and frequently forget to do it). Benwing2 (talk) 20:44, 23 April 2017 (UTC)

I still think this should be done automatically by the template. —CodeCat 21:38, 23 April 2017 (UTC)

I agree, but I have no idea how to decide where to set the cutoff, esp. as it ought to vary depending on your screen size (and hence should properly use some CSS magic). Benwing2 (talk) 21:39, 23 April 2017 (UTC)

True, but it's a start. Right now, everyone will insert inline=1 based on their own individual judgement, which will lead to a lot less consistent results. —CodeCat 21:41, 23 April 2017 (UTC)

I think all of Wiktionary should be written automatically with a template. Unfortunately that would be hard to implement. We do what we can. --WikiTiki89 16:53, 24 April 2017 (UTC)

Usex and quote templates can now take a sub= parameter. This is used for languages like Russian, Yiddish, Arabic, Hindi, etc. that have auto-transliteration but sometimes require exceptional transliterations of particular words in a usex. Previously, if any word required exceptional transliteration, you had to give a manual transliteration of the entire usex or quote, which is annoying and error-prone when the text to be transliterated is long. The sub= parameter fixes this by letting you supply phonetic respellings of individual words prior to transliteration being invoked. Here is an example:

Wikitext

#: {{ux|ru|Полицейские огородили середину шоссе́ на гора́х, '''всле́дствие чего́''' бегле́ц был на воле.|Police officers blocked the middle of the highway '''as a consequence that''' a fugitive was on the loose.|subst=шоссе́/шоссэ́}}

Output

1. Полицейские огородили середину шоссе́ на гора́х, всле́дствие чего́ бегле́ц был на воле.

   Policejskije ogorodili seredinu šossɛ́ na goráx, vslédstvije čevó begléc byl na vole.

   Police officers blocked the middle of the highway as a consequence that a fugitive was on the loose.

In this case, we want the word шоссе́ to be transliterated šossɛ́ instead of šossé, which is the auto-translit. the sub= param phonetically respells шоссе́ as шоссэ́ to match its pronunciation, causing it to be correctly transliterated as šossɛ́.

In Yiddish this would be especially useful in conjunction with Hebrew words.

The sub= expression is actually a Lua pattern substitution.

An alternative to the way I set up sub= is to apply the substitution *after* transliteration. This has the advantage that it works even if there are letters used in transliteration that have no ways of being represented in the source script; but it could potentially run into problems in languages like Arabic, where certain examples of source script can't be transliterated at all (typically if the vowel markers are missing). What do people think? Should I change sub= to apply after translit?

Benwing2 (talk) 21:30, 23 April 2017 (UTC)

Could the parameter be named subst= instead? It would be a little clearer, so as to not be confused with the meaning "below". —CodeCat 21:37, 23 April 2017 (UTC)

Sure. Benwing2 (talk) 21:39, 23 April 2017 (UTC)

Making the substitution apply to the transliteration would be less understandable, because the transliteration does not show in the wikitext, but only in the resulting HTML. However, applying the substitution to the transliteration might be more useful in other languages.

What about making the module detect which script is being used in the substitution parameter? If it's the native script of the language, the substitution would have to be applied to the text used to produce the transliteration; if it's the Latin script, the substitution would have to be applied to the transliteration. — Eru·tuon 22:05, 23 April 2017 (UTC)

Changed to use subst= instead of sub=, and to take multiple parameters instead of a single comma-separated param. Benwing2 (talk) 02:17, 25 April 2017 (UTC)

Changed back to using a single comma-separated parameter, but still named subst=. --WikiTiki89 14:41, 25 April 2017 (UTC)

I'm not fond of the name "subst=" since that string already has an entirely different meaning in connection with templates. How about "sptr=" for "specific (or special) transliteration"? —Aɴɢʀ (talk) 15:16, 25 April 2017 (UTC)

I was thinking "trsub=". --WikiTiki89 15:22, 25 April 2017 (UTC)

That'll work too. —Aɴɢʀ (talk) 15:43, 25 April 2017 (UTC)

I'm ok with that. —CodeCat 15:48, 25 April 2017 (UTC)

@Benwing2: Do you have anything against |trsub=? --WikiTiki89 19:23, 25 April 2017 (UTC)

My objection to this is that trsub= or trsubst= ought to be used for a substitution that applies to the transliteration rather than to the source text. I was actually thinking of adding a parameter with this exact name, which works like sub=/subst= but applies to the translit. Benwing2 (talk) 02:16, 26 April 2017 (UTC)

I honestly don't see why either sub= or subst= is a problem. We already have, for example, param gloss= and template {{gloss}}, which do different things. And I don't see why sub= would be confused with the meaning "below". Benwing2 (talk) 03:37, 26 April 2017 (UTC)

It's a substitution that applies in order to generate a translit. I don't see why that's such a problem. If you just say "sub" or "subst" then it is not obvious what the substitution is for. --WikiTiki89 14:14, 26 April 2017 (UTC)

It's a problem in that I wanted to implement trsub=/trsubst= with a different meaning. Another possibility is respell=; IMO that makes it even clearer what is going on, since it's respelling the word phonetically in order to generate proper translit. Benwing2 (talk) 03:32, 27 April 2017 (UTC)

@Benwing2: Have you considered my idea above, of making the substitution function detect the script before deciding whether to apply the substitution before or after transliteration? — Eru·tuon 03:46, 27 April 2017 (UTC)

@Erutuon This is possible but feels a bit hacky to me. Let me think about it more. Benwing2 (talk) 04:05, 27 April 2017 (UTC)

You could have trsubst= and trsubstafter= or something like that. --WikiTiki89 14:51, 27 April 2017 (UTC)

It's not even humorous how many examples of bad spellings we have in Wiktionary. Anybody have a friendly spellobot who can change all (most?) instances of humourous to "humorous", please? There's too many for me. --WF April 2017 (talk) 21:37, 23 April 2017 (UTC)

Are all of these errors, though? We should not generally be changing spellings that occur in quotations, for example. The spelling could occur in an old text at a time when there was less consensus about what the "correct" spelling was. — SMUconlaw (talk) 08:07, 24 April 2017 (UTC)

Fixed. Actually, the list wasn't too long, so I changed all the ones that were obviously errors. — SMUconlaw (talk) 08:14, 26 April 2017 (UTC)

I tagged the quoted uses with {{sic}}. --WikiTiki89 16:51, 2 May 2017 (UTC)

Thanks. Did you check if they were actually spelled that way in the sources, though? I wasn't able to, so that's why I didn't do anything to them. — SMUconlaw (talk) 16:53, 2 May 2017 (UTC)

Yes I did. In one case, the Google Books title even spelled it correctly, while in the actual scan of the book it was spelled incorrectly. --WikiTiki89 16:55, 2 May 2017 (UTC)

Great! — SMUconlaw (talk) 17:57, 2 May 2017 (UTC)

It seems to me it would be valuable to have a class "wikitext" to mark examples of wikitext with. For instance, Module:template link could add it to examples of template syntax created by {{temp}}. When someone finally comes up with a wikitext syntax highlighter, some of the text marked with this class could be switched over to that.

Unless there are objections, or better ideas for the name that the class should have, I will make {{temp}} add <code class="wikitext"></code> around the template code (in place of what it currently adds, just plain <code></code>), and perhaps also make {{para}} do the same. — Eru·tuon 08:03, 26 April 2017 (UTC)

Sounds like a good idea to me. The only alternative name which jumps out is wiki markup. I believe that technically wikitext is a document written in wiki markup, but that is a pretty trivial distinction in this case. - TheDaveRoss 11:25, 26 April 2017 (UTC)

Well, I kind of like being nit-pickingly correct, and so do many other Wiktionarians. Perhaps "wiki-markup" would be a better class name. — Eru·tuon 11:34, 26 April 2017 (UTC)

Before we argue about names, why do we need this in the first place? Maybe we should wait until there actually is a wikitext highlighter before worrying about it. --WikiTiki89 14:16, 26 April 2017 (UTC)

To make it clear what a given instance of the code tag actually is being used for. At the moment, we have it being used for wiki markup, URLs, and Lua code. It is a good idea to make distinctions using classes, even though there aren't any visual differences to these classes encoded by MediaWiki:Common.css yet. There are other semantic classes that we could add. One that we already have is "etyl", used for language names in etymologies. (Unfortunately, it's used for all etymology types alike; that is unsatisfactory.) — Eru·tuon 19:14, 26 April 2017 (UTC)

Lua code is normally tagged (and syntax highlighted). URLs don't use code tags at all. --WikiTiki89 19:36, 26 April 2017 (UTC)

I recall URLs using code tags (or maybe kbd tags) in one of the citation or quote templates, but I can't recall which right now. Lua code uses syntax highlighting when there's enough for the highlighter to work; but I have been using <code class="n"></code> to format individual variables at certain points. (Hmm, that may not be necessary; var works just fine.) — Eru·tuon 19:42, 26 April 2017 (UTC)

Under the Adyghe word кӏьэрыт there is a usage example containing the word Гонахьхэр which gets transliterated as Γonāḥxăr. Presumably this should be Gonāḥxăr and the capital Γ has just been overlooked somewhere. It also comes out as Γ in the transliteration created by {l|ady|...}, though it is correct in {l|ru|...}. -- 13:02, 26 April 2017 (UTC) — This unsigned comment was added by Hiztegilari (talk • contribs).

No error there. We transliterate Adyghe г, which represents IPA^(key): , with Greek γ, the capital of which is Γ. See WT:ADY TR. Perhaps we should switch to the Latin pair ɣ/Ɣ. @Adamsa123, what do you think? --Vahag (talk) 14:17, 26 April 2017 (UTC)

The Latin version is a bit problematic and confusing. While the letter Г represents , го is .--Adamʂa123 (talk) 20:45, 26 April 2017 (UTC)

@Vahagn Petrosyan: Perhaps it would be better to use the characters ɣ and Ɣ? --WikiTiki89 21:25, 26 April 2017 (UTC)

@Wikitiki89: Isn't that exactly what Vahagn himself proposed above? At any rate, I agree. —Aɴɢʀ (talk) 21:32, 26 April 2017 (UTC)

Oh yeah. --WikiTiki89 21:50, 26 April 2017 (UTC)

OK, then I am changing the transliteration to Latin ɣ/Ɣ. The Tower of Babel too uses the Latin version. --Vahag (talk) 05:02, 27 April 2017 (UTC)

Why not just transliterate it as G/g? —CodeCat 21:35, 26 April 2017 (UTC)

Because Adyghe г etymologically does not correspond to the phonemes transliterated as g in other West Caucasian languages. --Vahag (talk) 05:02, 27 April 2017 (UTC)

But it's a transliteration, not an etymology. We don't transliterate Г as G in Ukrainian, either, after all. —CodeCat 13:35, 27 April 2017 (UTC)

I have simply followed the Caucasiological transliteration documented here. It is designed to help comparing cognates in different Caucasian languages. --Vahag (talk) 14:58, 27 April 2017 (UTC)

The documentation of this template says that it must always be substituted, but it is used directly in {{ae-verb}}. Is this a problem? @Aryamanarora. DTLHS (talk) 17:14, 26 April 2017 (UTC)

@Aryamanarora: Would it be possible to enter the root in the Avestan script? --WikiTiki89 17:18, 26 April 2017 (UTC)

@DTLHS, Wikitiki89: This was mostly done for time-saving; I churned out a bunch of Avestan entries this week. The Avestan script is somewhat of an annoyance to type in... I can get rid of the direct transclusion if I have to though. —Aryamanarora ^{(मुझसे बात करो)} 17:45, 26 April 2017 (UTC)

You could use the substable version. Just page {{ae-verb|{{subst:chars|ae|transliterated root}}}} in the entry. You could even create a shortcut template and use it like this: {{subst:ae-verb-gen|transliterated root}}. --WikiTiki89 17:48, 26 April 2017 (UTC)

I don't know if something is wrong in Wiktionary or if it's just on my computer. Suddenly I cannot open or view Translation sections. The Translation sections are closed, and in the sidebar at the left margin "Show/Hide translations" does not appear. It's only here on en.wiktionary. When I look at other wiktionaries, such as ca:honor, I can see the Translation sections, and in the sidebar the words "Mostra traduccions" (Show translations) appear. —Stephen ^(Talk) 05:40, 27 April 2017 (UTC)

I have been having unpredictable problems with the Wikimedia JavaScript functions for a month or two now, including the translation sections, other collapsible content, my TemplateScript functions, the regular editor, and the code editor (Lua, CSS, and JavaScript pages). I just reload or shift-reload (clear cache), and eventually it fixes itself. It's a makeshift solution; I wish I had a permanent one. — Eru·tuon 05:51, 27 April 2017 (UTC)

I tried clearing my cache (a few times), but it didn't help. I logged out and back in again. I also cleared my cookies, but no help there. —Stephen ^(Talk) 06:56, 27 April 2017 (UTC)

Okay, I think I've found the problem. I don't know about other browsers, but I use Firefox for PC and I have always used Monobook skin. Monobook (as well as all of the other skins except Vector) is not working correctly anymore. The only way I can get Translation sections on en.wiktionary to work is by switching to Vector skin (which I don't like). I don't understand why this only affects en.wiktionary and not the other wiktionaries, but there you have it. —Stephen ^(Talk) 07:13, 27 April 2017 (UTC)

Is anyone looking at this problem? The toolbar is also gone.--Anatoli T. ^{(обсудить}/^вклад) 13:56, 27 April 2017 (UTC)

Do you mean the ADVANCED and SPECIAL CHARACTERS that are supposed to appear above the edit window, Anatoli? That's also affected. If you're using Monobook skin, the Special Characters, etc., have vanished. You have to use the Vector skin to see them. Besides that, when you click on WATCHLIST, at the top you should see either a box that explains abbreviations (N m n ! (±123)) or otherwise Legend:. Those are gone, too, for Monobook. You have to use Vector to see them. Maybe they will be fixed in a later update, or maybe they won't. It's extremely vexing. —Stephen ^(Talk) 19:53, 27 April 2017 (UTC)

I can't use Translations table with ANY skin. After a couple of hard refreshes, I can get the table contents displayed but I can't add translations. I can use my iPhone's Safari still but it doesn't work on PC's Chrome or Firefox browser (Firefox has been very unreliable for any Wiktionary work lately). --Anatoli T. ^{(обсудить}/^вклад) 10:36, 29 April 2017 (UTC)

• I am on Firefox, Monobook. I cannot expand translation sections. Most of my bookmarklets stopped working as well. From what I remember, I've had this problem only today and yesterday. --Dan Polansky (talk) 13:22, 29 April 2017 (UTC)

This is a serious problem. I wonder why not many editors have these symptoms:

I started having the same problem as of today. I use Firefox, too. It also occurs when I use Chrome. Vedac13 (talk) 03:21, 11 May 2017 (UTC)

Judging by comments in a couple of places, I think everyone has the problem now- this is new. Just now I've tried MS Edge, MS IE and Chrome, with the same results- nothing expands. Chuck Entz (talk) 03:38, 11 May 2017 (UTC)

I am currently using vector in preferences but tried other skins with the same or worse results. The translation adder doesn't work at all (no buttons appear). Translations appear intermittently, after a hard refresh only, both on Chrome and Firefox. --Anatoli T. ^{(обсудить}/^вклад) 13:59, 29 April 2017 (UTC)

Please make a screenshot of your browser's console.--Dixtosa (talk) 16:09, 29 April 2017 (UTC)

You are using the most recent Firefox, aren't you? (rev. 53.0). As long as I am in Vector, my Firefox (Windows 10) is working as expected. —Stephen ^(Talk) 21:25, 29 April 2017 (UTC)

Hi all, just advising that I think that one of my gadgets had a conflict with the translation adder. I've disabled them all as I don't have time to check all individual ones. I'm OK for now. --Anatoli T. ^{(обсудить}/^вклад) 02:21, 1 May 2017 (UTC)

@Atitarev: For me, the Tbot gadget recently broke, and I disabled it. You can probably re-enable everything but Tbot. --WikiTiki89 18:59, 1 May 2017 (UTC)

@Atitarev, Stephen G. Brown: I commented out a custom copy of Tbot.js in User:Dan_Polansky/common.js and I am fine. In User:Stephen G. Brown/monobook.js, I see "importScript('User:Ruakh/Tbot.js');" and "addOnloadHook(function() { Tbot.greenifyTranslinks('ru'); });", so I would try to comment those out. Maybe someone can figure out which part of User:Ruakh/Tbot.js needs an update. --Dan Polansky (talk) 17:59, 9 May 2017 (UTC)

I did the same, and it fixed it for me. —Aryamanarora ^{(मुझसे बात करो)} 19:47, 10 May 2017 (UTC)

Yeah, I use vector skin, and today all the collapsible tables stopped working for me. I don't have much in the way of js customization, and so I have no idea how to fix this. I'm using Chrome. Any ideas? —JohnC5 03:39, 11 May 2017 (UTC)

Tabbed languages aren't working either. I don't think the problem is with our individual browsers; there's something wrong serverside. —Aɴɢʀ (talk) 08:18, 11 May 2017 (UTC)

Discussion of the issue which started today is at Wiktionary:Grease pit/2017/May#Show-and-hide_templates_not_working_properly. - -sche (discuss) 08:30, 11 May 2017 (UTC)

Can this be changed so that, when one of the inflection tags (numbered parameters) is just a comma, a space is not inserted before? e.g. nom|,|acc|and|dat should become "nominative, accusative and dative" and not "nominative , accusative and dative". —CodeCat 14:01, 27 April 2017 (UTC)

Are we sure this is the right way to handle syncretism? In Russian what we always do is list each case as a separate definition. Benwing2 (talk) 02:54, 28 April 2017 (UTC)

For languages where a very high number of inflected forms are homographic, it may be. Compare roten, Template talk:inflected form of. - -sche (discuss) 19:50, 29 April 2017 (UTC)

I agree that it's better to list them in one line, as long as it can be done concisely and clearly. --WikiTiki89 19:00, 1 May 2017 (UTC)

I generally use the semicolon, which avoids repeating the lemma form over and over. — Eru·tuon 20:07, 1 May 2017 (UTC)

That's overly repetitive. —CodeCat 20:13, 1 May 2017 (UTC)

Perhaps, but I'm doubtful that listing a gender, three cases, and a number is a good idea either. It might be ambiguous or at least confusing to someone who doesn't know what categories these things belong to (i.e., that one chooses the gender, one of the three cases, and the number in order to get a correct set of inflectional categories for one of the grammatical forms to which the term belongs), and it may not be machine-readable. There ought to be a better of doing this. (Ideally, the module would object if you failed to include one of the necessary grammatical categories: a case and number, but no gender, for instance. That would require part-of-speech information to be supplied to the template, though, and language-specific sets of grammatical categories required for each part of speech. But this is sort of tangential to the topic of this thread...) — Eru·tuon 22:17, 2 May 2017 (UTC)

I'm very partial to conflating these things on a single line, especially when the forms in question always or usually pattern together. From the δίκαια (díkaia) example above: in Ancient Greek (indeed, in all IE languages I know of), the nominative, accusative, and vocative of all neuter nouns, singular and plural, are always the same. So conceptually, it's preferable to say that δίκαια (díkaia) is the nominative/accusative/vocative plural, rather than suggesting it's the nominative plural, and coincidentally also the accusative plural, and coincidentally also the vocative plural. In other forms, where it is just coincidence that the same word belongs to two different nonlemma forms, it makes more sense to list them separately. —Aɴɢʀ (talk) 18:30, 9 May 2017 (UTC)

This is the situation in which I'm using it too. I also use it when there is always syncretism between different forms of nouns belonging to a certain inflectional class. For example, Middle Dutch dāge belongs to the a-stem class (or what's left of it) and these three cases are always identical for such nouns. I opted not to use it for the syncretism between masculine and neuter in grôten, though, instead using it for the accusative-dative syncretism. —CodeCat 21:32, 9 May 2017 (UTC)

My other concern is formatting the three-member list correctly. It should have a serial comma ({{,}}) before the and; not sure how to make that happen. — Eru·tuon 19:36, 9 May 2017 (UTC)

Is it possible to have {{trans-see}} improved, so it goes directly to the entry rather than to the top of the page as it does at present? DonnanZ (talk) 21:56, 27 April 2017 (UTC)

• Isn't that achievable using the following, quoting from the documentation?

Optionally, the second parameter can be used, for example to link to particular etymology or part of speech e.g. {{trans-see|rally|]}}, which yields:

Do you have something else in mind? DCDuring (talk) 22:22, 27 April 2017 (UTC)

I think Donnanz means that the first parameter should link to #English by default (when no second parameter is present). DTLHS (talk) 22:25, 27 April 2017 (UTC)

I don't think {{trans-see}} is used for any language other than English, I did mean a direct to the top of the English entry, in the same way as {{l|en|xxxx}}. DonnanZ (talk) 22:41, 27 April 2017 (UTC)

I was using {{l|en|xxxx}} nested in {{trans-see}} as a workaround, and that worked fine, but these have been nuked by Matthias Buchmeier, so I'm looking for a permanent solution. DonnanZ (talk) 22:51, 27 April 2017 (UTC)

Translation tables could add an anchor to the page, which other pages can then refer to. This would allow a link to go directly to the right translation table, and if I'm not mistaken, it will automatically expand too. —CodeCat 22:58, 27 April 2017 (UTC)

@CodeCat: {{trans-top}} does automatically add an anchor (id), but {{trans-see}} might need to be modified so that it can actually point to it. At the moment, the id is simply Translations- plus an anchor-encoded version of the first parameter supplied to {{trans-top}}. So, the anchor is going to change whenever someone changes the gloss at the head of the translations table. To fix this, there should be a way of specifying a more permanent anchor (id). I like the idea of assigning numbers to each translations table, but those too would end up changing whenever someone added or removed a translations table. — Eru·tuon 00:46, 28 April 2017 (UTC)

Or we could not do any of that. Just linking to #English would be an improvement. This is why we have glosses. DTLHS (talk) 00:51, 28 April 2017 (UTC)

I like the idea of linking to specific translation tables; as with sense ids, it makes navigation much easier. But till that can be done, I agree that linking to the English section is the best solution. — Eru·tuon 00:56, 28 April 2017 (UTC)

Translation tables should match each sense. So preferably the translation tables should have the same sense ids as the senses themselves. The on-page anchors could be English-xxx for a senseid and Translations-xxx for the corresponding translation table. As long as we don't have a language called Translations, that should be ok. :P —CodeCat 01:51, 28 April 2017 (UTC)

• Having just used {{trans-see}}, I'm tempted to ask if there's any progress with this. DonnanZ (talk) 11:33, 5 May 2017 (UTC)
  • Seems like one solution would be to add a |anchor= parameter to {{trans-see}} and {{trans-top}}, which will remain unchanged even if someone changes the gloss. That can then be used to make {{trans-see}} link directly to the correct translation table. Otherwise, if someone decides to change the gloss in {{trans-top}}, the link from a {{trans-see}} will either break or someone will have to go and change the gloss in {{trans-see}} whenever the corresponding gloss in {{trans-top}} is changed.
  • Or perhaps a bot could automatically change the gloss in {{trans-see}} to match the corresponding gloss in {{trans-top}}, when it has been changed. @DTLHS, what do you think? Could that be done? — Eru·tuon 19:57, 5 May 2017 (UTC)
    • Why not use senseids, as I suggested? They were created specifically for the purpose of pointing unambiguously to one particular sense. {{trans-see}} and {{trans-top}} should both get an |id= parameter. —CodeCat 20:24, 5 May 2017 (UTC)
      • @CodeCat: When you said "sense id", I thought you meant having {{trans-see}} point to a definition in the POS section, because that's where sense ids are used. That would be unhelpful, because {{trans-see}} should be pointing to a translations table. I suppose that was a misunderstanding. Having translation ids that are consistent with sense ids isn't relevant to the current issue, of how to make {{trans-see}} point to a particular translation table. It would, however, be useful if at some point we want to make definitions link to translation tables. Anyway, I suppose |id= would be a pretty good name for the parameter in {{trans-see}} and {{trans-top}} that determines what text to add after Translations-; briefer than the parameter |anchor= that I proposed. — Eru·tuon 18:57, 6 May 2017 (UTC)
    • No I don't think it could be done. I am opposed to senseids or translation anchors from a maintainability perspective. DTLHS (talk) 03:27, 6 May 2017 (UTC)
      • What is your opposition to senseids? Does it also apply to the {{senseid}} template used in definitions? —CodeCat 12:11, 6 May 2017 (UTC)

@CodeCat: Template:Trans-see used to link directly to the entry, but it stopped working earlier this year. Someone must have made a mistake when editing its source code. Jarble (talk) 15:12, 18 June 2017 (UTC)

Another vandal meddling with interwiki links reminds me that someone ought to run a bot to remove them all, and we could also use an abuse filter to prevent any rogue bot from trying to add them back. —Μετάknowledge^{discuss/deeds} 22:11, 28 April 2017 (UTC)

• I notice OctraBot has been removing what are described as "old interwiki links", but they still appear in the entry's left-hand column. DonnanZ (talk) 14:48, 29 April 2017 (UTC)

  @Donnanz: That's exactly the point. We are removing the old interwiki links because now Wiktionary fetches them automatically. If you create ja:dogless in the Japanese Wiktionary, an interwiki will appear automatically in dogless, here in the English Wiktionary. --Daniel Carrero (talk) 14:51, 29 April 2017 (UTC)

Oh, I wondered why. They are still useful to have. Thanks for the explanation. DonnanZ (talk) 14:59, 29 April 2017 (UTC)

You're welcome. --Daniel Carrero (talk) 15:05, 29 April 2017 (UTC)

@Metaknowledge I am happy to make a bot to remove all the old links, but I gather that there are some which should stay. Also, as the Conflagrate extension is not yet working properly, should we wait a bit longer? - TheDaveRoss 20:29, 5 May 2017 (UTC)

@TheDaveRoss: I would appreciate that. All the mainspace ones can go once we get assurances that they actually know what they're doing and that the extension will continue to be operational. —Μετάknowledge^{discuss/deeds} 20:42, 5 May 2017 (UTC)

• I have a serious comment. It's about apostrophes. Some Wiktionaries use different ones to us, we should keep those interwikis. --Celui qui crée ébauches de football anglais (talk) 21:02, 5 May 2017 (UTC)

  Keep for now, and request the fancy new interwiki machine to understand them in the future. - TheDaveRoss 21:10, 5 May 2017 (UTC)

  No, you misunderstand. Our old interwiki system ignored the apostrophe problem, and relied on redirects. The new system ignores the apostrophe problem as well. So there are no exceptional interwikis to keep. —Μετάknowledge^{discuss/deeds} 22:07, 5 May 2017 (UTC)

  I am not familiar with the apostrophe problem, can you explain it? Perhaps I could do something useful about it while removing the existing ones? - TheDaveRoss 13:00, 6 May 2017 (UTC)

  Some Wiktionaries use curly apostrophes while we use straight ones. This makes interwikis not work if the page name has to match exactly. The solution has been to create redirects from one type of apostrophe to the other, on all Wiktionaries. Since the new Cognate extension still relies on pages having the exact same name, nothing has changed in that respect. —CodeCat 13:16, 6 May 2017 (UTC)

  Ah, thanks for explaining. - TheDaveRoss 13:25, 6 May 2017 (UTC)

I have a bot ready to go to remove these, has anyone heard any objection or should I let it run? - TheDaveRoss 18:01, 6 May 2017 (UTC)

I would think it would be appropriate to hold off on removing interwikis for a few days, at least, given that the devs had to temporarily shut down the extension that automatically supplied the links, as detailed in other threads on this page (Wiktionary:Grease_pit/2017/May#Automatic_interlanguage_links, phabricator report). - -sche (discuss) 18:20, 6 May 2017 (UTC)

@TheDaveRoss: Cágate Cognate (was that too mean?) is working and it seems you're good to run your bot now. —Μετάknowledge^{discuss/deeds} 23:42, 11 May 2017 (UTC)

Actually not yet, on the some pages it doesn't work yet. There is a bug in phabricator for it already (and a thread in this month's GP). --WikiTiki89 00:45, 12 May 2017 (UTC)

@TheDaveRoss, Wikitiki89: It seems any remaining problems with it in mainspace are resolved, so I think you should run your bot now. —Μετάknowledge^{discuss/deeds} 19:47, 18 May 2017 (UTC)

@Metaknowledge, TheDaveRoss: There is still the issue of pointing to redirects. Is it worth waiting for that to be resolved? Is it worth writing a bot that will leave links to redirects in place for now? --WikiTiki89 19:58, 18 May 2017 (UTC)

This is something which they are trying to handle through the extension eventually, but cannot yet, right? - DaveRoss 20:15, 18 May 2017 (UTC)

Yes. However, there seems to be some disagreement between us and the French Wiktionary regarding normalization, which may delay or block this feature. See the discussion at phab:T165061. --WikiTiki89 20:43, 18 May 2017 (UTC)

Thanks for standing up for English Wiktionary there. I guess I found the normalization rules here. I would much rather not have them, but at least there are only three of them. — Eru·tuon 21:44, 18 May 2017 (UTC)

I'm tempted to think that having only three is even worse, because it is sorely inadequate on its own and it might block the fixing of the redirect bug, which we would need to fill in the gaps. --WikiTiki89 21:57, 18 May 2017 (UTC)

Is there a subset of pages that we can avoid while removing interwikis from the rest? DTLHS (talk) 21:04, 19 May 2017 (UTC)

How about the pages whose titles would be subject to the normalization: those containing the characters listed in the link above? — Eru·tuon 21:10, 19 May 2017 (UTC)

That wouldn't be enough. It doesn't include geresh/gershayim, and it doesn't include other types of redirects. --WikiTiki89 20:57, 25 May 2017 (UTC)

Ok. It is going to take a while, there are a lot of interwiki links. - DaveRoss 19:54, 18 May 2017 (UTC)

Would you like any help? We could divide up the pages somehow. DTLHS (talk) 19:59, 18 May 2017 (UTC)

Udo has also offered to help. —Μετάknowledge^{discuss/deeds} 20:06, 18 May 2017 (UTC)

Sure. I was planning on searching the May 1 dump to find instances of interwikis, would you be doing the same or using AllPages from the API? Or something else? Either way we can find a good offset for start points. - DaveRoss 20:08, 18 May 2017 (UTC)

My bot UT-interwiki-Bot uses a customized script (removeiw.py) for Wiktionaries from Hydriz (the owner of HydrizBot, a global bot, too). This pywikibot-script doesn't use a dump and will be started the first time with the option -start:! and then works alphabetically through all entries (only in namespace=0). To divide the work, other bots could start for example at -start:G, -start:m or something else. Greetings --Udo T. (talk) 20:33, 18 May 2017 (UTC)

I'll be using the dump and my own script. DTLHS (talk) 21:36, 18 May 2017 (UTC)

Ok, but it's completely unnecessary to use a dump because a bot has to edit almost all entries. --Udo T. (talk) 21:43, 18 May 2017 (UTC)

There are lots of entries that are only on enwikt. Using a dump means I don't have to query the site until I find a page that needs to be edited. DTLHS (talk) 21:47, 18 May 2017 (UTC)

I also have a custom framework that I use, and it doesn't really go alphabetically (since the dump is in pageid order). Is it possible to have the Python bot run in pageid order instead of alphabetical? I can change the way I am doing it, but as DTLHS mentioned there are hundreds of thousands of pages with no interwiki links, and it would be a bit more efficient to skip them. - DaveRoss 21:53, 18 May 2017 (UTC)

You could generate a list of pages to edit and then sort them alphabetically. DTLHS (talk) 21:57, 18 May 2017 (UTC)

I can do that, just have to rewrite some of the bot. Another question is how many edits per minute we should all have combined, presumably each of these bots could run at least three times as fast as they should run. - DaveRoss 23:47, 18 May 2017 (UTC)

Well I am somewhat limited by slow internet speed so I don't know how fast I could push it. I didn't realize we were in a hurry. DTLHS (talk) 00:01, 19 May 2017 (UTC)

I don't think there is a hurry, except that it would be nice to get the job done. - DaveRoss 00:16, 19 May 2017 (UTC)

I think we could use devs' help by using User:Conversion script or something similar. This way it would be much smoother. Note that 100k articles were renamed in just 30 minutes by Conversion script. --Giorgi Eufshi (talk) 06:37, 19 May 2017 (UTC)

Sorry, but I think then I can not support you. Because my Pywiki-bot runs either on Tool Labs or my own Linux server and I do not waste time downloading a gigabyte-sized dump, which is no longer up-to-date after 1 or 2 weeks. In addition, I have no problems with Internet speed, neither on Tool Labs nor on my own Linux server. With the Pywikibot framework you can, by the way, quietly change every 5 seconds, because a Pywiki-bot can be slowed down via API, if the load on the servers becomes too large. Another last tip: You should first set up a filter that prevents users from continuing to add interwiki links in entries. Take a look at User talk:Udo T.... Greetings from Austria --Udo T. (talk) 09:24, 19 May 2017 (UTC)

Not sure why downloading the entire uncompressed wiki via the API is more onerous than downloading the dump, but that is neither here nor there. I created an abuse filter which tags interwiki links that point at identically titled pages. We can flip it from tag to disallow at some point. - DaveRoss 22:40, 19 May 2017 (UTC)

Well since non-identical interwikis are not allowed at all, you could just simplify the filter to catch all interwikis. --WikiTiki89 20:57, 25 May 2017 (UTC)

We probably don't want to ban them until all the bugs are fixed in this poorly named extension. --WikiTiki89 20:58, 25 May 2017 (UTC)

I haven't had a chance to say this anywhere else, but it is by the way really awesome that we finally don't have to manually add interwiki links, and they just show up automatically. That's a real accomplishment!!!!! Thank you!!!!! PseudoSkull (talk) 18:57, 25 May 2017 (UTC)

I second that. bd2412 T 11:10, 26 May 2017 (UTC)

Something's broken... —Aryamanarora ^{(मुझसे बात करो)} 13:52, 29 April 2017 (UTC)

An anon messed with the "return labels" in Module:category tree/poscatboiler/data/terms by usage. I reverted the edit and protected the page. --Daniel Carrero (talk) 13:54, 29 April 2017 (UTC)

Great, seems good now! —Aryamanarora ^{(मुझसे बात करो)} 14:02, 29 April 2017 (UTC)

The headword of Reconstruction:Proto-Sino-Tibetan/p(r)an/t ~ b(r)an/t displays as "*t". We could add head=*p(r)an/t ~ b(r)an/t, but it would be better to update Template:head to handle cases where a page in the Reconstruction namespace uses a slash, the way it already handles pages in the main namespace that use slashes, like he/she. I don't think there are pages in the Reconstruction namespace that use slashes to form subpages (which is what the template is currently assuming is happening), are there? - -sche (discuss) 19:41, 29 April 2017 (UTC)

Actually all RC entries use a slash as a subpage. I think what you meant is that none of them have a second level subpage. Still, subpages are enabled in the RC namespace to allow for the first level subpages. I think it would be better not to use slashes in reconstructions, I don't even understand what the slash means here. --WikiTiki89 19:04, 1 May 2017 (UTC)

As a stopgap, it's possible to specify how the headword is supposed to look with head=. I've done that for *p(r)an/t ~ b(r)an/t now. —Aɴɢʀ (talk) 19:45, 1 May 2017 (UTC)

The basic issue is in Module:headword it's using mw.title.getCurrentTitle().subpageText as a starting point for generating the default headword. This is also used for generating various other defaults in modules, such as sort keys. subpageText takes the part after the last slash, but it takes into account whether a namespace has subpages or not, so it still works for the main namespace where subpages are disabled. A possible, but drastic, solution would be to just not use subpages for reconstructions anymore. —CodeCat 20:22, 5 May 2017 (UTC)

Instead of using subpages, we could remove the Reconstruction:language_name/ from the beginning of the pagename. That would solve the problem. — Eru·tuon 01:01, 6 May 2017 (UTC)

Done. Everyone, please let me know if the new code causes any problems. — Eru·tuon 01:18, 6 May 2017 (UTC)

It seems to be working. Excellent, thank you! That's a better and less drastic solution than renaming all the pages to not use subpages. - -sche (discuss) 01:55, 6 May 2017 (UTC)

This is perhaps something for BP, ES or WT:About Proto-Sino-Tibetan instead, but I'd like to note that having extensive punctuation in headwords is quite ugly and should perhaps be avoided. OP's example seems particularly egregious, using three different types of punctuation purely to indicate uncertainty in the reconstruction. --Tropylium (talk) 11:06, 8 May 2017 (UTC)

Yes, it's a bit confusing. Is it saying the form could have beem pan, pat, pran, prat, ban, bat, bran, or brat? Then why not write p/b(r)an/t? It would be good if the meaning of the punctuation was at least documented, with examples. - -sche (discuss) 18:47, 9 May 2017 (UTC)

Or better yet, just call it pran and list the alternatives on the page. --WikiTiki89 19:14, 9 May 2017 (UTC)

Hello, I was wondering if Wiktionary had a feature equivalent to wiki-blame or git-blame where we could see the page's text with editor name and edit date on the left, with possibly some color code (the redder the more recent etc). This would greatly improve time for locating editors responsible for certain changes. Thank you. —Julien D. (talk) 20:05, 29 April 2017 (UTC)

The official w:Wikipedia:WikiBlame works for Wiktionary too. I have too written it myself although it does not have that many options and mainly lacks binary search method. On a positive side mine uses newer API to fetch multiple pages (50 AFAICR) at once making it faster when the search method is set to linear.--Dixtosa (talk) 20:28, 29 April 2017 (UTC)

Thank you, your button works very well, but I couldn't make the wiki-blame page work. That said, it seems your button works on selected text only. Do you have a mode where the entire page is annotated line by line with author and date? —Julien D. (talk) 21:20, 29 April 2017 (UTC)

Can someone with a bot and/or AWB do null edits on all the categories in CAT:E? I suspect the system isn't going to clear them any time soon. Since this wouldn't constitute making changes to anything and won't show up in edit histories, even an unauthorized bot would do. Chuck Entz (talk) 21:10, 29 April 2017 (UTC)

 Done Either it cleared itself overnight, or someone did the null edits (if someone did- thank you!). If memory serves, it was fine the next day. Chuck Entz (talk) 02:47, 3 May 2017 (UTC)

@Chuck Entz I have a script for this that I can very easily run at any time. You can PM me whenever you need it done. —CodeCat 13:20, 11 May 2017 (UTC)

Sorry for the delay. I ran my bot to clear the category after seeing the request, but forgot to reply here after it finished. Wyang (talk) 13:26, 11 May 2017 (UTC)

Is this something we want? —suzukaze (t・c) 00:32, 1 May 2017 (UTC)

Obviously not, so I deleted it and protected it so DTLHS's bot doesn't recreate it. I don't know what to do with CAT:No script specified script characters, though, which is a bit more problematic. —Μετάknowledge^{discuss/deeds} 00:36, 1 May 2017 (UTC)

I mean, we should assign them to their respective scripts — in Module:scripts/data, I guess? Looking at ꜷ, is the Latin Extended-D block not already marked as Latin (Latn or Latinx) script? - -sche (discuss) 00:46, 1 May 2017 (UTC)

We could have Category:Unspecified script -- I mean, if there's any use for it, at least this name makes sense and can end with the word "script". --Daniel Carrero (talk) 01:24, 1 May 2017 (UTC)

This could be implemented by changing the canonical name for the code None in Module:scripts/data from "No script specified" to "unspecified". Then the category would be CAT:Unspecified script, as you propose. — Eru·tuon 03:44, 2 May 2017 (UTC)

Sure, thanks for linking to the data module. Now I've done just that. --Daniel Carrero (talk) 23:03, 4 May 2017 (UTC)

Would it be worth the trouble to add code suppressing the addition of "Script" when the script name already includes it? I believe we already do something like that with languages- at least I haven't seen anything like "American Sign Language language". Chuck Entz (talk) 03:08, 2 May 2017 (UTC)

At some point, I already added some code to treat "Morse code" as a script like Latin or Cyrillic for categorization and formatting purposes. The main category is Category:Morse code. It does not have the word "script" added, so it's not Category:Morse code script or Category:Morse script. So, we can do the same for other scripts if we want. --Daniel Carrero (talk) 03:14, 2 May 2017 (UTC)

The use of an incorrect parameter name (|script= rather than |sc=) in the Translingual entry for ɓ caused it to be categorized under Cat:Unspecified script characters rather than Cat:Latin script characters. I've fixed that by adding the incorrect parameter to Module:mul-letter as an alternative. Probably should fix the parameter and then remove the alternative. — Eru·tuon 09:10, 11 May 2017 (UTC)

A case for Module:parameters maybe? —CodeCat 13:20, 11 May 2017 (UTC)

@CodeCat: Yeah, that would be a good idea, though after I do an AWB run to change |script= to |sc=. — Eru·tuon 16:53, 11 May 2017 (UTC)

Gah, there are so many cases of {{mul-letter}} that I don't want to do this with AWB. — Eru·tuon 01:00, 12 May 2017 (UTC)