Wiktionary:Grease pit

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

August 2017

Alternatives for Template:reconstructed?[edit]

Is there any way that we could automatically show the message above all pages in the Reconstruction namespace? Then we wouldn't need to put {{reconstructed}} on all the pages manually anymore. —CodeCat 10:05, 1 August 2017 (UTC)

(Previous discussion: Wiktionary:Grease pit/2016/March#Template:reconstructed.) — Eru·tuon 05:58, 3 August 2017 (UTC)

MediaWiki:Gadget-TranslationAdder.js nests Gujarati under Aramaic[edit]

diff. --Anatoli T. (обсудить/вклад) 02:22, 4 August 2017 (UTC)

Quite bizarre. Neither the canonical name or the code would explain that. — Eru·tuon 03:27, 4 August 2017 (UTC)
And it's the 2nd it happened to me. Not sure I fixed it correctly the first time it happened. I thought it was replacing one language with another, not nesting. --Anatoli T. (обсудить/вклад) 03:34, 4 August 2017 (UTC)
Ohh, actually... I bet it's trying to put it before "Hebrew" – which it shouldn't, because Hebrew is just a script name nested under Aramaic. — Eru·tuon 03:57, 4 August 2017 (UTC)
@Dixtosa: Can you put this on your list of things to fix? — Eru·tuon 19:54, 7 August 2017 (UTC)
I think this fixed the bug. --Dixtosa (talk) 15:45, 12 August 2017 (UTC)

Maintenance category for quotes with translit but not native-script text?[edit]

Currently entries such as jb, which have quotations with transliteration but not the original native-script text, don’t seem to be put in any maintenance category, and they’re not categorized under the category of entries with usexes either (e.g. Category:Egyptian terms with usage examples), making them very hard to find. Could we perhaps make {{quote}}/{{ux}} automatically add them to the ‘… needing native script’ maintenance categories (e.g. Category:Egyptian terms needing native script) or make a new maintenance category for them? — Vorziblix (talk · contribs) 02:31, 4 August 2017 (UTC)

I think the "terms needing native script" is (theoretically) reserved for links to terms that would have entries. I've made Module:usex add the category Egyptian usage examples lacking native script (and the equivalent for other languages). The name can be changed if others object. I'll wait before adding it to the category-handling modules.
I guess the main question is which word we want: "needing", "lacking", "missing", something else? "Needing", which is used in the corresponding "term" category, would imply that ideally we want the native script to be supplied, whereas "lacking" does not. Maybe it would be best to switch, unless there are languages for which getting the native script isn't very important... — Eru·tuon 03:24, 4 August 2017 (UTC)
All right, thanks! I’m indifferent to the naming issue myself, but I’ll wait a while longer to see if anyone else comments before creating the category. — Vorziblix (talk · contribs) 21:24, 4 August 2017 (UTC)
I think "needing native script" is just fine for this. I don't think we need to distinguish links versus usexes. —CodeCat 21:27, 4 August 2017 (UTC)
@CodeCat: Yeah, but the category is "terms needing native script". I assume "terms" would be referring to links to entries, not to any old text. — Eru·tuon 21:32, 4 August 2017 (UTC)
True, maybe. Renaming the category is also a possibility. Is there a reason other than naming that favours splitting the two? —CodeCat 21:33, 4 August 2017 (UTC)
Not really. But subcategories for types of template might be useful, in case for some reason a person particularly wants to improve usage examples or quotes and not other categories of text in that language. — Eru·tuon 21:38, 4 August 2017 (UTC)

Font for Jawi (Arabic-script Malay)?[edit]

The current font for Jawi (Arab) doesn't display the Jawi-specific letters well. For example, {{m|ms|تڠن|tr=tangan}} produces تڠن (tangan) with disjointed ڠ, unlike the desired form of تڠن. Is it possible for this to be fixed? (Mac, Chrome) Wyang (talk) 08:28, 4 August 2017 (UTC)

While you're at it. Please check the Uyghur fonts. They are too small on most systems. --Anatoli T. (обсудить/вклад) 08:38, 4 August 2017 (UTC)
Yuck. I created a new script code ms-Arab for Malay in Arabic script, so more appropriate fonts can be selected for it in MediaWiki:Common.css. The typical Arab fonts probably don't have some of the extended characters. (Traditional Arabic, which I use, certainly doesn't.) — Eru·tuon 21:46, 4 August 2017 (UTC)
Woops. Could an admin add ms-Arab to the various lists of all Arabic script codes in MediaWiki:Common.css, so it doesn't display italicized? — Eru·tuon 21:48, 4 August 2017 (UTC)
Added. DTLHS (talk) 05:31, 6 August 2017 (UTC)
Why the heck is Arial Unicode MS so high in the .Arab font stack? There are better fonts out there. Investigating with BabelPad shows that Segoe UI, Tahoma, Microsoft Sans Serif are sans-serif fonts capable of displaying the text تڠن correctly. —suzukaze (tc) 07:04, 6 August 2017 (UTC)
  • Does someone at MW test font appearance on mobile devices, especially for less common languages? How is font delivery handled if the user's mobile device doesn't already have the font? (I focus on mobile devices because I imagine that PCs have abundant resources and techniques to accomplish the result.) DCDuring (talk) 23:38, 6 August 2017 (UTC)
    • MediaWiki has no input in Wiktionary's font choices. All the font-related CSS styles are locally hosted in MediaWiki:Common.css. Unfortunately, none of the script- or language-specific CSS styles apply in the mobile version. MediaWiki:Common.css contains all of them, and it is only loaded in the desktop version. MediaWiki:Mobile.css contains very little, none of it font-related. So, in the mobile version non-Latin-script mentions are italicized (example: أهلا وسهلا), many obscure scripts probably display as boxes, etc. — Eru·tuon 00:34, 7 August 2017 (UTC)
      The question arose in my mind because some anon using a mobile complained rudely about his phone being ruined by something or someone here. But the question of how fonts look on mobile devices is important. If we don't research it, we probably should rely on MW for that for mobile devices. DCDuring (talk) 04:32, 7 August 2017 (UTC)
      I don't understand what you mean. Doesn't a given font (say, Times New Roman) look roughly the same on a computer and on a tablet or phone?
      And as far as I know MediaWiki has nothing to do with font selection. There might be a default font for the site, but besides that and the font selections that we have added to our CSS pages, browsers are what select which fonts are used for which characters. And they in turn can only select fonts that the user actually has on their device (ignoring web fonts). Avestan, for instance, seems to be unrecognized by my browser; I have the right fonts, but they only show up if the Avestan text is explicitly marked as Avestan (class Avst) and if our Common.css is loaded. So, anyway... I'm not aware of anything that MediaWiki can do for us. — Eru·tuon 05:30, 7 August 2017 (UTC)

I do not support Arial Unicode MS. Although, it may be useful for basic users but it is created for ages, given free with Office, less glyphes and no any update. Its rendering is also awful. Other fonts like Arial, Microsoft Sans Serif, Segoe UI, Times New Roman are okay. --Octahedron80 (talk) 01:09, 20 August 2017 (UTC)

Automatic listing of languages that use a transliteration module[edit]

Transliteration module documentation pages will now automatically list all languages that use the module, as long as the module is listed either in the language's data file or in the data module Module:translit-redirect/data. The module will also have a category added for each language. Till now, categorization was inconsistent for modules used by more than one language.

Also, for curiosity's sake, modules are categorized by how many languages use them. The record seems to be held by Module:Ital-translit, which is used by 12 languages.

The system isn't perfect: some languages have a dedicated module for one of their scripts, but also redirect to another module. There's no way for Module:languages/byTranslitModule to detect those, as far as I know. — Eru·tuon 05:19, 6 August 2017 (UTC)

Headword templates that should be converted to use Template:head[edit]

{{sco-proper noun}}, {{scn-adj}}, {{sw-inf}}, {{rom-adj}}, {{mt-possessive pronoun}}, {{lv-adj}}, {{kj-noun}}, {{id-proper noun}}, {{hil-verb}}. Some of them have very complicated logic if you're looking for a challenge. DTLHS (talk) 00:34, 7 August 2017 (UTC)

Template:eo-head issue[edit]

On damoj, the entry is ending up in Category:head tracking/unrecognized pos because it has "plurale tantum" as part of speech category. This isn't a part of speech category, so it should be changed to "noun". —CodeCat 12:21, 7 August 2017 (UTC)

Fixed. —Aɴɢʀ (talk) 14:27, 7 August 2017 (UTC)
I wouldn't call that a fix. Also, there's many more Esperanto entries in that category with the same issue. —CodeCat 16:24, 7 August 2017 (UTC)
@CodeCat, Mx. Granger: Well, it looks to me like MOD:eo-headword needs to be fixed. It shouldn't be hard for {{eo-noun}} to be able to figure this out without arguments. —Μετάknowledgediscuss/deeds 21:28, 7 August 2017 (UTC)
It could be done that way, or "plurale tantum" could be specified using the label template and not through the headword template. — Eru·tuon 21:35, 7 August 2017 (UTC)
I've reverted Angr's edits, which resulted in displaying incorrect inflection information. I don't have an opinion on what the template syntax should be, but the entry should display something like "accusative damojn", not "accusative singular damoj, plural damoj, accusative plural damoj". —Granger (talk · contribs) 23:24, 7 August 2017 (UTC)

Template:mul-semaphore letter, Template:mul-morse letter and Template:mul-morse number issue[edit]

As above. The template is specifying an invalid lemma category. —CodeCat 12:31, 7 August 2017 (UTC)

Applying Vietnamese sortkeys[edit]

