: I think there may be some wasted memory in our language and script objects, though I'm not sure how to confirm that. Each language object contains one or more script objects. This probably results in duplication. For instance, when we have many languages in the translations list that use the <code>Latn</code> script, the Latin script object will be repeated inside each of those language objects. That duplication could account for part of the memory problem.
: I think there may be some wasted memory in our language and script objects, though I'm not sure how to confirm that. Each language object contains one or more script objects. This probably results in duplication. For instance, when we have many languages in the translations list that use the <code>Latn</code> script, the Latin script object will be repeated inside each of those language objects. That duplication could account for part of the memory problem.
: (I don't know about the whole memory-releasing thing, but I'm imagining there's a counter that tracks how much memory is used, whether or not it is released when the functions have done their work.) — [[User:Erutuon|Eru]]·[[User talk:Erutuon|tuon]] 08:34, 14 May 2017 (UTC)
: (I don't know about the whole memory-releasing thing, but I'm imagining there's a counter that tracks how much memory is used, whether or not it is released when the functions have done their work.) — [[User:Erutuon|Eru]]·[[User talk:Erutuon|tuon]] 08:34, 14 May 2017 (UTC)
== Adding ids to enable linking to headwords ==
I think we need ids in headwords, for form-of templates to link to.
Form-of templates currently allow an {{para|id}} parameter to link to a sense id. The need for some kind of id is clear, when there are multiple POS sections each with their own alternative forms. But using a sense id implies that an alternative form or inflected form only belongs to one sense. That's usually not true. Alternative or inflected forms generally apply to all senses inside a particular POS section. In order to use a sense id in a form-of template, you have to arbitrarily choose a sense to link to.
Ideally, we would link to the POS header itself. That's currently impossible, because sections for the same part of speech often occur multiple times in the same page. For instance, the page [[set]] has no less than 16 Noun sections, two of which are inside the English section. Adding the anchor <code>#Noun</code> will link to the first Noun section on the page, which is not necessarily correct. There is no way to add unique anchors to POS headers. It could be done by putting {{temp|anchor}} within the equals signs of the header (for instance, <code><nowiki>===Noun{{anchor|English noun 1}}===</nowiki></code>), but that's not currently allowed, and for good reason: it makes the anchor template display in the edit summary when you edit that section, and it breaks the link from the edit summary to the section.
The current solution is to link to a sense id in one of the definition lines in the desired POS section. This does not make sense for a form-of template. Forms generally apply to all or most definitions within the POS section, not to only one.
A better solution would be to link to an anchor within their headwords. We could add a {{para|id}} parameter to the headword template, and have [[Module:headword]] add <code>id="<var>headword id</var>"</code> to the first form in the headword. The form-of templates could then link to this id, instead of linking to the POS header directly above the headword.
<small>(An alternative would be to place {{temp|senseid}} in the same line as the headword template. That's sloppy, because it's called a sense id, not a headword id. As a sense id, it should only be used in senses [definition lines].)</small>
To implement this, we would have to replace the existing {{para|id}} parameter in existing form-of templates with {{para|senseid}}. Then we would decide on a format for the headword ids, and allow [[Module:headword]] to create these ids, and [[Module:links]] to link to them. This may be complicated, but I am interested in making it happen. — [[User:Erutuon|Eru]]·[[User talk:Erutuon|tuon]] 22:07, 14 May 2017 (UTC)
I can do this, but I want to make sure there's consensus for this before doing something major like this. Any objections? Benwing2 (talk) 03:39, 2 May 2017 (UTC)[reply]
The only objection is that we shouldn't rely on the boxes to provide these categories. For languages for which no one has added these boxes, the numbers should still be properly categorized with the headword templates and such. --WikiTiki8921:25, 2 May 2017 (UTC)[reply]
Sauraseni Prakrit transliteration
When I link to a word in Sauraseni Prakrit (psu) written in Devanagari (according to Module:languages/data3/p the only script for this language) with a template like {{l}} or {{m}}, the transliteration comes out in Devanagari as well, which seems counterproductive (e.g. Lua error in Module:parameters at line 95: Parameter 1 should be a valid language or etymology language code; the value "psu" is not valid. See WT:LOL and WT:LOL/E.). Either we should automatically transliterate the Devanagari into the Latin alphabet, or we shouldn't transliterate it at all. But "transliterating" it into the exact same script can't be right. —Aɴɢʀ (talk) 14:06, 2 May 2017 (UTC)[reply]
I think the problem is that it invokes Module:Brah-translit as if it were using Brahmi script, when it should (if it is written in Deva) invoke Module:Deva-Latn-translit. Any character that is not recognized by a transliteration module is "transliterated" as itself. ... But having made that change, I see that the instance above now produces a module error, so I undid my edit. - -sche(discuss)17:21, 2 May 2017 (UTC)[reply]
Or at the very least, edit some module so that no transliteration appears at all, as already happens for other Devanagari-script languages like Awadhi and Bhojpuri: {{l|awa|वेदस}} and {{l|bho|वेदस}} simply surface without transliteration, and that would be preferable for Sauraseni rather than this ridiculous "transliteration" into itself. —Aɴɢʀ (talk) 21:19, 2 May 2017 (UTC)[reply]
Yeah, I think interlingual script translit modules should check the script before transliterating (and return nil if it's the wrong script). --WikiTiki8921:24, 2 May 2017 (UTC)[reply]
So we have automatic interlanguage links now. I don't know where this is coordinated, but it apparently isn't working for entries containing certain non-ASCII characters. When I tried removing the interlanguage links from mało, łopata, and Sigolène, they vanished. The same problem is occurring in some other languages as well, but not all: cy:łopata is showing the links (although they've been removed from the page by bot), but pl:łopata has no links showing. —Aɴɢʀ (talk) 20:08, 3 May 2017 (UTC)[reply]
The Cognate extension has been discussed at length and announced at N4E, but the problem that it works on some pages and not on others has AFAICT not been discussed yet anywhere. —Aɴɢʀ (talk) 20:30, 3 May 2017 (UTC)[reply]
Thanks for your messages. Indeed, if you find some bugs or other things that Cognate doesn't do correctly, you can ping me and I'll transmit it to the developers. I created a ticket with the examples you mentioned.
Right now, like Vriullop mentioned, a problem occurs with the extension. We try to solve it as soon as possible, thanks for your understanding. Lea Lacroix (WMDE) (talk) 07:47, 4 May 2017 (UTC)[reply]
Broken script and links in new request categories
None of the request categories have links that point to the appropriate language section anymore. They are also no longer formatted with the appropriate script. This was still done when they were implemented by {{poscatboiler}}. —CodeCat20:51, 3 May 2017 (UTC)[reply]
Okay, I've made that category use an English catfix. If there are other categories like that, it can be done the same way. — Eru·tuon02:19, 4 May 2017 (UTC)[reply]
I think it can be attributed to the strain of introducing a major new extension at the same time they've been doing major work connected to the new backup-server location. With all that going on at the same time, it's a wonder that WMF's already-overextended technical staff hasn't completely lost it... Chuck Entz (talk) 02:15, 5 May 2017 (UTC)[reply]
Listing scripts for etymology languages
Now that we are using etymology language codes not only in {{etyl}} but also in templates like {{der}} and {{desc}} which take a term, we should list scripts for these languages in Module:etymology languages/data as well. In particular, I wanted to add Zzzz, Mani, Syrc to sog-bud, sog-man, and sog-chr, but I guess there won't be a difference since our modules are developed in a way to fetch data from Module:languages/data2 (etc.) only. --Z07:55, 5 May 2017 (UTC)[reply]
@ZxxZxxZ: It probably wouldn't hurt to add script codes to Module:etymology languages/data, since Module:etymology languages will probably just ignore them. But I can only imagine them being useful if the etymology language uses a subset of the scripts used by its parent language. In that case, they could be used to provide an error message if the script supplied to the template is not used for that etymology language, even if it is used for other varieties of the parent language. I can't think of examples where that would be needed, but perhaps there are some. — Eru·tuon08:56, 5 May 2017 (UTC)[reply]
@Daniel Carrero, Ungoliant_MMDCCLXIVMiddle Dutchhollant is a county that doesn't belong to a larger entity. Countries as such didn't exist yet, and the status of various polities as county, duchy, bishopric and such is largely arbitrary and probably not worth subcategorising. So I made brabant, a duchy, categorise in Category:dum:Polities. Can hollant be also made to categorise in that? I was able to add a new place type (duchy) but since county is already used by existing entries, I don't know how to do it. A thorough documentation of Module:place/data would certainly be appreciated for future reference! —CodeCat20:57, 5 May 2017 (UTC)[reply]
I see it too, even when logged in: <img src="//upload.wikimedia.org/wikipedia/commons/thumb/7/72/Disambig.svg/25px-Disambig.svg.png" alt="" style="width: 25px; height: 20px;" />. A quick guess is that perhaps the person who translated the banner at the top of the page that links to [1] into Icelandic may have messed something up in the code for it. I suggest leaving a post at meta:Meta:Babel asking them to check that everything is alright on their end. Or perhaps a recent change to some is.wikt site-wide .js or .css has done it? - -sche(discuss)17:10, 6 May 2017 (UTC)[reply]
Display of vertically written languages (Mongolian, Manchu)
Is it possible to convert a space in terms of these languages to a new line character (while keeping the transliteration unchanged), when they are generated by the link templates?
One problem: it will only transform spacing characters into <br> tags when the space is inside a link. Any spaces outside a link will not be converted to newlines. For instance, {{m|mnc|[[ᠰᡠᠩᡤᠠᡵᡳ]] [[ᠪᡳᡵᠠ]]||Milky Way}} displays as ᠰᡠᠩᡤᠠᡵᡳ ᠪᡳᡵᠠ(sunggari bira, “Milky Way”). There may be a way to fix this. — Eru·tuon23:27, 7 May 2017 (UTC)[reply]
@Erutuon Thanks. One correction is needed though: The character ‹› (U+180E, MONGOLIAN VOWEL SEPARATOR) should not be converted to a line break. An example is at тарвага(tarvaga); ᠲᠠᠷᠪᠠᠭᠠ is currently displayed as ᠲᠠᠷᠪᠠᠭᠠ(tarbag-a). Wyang (talk) 12:40, 8 May 2017 (UTC)[reply]
In ᠭᠠᠩᠰᠠ, the first instance of "ᠭᠠᠩᠰᠠ", above the language header displays horizontally, while the headword line displays vertically. I know we can italicize particular pages' titles (see w:Template:Italic title), can we cause these pages' titles to display vertically?
Also at ᠭᠠᠩᠰᠠ, it might be a more economical use of space to display the usexes side-by-side (perhaps in box elements?) instead of one after the other; can/should this be done? Ideally, the boxes would "break" onto new lines/rows based on screen width, or at least the current display would be preserved on the mobile version of the site.
Alternatively, perhaps {{usex}} (or a script-specific template) could take usexes of Mongolian-script and either link each individual word with a "black link" (a link that looks like regular text, as used in e.g. some inflection tables), or else somehow subject them to Erutuon's excellent line-breaking feature without linking anything, to reduce the amount of vertical space the usexes take up.
As the class Mong isn't applied to the heading at the top of the entry ᠭᠠᠩᠰᠠ(ɣaŋsa), the heading displays horizontally instead of vertically. {{DISPLAYTITLE:}} or a JavaScript function can be used to apply the class to the article title (see this edit, for instance). JavaScript would require less editing than {{DISPLAYTITLE:}}, but {{DISPLAYTITLE:}} would work even for readers who don't have JavaScript enabled. — Eru·tuon08:33, 8 May 2017 (UTC)[reply]
It seems to be possible to obtain verticalization even by transcluding a template that includes {{DISPLAYTITLE:{{lang|mn|{{PAGENAME}}|sc=Mong}}}}. Would it be feasible and desirable to edit the headword-line templates of languages that use Mongolian script to use such an approach (perhaps different templates could be used on Mongolian- vs Cyrillic- pages, or one template could be smart enough to only apply DISPLAYTITLE on Mongolian-script pages), so that rather than separately spelling out {{DISPLAYTITLE:}} on every page, merely adding a standard headword-line template would verticalize the page title? - -sche(discuss)09:01, 8 May 2017 (UTC)[reply]
Hmm, that's an interesting idea. I wonder if a Lua module can use the {{DISPLAYTITLE:}} magic word (or if it can correctly expand a template that contains that magic word). If it can, the headword module could certainly do what you suggest. That would also be nice, though perhaps less important, in entries using other scripts. For instance, it would be great if Ancient Greek entries could apply the class polytonic to the title, though in some cases the Modern Greek entry would be found on the same page, and Modern Greek uses the class Grek instead. — Eru·tuon09:58, 8 May 2017 (UTC)[reply]
@Vriullop: I copied your Lua code to Module:User:Erutuon/Mongolian and am testing it at User:Erutuon/ᠭᠠᠩᠰᠠ, but it doesn't seem to be working. In preview mode, it gives the message Warning: Display title "<span class="Mong">Erutuon/ᠭᠠᠩᠰᠠ</span>" was ignored since it is not equivalent to the page's actual title. Rather odd. — Eru·tuon12:33, 8 May 2017 (UTC)[reply]
@Vriullop: I find display:table-caption; causes the quotations in ᠭᠠᠩᠰᠠ(ɣaŋsa) to overlap, and the headword to overlap the bullet that is after it. See the screenshot to the right. Screenshot of the entry ᠭᠠᠩᠰᠠ on the English Wiktionary, with display: table-caption; applied to the class Mong (for Mongolian script) in my common.css. — Eru·tuon13:04, 8 May 2017 (UTC)[reply]
Thanks to @Vriullop, I tried again and figured out how to make the display title thing work. So the top header in ᠭᠠᠩᠰᠠ(ɣaŋsa) and other Mongolian-script entries will now have the class Mong and will display vertically. The same can perhaps be done with other scripts. — Eru·tuon13:26, 8 May 2017 (UTC)[reply]
I notice that the entries in Category:Manchu lemmas are vertical (and remain so even when I add testentry to the category, which itself becomes vertical), whereas Mongolian-script entries in Category:Mongolian adjectives are horizontal (probably so that the more numerous Cyrillic entries display correctly?). I suppose there's no way around that.
What does this newline conversion code do when it encounters spaces in code, like say in a HTML tag or Wikimarkup? —CodeCat18:05, 8 May 2017 (UTC)[reply]
Well, {{usex|cmg|ᠮᠥ<a href{{=}}"https://en.wiktionary.org/wiki/ice">ᠰ</a>ᠦᠨ|ice}} results in the "<a href="https://en.wiktionary.org/wiki/ice">" being broken at the space and displayed as text (see here), but under what circumstances would such a thing occur validly? I had to use {{=}} just to make that "work" (i.e. not just resolve to a Lua "parameter not used" error). (If there are valid usecases, perhaps we could add a switch by which users could suppress space-to-newline conversion in individual instances?) If the concern is that it might sometimes be necessary to call a template that includes a space in its name inside a {{usex}} or the like (as in this contrived example), that could be solved by having a redirect to the template from an unspaced name. - -sche(discuss)19:54, 8 May 2017 (UTC)[reply]
The code I've written assumes that the text being script- and language-tagged only contains wikilinks, nothing else. I'm not satisfied with it, because it's overly verbose. And it should be able to find and ignore anything that should not be transformed (HTML tags, the target part of wikilinks) and then just replace spaces in the rest. That would be much simpler. I'm trying to figure out how to do that. — Eru·tuon22:17, 8 May 2017 (UTC)[reply]
Done. Anything that should not have its spaces transformed (currently, wikilink targets and HTML tags) is escaped before the replacement, then unescaped. — Eru·tuon22:50, 8 May 2017 (UTC)[reply]
It's good that our articles nowadays automatically get interwiki (inter-language) links. But our semantic categories still need manual linking (right?), the way it used to be in Wikipedia. So, once I found out that Category:Hormones should link to ru:Категория:Гормоны and sv:Kategori:Hormoner, is there some tool (on the WMF toolserver) that helps me in interwiki linking all the subcategories such as Category:en:Hormones to their counterparts in the other languages? --LA2 (talk) 21:25, 7 May 2017 (UTC)[reply]
I'm working on some changes to {{desctree}} in {{desctree2}}, which I outlined here. I'm trying to logic out how to deal with the alternative forms. I could employ some method using |altN=, but I would prefer it if I could use * {{desctree|goh|apful}}{{l|goh|aphul}}, ... and have the imported list of descendants start on the next line. Is there some way to do this in Lua, like table.insert(arr, currentline+1)? --Victar (talk) 04:37, 8 May 2017 (UTC)[reply]
@Victar: I don't think that's possible. A Lua-based template can only insert content at the position where you put it in the text. — Eru·tuon04:39, 8 May 2017 (UTC)[reply]
@Victar: The module might be able to grab the content from the {{l}} after the {{desctree}}, but I'm not aware of any way in which it could delete the content of that {{l}}. So, you would still have the alternative form aphul repeated after the descendant tree. — Eru·tuon05:54, 8 May 2017 (UTC)[reply]
Apply a font to cuneiform page titles
Erutuon, with some help from Vriullop and me, excellently found a way to apply a class to the page titles of Mongolian-script pages so that they display correctly. Can we similarly apply a class to the pagetitles of cuneiform pages, so that they are rendered in the same font as they are when they are linked (𒋼), rather than the default font they are currently rendered in, which displays them as boxes (for me)? More generally, we could perhaps apply classes and hence relevant fonts to many non-Latin scripts which might otherwise display as boxes. - -sche(discuss)19:39, 8 May 2017 (UTC)[reply]
You mean they do now, or they always did? I think that whether or not they display without script-tagging depends to some extent on whether a user already has a font installed that can display them, and on how recent their operating system and browser are. Script-tagging them helps them display for more people. - -sche(discuss)00:46, 11 May 2017 (UTC)[reply]
How "expensive" is this script-tagging of page titles? Do we know? If it's "inexpensive", perhaps tagging most non-Latin scripts would be appropriate. - -sche(discuss)00:46, 11 May 2017 (UTC)[reply]
Something to consider: the software disallows overriding the display title more than once. I believe the second attempt results in an error. That means that any entry with more than one headword line will break. —CodeCat00:59, 11 May 2017 (UTC)[reply]
I don't think it does cause an error. I have added tagging for polytonic, and that would probably make the display title function be called twice in a page such as ὅς(hós), yet there's no error there. — Eru·tuon01:25, 11 May 2017 (UTC)[reply]
However, if I tried to add tagging for Grek along with polytonic, on a page like λόγος(lógos) that has an entry for Modern Greek as well as Ancient, I suspect the <spanclass="Grek"></span> added by the Greek headword template would override the <spanclass="polytonic"></span> added by the Ancient Greek one, because the alphabetization makes it be the last on the page. It seems the last display title on the page is what is actually used. I tested this by adding {{DISPLAYTITLE:ὅς}} on ὅς(hós): if I place this DISPLAYTITLE parser function at the top, it's overrided by the polytonic-class display title added by the headword template; if I place it at the bottom, it overrides the headword template. So, the last DISPLAYTITLE on the page is the one that wins out, but there is no error. — Eru·tuon01:33, 11 May 2017 (UTC)[reply]
Oops! There is an error, at the bottom of the page, in preview mode at least: Warning: Display title "ὅς" overrides earlier display title "<span class="polytonic">ὅς</span>". When the display titles added by subsequent headwords are identical, there seems to be no such message. — Eru·tuon01:43, 11 May 2017 (UTC)[reply]
@Romanophile: I think what "missing plurals" means is that there is currently no entry for the plural. Module:fr-headword, which is used by {{fr-noun}}, checks to see if the entry title for each plural form exists. Feminine nouns without entries for their plurals are also put in this category: see accessoirisation. — Eru·tuon02:58, 10 May 2017 (UTC)[reply]
The current spelling templates produce confusing and misleading entries, at least the one for American spelling. Now almost all users interpret demonize, for example, as saying that its meanings are American, not its spelling (which isn't even true). --Espoo (talk) 07:03, 10 May 2017 (UTC)[reply]
I'd thought the spelling e instead of ae might be not in use in UK English, but it seems we have editors who don't even know the basics of UK spelling and think that -ize is not also UK. Is there a bot that can find and fix this kind of nonsense? --Espoo (talk) 07:13, 10 May 2017 (UTC)[reply]
@Victar: I'm sort of a newbie with JavaScript, but perhaps it's not working because you only escaped the first curly bracket in each group? Each one should be individually escaped. — Eru·tuon03:02, 11 May 2017 (UTC)[reply]
I copied your code to my common.js and correctly escaped the brackets, but it still doesn't add anything to the toolbar while I'm in editing mode. — Eru·tuon03:33, 11 May 2017 (UTC)[reply]
The instructions for adding your own toolbar button that uses a JavaScript function leave me at sea as to just how the callable function is supposed to work. — Eru·tuon03:54, 11 May 2017 (UTC)[reply]
@Erutuon: Yeah, the documentation really sucks. Thanks for looking into it. I just reverted it back to my original version so I can at least use it for now. --Victar (talk) 04:17, 11 May 2017 (UTC)[reply]
Show-and-hide templates not working properly
The templates in the "derived terms" and "translations" sections of our entries ({{trans-}} and {{rel-}}) are not working anymore. They normally have a button to show and hide the content inside them, but this button apparently disappeared, making the templates nonfunctional. I've tried different browsers and computers and still get the same problem. What is the matter? - Alumnum (talk) 04:06, 11 May 2017 (UTC)[reply]
Additionally with Chrome (but not Netscape or Edge) I have a long blank space between the bottom line and the category section - but only when there is a pull down table (like inflections) present. — Saltmarsh. 04:46, 11 May 2017 (UTC)[reply]
Using Chrome logging out make the long blank space (see above) disappear, by the show/hide problem is still there — Saltmarsh. 05:22, 11 May 2017 (UTC)[reply]
Yup, all quotations are no longer visible, and the "Show translations" and "Show quotations" links on the left side of the screen are gone. Quiet Quentin also no longer appears. — SMUconlaw (talk) 08:48, 11 May 2017 (UTC)[reply]
Not loading LegacyScripts was provoking a cascade of errors in unexpected places. Once fixed, the problem with TabbedLanguages is beyond my understanding, but obviously they are related and provoked by last version of Mediawiki installed last UTC night. --Vriullop (talk) 15:57, 11 May 2017 (UTC)[reply]
Help, declension tables no longer are openable
I think this applies to all collapsible tables. I see it e.g. on the page любимица, where the declension table is missing the button to open it. User:JohnC5 noted something similar in the April Grease Pit. I don't have any Javascript, and I don't even know what skin I have. (How does one switch skins?) I tried this on Chrome and Safari (on Mac OS 10.9.5), same thing. It even happens when I log out. Any ideas? Benwing2 (talk) 05:58, 11 May 2017 (UTC)[reply]
Is the JavaScript function that handles this collapsible content a local Wiktionary thing or a global MediaWiki feature? — Eru·tuon06:06, 11 May 2017 (UTC)[reply]
Is it my phablet or is there a bigger problem? I restarted the phablet, but nothing happens when i click on a translation box in Android Chrome and Firefox. It worked yesterday. --Espoo (talk) 07:40, 11 May 2017 (UTC)[reply]
Just discovered that all other drop-down boxes are broken too, f.ex. conjugations. Also discovered it's only broken in desktop view, not mobile -- both on phablet. Will now test on laptop. --Espoo (talk) 07:58, 11 May 2017 (UTC)[reply]
Checked with 3 browsers. Arrows do not appear, nor selected language translations. When inspecting pages I can see:
Gadget "LegacyScripts" styles loaded twice. Migrate to type=general.
Gadget "DocTabs" styles loaded twice. Migrate to type=general. <https://www.mediawiki.org/wiki/RL/MGU#Gadget_type>.
VM60:243 This page is using the deprecated ResourceLoader module "es5-shim".
Use of the "es5-shim" module is deprecated since MediaWiki 1.29.0--Spiros71 (talk) 09:38, 11 May 2017 (UTC)[reply]
Thank you, this is informative. Vriullop describes the same message on ca.Wikt, and a fix which could be tried. I wonder what caused the gadgets to break / to 9apparently) need |type=general] to be declared... - -sche(discuss)09:51, 11 May 2017 (UTC)[reply]
Apparently there is a general issue where "Gadgets that use both scripts and styles, but do not specify type=general, are never loaded (JS file not loaded but CSS file is)" (per a report on Phabricator). But type=general appears to have been set for TabbedLanguages in this diff; does the problem persist? - -sche(discuss)19:02, 11 May 2017 (UTC)[reply]
This was one of the collateral effects by LegacyScript not loading. Once fixed, this error message does not appear any more and purgetab is working fine. But the problem with TabbedLanguages persists. --Vriullop (talk) 20:21, 11 May 2017 (UTC)[reply]
CSS classes for transliterations
It would be beneficial to have CSS classes for transliterations. Many transliteration systems use characters that will not display well in all fonts. With predictable classes, fonts could be specified in MediaWiki:Common.css to ensure they display well. Or users can set whatever fonts they like in their common.css. I've wanted to do the latter. Or users can write JavaScript functions that convert one transliteration system to another, allowing people to see whatever transliteration system they prefer.
Currently, all transliterations are tagged with class="tr", if generated by {{l}}, or with class="tr mention-tr", if generated by {{m}}. So, there is no way to distinguish between transliterations of different languages when using JavaScript, and absolutely no way when using CSS. They are all identical.
I was thinking the class names could be tr- plus the language code. Then, the transliteration class for Ancient Greek (language code grc) would be tr-grc. That would be following the tradition of using |tr= for transliteration, and of using the class tr to mark transliterations in general. Or perhaps translit- plus the language code could be used instead (translit-grc). Or the order could be reversed (grc-tr or grc-translit). This reversed order would resemble a language code combined with script code (fa-Arab), though translit isn't a script. Not sure which of these ideas is best.
These class names would be added on to the default ones: thus, the class for an Ancient Greek transliteration in the {{m}} template would be class="tr mention-tr tr-grc". So, no existing functionality would be broken.
This idea is perhaps not absolutely necessary, but it would allow for easier customization of transliterations with CSS and JavaScript. — Eru·tuon05:49, 11 May 2017 (UTC)[reply]
I don't think this is necessary, as it is possible with CSS selectors to style by language (e.g. .tr:lang(grc)). This was added in CSS2 and has wide support. – Krun (talk) 11:28, 11 May 2017 (UTC)[reply]
@Krun: But at the moment there's no language attribute (lang="grc") added to a language's transliteration, so that selector wouldn't work. For instance, in the headword of ἀρχιμανδρῑ́της(arkhimandrī́tēs), the transliteration is coded as follows: <spanclass="tr"lang=""xml:lang=""><spanclass="tr"lang=""dir="ltr"xml:lang="">arkhimandrī́tēs</span></span>. This can only be selected with .tr or :dir(ltr). Perhaps Module:links (which currently handles transliterations) should add the language attribute to the transliteration. This would be fine since MediaWiki:Common.css currently doesn't use language codes alone to set fonts (if it did, adding language attributes to transliteration might cause the wrong fonts to be applied to transliteration). — Eru·tuon16:43, 11 May 2017 (UTC)[reply]
On the other hand, it might cause problems for screen readers, which would try to read the transliteration because it was tagged with a language code, and would likely fail because they would only be able to read the language's native script. Hence, separate classes for each language's transliteration might be a better idea. — Eru·tuon16:45, 11 May 2017 (UTC)[reply]
@Erutuon: Ah, I didn't realize the language code was missing. The transliteration should definitely be tagged with the relevant language code (in this case grc), as it is text in that language, whatever the script. It's definitely a problem if it isn't, because in that case it inherits the language designation of a parent/ancestor tag or the entire page, namely en, and would e.g. be read by a screen reader as text in English! When the script is different, as in this case, that can and should be indicated in the HTML (lang="grc-Latn"). – Krun (talk) 10:17, 12 May 2017 (UTC)[reply]
@Krun: Hmm. lang="grc-Latn" sounds reasonable, but what about class="(tr mention-tr )Latn" lang="grc"? Putting in Latn as a class would be more consistent with the way we usually handle scripts. — Eru·tuon01:20, 14 May 2017 (UTC)[reply]
I've gone and done the script class and language attribute solution. Now a language's transliteration can be selected with, for instance, :lang(grc).Latn. — Eru·tuon02:03, 14 May 2017 (UTC)[reply]
Automatic sorting
Greetings. Is there any way to sort lists automatically in wiki? It would be useful as it is painstaking to sort long lists by hand (lets say without text editor). Perhaps something like this could be enabled? https://www.mediawiki.org/wiki/Extension:Sort2 Another option I can think of could be the table sorting Javascript ("wikitable sortable") https://en.wikipedia.org/wiki/Help:Sorting Anyone care to find the best way and implement it (in case we have nothing)? --Hartz (talk) 06:03, 11 May 2017 (UTC)[reply]
It is possible to make a list auto-sorted by Lua modules. However, every language is alphabetically ordered in its own way, so it must be per-language concept. The extension just globally sorts them out in one way which might not be preferable. --Octahedron80 (talk) 11:52, 11 May 2017 (UTC)[reply]
Possibly I'm doing something wrong. I'm typing a new word into the search box, eg ghzz. Then I click on the "create it" link in the search results. This takes me to this page, which the url claims to be the User:Yari_rand app for new creations, but the edit box is completely blank and there is no template for selecting entry parameters. Monobook, Firefox 53.0.2, Windows 7 SP1 64bit. SpinningSpark18:10, 11 May 2017 (UTC)[reply]
Looking at this further, it seems that it is something in my own monobook.js that is breaking it. Since I haven't changed anything in my personal js recently, I guess this must be an old script-pocalypse issue. SpinningSpark21:05, 11 May 2017 (UTC)[reply]
Translation pop-ups not opening?
When I checked a word today (11 May), the translation pop-ups did not display an 'open' button.
The html text of the translations is still there, if I click on 'edit', so I am assuming a technical problem of some sort.
I checked a number of other words, and they are all doing the same thing. — This unsigned comment was added by 2602:302:D10C:83B0:226:8FF:FEEB:4F85 (talk) at 13:44, 11 May 2017 (UTC).[reply]
Is there a way to place site-wide JS pages in a category? I think this would be useful as half the time I can't find them. —CodeCat19:20, 11 May 2017 (UTC)[reply]
I created Module:translit-redirect to do the work of choosing between transliteration modules, for languages written in several different scripts. It replaces modules such as Module:pa-translit and Module:khb-translit (Punjabi and Lü), which simply redirect to another module, depending on which script is being used. The other module does the actual work of taking the native script and generating a transliteration. The redirecting code in these two modules is remarkably similar. It seems simpler to centralize all this transliteration-redirecting in one module. So far, I've made Punjabi use the redirecting module, and it appears to work. — Eru·tuon04:04, 12 May 2017 (UTC)[reply]
Bot request: External links → Further reading
Can a bot do this, please?
Change all instances of the heading "External links" into "Further reading".
While someone is running a bot doing this, you could also check for any instances of "Future reading". I may have made that typo from time to time when renaming the sections manually. —Aɴɢʀ (talk) 09:47, 12 May 2017 (UTC)[reply]
I just grabbed the latest dump and can work on this. TheDaveBot has started running, if anyone wants to look at the changes. And I am looking for "Future reading" as well. - TheDaveRoss15:04, 12 May 2017 (UTC)[reply]
Also, it's being transcribed as a two-syllable word, but it's a monosyllable with a long diphthong. The 5th-century BC pronunciation should be /nɛ̂ːu̯s/, not /nɛː.ŷːs/. —Aɴɢʀ (talk) 14:56, 12 May 2017 (UTC)[reply]
Hi , Is there a tool that check loops in wiktionary definitions ?
that is two terms each defined by the other.
I was asked to write such a bot to the hebrew wiktionary so I better first check if such a bot exist already. — This unsigned comment was added by Shavtay (talk • contribs) at 21:07, 12 May 2017 (UTC).[reply]
Do we still need this? It claims "This script changes timestamps such as those in comments to be relative to the local time", but all it does is import MediaWiki:Gadget-TranslationAdder.js. (Is this a reminder that the "editor" functions need to be split out of the "translation adder", and if so, can someone do that?) Also on the subject of gadgets which seem to only load other gadgetry: MediaWiki:Gadget-WiktBlockedNotice.js. - -sche(discuss)16:51, 13 May 2017 (UTC)[reply]
A discussion from 2010, archived on the talk page, suggests this category should be renamed, but a bigger issue IMO is that it should be generated automatically in entries that use {{en-noun}}, rather than being added manually to such entries. (Then we have to decide what is "irregular": any plural other than "s" or "es"?) - -sche(discuss)20:03, 13 May 2017 (UTC)[reply]
Yes, the only cases that come to mind where a plural could be in the "irregular plural" category while the singular was not in the "nouns with irregular plurals" category are cases where the plural is too nonstandard and uncommon to give in the headword of the singular, like dogz, but I wouldn't expect casual users to notice such a distinction and I'm not convinced it'd be useful. (Plus it could be argued dogz isn't even irregular, but a regular eye-dialectal change.) So I'd be OK with getting rid of Category:English irregular plurals. - -sche(discuss)04:08, 14 May 2017 (UTC)[reply]
Like water did before we split its translations onto a subpage (see GP, BP), man is now running out of memory. I've null-edited the page several times and the error is consistently in the Swedish etymology section (whereas the error in water would move several sections up or down after null edits), but it does display a small amount of randomness: sometimes the memory runs out right at Proto-Germanic, sometimes it runs out at PIE. I have a Phabricator report ready to file about water and man, but before I file it, are we still suspecting that individual tasks like instances of {{t}} not releasing memory after they finish is a cause? And what assistance would we want from the folks at Phabricator if they say they can't change their implementation of Lua? - -sche(discuss)06:44, 14 May 2017 (UTC)[reply]
I don't have answers to your questions, but I changed{{t-simple}} so that it frees up a little memory, pushing the error to the Declension section for Volapük. Strangely, when I switched more translations to {{t-simple}}, it made the problem worse. — Eru·tuon08:23, 14 May 2017 (UTC)[reply]
I think there may be some wasted memory in our language and script objects, though I'm not sure how to confirm that. Each language object contains one or more script objects. This probably results in duplication. For instance, when we have many languages in the translations list that use the Latn script, the Latin script object will be repeated inside each of those language objects. That duplication could account for part of the memory problem.
(I don't know about the whole memory-releasing thing, but I'm imagining there's a counter that tracks how much memory is used, whether or not it is released when the functions have done their work.) — Eru·tuon08:34, 14 May 2017 (UTC)[reply]
Adding ids to enable linking to headwords
I think we need ids in headwords, for form-of templates to link to.
Form-of templates currently allow an |id= parameter to link to a sense id. The need for some kind of id is clear, when there are multiple POS sections each with their own alternative forms. But using a sense id implies that an alternative form or inflected form only belongs to one sense. That's usually not true. Alternative or inflected forms generally apply to all senses inside a particular POS section. In order to use a sense id in a form-of template, you have to arbitrarily choose a sense to link to.
Ideally, we would link to the POS header itself. That's currently impossible, because sections for the same part of speech often occur multiple times in the same page. For instance, the page set has no less than 16 Noun sections, two of which are inside the English section. Adding the anchor #Noun will link to the first Noun section on the page, which is not necessarily correct. There is no way to add unique anchors to POS headers. It could be done by putting {{anchor}} within the equals signs of the header (for instance, ===Noun{{anchor|English noun 1}}===), but that's not currently allowed, and for good reason: it makes the anchor template display in the edit summary when you edit that section, and it breaks the link from the edit summary to the section.
The current solution is to link to a sense id in one of the definition lines in the desired POS section. This does not make sense for a form-of template. Forms generally apply to all or most definitions within the POS section, not to only one.
A better solution would be to link to an anchor within their headwords. We could add a |id= parameter to the headword template, and have Module:headword add id="headword id" to the first form in the headword. The form-of templates could then link to this id, instead of linking to the POS header directly above the headword.
(An alternative would be to place {{senseid}} in the same line as the headword template. That's sloppy, because it's called a sense id, not a headword id. As a sense id, it should only be used in senses [definition lines].)
To implement this, we would have to replace the existing |id= parameter in existing form-of templates with |senseid=. Then we would decide on a format for the headword ids, and allow Module:headword to create these ids, and Module:links to link to them. This may be complicated, but I am interested in making it happen. — Eru·tuon22:07, 14 May 2017 (UTC)[reply]
Done. The documentation for editing the data module is at Template:place/documentation, as I felt it better to keep documentation in a single page at the time. — Ungoliant (falai) 21:04, 5 May 2017 (UTC)