@Fumiko Take, Wyang: The Vietnamese sortkey module has been created, but there are lots of pages with categories added using wikilinks. If they have any diacritics, they will not be correctly sorted. @DTLHS has said that he has a bot script that can convert all these categories to templates, which would apply the correct sortkeys. Would the Vietnamese editors (I don't know who they are, besides @Fumiko Take) be in favor of that? — Eru·tuon 20:01, 7 August 2017 (UTC)

Yes, absolutely. Wyang (talk) 21:22, 7 August 2017 (UTC)
It's done. DTLHS (talk) 04:11, 11 August 2017 (UTC)

I've made Module:vi-sortkey use Module:zh-sortkey (which should perhaps have been titled Module:Hani-sortkey) when it receives Han characters, because that seems to be the way Vietnamese Han characters and its subcategories are already sorted, for the most part. — Eru·tuon 04:43, 11 August 2017 (UTC)

Interwiki RecentChanges[edit]

Some days ago, the interwiki links disappeared from the Special:RecentChanges page on (as far as I can see) all languages of Wiktionary, Wikipedia and other projects. What's up? A bug? --LA2 (talk) 20:49, 7 August 2017 (UTC)

I have not heard anything about this. Also no longer on the Special:Watchlist. Maybe WikiMedia removed the link-hub page (or whatever they call that page, the wikidata site-links). I don't think there is any need for interwikis from Special:RecentChanges or Special:Watchlist, so maybe they simply removed the site-links page. —Stephen (Talk) 18:34, 8 August 2017 (UTC)
I noticed that it's also gone from Wikipedia (I don't often look at their recent changes so I don't know if it was removed at the same time). DTLHS (talk) 18:37, 8 August 2017 (UTC)
See phab:T172461. --Vriullop (talk) 10:51, 24 August 2017 (UTC)
As a workaround, an admin can move interwiki links from MediaWiki:Recentchangestext to MediaWiki:Recentchanges-summary. It works on ca:Special:RecentChanges. --Vriullop (talk) 19:31, 25 August 2017 (UTC)
Done, and it looks like the interwiki links have returned. - TheDaveRoss 19:36, 25 August 2017 (UTC)
Now, suddenly, they are back on Swedish, Russian, and Ukrainian Wiktionary too. I don't know how that happened, but I'm quite sure they weren't there yesterday. --LA2 (talk) 01:08, 8 September 2017 (UTC)

xx[edit]

Almost every day some version of xxx gets added. Can we automatically prevent the addition of terms containing two or more adjacent x characters? SemperBlotto (talk) 05:04, 8 August 2017 (UTC)

The xx's seem to be from random mobile users in countries that don't use the Latin script- mostly Arabic or Persian, with a few Thai. I suspect that most of it is some kind of misapplied phone-OS navigation commands, but the evidence is inconclusive. It's all in the past year or so, so perhaps there's some kind of new dictionary app that's dumping users here with telling them they're editing a dictionary.
There's already a filter to prevent adding small amounts of text with nothing but x's, but it doesn't seem to catch this. I've now added a separate filter for article creations. Please tweak or fix. Chuck Entz (talk) 13:51, 8 August 2017 (UTC)
It's people in India etc. trying to find porn. The titles often indicate this, "xx video", "xx sex" etc. Equinox 17:33, 8 August 2017 (UTC)

Dutch male/female gender[edit]

I think this is the right place. I just edited ex#Dutch and added {{nl-noun|mf|exen|exje}} just like the Catalan entry above it. But unlike the Catalan entry, it now says (question mark) "gender incomplete". It isn't! I entered "mf" (male/female) which is correct! See http://woordenlijst.org/#/?q=ex for evidence. This is not the same as neutral gender. An example of neutral gender is http://woordenlijst.org/#/?q=project. Template:nl-noun seems to have no option to have mf gender. W3ird N3rd (talk) 18:55, 9 August 2017 (UTC)

Fixed. You don't have to flip out when you don't know how to do something. --WikiTiki89 18:58, 9 August 2017 (UTC)
Thanks. I'm not really flipping out, but I suppose it can come across like that. If I'm flipping out at all, it's not towards any person here but just towards the templates which nicely convert mf to "m, f" for Catalan but won't do the same thing for Dutch. W3ird N3rd (talk) 19:11, 9 August 2017 (UTC)
"mf" is a specific exception in the Catalan templates. It's not supported by templates generally. —CodeCat 19:03, 9 August 2017 (UTC)
I think the nl-noun template (and any others for languages where mf is possible) should have the mf option added, or the option should be removed from the Catalan template if it's not standard so you don't get unexpected results like I did. W3ird N3rd (talk) 19:11, 9 August 2017 (UTC)
Isn't c how such things are usually marked? —Aɴɢʀ (talk) 20:10, 9 August 2017 (UTC)
c means that the gender is masculine or feminine, but the creator of the entry doesn't know which because they speak a two-gender variety of Dutch. —CodeCat 20:13, 9 August 2017 (UTC)
Yeah, common gender refers to a merger of masculine and feminine genders, not to nouns that can be either masculine or feminine. --WikiTiki89 20:37, 9 August 2017 (UTC)
There isn't any requirement that template parameters have to be standardized. But it might be easier to add |1=mf as an option for {{nl-noun}} than to remove it from the Catalan template, depending on how much mf option is used. — Eru·tuon 21:47, 9 August 2017 (UTC)
{{es-noun}} accepts the parameter too. —Granger (talk · contribs) 21:51, 9 August 2017 (UTC)
I'd rather remove it from Catalan. —CodeCat 22:19, 9 August 2017 (UTC)
It seems {{pt-noun}}, {{it-noun}}, and {{fr-noun}} accept it too. That makes at least five templates we'd be removing it from, maybe more. Moreover, the syntax "mf" is more intuitive than "m|g2=f", in my opinion. I think we should keep the option for the templates that have it and consider adding it to {{nl-noun}}. —Granger (talk · contribs) 22:39, 9 August 2017 (UTC)
They're all Romance languages. Compare that to the many languages whose templates do not allow it. And the most important of all, {{head}}. I can only support this kind of "standardisation" if it can be applied to {{head}} as well. Otherwise the consistency argument is moot. —CodeCat 22:57, 9 August 2017 (UTC)
"There isn't any requirement that template parameters have to be standardized."
There's no requirement for me to eat pizza either, but it sure would be nice. Since {{nl-noun|m|g2=f|g3=n|g4=p|-en|exje}} is also supported, is there a technical reason not to support any combination like {{nl-noun|pmnf|-en|exje}}? I know this example is nonsense, but so is the variant with g2g3g4, this is just easier for multiple genders. Unless of course combinations other than mf simply don't exist in any language, in that case it's more sensible to just support mf. W3ird N3rd (talk) 22:46, 9 August 2017 (UTC)
I've checked a few. (not all) Besides {{pt-noun}}, {{it-noun}}, {{es-noun}}, and {{fr-noun}} this is also supported by {{lv-noun}}, {{ast-noun}}, {{vec-noun}}, {{cy-noun}}, {{gl-noun}} and {{frm-noun}}.
These require g= for any gender but do support mf: {{yi-noun}}, {{ur-noun}}, {{bg-noun}}
These do not support mf but for I don't know if mf would be valid for these languages anyway: {{la-noun}}, {{lt-noun}}, {{wa-noun}}, {{sv-noun}}, {{sh-noun}}, {{gd-noun}}, {{rom-noun}}, {{ar-noun}}, {{osx-noun}}, {{mt-noun}}, {{lb-noun}}, {{ga-noun}}, {{el-noun}}, {{got-noun}}, {{fur-noun}}, {{fo-noun}}, {{ovd-noun}}, {{cs-noun}}, {{br-noun}}, {{be-noun}}, {{sq-noun}}, {{mk-noun}}
W3ird N3rd (talk) 23:42, 9 August 2017 (UTC)

Template:case-gov[edit]

I have created a new template to categorize prepositions based on which case they govern, as a way to help clean up the "(+ accusative)" stuff lying around. Anti-Gamz Dust (There's Hillcrest!) 02:58, 10 August 2017 (UTC)

We already have {{+preo}} for this purpose. —CodeCat 09:43, 10 August 2017 (UTC)
"Module is unfinished"? Anti-Gamz Dust (There's Hillcrest!) 09:56, 10 August 2017 (UTC)

Template:ga-noun creating spurious "whatlinkshere"s (but only three?)[edit]

Check out Special:WhatLinksHere/~a and Special:WhatLinksHere/~e. There are hundreds of pages there, all of which use {{ga-noun}} and the parameter |~a or |~e. However, if you look at the actual pages, they don't have links to ~a and ~e, because the template knows to convert them to [[{{PAGENAME}}a]] and [[{{PAGENAME}}e]]. So why are the "whatlinkshere"s being created? And how can we stop them from being created? To make the phenomenon even weirder, {{ga-noun}} uses other similar shortcuts like |~í, but those aren't creating spurious "whatlinkshere"; Special:WhatLinksHere/~í is empty, even though that parameter is also used on hundreds of pages. What gives?Aɴɢʀ (talk) 14:23, 10 August 2017 (UTC)

Special:WhatLinksHere/~ is also populated by a large number of pages using {{ga-noun}} but without actual links to [[~]]. —Aɴɢʀ (talk) 14:55, 10 August 2017 (UTC)

@Angr: I think it is the line {{#ifexist:{{{2|{{{3|{{PAGENAME}}}}}}}}||[[Category:Missing Irish noun forms]]}}. If the input to {{ga-noun}} is {{ga-noun|m|g2=f|~a|~aí}}, this would mean that the code checks to see if [[~a]] exists (and, it doesn't). —suzukaze (tc) 06:23, 17 August 2017 (UTC)
@Suzukaze-c: I could see that that would populate CAT:Missing Irish noun forms even when the noun forms aren't missing, but it's still weird that it would create imaginary links to [[~a]]. Anyway, I'm not a fan of Category:Missing Irish noun forms anyway (it seems really useless to keep track of that, especially when it only looks at the headword line and not at the inflection table), and the person who created it has been blocked indefinitely, so I'm tempted to just remove that bit of code. —Aɴɢʀ (talk) 08:28, 17 August 2017 (UTC)
I have removed the code. —suzukaze (tc) 08:40, 17 August 2017 (UTC)
@Angr #ifexist counts as a link. The same with its Lua equivalent. —CodeCat 11:14, 17 August 2017 (UTC)

What are the advantages to the Reconstruction namespace?[edit]

(Apart from letting us adhere to the letter of the rule "only attested terms in mainspace"). A user on da.wikt may be interested in adding reconstructions (which we currently do not have there), but was unsure how to do so. If we all use special namespaces, we can use sitelinks, but da.wikt and eo.wikt (and probably many other versions) do not even currently have appendices. If we all use mainspace (and the same transcription standards), we can let Cognate do all the work. If neither of those, we need to go back to interwikilinks (which is not currently being maintained, see e.g. Reconstruction:Proto-Indo-European/deywós/es:*deywós).
So, what are the advantages?__Gamren (talk) 14:40, 10 August 2017 (UTC)

We find it useful to have reconstructions in a dedicated namespace; the solution at es.wikt, for example, marks reconstructions with the asterisk in namespace and thus confuses them with something like *band (yes, that is a word in English). For us, linking between Wiktionaries is a somewhat secondary concern, and also one that will probably be solved fairly soon for all namespaces, I think. —Μετάknowledgediscuss/deeds 17:28, 11 August 2017 (UTC)
The original reasoning for not putting reconstructions in the main namespace was that they are not attested and therefore do not pass CFI. --WikiTiki89 17:34, 11 August 2017 (UTC)
The asterisk * is not really a part of the reconstructed word, so it is an improvement to omit it in the article title. If we put Reconstruction:Proto-Indo-European/deywós at *deywós, it could be taken to indicate that the asterisk was part of the orthography, as it is in English words beginning with an asterisk. — Eru·tuon 21:00, 11 August 2017 (UTC)

Some questions about adding audio recording of words pronunciation[edit]

Hi, I'm from the Hebrew Wiktionary team. I also took part in writing a site for easy recording of mass of words from a lists: https://lingualibre.fr/ (only French UI at the moment).

I wanted to know whether there is already an extension or a bot for uploading audios of words pronunciation to wiktionaries ? I think that an extension where users can record words and add it directly from the wikitionary page just like with editing, could be really cool.

Also, there is this site of words pronunciation forvo , I wanted to know if it is allowed to write a bot that import audio from there to wikicommon?

Thanks —This unsigned comment was added by Shavtay (talkcontribs) at 12:43, 11 August 2017‎ (UTC).

@Shavtay: Try User:Yair rand/AddAudio.js. --Yair rand (talk) 19:16, 14 August 2017 (UTC)
@Shavtay About Forvo, its CC license is not compatible with Commons. Many files from Forvo have been deleted, like these. — justin(r)leung (t...) | c=› } 16:23, 7 September 2017 (UTC)

Editor2 and TabbedLanguages2[edit]

What are these? Who uses them? Should they be included in legacyscripts gadget? It says it was added temporarily. @Yair rand, what are the development stages of these two scripts? Dixtosa (talk) 17:21, 11 August 2017 (UTC)

@Dixtosa: TabbedLanguages2 works, editor2 may or may not still work. Both are also available as gadgets. We actually had a vote pass back in 2012 to turn on TabbedLanguages for all users, and that was going to happen as soon as someone could write a bot to make sure that categories were placed in the right sections, so that readers wouldn't have relevant categories hidden in other sections. That never ended up happening, afaik. The (intended to be) temporary script added in Common.js (later moved to legacyscripts) allow adding simple enable/disable buttons so that users could easily test the scripts in the intermediary period. I don't know if anyone still has it enabled only through the legacyscripts mechanism, but I suppose we could change it to just enable the gadgets for any remaining users using it that way, and then remove the bit from legacyscripts. --Yair rand (talk) 18:30, 14 August 2017 (UTC)
@Yair rand, so which tabbedlanguage is newer the one in your userspace or in the MW namespace? Also TL2 uses langrev templates which we decided to delete and I am set to replace all the remaining uses from active user scripts. So should I touch it too? And what do we do about editor2?BTW, TL2 does not work for me when I enable it from the page you linked. I use Chrome 60 and there are no js errors. BTW2, editor is a terrible name Conrad called TranslationAdder editor and in the code there is a class called Editor. Dixtosa (talk) 20:09, 22 August 2017 (UTC)

Collapsible table initially displaying “Collapse” when it is collapsed[edit]

For example, the homophone table inside {{zh-pron}} on 勢力 is displaying “Collapse” when it should be “Expand”. The table makes use of the collapsible element wikitable mw-collapsible mw-collapsed and the code is housed at the bottom of Module:cmn-pron. Is there a way to fix this? Wyang (talk) 22:29, 11 August 2017 (UTC)

It seems the collapsible table of {{zh-pron}} is interfering with this subtable. Perhaps id="..." could fix this. Wyang (talk) 22:52, 11 August 2017 (UTC)

Language-specific alphabetisation[edit]

I was about to add the information for how to sort Hausa entries when I realised that I still don't know how to solve a long-running problem. I want the letter ɓ to alphabetise after b but before c; this could be achieved by telling the module to sort ɓ as bz, but I also want it to be in a separate section in the categories, since it is considered a separate letter in Hausa. Is this currently possible? If not, could we submit a Phabricator request to make it possible? It would be useful for a great many languages. @ErutuonΜετάknowledgediscuss/deeds 05:28, 12 August 2017 (UTC)

It is possible with new sortkey functionality (Module:vi-sortkey for example). The main annoyance is you have to make sure all categories are routed through the sortkey module, so categories must be templatised in {{C}}, etc. DTLHS (talk) 05:43, 12 August 2017 (UTC)
@DTLHS: When I look at, say, CAT:Vietnamese verbs, words starting with đ are still under D, despite that being a separate letter. I'm saying that I want there to be a Đ section after the D section, if that makes sense. —Μετάknowledgediscuss/deeds 05:49, 12 August 2017 (UTC)
Sorry I misunderstood. I think that this is not currently supported except as a configuration setting for the entire wiki (see [1]) DTLHS (talk) 06:04, 12 August 2017 (UTC)
Extremely hacky dumb solution: you could create a new alphabet that you would sort under (let a = 0, b = 1, ɓ = 2, c = 3, etc), then everything would be in the correct order but the collation headings would be meaningless. DTLHS (talk) 06:51, 12 August 2017 (UTC)
I think that would be worse. Do you think you could file a Phabricator request for category-specific collation? Even if it's not likely to happen any time soon, it would be good to let them know that we could really use it. —Μετάknowledgediscuss/deeds 06:53, 12 August 2017 (UTC)
I second that. It would be a wonderful feature. Having a way to treat digraphs and trigraphs as single letters and to give them their own sections would also be nice – for instance, for Hungarian. That would probably be more difficult than changing the order of the single letters, though. — Eru·tuon 07:20, 12 August 2017 (UTC)
@DTLHS: Make it even more hackier by making fake entries that will be converted to headers using JavaScript. 👍 —suzukaze (tc) 07:14, 12 August 2017 (UTC)
Maybe we should poke the devs some more. They were supposed to have custom collations done ages ago. —CodeCat 10:22, 12 August 2017 (UTC)
I'm thinking the idea related to digraphs could work. In the sortkey, we would convert each digraph or trigraph (or tetragraph, pentegraph) to an arbitrary character that doesn't appear in entry names. Then the new extension would correctly order the sortkeys using a language-specific collation order, and it would generate the headings by converting the arbitrary characters back into the digraphs and trigraphs that they represent.
For instance, dzsessz (jazz) could have the sortkey ₁e₂₂, in which represents the trigraph dzs and represents the digraph sz. (I'm not sure if this is the way a Hungarian dictionary would handle the double consonant ssz. Maybe the sortkey should use s₂ instead.) would be ranked after e in the extension, while would be ranked after s. And instead of placing the entry dzsessz under the heading , it would convert that symbol back to DZS and use that as the heading instead.
This would require that the collation extension be coordinated with whatever Lua module generates the sortkeys (currently, for most languages, Module:languages combined with the sortkey data from the language's data table). That is, whatever generates Hungarian sortkeys would have a list of correspondences between the digraphs or trigraphs and the arbitrary characters chosen to represent them in sortkeys, and the collation extension would have, in its data for the language code hu, an identical list to convert back from the sortkey characters to the digraphs or trigraphs. — Eru·tuon 18:10, 12 August 2017 (UTC)
@Erutuon: That would be every more amazing. But as I keep saying, I need someone else (like you) who can explain this well to file a Phabricator request... —Μετάknowledgediscuss/deeds 18:50, 12 August 2017 (UTC)
The proper solution is to have custom collation for each category. That way, we don't need to bother with sort keys anymore. —CodeCat 19:23, 12 August 2017 (UTC)
We would still need sortkeys, unless the custom collation can somehow create the same effect as the complex sortkeys that we use for Coptic and Vietnamese (see Module:cop-sortkey and Module:vi-sortkey). — Eru·tuon 20:17, 12 August 2017 (UTC)
Also I think it would be preferable in at least some cases to handle digraphs, trigraphs, etc. through sortkeys, rather than having the collation extension automatically consider all possible instances of the correct group of letters as a letter: I suspect that there are languages in which a sequence of letters is sometimes a digraph and sometimes not.
For instance, Serbo-Croatian nadžíveti and pódzēmlje might have instances of d + ž and d + z rather than the digraphs and dz, as the d is at the end of a prefix. I could be wrong about this specific instance. But if there are any examples like this, they would have to be handled by manual sortkeys. — Eru·tuon 00:07, 13 August 2017 (UTC)

Some help developing my Mongolian headword module[edit]

Here it is: Module:User:Crom_daba/mn-headword. I'm testing it on User:Crom_daba/Sandbox, but for some reason the noun won't display the given head parameter while the verb seems to work fine. Their implementation looks the same to me, what am I not seeing?

"heads" not "head" on line 75. DTLHS (talk) 20:45, 12 August 2017 (UTC)
Gotta love how a fresh pair of eyes can save hours of debugging. Crom daba (talk) 20:50, 12 August 2017 (UTC)

Bug in "+Add new rhyme" feature[edit]

The "+Add new rhyme" feature sorts the words using a case-sensitive (Linux-style) sort, so that when, say, adding "dismember" as a rhyme for "November", "dismember" will be listed after "November" instead of before. The sort needs to disregard case. — Paul G (talk) 15:54, 13 August 2017 (UTC)

Sorting is disregarded on save anyways. It never respected sorting. --Dixtosa (talk) 16:42, 13 August 2017 (UTC)
Fixed it anyways. Dixtosa (talk) 16:49, 13 August 2017 (UTC)

Transliterating inflections[edit]

Could we allow for a way to have inflections transliterated by Module:headword if so requested? I'm making a Mongolian headword module, and I think it would be nice if I could display the transliteration of Uighur script, compare the current state with my module. Crom daba (talk) 18:59, 13 August 2017 (UTC)

Can't you do this with the f1tr, f2tr... parameters, or am I misunderstanding? DTLHS (talk) 19:04, 13 August 2017 (UTC)
Arabic already does this, so the support for it exists in Module:headword. I'm not sure what's needed to get the transliterations to appear. —CodeCat 19:10, 13 August 2017 (UTC)
Here's how this support looks (line 281) tr = part.translit or ((not (parts.enable_auto_translit or data.lang:getCode() == "ar")) and "-" or nil) Crom daba (talk) 23:15, 13 August 2017 (UTC)
I'll update the documentation. Crom daba (talk) 23:17, 13 August 2017 (UTC)
@Erutuon That specific exception for Arabic should probably go, so it can use the generic code. —CodeCat 19:05, 14 August 2017 (UTC)
@CodeCat: Done. Also, @Crom daba, I made it so that you can enable transliteration for all inflections by placing enable_auto_translit = true in the data.inflections table. That's more convenient than having to add enable_auto_translit = true to every inflected form in the table. — Eru·tuon 19:44, 14 August 2017 (UTC)
It would be preferred to only have one way to do it. Are there any modules that use the "old" code? —CodeCat 19:48, 14 August 2017 (UTC)
From a wikitext search, it looks like Module:yi-headword is the only non-sandbox module to use it. The question is if all inflected forms are supposed to have transliterations or not. — Eru·tuon 19:52, 14 August 2017 (UTC)
In the case of Module:mn-headword, only alternative script should be transliterated. Crom daba (talk) 20:08, 14 August 2017 (UTC)
In that case, I guess both ways of turning on transliteration should exist. — Eru·tuon 20:45, 14 August 2017 (UTC)

Watchlist options[edit]

I'm using Firefox browser with the Vector skin. For the past week or so, I have had trouble with the Watchlist options (appears at the top of the Special/Watchlist page. In the options, you can select your watchlist according to various lengths of time, such as 1 day, 3 days, 7 days, and so on:
Watchlist options
Legend:
Below are the last 250 changes in the last 72 hours, as of 14 August 2017, 11:20
The problem that I'm having is that, no matter which number of days I select, 1, 3, 7, or 30, I still get the same "last 250 changes in the last" list. It's the weirdest thing. —Stephen (Talk) 11:28, 14 August 2017 (UTC)
That is a technical limitation. Watchlist and recent changes have always had this limitation. Giorgi Eufshi (talk) 11:57, 14 August 2017 (UTC)
Something has changed. Not sure what it is, but for years I have been able to change my default watchlist of 24 hours to 3 days, and I would always see a list of triple length, with such headers as 14 August 2017 (partial day), 13 August 2017 (full day), 12 August 2017 (full day), 11 August 2017 (partial day). No longer. Now all I get is about 14 hours, regardless of how many days I tick. At this moment, even if I select the last 30 days, all I get are the 13 hours corresponding to 14 August, plus one hour of 13 August, beginning with скорее‎, 23:26 (13 August 2017). No matter how hard I try, I cannot see the full list for 13 August 2017, 12 August 2017, or 11 August 2017. —Stephen (Talk) 13:35, 14 August 2017 (UTC)
Okay, I have figured out the problem. It seems that something (it wasn't me) has changed a quantity in my Preferences. I looked in Preferences > Watchlist, and there is a box called Maximum number of changes to show in watchlist. It was set at 250, which is the number that I have been seeing for the past week regardless of the number of days I selected. I reset it to 1000, and now I'm seeing what I have been accustomed to see. —Stephen (Talk) 13:44, 14 August 2017 (UTC)

Edit filter to block edits that add interwikis[edit]

diff. Can we get an edit filter to stop edits such as these? The filter should actually stop the edit, not merely warn. —CodeCat 21:19, 14 August 2017 (UTC)

Category:Plurals with a red link for singular[edit]

Would it make sense to split this category into multiple ones - one for each language? SemperBlotto (talk) 13:40, 15 August 2017 (UTC)

Yes, it would make it easier to find entries in the language(s) one is interested in. Each one should go in that languages "entry maintenance" category too. —Aɴɢʀ (talk) 14:32, 15 August 2017 (UTC)

Wanted: Gadget to speed linkification[edit]

As I add taxonomic names, I try to linkify any existing entry (actually L2 section) that uses the taxon, but does not link to it. It would be a help to be able to do that, say, from the entry page or from an entry creation page, without have to type the entry name and to obtain a list only containing the taxon not already linked. It would be nice if not only bare links, but also taxa enclosed in templates such as {{taxlink}}, {{m}}, {{l}} were excluded.

It would seem likely that it be possible. Obviously, it would be a resource hog for terms of wide use, like letters, many short words, and function words. Perhaps short terms in Latin and similar scripts at least could be excluded. Would it still be a resource hog? DCDuring (talk) 21:01, 15 August 2017 (UTC)

Number of modules invoked and Lua memory errors[edit]

Part of the reason for so much Lua memory usage is the number of modules that are required or have their data loaded in another Lua module, because there is additional memory used by the require() or mw.loadData functions beyond the size of the module itself.

I don't know how much memory each one requires. I thought it might be a half megabyte based on a test I did once, but that could be wrong. If anyone more digitally astute can find a way to get a more precise figure, that would be nice.

The memory used to transclude each module might explain why pages like air, which invokes 69 transliteration modules, mostly in the Translations sections, use so much memory. (Air is currently at 47.95 MB, and it went over the limit until recently, when I switched many of the Latin translations to the non-Lua template {{t-simple}}.)

Some of this memory could be freed up, then, by merging some of the transliteration modules, so that fewer modules have to be transcluded. There are some candidates that I noticed when I was going through the transliteration modules reformatting and simplifying the code. First, there are quite a few non-Slavic Cyrillic-script transliteration modules, probably for languages spoken in the former Soviet Union, that have similar code for handling iotated vowels. These could be merged to a single module with a bunch of tables for language-specific replacements. Second, there are a number of modules for languages using Canadian syllabics that are really small; they should be combined with the main module. Third, any modules that simply replace each letter with its Latin equivalent (Module:Phnx-translit, Module:Cher-translit) could be easily handled by a single module.

Merging the modules would make it somewhat harder to find the module for a particular language: instead of typing the language code and -translit, people will have to navigate to the correct module using the Modules by language categories. That's already the case for certain modules that are titled with script rather than language codes (for instance, Module:Armn-translit), so it's not a problem in my opinion.

This proposal wouldn't finally solve the memory problem, but would at least defer the final reckoning. — Eru·tuon 22:13, 15 August 2017 (UTC)

Tabbedlanguages miscategorising at ؟[edit]

@Dixtosa On this entry, Category:Arabic block and Category:Arabic script characters are placed under the Arabic tab, but these are actually added by the Translingual section and belong there. —CodeCat 19:34, 16 August 2017 (UTC)

Bot request: remove the |style= parameter from {{ja-kanji}}[edit]

It is a deprecated parameter (that was theoretically never necessary in the first place, with clever enough code...). —suzukaze (tc) 06:15, 17 August 2017 (UTC)

I think |rs= can also be removed, since Module:ja now invokes Module:zh-sortkey to get the radical and stroke number, if it wasn't added to the template. — Eru·tuon 06:45, 17 August 2017 (UTC)
Theoretically, yes. Technically, Japanese requires a new module (maybe even all of the 漢字文化圏 languages...) due to Han unification combining codepoints for characters whose local variants may have varying numbers of strokes. —suzukaze (tc) 07:12, 17 August 2017 (UTC)
Removed style= from entries. DTLHS (talk) 19:48, 17 August 2017 (UTC)

"Declension", "Personal forms" or what - a question to grammar wizards[edit]

In Finnish there's a class of adverbs that require a possessive suffix which reflects the person of the subject of the sentence. For example, hyvillään (pleased):

Olen hyvilläni. I'm pleased.
Olet hyvilläsi. You are pleased.
Hän on hyvillään. He/she is pleased.
Olemme hyvillämme. We are pleased.
Olette hyvillänne. You are pleased.
He ovat hyvillään. They are pleased.

A comprehensive list of this type of adverbs can be found here: Special:WhatLinksHere/Template:fi-decl-pred-adv.

On each of these pages there's a table showing these forms. The header for the table is currently "Declension". I wonder if that is the correct term, or should the header be something else, like "Personal forms". --Hekaheka (talk) 07:42, 18 August 2017 (UTC)

"Inflection". It works for everything. —CodeCat 10:04, 18 August 2017 (UTC)
I agree. I don't use "Inflection" much, but I do use it for the inflected prepositions of the Celtic languages (e.g. wrth#Inflection). —Aɴɢʀ (talk) 12:45, 18 August 2017 (UTC)
I use "Inflection" for all situations. There's no need to differentiate when they are the same thing. The division between declension and conjugation is Eurocentric anyway. —CodeCat 12:19, 19 August 2017 (UTC)
Or Indo-Euro-centric? The distinction works for Indo-Aryan languages at least. —Aryaman (मुझसे बात करो) 20:14, 19 August 2017 (UTC)

Current font size for the title of Hani-script entries[edit]

is IMO a bit too big (to the extent that it becomes a little frightening); e.g. 獼猴桃. Wyang (talk) 12:04, 19 August 2017 (UTC)

.firstHeading .Hani { font-size: inherit; }. —suzukaze (tc) 23:44, 19 August 2017 (UTC)

Quotations dropdown has changed appearance[edit]

The quotations dropdown [quotations ▼] has changed somehow, with less horizontal space between it and the preceding line of text. Why is that? Equinox 13:29, 19 August 2017 (UTC)

I have moved toggling functionality from the gadget legacy scripts to the main Common.js and changed them a little bit too. But I do not know why the appearance changed. Anyways, I tried to style it as it was before. Is it better?--Dixtosa (talk) 14:24, 19 August 2017 (UTC)
The only difference I see is it is slightly larger. DTLHS (talk) 21:27, 19 August 2017 (UTC)
Can we convert the display of Module:nyms to a similar dropdown appearance too ([synonyms ▼] or something)? Wyang (talk) 00:45, 20 August 2017 (UTC)
That seems impossible since presumably each different line is its own template invocation (one for synonyms, antonyms, ...). DTLHS (talk) 01:05, 20 August 2017 (UTC)
Perhaps feasible by assigning class to each of the templates and using Javascript to convert it to a dropdown? Wyang (talk) 01:14, 20 August 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── This may be related – I've noticed that the "quotations" link is not working properly. Even though I have "Show quotations" activated and the link suggests that quotations are being shown, they do not in fact appear. I have to click the link twice – once to hide quotations, and again to show them – to make them appear. However, the choice is not remembered when I move on to another entry. — Cheers, JackLee talk 12:45, 20 August 2017 (UTC)

@Jacklee, what browser are you using?Dixtosa (talk) 12:51, 20 August 2017 (UTC)
I'm having the issue with both Mozilla Firefox and Safari on my mobile device. — Cheers, JackLee talk 13:18, 20 August 2017 (UTC)
No one else is experiencing this? — Cheers, JackLee talk 00:41, 22 August 2017 (UTC)
@Jacklee @Dixtosa, I am (Chrome). It's extremely annoying. Ƿidsiþ 09:43, 2 September 2017 (UTC)
@Jacklee, Widsith I have simulated iphone on my desktop Chrome and I do not see any problem :(. Are you using mobile version of the site (prefixed with m. by any chance? Dixtosa (talk) 12:23, 2 September 2017 (UTC)
No, I'm using the desktop version of the site. I'm still experiencing the problem with the latest version of Mozilla Firefox on Windows 10, and with Safari on iOS. — Cheers, JackLee talk 12:54, 2 September 2017 (UTC)
The problem seems to have gone away. — Cheers, JackLee talk 21:58, 6 September 2017 (UTC)

Module:Quotations and Wikidata[edit]

Would it be possible for MOD:Quotations to automatically get data from Wikidata if the language's data page does not have metadata for a specific work or author? —Aryaman (मुझसे बात करो) 20:13, 19 August 2017 (UTC)

Glitch in Translation tool?[edit]

Well, something weird just happened. This has never happened to me before, so I'm wondering if this is a temporary glitch or something that's happened only to me? --Robbie SWE (talk) 18:54, 20 August 2017 (UTC)

@Robbie SWE It was my mistake. It is now fixed. Sorry.--Dixtosa (talk) 19:40, 20 August 2017 (UTC)
@Dixtosa no worries, just thought my computer/account was on the fritz. --Robbie SWE (talk) 19:42, 20 August 2017 (UTC)

Misplacement of furigana[edit]

I found that the third example sentence in the page ある has misplaced furiganas, which I am not sure how to correct:


 (わたし)学校 (がっこうは)花園 (なぞの)あります

Watashi no gakkō wa hanazono ga arimasu.
My school has a flower garden.

Solution:

 (わたし) (がっ) (こう)花園 (はなぞの)あります
Watashi no gakkō wa hanazono ga arimasu.
My school has a flower garden.

This seems to be a systematic error. It goes like this:

When a part of the sentence is of the sequence kanji-kana-kanji, and the first kana of the second kanji is identical to the standalone kana, the standalone kana is erroneously shown as part of the first kanji's furigana, and the first kana of the second kanji is displayed as the standalone kana.

So, as the example has it,

...gakkou ha hanazono...

is mistakenly reanalyzed as

...gakkouha ha nazono...

even though the source code is correct. I cannot access the visual editor for some reason, so that is all I have. If I change the second ha to something like ga, the sequence of furiganas is correct. And since the algorithm seems to ignore spaces to first match for the kanas, changing the standalone ha to something else like sa does not correct the mistaken reanalysis.

I hope I have made myself clear.

Could this be fixed soon?

Rethliopuks (talk) 05:35, 21 August 2017 (UTC)

I hit on a solution by accident (which might be mentioned in Module:ja; search for "leak"): adding spaces around the particle in the first parameter – {{ja-r|私の学校 は 花園があります。|...}}. I don't understand how it works, but I think the ruby is correct now. — Eru·tuon 06:02, 21 August 2017 (UTC)
Oh, I guess it signals to Module:ja that the surrounded by spaces in the first parameter is the same as the surrounded by spaces in the second parameter. Duh. — Eru·tuon 06:16, 21 August 2017 (UTC)
@Erutuon: The solution is documented at Template:ja-r/documentation. (There should really be one centralized place where the ruby function is documented...) —suzukaze (tc) 06:36, 21 August 2017 (UTC)
@Suzukaze-c: Ahh, I had read that before, but didn't connect it to this. It's related but slightly different. In the case above, replacing the spaces with percents gives a module error. So the use of spaces should be mentioned in a documentation page somewhere. Whether it would be used in {{ja-r}} or just in {{ja-usex}}, I don't know for sure. — Eru·tuon 07:30, 21 August 2017 (UTC)
One thing I've always wondered, is why {{ja-r}} and {{ja-usex}} were not designed as having Kanji directly and adjacently annotated by kana. All the % markup is rather cryptic and unsightly. For example, 般若波羅蜜多 can have
観(かん)自(じ)在(ざい) 菩(ぼ)薩(さつ) 行(ぎょう) 深(じん) 般(はん)若(にゃ) 波(は)羅(ら)蜜(みっ)多(た) 時(じ) 照(しょう) 見(けん) 五(ご)蘊(うん) 皆(かい) 空(くう) 度(ど) 一(いっ)切(さい) 苦(く)厄(やく)
(or something similar), rather than the current
観%自%在 %[[菩%薩]] %行 %深'''%般%若 %波%羅%蜜%多''' %時 %照 %見 %[[五%蘊]] %皆 %空 %度 %一%切%苦%厄…|^かん%じ%ざい %^ぼ%さつ %ぎょう %じん '''%はん%にゃ %は%ら%みっ%た''' %じ %しょう %けん %ご%うん %かい %くう %ど %いっ%さい %く %やく…
In addition the module should be made more intelligent as well by knowing that Kanjis cannot start with certain morae (nasal or sokuon), so that something like いっせ or はんし can be correctly interpreted automatically, without resorting to %. Wyang (talk) 08:07, 21 August 2017 (UTC)
Personally I like the way kanji and kana are separate; the text remains fairly legible (to the degree that pure kana text is legible). The problem with % is that it was an afterthought, and the problem with the module is that it is not clever enough. Maybe it could be modified to support both styles of markup. —suzukaze (tc) 08:16, 21 August 2017 (UTC)
I agree the module needs improvement. Even where the alignment of the ruby is more or less correct, it isn't quite perfect: for instance, compare {{ja-r|兄弟|きょうだい}}兄弟 (きょうだい) (kyōdai) with {{ja-r|兄%弟|きょう%だい}} (きょう) (だい) (kyōdai). In the second case, the kanji are centered below the three or two kana that indicate their pronunciation, while in the first the two kana are centered below all five kana. (This is more obvious in the HTML.) I think in this case the module should try to figure out which kana belong with which individual kanji, rather than centering each group of kanji below the sequence of kana that correspond to them.
Moraic and syllabic analysis of the kana could play a part. For instance, in the current example, perhaps the module could calculate that the sequence きょうだい (kyōdai) consisted of four morae (きょ、う、だ、い). And secondly (as already mentioned), if and are involved, the module should consider them and the previous mora to constitute a syllable, which then cannot be divided between kanji. Perhaps then these morae or syllables could be divided up equally between kanji. In the example above, it would give the right result. In other cases, it might not, in which case percents would be required. But it would be good for the module to try to figure out which kana belong to which kanji, instead of doing what it does now. — Eru·tuon 19:56, 21 August 2017 (UTC)

I created a function that does the syllabic and moraic division: Module:User:Erutuon/ja. — Eru·tuon 20:39, 21 August 2017 (UTC)

Bugs in translation adder[edit]

Screenshot of two bugs

@Dixtosa: Here is a screenshot showing two separate bugs in the translation adder:

  1. The second translation added displays on a new line in the preview (although it is saved correctly when the translations are saved).
  2. There are extra blank lines in place of the hidden gender checkboxes that take up unnecessary space.

--WikiTiki89 15:28, 23 August 2017 (UTC)

The second feature request is fulfilled. Dixtosa (talk) 18:00, 23 August 2017 (UTC)
Thanks! Hopefully the first one is easier to fix. --WikiTiki89 19:04, 23 August 2017 (UTC)

Special:Tags accountability[edit]

A bunch of these are still not properly documented. How can I get from that page to the actual code/regex/etc. that causes the given tag to be triggered? For example, I want to document what NewNum does. Where do I find the code? Equinox 22:55, 25 August 2017 (UTC)

I have found one abuse filter that adds this tag. Dixtosa (talk) 08:38, 26 August 2017 (UTC)

Global preferences – do you want local overrides?[edit]

Hey everyone, m:Community Tech are working on global preferences, to make it possible to set preferences for all Wikimedia wikis instead of for each one individually (which you’ll still be able to do – global preferences will be optional). You can read more at m:Community Tech/Global preferences.

The developers are now investigating how important it is to override global preferences locally, which would mean you set a preference for almost all wikis but still have different settings on one or a few wikis. Maybe because you’re more active on one wiki, maybe because you edit in different ways there. If you want to be able to set exceptions to global preferences it is important that you tell the developers this now. Tell them what, how you’d use it and why it is important on this talk page.

This is only necessary if you want global preferences and exceptions to them. If you only edit one wiki, or are happy having the same preferences everywhere, you can ignore this.

The reason they’re asking is it’s technically complicated to build. /Johan (WMF) (talk) 15:38, 28 August 2017 (UTC)

I have never yet needed local overrides (in about a decade). I actually find it mildly annoying each time I go to a new wiki and get the alert flag (red thing at top-right) for messages on other wikis, because I haven't yet set "only show local messages" in my global settings at the new wiki. Equinox 15:40, 28 August 2017 (UTC)
@Johan (WMF): Thanks for asking! If global preferences are implemented, I would certainly use them, and I would certainly want local overrides. The preferences I use on Wiktionary and Wikipedia are slightly different, and I wouldn't want differences like that to prevent me from benefiting from global preferences. --WikiTiki89 15:45, 28 August 2017 (UTC)
Wikitiki89: Happy to hear they'll be helpful. If possible, please try to shortly explain why you'd want local overrides on this talk page on Meta, that'd be very helpful (true for everyone else, too). (: /Johan (WMF) (talk) 16:51, 28 August 2017 (UTC)
I have only edited on four projects (WP, enwikt, species, and commons), but probably more than 98% on enwikt. One the others, I only do occasional corrections or minimal additions. I'm happy to dispense entirely with global preferences and set my preferences one project at a time. Alternatively, I could live with global preferences with no overrides. I would like developers to provide me with a lexicographer's workbench instead. DCDuring (talk) 16:37, 28 August 2017 (UTC)

Pronunciation evaluation gadget for Wiktionary: GSoC 2017[edit]

Every dictionary need to provide phonetic representation of a word along with its written form. With advanced speech recognition tools now available, it's also possible to evaluate and correct user's pronunciation. I have shown it in a live demo hosted here. I request the admins to grant me permission to create a Gadget which will evaluate the pronunciation of a user within Wiktionary. Here's how the gadget will look like.

Wiktionary pronunce interface.png

.

I want to create a page: https://en.wiktionary.org/wiki/MediaWiki:Gadget-pronunce.js This page will contain the contents of https://en.wiktionary.org/wiki/User:Brijsri/common.js.

Finally, I would like to publish it as a gadget. Thanks for the help.

This is interesting to me. I am less interested with the idea of 'correcting' pronunciation than in evaluating pronunciation and producing valid IPA representation. That is, allow contributors to add regional/dialectic variant pronunciations via a gadget. e.g. Parisian vs. Québecois, Delhi vs. London, etc. - Amgine/ t·e 15:17, 30 August 2017 (UTC)


Thanks for the suggestions. I will incrementally implement these requirements. Kindly create this page (https://en.wiktionary.org/wiki/MediaWiki:Gadget-pronunce.js) so that I can proceed with the development. Thanks! —This unsigned comment was added by Brijsri (talkcontribs).
You need to be an admin to edit MediaWiki namespace. As for your script it won't become a gadget until it is well tested. Last time I included your script it did not produce what was expected of it I think in Chrome. I make a screenshot if you wish. Giorgi Eufshi (talk) 06:29, 5 September 2017 (UTC)

{{R:IEC2}} not working[edit]

See càncer. Ultimateria (talk) 16:55, 30 August 2017 (UTC)

It looks like a temporary problem with the external website, or has it relocated to a different URL or even shut down? — SGconlaw (talk) 17:06, 30 August 2017 (UTC)
The front page leads to the dictionary just fine. Ultimateria (talk) 19:46, 30 August 2017 (UTC)
Fixed. DTLHS (talk) 19:56, 30 August 2017 (UTC)

Linking to transliteration[edit]

At lahar, {{bor|en|jv|ꦭꦲꦂ|tr=lahar|notext=1}} knows to attempt to link the transliteration lahar to lahar#Javanese, since Javanese can also be written in Latin script, but it's not smart enough to realise that it is on the very page it is trying to link to. As a result, the translit gets bolded as lahar. This should be fixed so that the link is not direct in this case. —Μετάknowledgediscuss/deeds 00:27, 31 August 2017 (UTC)

Category:French nouns with missing forms[edit]

All the entries in this category seem to have no missing forms. However yodleur, which does, is not in the category. Any ideas? SemperBlotto (talk) 10:46, 31 August 2017 (UTC)

p.s. "Category:French adjectives with missing forms" and "Category:French nouns with missing plurals" seem to be suffering from the same problem.

It seems like the category is just being updated very slowly- I was able to get yodleur to show up with a null edit. DTLHS (talk) 16:06, 31 August 2017 (UTC)
It was my mistake: fixed. I seem to sometimes have a problem with getting basic logic right: I had made the "missing forms" categories track forms that have entries. — Eru·tuon 19:40, 31 August 2017 (UTC)

Detection of invalid IPA not working?[edit]

Someone just added IPA to bekerkard, but there's some HTML in there. How come this isn't being marked as invalid IPA? I'm not aware of any particular significance to an IPA superscript schwa. —Rua (mew) 18:30, 31 August 2017 (UTC)

Actually the superscript schwa is used in IPA, but the ᵊ character is what is meant to be used for that. But here, it's really the <, >, and / that should be detected as invalid (unless they are in fact used for something). I don't know if the superscript schwa is correct here or not. --WikiTiki89 19:09, 31 August 2017 (UTC)
(edit conflict) Because HTML tags are removed before the module checks for incorrect characters. The characters in HTML tags aren't really invalid IPA characters; they make up the formatting that is applied to the characters. And the category gets messy and useless if HTML is tracked in it. However, if you want to track superscript tags, or schwa encircled in superscript tags, that can certainly be done. — Eru·tuon 19:21, 31 August 2017 (UTC)
@Erutuon: Why do we allow HTML tags in IPA? --WikiTiki89 19:35, 31 August 2017 (UTC)
@Wikitiki89: I don't know. But they are there, and tracking them as invalid characters makes no sense. — Eru·tuon 19:36, 31 August 2017 (UTC)
Paired HTML tags in IPA are now tracked with the category IPA pronunciations with paired HTML tags. — Eru·tuon 19:47, 31 August 2017 (UTC)
So far it seems they are only used for tone marking in reconstructed Middle Chinese. Since those transcriptions are automatically generated, I think we should create a way for them to bypass the check for invalid characters (or perhaps not treat those transcriptions as IPA at all, since they really aren't if they are using non-IPA tone marking), and then ban HTML tags from IPA. --WikiTiki89 20:05, 31 August 2017 (UTC)

September 2017

Different Arabic and Persian fonts[edit]

Why do some Persian words appear on different pages (linked with a 'See also') from their Arabic etymons spelt exactly the same way? I don't know of any need for glyphic variation between the two languages, apart from new Persian letters like /p/ and /g/, and some problem with alif maqsura. Examples are كتف kitf/ketf (shoulder) and دليل dalîl (proof); but they appear on the same page (as I would expect for all such) with دار dâr (house) and دفتر daftar (notebook). (If I have a choice, the Persian font is much better looking, like proper print.) --Hiztegilari (talk) 10:55, 1 September 2017 (UTC)

The first example features ك vs. ک. The second example features ي vs. ی. —suzukaze (tc) 10:59, 1 September 2017 (UTC)
In cases where the two glyphs are identical, though, such as كتف vs. کتف and دليل vs. دلیل, I wonder if a hard redirect would be a better solution. We can still use separate pages for words in which ك/ک and ي/ی appear differently. —Aɴɢʀ (talk) 13:19, 1 September 2017 (UTC)
If we did that, the pagename would show codepoints that are never used for Persian, which is a problem from my perspective (people searching for Persian will probably use a Persian input method, which produces the right codepoints). With updating of {{also}}, being on separate pages poses no real issue in terms of users navigating to words. —Μετάknowledgediscuss/deeds 16:47, 1 September 2017 (UTC)
The correct solution to this problem would be to redesign Unicode from scratch. Until we can do that, we'll have to settle for having them on separate pages. --WikiTiki89 18:10, 1 September 2017 (UTC)

Diacritic stripping function[edit]

Is there a diacritic stripping function built into Lua? If not, anyone know of a streamlined method? --Victar (talk) 15:26, 1 September 2017 (UTC)

If there were, I wouldn't trust it. Module:links does something like that, depending on the language. Ask at the Grease pit for more information. Chuck Entz (talk) 15:48, 1 September 2017 (UTC)
Thanks, I'll check it out. Whoops, I meant to post this there. Will move. --Victar (talk) 16:05, 1 September 2017 (UTC)
What language, what diacritics do you specifically want to remove. DTLHS (talk) 16:43, 1 September 2017 (UTC)
@DTLHS: I'm working on a declension table module for PII, so I'm just removing acute accents. --Victar (talk) 16:53, 1 September 2017 (UTC)
If you have a list it can be added to Module:languages/datax. Or if you don't want it to apply to every PII entry you could just put a hardcoded table in your module. DTLHS (talk) 17:06, 1 September 2017 (UTC)
@DTLHS: I need to strip acute accents from the declension suffixes if an accent exists on the stem. Module:User:Victar/iir-decl-noun --Victar (talk) 17:12, 1 September 2017 (UTC)
Module:ine-common has a variety of functions for manipulating accents that might be useful. —Rua (mew) 17:32, 1 September 2017 (UTC)
Perfect, thanks @CodeCat. --Victar (talk) 17:35, 1 September 2017 (UTC)

WM attention to "the two-stage page loading problem"[edit]

Here is the beginnings of a discussion thread on Wikimedia-l on a matter directly relevant to us, based on my recollection of discussions:

Michael Peel email@mikepeel.net via lists.wikimedia.org 9:09 PM (4 hours ago)

to Wikimedia This is possibly the most annoying feature of the Wikimedia projects at the moment. You access a page. Then you start reading or editing it. And then suddenly the page jumps when a fundraising banner / central notice / gadget / beta feature loads. So you have to start reading the page again, or you have to find where you were editing again, or you have to undo the change you just made since you made it in the wrong part of the page.

I understand that this isn't intentional. Presumably there is a phabricator ticket about this. But how can we fix this - does this need more developer time, is this an external problem that we need someone else to fix, or is this a WONTFIX?

--

James Heilman jmh649@gmail.com via lists.wikimedia.org 11:25 PM (2 hours ago)

to Wikimedia I just put forwards a proposal to fix part of this issue Mike :-)

https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle#Button_load_issues

The TW button is easy to fix at least I am told, once I get consensus. Amir fixed one of the buttons earlier today.

  • Does this also relate to the timing problem that leads to the all-too-frequent failure of certain JS-implmented features (show-hides most annoyingly) to load? DCDuring (talk) 05:37, 2 September 2017 (UTC)
    • Should someone here who is technically knowledgeable follow this and push our view of the problem. DCDuring (talk) 05:40, 2 September 2017 (UTC)
Hooray! The main problems in general editing (for me at least) are the entire tab bar (or the space directly below it), causing the edit box to jump downward, and the late-loading Citations tab on that bar, causing some tabs to jump rightward. Equinox 09:37, 2 September 2017 (UTC)

No more automatic link for plural creation?[edit]

What happened to the automatic link that would load if you tried to create an English plural form? Now I just get a blank page. — SGconlaw (talk) 17:49, 2 September 2017 (UTC)

You need to reenable it in your preferences. DTLHS (talk) 17:53, 2 September 2017 (UTC)
Thanks. How did it get turned off? — SGconlaw (talk) 18:34, 2 September 2017 (UTC)
By moving and/or renaming the file, which, if I remember correctly, was for good reasons. It would have been a good idea, though, to let people know it would happen. But then, hindsight is 20/20. Chuck Entz (talk) 18:41, 2 September 2017 (UTC)
Now that we have the hindsight, I hope future changes of this kind will be seamless. Equinox 18:48, 2 September 2017 (UTC)
  • Inconveniences likes this are good. It makes you reconsider whether you actually need the gadget. I might as well make this a feature - turning random gadgets off at random intervals. Dixtosa (talk) 19:28, 2 September 2017 (UTC)
    • My immediate assumption when the form creation gadget stopped working was that it had broken, not that I needed to re-enable it. If there were some way to distinguish between those situations, the idea might work. (Or maybe you're joking.) — Eru·tuon 19:52, 2 September 2017 (UTC)
      • A notice at "News for editors" would have been welcome. — SGconlaw (talk) 20:07, 2 September 2017 (UTC)

Wildcard Contributions Searches[edit]

The Wiktionary:Per-browser preferences have stopped working for me. Given the sad state of my system, it's not worth the trouble of troubleshooting. There was only one thing it it I ever used: there was a thing that popped up in Special:Contributions pages that allowed me to do wildcard searches on IP. It wasn't exactly a masterpiece of user-interface design, but I was able to look for IP users who were changing their IPs, but staying within their ISP's local allocation. Would it be possible to have a regular gadget or a special page that would allow the same thing?

Basically it would take "77.37.156.*", or, even better, "77.37.156.23/24" as input and give a combined list of edits by every IP within that range. This capability is especially helpful when contemplating a range block, because it helps refine the range needed and makes it possible to check if anyone has made legitimate edits from within it. Thanks! —This unsigned comment was added by Chuck Entz (talkcontribs).

The code behind the gadget was deleted. Pinging @TheDaveRoss. Dixtosa (talk) 07:15, 3 September 2017 (UTC)
I had not realized that this was being used by anyone, or that it was added to the per-browser preferences. Restored. - TheDaveRoss 13:54, 3 September 2017 (UTC)
@TheDaveRoss Well, now the user interface works like it used to, but it doesn't do anything- there's no list of edits. Chuck Entz (talk) 14:03, 4 September 2017 (UTC)
@Chuck Entz, I have copied the latest source of the gadget from wp. Is it working now? Dixtosa (talk) 15:53, 4 September 2017 (UTC)
Yes. Thank you! Chuck Entz (talk) 18:06, 4 September 2017 (UTC)
@Dixtosa Did you move it to somewhere global so I can delete it again from my userspace? - TheDaveRoss 14:03, 6 September 2017 (UTC)
@TheDaveRoss, now you can delete your page. Dixtosa (talk) 16:55, 6 September 2017 (UTC)

Testcases fail but are identical?[edit]

Module:ha-headword/testcases- as far as I can tell the expected and actual cells for "aeionū̀ (m)" and "aeionā̀ (f)" are identical, but still failing- why? —This unsigned comment was added by DTLHS (talkcontribs).

It might be because the testcases use the combined Unicode character [A WITH ACUTE] while the module itself outputs the letter + the combining diacritics [LATIN LETTER A + COMBINING ACUTE]. Use mw.ustring.toNFD() to break A WITH ACUTE into pieces and mw.ustring.toNFC() to do the reverse. —suzukaze (tc) 23:42, 2 September 2017 (UTC)
Thanks, I didn't realize it was that easy. DTLHS (talk) 23:49, 2 September 2017 (UTC)

Mobile App Word Game[edit]

Hi,

I am looking for some advice on changing the downloaded version of the Wiktionary so that the size and formatting of the data is in a workable format for my purposes. I am investigating how to rearrange the data into the following columns (preferably with some type of delimiter):

COL1 (The word)|COL2 (The meaning)

Is this at all possible?

Regards,

John.

Are you interested in a particular language? What about words that have multiple meanings? Are you interested in both lemmas and nonlemmas (cat vs cats)? DTLHS (talk) 16:41, 6 September 2017 (UTC)

inc-mgd[edit]

This language (already added) needs MOD:Brah-translit as a translit module. —Aryaman (मुझसे बात करो) 20:05, 6 September 2017 (UTC)

@Aryamanarora: Yes check.svg Done. — Eru·tuon 21:51, 6 September 2017 (UTC)

"Derived terms" thing not working at -thermic[edit]

When clicked, the arrow turns around as if to expand a list, but no list appears. (Using latest Chrome.) Equinox 21:16, 6 September 2017 (UTC)

Fixed. DTLHS (talk) 21:17, 6 September 2017 (UTC)

Redlinks from reconstruction pages[edit]

I was looking over Category:Proto-Indo-Iranian redlinks and I noticed that the redlinks from reconstruction pages, like those for PIE, aren't included in the list. Is that by design? Is there some way I can generate this list? --Victar (talk) 13:52, 7 September 2017 (UTC)

I don't know the reason, but {{redlink category}} only categorizes in mainspace pages. That could be changed using {{#switch:}}. — Eru·tuon 18:38, 7 September 2017 (UTC)
@Erutuon: Yeah, I don't see why not. Do we need a vote to add reconstruction pages? --Victar (talk) 02:42, 8 September 2017 (UTC)
@Angr, CodeCat, JohnC5, Metaknowledge what are your thoughts on this? --Victar (talk) 17:20, 9 September 2017 (UTC)
I don't have strong feelings one way or the other. I guess it makes sense to include links from the Reconstruction namespace as well, and probably Appendix namespace too. —Aɴɢʀ (talk) 17:24, 9 September 2017 (UTC)
I'm fine adding the Reconstruction namespace, though I don't know why the Appendix should be added. Do we put any lemmata in the Appendix now? —JohnC5 21:56, 10 September 2017 (UTC)
Okay, no objections so far and I can't think of a reason why not, so redlinks will now be tracked in the Reconstruction namespace. — Eru·tuon 22:39, 10 September 2017 (UTC)
Thanks, @Erutuon! --Victar (talk) 21:40, 12 September 2017 (UTC)
@JohnC5: We have lots of lemmas in Appendix namespace: Swadesh lists, lists of names, various other lists (e.g. Appendix:Burmese units of measure). —Aɴɢʀ (talk) 22:18, 12 September 2017 (UTC)
@Angr: Yep, I wasn't paying attention. Thanks! —JohnC5 22:46, 12 September 2017 (UTC)
I think it is useful to track the words in wordlists and stuff, so I've added the Appendix namespace. — Eru·tuon 23:20, 12 September 2017 (UTC)
Hmm, @Erutuon, it doesn't seem to be working right, i.e Proto-Indo-European *kʷékʷlos is coming up in Category:Proto-Indo-Iranian redlinks. --Victar (talk) 05:41, 14 September 2017 (UTC)
@Victar: Oh... good catch. That's because the page *čakrám doesn't exist. I'll have to make Module:redlink category check the pagename Reconstruction:Proto-Indo-Iranian/čakrám instead. — Eru·tuon 05:51, 14 September 2017 (UTC)
Yes check.svg Done (diff). — Eru·tuon 20:22, 14 September 2017 (UTC)
@Erutuon: Gangbusters! --Victar (talk) 20:47, 14 September 2017 (UTC)

what happened to the nocap parameter for the bor template?[edit]

I get an error message when I use this now? What gives?! Word dewd544 (talk) 14:21, 7 September 2017 (UTC)

See this conversation, essentially the inclusion of the "borrow" text is getting phased out. - TheDaveRoss 15:25, 7 September 2017 (UTC)
In other words, if you want to write {{bor|...|nocap=1}}, write {{bor|...|notext=1}} instead and write in "borrowing from" by hand. —Aɴɢʀ (talk) 12:20, 8 September 2017 (UTC)
Oy vey, what's with all the changes? I see. Well that's fine actually, as long as the ones that used "nocap" have been automatically converted to having "Borrowed from" as text before it. I guess this does make sense since it gives us more flexibility in using the template as part of an etymology, without having to use the "notext" parameter. Thanks. Word dewd544 (talk) 15:55, 8 September 2017 (UTC)
I (and probably others) have been doing some of those conversions, hopefully we are well along the way to having everything cleaned up. - TheDaveRoss 17:58, 8 September 2017 (UTC)
For the record, this change in {{bor}} was voted and approved here: Wiktionary:Votes/2017-06/borrowing, borrowed. --Daniel Carrero (talk) 18:02, 8 September 2017 (UTC)
Wait a sec, just to make things clear: so now it isn't even good practice to just start an etymology with the borrowed template without a notext, even if it's at the beginning of an etymology, because that will be phased out soon too? So always use notext=1 and write out "Borrowed or borrowing from..."? Word dewd544 (talk) 22:51, 22 September 2017 (UTC)
Isn't it obvious? DCDuring (talk) 23:47, 22 September 2017 (UTC)
DCD, you may think you're being funny, but it's really just low-quality trolling. Stop it. —Μετάknowledgediscuss/deeds 23:49, 22 September 2017 (UTC)

Lua memory errors related to Wikidata use in Module:senseid[edit]

There are quite a few pages in CAT:E with Lua memory errors. I think they are due to recent changes by @CodeCat in Module:senseid. Now, if a sense id formatted with {{senseid}} is a Wikidata id (QN), then the module does a bunch of stuff with the it: checking if the id is for a planet, continent, country, language, taxon, emotion, etc. Some part of this process is taking enough memory to cause quite a few pages to run out of memory.

I can see two obvious options: disable the Wikidata stuff in Module:senseid entirely, or create a list of the pages on which the function should not run (those currently running out of memory). — Eru·tuon 19:13, 8 September 2017 (UTC)

I thought there was an agreement not to include anything which uses Wikidata in the main namespace without approval. Was use of senseid with Wikidata discussed? - TheDaveRoss 19:24, 8 September 2017 (UTC)
The rationale was that since it currently only adds tracking categories it didn't need a discussion. DTLHS (talk) 19:28, 8 September 2017 (UTC)

(edit conflict) Hm, I might be wrong. I don't see {{senseid}} in fish, one of the pages that recently ran over the memory cap, for example. Maybe it's something else. But I don't feel like going through and checking each page. — Eru·tuon 19:27, 8 September 2017 (UTC)

Toggling the wikidata code on and off didn't seem to have much of an effect on memory- the template uses about 1 MB for the first invocation either way. —This unsigned comment was added by DTLHS (talkcontribs) at 19:28, 8 September 2017 (UTC).
I was wondering this myself as the errors started appearing, but they seem to be unrelated to the Wikidata stuff. —Rua (mew) 19:35, 8 September 2017 (UTC)
If I remove the translation table from language, usage drops from 50 MB to 10 MB. Was anything changed in Module:translations or the templates it depends on? Maybe a change in the Lua implementation itself? —Rua (mew) 19:44, 8 September 2017 (UTC)
I've been looking at recent changes in the Module namespace. It's hard to answer your question, because there are a lot of modules involved in an actual use of Module:translations: language and script data modules, transliteration modules, other modules that are loaded by another module when that module is loaded. — Eru·tuon 20:02, 8 September 2017 (UTC)
I still don't really understand why there are these extra restrictions on the use of Lua. —Rua (mew) 20:25, 8 September 2017 (UTC)
What extra restrictions are you referring to? — Eru·tuon 20:59, 8 September 2017 (UTC)
The memory limits based on how many Lua-fied templates you use on a page. A page shouldn't need more memory just because it has more Lua on it, because each template runs in its own sandbox. Different invocations don't need to share memory, so once one is finished processing, the memory should be freed. The only memory that should be kept across invocations is loadData stuff. If one invocation of {{t}} uses X amount of memory, then each invocation of {{t}} uses its own separate X amount of memory. The fact that memory usage accumulates when more invocations are added, indicates to me that there is something wrong with how Scribunto handles memory. —Rua (mew) 21:11, 8 September 2017 (UTC)
I'm tempted to agree, but I wish I knew just what all the accumulated memory was: previously loaded modules, module output, loaded data modules? It seems that previously loaded modules at least aren't shared between template invocations, as can be seen when I dump a representation of the package.loaded Lua variable on a page that uses other templates (see the current revision of Module:sandbox). But maybe there is other inaccessible memory usage in the Scribunto extension that counts towards the limit. — Eru·tuon 21:55, 8 September 2017 (UTC)
A possibility is that the software processes all Lua invocations in parallel threads, but using a shared memory pool. Since each template and module expansion is completely independent of any others, it's very parallelisable. On the other hand, the more parallel processing is done, the less memory each thread has for itself. If this is indeed how it's done, they could be more smart about it. For example, rather than just bailing out with an "out of memory" error, they could just throttle/stall some threads until some memory is freed up again once other threads finish, then resume. —Rua (mew) 22:39, 8 September 2017 (UTC)
To me, it looks like the Lua invocations are processed in order, so the invocation at which memory runs out moves higher up the page when there is more memory used. I also recall an odd case in which one template (I think it was {{zh-der}}) ran out of memory, but the ones after it didn't. So it looked like the one template went over the limit, but then its memory was freed up and the smaller-memory templates after it were able to run. — Eru·tuon 19:37, 9 September 2017 (UTC)
But then if each individual template doesn't run over the limit, why do we run over the limit when we have many of them? That shouldn't happen. The page would be just fine if only it didn't try to use more memory than was available. —Rua (mew) 20:09, 9 September 2017 (UTC)
Clearly there must be something adding more memory with each new use of Lua. But I don't know what or how. — Eru·tuon 20:16, 9 September 2017 (UTC)
You'd almost think they didn't want us to use it, and would prefer us to start using slow and clumsy template logic again... —Rua (mew) 20:50, 9 September 2017 (UTC)
All of the source code is fully viewable by anyone if you think you can improve it. DTLHS (talk) 20:51, 9 September 2017 (UTC)

Swahili classes >2[edit]

I can make pages for first, second, & third person conjugations of verbs, but what about the ma class, ki-vi class, & so on? Anjuna (talk) 05:33, 9 September 2017 (UTC)

@Science Bird: You can create these pages as well, although creating any of these inflected forms is not nearly as useful as creating lemma forms with definitions, because the inflected forms can always be created later by robots. —Μετάknowledgediscuss/deeds 11:13, 9 September 2017 (UTC)
Robots? Thank you. Is there a way to get them moving? Anjuna (talk) 13:44, 9 September 2017 (UTC)
We call them bots, and it's simply a matter of asking here for someone with a bot to do a particular task for you. In some cases, it may be better to wait until it's more clear what will need to be done and until there's enough potential work waiting to make a bot run worth it- but I have no idea if this is one of those cases. Chuck Entz (talk) 13:54, 9 September 2017 (UTC)

Distinguishing affixes that are identical in form[edit]

I want to have separate categories for prefixes that all take the form ma- but are distinct in use. I feel like this problem has been solved before somewhere, but I don't know where and how. @CodeCat, do you (or does anyone else) remember? —Μετάknowledgediscuss/deeds 02:04, 11 September 2017 (UTC)

@Metaknowledge: Category:English_words_suffixed_with_-er#mw-subcategories? —suzukaze (tc) 02:06, 11 September 2017 (UTC)
Thank you, the id1= (etc.) parameter does the job. —Μετάknowledgediscuss/deeds 18:56, 11 September 2017 (UTC)

Recentchanges tag filter inverse[edit]

Does anyone know if it's possible to filter recent changes for edits that are not labelled with a specific tag? DTLHS (talk) 04:19, 12 September 2017 (UTC)

No it is not possible.5.178.149.114 05:42, 12 September 2017 (UTC)

Template:quote categorizes the entry as having a usage example[edit]

For example, פרזלא is in the category Category:Aramaic terms with usage examples when it shouldn't be, because it only has a quotation. --WikiTiki89 20:07, 12 September 2017 (UTC)

Fixed. DTLHS (talk) 20:10, 12 September 2017 (UTC)

Visual Editor[edit]

The visual editor goes against all our style guidelines (see diff, for example). If this cannot be fixed, we should disable the visual editor entirely. --WikiTiki89 15:54, 13 September 2017 (UTC)

Abuse filter required[edit]

We're getting lots of English entries that are just the generated rfdef template, with no attempt to fill it in. (Part of speech varies.) Can we block these? Also, a lot of the entry titles are in Arabic script. Can we block any attempt to create an English entry with Arabic characters in the title? Equinox 22:52, 13 September 2017 (UTC)

  • Yes please - these are getting annoying. SemperBlotto (talk) 11:01, 19 September 2017 (UTC)
@Equinox: I am happy to try and create an edit filter, do you have a couple of diffs I could use as a basis/test? - TheDaveRoss 11:40, 19 September 2017 (UTC)
This Arabic-script one was just created: معلومات_عن_العادة_السرية. Equinox 13:23, 19 September 2017 (UTC)
Another: فتيات من ورقلة. Equinox 14:08, 19 September 2017 (UTC)
Another, created as sign-language rather than English: پروتز. Equinox 17:22, 19 September 2017 (UTC)
This last one is a bit different: Persian rather than Arabic, and a word that I think we actually ought to have (I reckon it means "prosthesis") rather than an entry that should never exist. —Μετάknowledgediscuss/deeds 22:24, 19 September 2017 (UTC)
I'm a little concerned about how to distinguish between the normal case with the new entry creator, where everything is preloaded with the empty templates and then edited by the contributor before saving, and the bad cases, where it's saved without being edited- they both start out identical. Chuck Entz (talk) 16:19, 19 September 2017 (UTC)
I created Special:AbuseFilter/72 which is currently only tagging such entries (rfdef). If the user clicks a template and edits before saving to remove the {{rfdef}} it is not tagged, however if they create the entry with the {{rfdef}} and intend to edit is further in subsequent edits we are never going to be able to capture that. - TheDaveRoss 11:42, 22 September 2017 (UTC)
I created some entries with {{rfdef}} only yesterday, for example ruibi. So we should probably choose some better way to recognise these edits. —Rua (mew) 11:52, 22 September 2017 (UTC)
It only flags new entries by anonymous users, so your creations would not be tagged. - TheDaveRoss 12:31, 22 September 2017 (UTC)

Improvements coming soon to Recent Changes[edit]

Rc-beta-tour-welcome-ltr.gif

Hello

Sorry to use English. Please help translate to your language! Thank you.

In short: starting on 26 September, New Filters for Edit Review (now in Beta) will become standard on Recent Changes. They provide an array of new tools and an improved interface. If you prefer the current page you will be able to opt out. Learn more about the New Filters.

What is this feature again?

This feature improves Special:RecentChanges and Special:RecentChangesLinked (and soon, Special:Watchlist – see below).

Based on a new design, it adds new features that ease vandalism tracking and support of newcomers:

  • Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
  • Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
  • Bookmarking to keep your favorite configurations of filters ready to be used.
  • Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help. They are not available on all wikis.

You can know more about this project by visiting the quick tour help page.

Concerning RecentChanges

Starting on 26 September, New Filters for Edit Review will become standard on Recent Changes. We have decided to do this release because of a long and successful Beta test phase, positive feedback from various users and positive user testing.

Some features will remain as Beta features and will be added later. Learn more about those different features.

If your community has specific concerns about this deployment or internal discussion, it can request to have the deployment to their wikis delayed to October 1, if they have sensible, consistent with the project, actionable, realistic feedback to oppose (at the development team's appreciation).

You will also be able to opt-out this change in your preferences.

Concerning Watchlists

Starting on September 19, the Beta feature will have a new option. Watchlists will have all filters available now on the Beta Recent Changes improvements.

If you have already activated the Beta feature "New filters for edit review", you have no action to take. If you haven't activated the Beta feature "New filters for edit review" and you want to try the filters on Watchlists, please go to your Beta preferences on September 19.

How to be ready

Please share this announcement!

Do you use Gadgets that change things on your RecentChanges or Watchlist pages, or have you customized them with scripts or CSS? You may have to make some changes to your configuration. Despite the fact that we have tried to take most cases into consideration, some configurations may break. The Beta phase is a great opportunity to have a look at local scripts and gadgets: some of them may be replaced by native features from the Beta feature.

Please ping me if you have questions.

On behalf of the Global Collaboration team, Trizek (WMF) 15:27, 14 September 2017 (UTC)

@Trizek (WMF): I guess the Watchlist filter beta is out now. Here is my main serious issue with it: it makes the Watchlist take a good amount of extra time to load, which is a severe issue for those who refresh their Watchlist frequently. I would hope there would be a solution that allows the Watchlist to load in the normal amount of time when no filters are active. In fact I'm disabling this feature, as the Watchlist is now unusable for me. --WikiTiki89 16:41, 19 September 2017 (UTC)

Why is domoic broken? -- Red Lua error[edit]

This syntax worked fine the other day. Equinox 22:17, 14 September 2017 (UTC)

@Erutuon DTLHS (talk) 22:22, 14 September 2017 (UTC)
@DTLHS, Equinox: Thanks for the ping. Yes, it was me. I believe it's fixed now. — Eru·tuon 22:44, 14 September 2017 (UTC)

Can't reply to LiquidThreads posts[edit]

@IvanScrooge98 I use LiquidThreads on my talk page. When I click reply to answer someone's post, a new window with a spinny thing appears as usual. However, the spinny thing is supposed to disappear and an edit window should appear instead. Now, the spinny thing stays forever. This makes it impossible for me to post anything in LiquidThreads. Can this be fixed, please? —Rua (mew) 13:41, 17 September 2017 (UTC)

@CodeCat: mmh, no clue. When I do, the “spinny thing” does not appear in a new window but right below the thread, giving me the same problem though. If I open the link in a new window, a perfectly normal editor appears, allowing me to reply. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 13:46, 17 September 2017 (UTC)
Ah, that works for me. Thank you for suggesting that. Still, the problem stands. —Rua (mew) 14:36, 17 September 2017 (UTC)

8-cell and categorising by characters[edit]

Category:English terms spelled with 8 is currently manually added to this page. Module:headword is supposed to automatically categorise terms by their characters, making this manual category superfluous. However, {{en-noun}} isn't adding this category automatically. Is something missing in our data? The same applies to Chinese on 69. —Rua (mew) 14:35, 17 September 2017 (UTC)

Something wrong with Tabbed languages[edit]

Some pages aren't displaying Tabbed languages correctly. At bod, the ==Volapük== line is at the very bottom of the page and all the Volapük info is inside the Swedish tab. At faen, it's the ==Norwegian Bokmål== that's at the very bottom of the page and all the Norwegian Bokmål info is inside the Bislama tab. But other pages with multiple languages are displaying everything correctly. —Aɴɢʀ (talk) 09:14, 19 September 2017 (UTC)

No ideas? It still isn't fixed. It's apparently related to the special characters in the language names, because changing them to ==Volapuk== and ==Norwegian Bokmaal== solves the problem, though obviously that's not a desirable solution. —Aɴɢʀ (talk) 10:54, 20 September 2017 (UTC)
Do you know where the code for tabbed languages is? --WikiTiki89 14:39, 20 September 2017 (UTC)
Never mind, found it. I'll take a look. --WikiTiki89 14:40, 20 September 2017 (UTC)

So here's what I found: A heading with no special characters looks like this in the HTML:

<h2>
  <span class="mw-headline" id="Bislama">Bislama</span>
  <span class="mw-editsection">...</span>
</h2>

While a heading with special characters looks like this:

<h2>
  <span id="Norwegian_Bokmål"></span>
  <span class="mw-headline" id="Norwegian_Bokm.C3.A5l">Norwegian Bokmål</span>
  <span class="mw-editsection">...</span>
</h2>

I'm guessing the line <span id="Norwegian_Bokmål"></span> is a new addition to support section links directly with special characters in addition to the old format. It doesn't look like the tabbed languages code knows how to handle that. --WikiTiki89 14:53, 20 September 2017 (UTC)

Is it fixed? --WikiTiki89 15:16, 20 September 2017 (UTC)
Seems to be. Thanks for your help! —Aɴɢʀ (talk) 15:29, 20 September 2017 (UTC)

Inflection templates categorizing in non-mainspace entries[edit]

Appendix:Snowclones/don't X me, Citations:elephant juice for example. Can this be disabled? DTLHS (talk) 18:51, 21 September 2017 (UTC)

It should be possible, but what are the cases in which categorization needs to be disabled? English headwords in Appendix and Citations namespaces, or any non-appendix-language headword in those namespaces? — Eru·tuon 00:58, 22 September 2017 (UTC)
Well, appendix languages should only categorize in appendices, reconstructed languages only in the reconstructed namespace, everything else only in the main namespace. Would that work? DTLHS (talk) 05:24, 22 September 2017 (UTC)
It's a little more complicated. {{citation}} uses {{cln}}, which is handled by the format_categories function in Module:utilities, and Latin has some Reconstructed entries (*genuclum), but it's not a reconstructed language. So sometimes the function needs to add categories in the Reconstruction namespace for regular languages, and in the Citations namespace. It might be okay to have the function only add categories to an Appendix page if the language is appendix-constructed, though. I doubt someone would use the function to categorize other types of Appendix pages, because it assumes that the title is in the language in question. For the headword in a citations page, there probably has to be a specific exception. — Eru·tuon 05:45, 22 September 2017 (UTC)
I'm still in favour of deleting appendix-constructed languages altogether. —Rua (mew) 12:16, 22 September 2017 (UTC)
Could there be "cat" and/or "nocat" parameters to allow for missing exceptions and reduce the need for excessive complication of template/Lua. DCDuring (talk) 12:20, 22 September 2017 (UTC)

Extra IPA characters in box below edit area[edit]

Would somebody be able to add ŋ̊ and ɲ̊ to the list of IPA characters in the clickable box below edit area (sorry, I don't know the technical name)? These are both used transcribing Icelandic words in IPA, and I am currently going through all the Icelandic nouns to add missing transcriptions so this would be very useful. Thanks, BigDom 10:45, 22 September 2017 (UTC)

A better solution in the long term would be to have buttons that add combining diacritics separately. Then you could make any combination you want. Wikipedia does it this way. —Rua (mew) 12:15, 22 September 2017 (UTC)
Yes, that would be even better. BigDom 13:46, 22 September 2017 (UTC)
The list of characters is called CharInsert, and it's located at MediaWiki:Edittools, while the script that makes it actually work is at MediaWiki:Edit.js. — Eru·tuon 17:40, 22 September 2017 (UTC)

Please add Persian translation of dotard[edit]

The entry dotard has been locked. Please add its Persian translation as follows:

  • language code: fa
  • translation: خرفت
  • transliteration: xereft

Thank you 4nn1l2 (talk) 12:02, 22 September 2017 (UTC)

Added and changed protection level. DTLHS (talk) 17:28, 22 September 2017 (UTC)

Tabbed languages miscategorising at balts[edit]

@Donnanz The Dutch tab is completely missing the categories. Instead they're placed under Latvian for some reason. —Rua (mew) 23:06, 22 September 2017 (UTC)

@CodeCat: Did you ping the right person? I have never edited the page. DonnanZ (talk) 23:16, 22 September 2017 (UTC)
<:ref name="LEV"/> is entered in the Latvian entry, but I have no idea why it comes before Dutch in the category listings and is separated from the rest of the Latvian categories. DonnanZ (talk) 23:53, 22 September 2017 (UTC)
Me and names, bleh. It was the other person with a D. I still can't remember it. —Rua (mew) 11:07, 23 September 2017 (UTC)
@Dixtosa I think. DTLHS (talk) 17:14, 23 September 2017 (UTC)
Yes, thank you, yet another person with a D. —Rua (mew) 18:17, 23 September 2017 (UTC)