[10:43:26] hi everybody! i have a weird problem with a mediawiki installation. i upgraded it from 1.2x to 1.37 which went mostly perfectly smooth. but all TOC entries with non-ascii characters in them are broken now (and we have a lot of them, as we are in germany...). The problem is: The heading, the TOC entry, and the #link in the TOC is, for example, [10:43:27] "Übersichten". Just the anchor in the seite, the point where it should scroll to, is ".C3.9Cbersichten". only the anchor in the site is converted to .-seperated unicode, while all other places are not converted, so the links no longer work. when i edit one of those headings, it works for a while - but after a few hours it seems to break again [10:43:27] which is completely weird for me. any ideas on that? [11:47:08] hi everybody! i have a weird problem with a mediawiki installation. i upgraded it from 1.2x to 1.37 which went mostly perfectly smooth. but all TOC entries with non-ascii characters in them are broken now (and we have a lot of them, as we are in germany...). The problem is: The heading, the TOC entry, and the #link in the TOC is, for example, [11:47:08] "Übersichten". Just the anchor in the seite, the point where it should scroll to, is ".C3.9Cbersichten". only the anchor in the site is converted to .-seperated unicode, while all other places are not converted, so the links no longer work. when i edit one of those headings, it works for a while - but after a few hours it seems to break again [11:47:09] which is completely weird for me. any ideas on that? [11:52:56] damaltor: link anchors with non-ascii characters are no longer encoded. This is a change in recent versions [11:53:40] It should work and be consistent from the TOC and from links from other pages using [[internal links]] [11:54:10] If you pasted a full URL from another page, the anchor may have been changed during the upgrade [11:54:53] yes, that is what i would expect. but i have installed 1.37.1 which should be the latest stable version, and while the TOC entry, the link#anchor and the heading itself are not encoded, the acutal anchor in the page (in the tag) is encoded, so the links in the toc do not work. [11:56:20] i have not pastet from somewhere else - i mean the auto-generated TOC on every normal mediawiki page. The toc is generated fine, all texts in the toc look good, all headings are nice, and the anchor after the # sign is ok. but the span id which encloses the heading itself to allow linking to that section is encoded. [11:58:44] in fact, i "just" have to find out where the span code is generated so i can remove the encoding function... [12:00:09] Vulpix this is an actual line from my wiki:

Übersichten and you can see that in the anchor the encoding is still done for some reason [12:05:11] damaltor: according to https://www.mediawiki.org/wiki/Manual:$wgFragmentMode the HTML should generate both encodings (encoded and not encoded) [12:05:50] And that's what its doing btw, it should work with the second [12:07:11] In what browser are you experiencing this problem? Looks like that browser may not be supporting HTML5 anchors [12:07:53] It works for me here for example [12:09:07] i am experiencing this with firefox. did not experience it with the old 1.27 (?) version, so i am unsure why that happens. will have a try with edge... [12:09:26] your link does not work for me, but if i click the link in the toc on that page it works fine 0o [12:10:16] does not work with edge either. :( [12:11:34] IRC may break some links. I've surrounded the link between <> because that's how some of them delimiter links. The parentheses may break the link before the actual end, or the > may be included in the actual link... IRC sucks for this :) [12:11:48] yep, thats right :) [12:13:09] i really dont know why that does not work. my TOCs dont work in firefox and in edge. this ist the line in the TOC: [12:13:09]
  • 10 Übersichten
  • [12:13:40] and this is the line of the actual heading:

    Übersichten [12:14:43] so, it should work as there is a link to #Übersichten and there is a span with the corresponding id. it does not tho. maybe i have to set the fragmentmode to that legacy setting ad it is a migrated wiki? [12:14:59] *as it is... [12:16:34] You can of course define that setting as [ 'legacy', 'html5' ] to return to the old behavior [12:17:14] The HTML it generates is valid to current standards. I don't know why it would fail for you, though [12:18:10] i dont know either. it affects both browsers on my pc and a lot of other users as well. while i dont like living with the legacy stuff i will have to try that probably. [12:19:03] I don't know if the browser will "downgrade" its acceptance of HTML5 anchors if it detects the page as not being HTML5. For example, if the page is rendered as quirks mode because there's some spurious text before the at the start of the HTML [12:19:53] interesting idea. give me a minute, i will try changing that setting. [12:19:58] Is your wiki public so we can see an example page if you share the URL here? [12:22:35] well, i made the setting in the way you suggested. in the source code of the page the "old" and "new" span ids did now swap their place and the TOC links do work now [12:23:19] i am sorry, but it is the internal wiki of my corporation so it is only reacheable in the local network [12:25:38] Vulpix while i am still stunned why this would not want to work, and still dont understand at all why it works for a few minutes directly after editing the page (though that might hve something to do with some javascript trickery of the visual editor), the problem ist kinda solved now - changing the fragmentmode makes the links work again though it [12:25:39] really feels like a hack more than like a soution... still a big, big thanks to you for pointing me in that direction. 100 internet points to you [12:30:38] I guess your browsers are recent-ish versions, right? We're not talking about Firefox 38 or similar... [12:31:41] nah, firefox updated today actually :) and edge.. well i never use edge and our windows updates come from our local WSUS but it should not be _that_ old [12:33:28] i can see the trick with the double span tags now, i never realized why there are two of them until now. still i am stunned why on earth that would not work as the code looks perfectly valid to me [12:33:56] also, klicking unice toc links on wikipedia works for me, too so there must be a difference [12:37:51] OMG i just noticed something else: before changing the setting, the toc link was not encoded, and the heading had an empty encoded and a filled not encoded span. now the TOC is encoded, the EMPTY span is unencoded, and the filled span is encoded. all things switched places. before and after the setting change, the toc pointed to the span that [12:37:52] contained the actual header. [12:38:09] so... if it did not work before... why does it now? :D [12:41:18] i have now copied the source code of a wikipedia page into my wiki and it behaves the same. unchanged setting: not working. setting to legacy as described: does work [12:43:24] both websites - wikipedia and mine - start with the same doctype and the same encoding meta. i have no more ideas... still i am happy to have found a workaround now.. [12:50:58] Very strange, yes [12:52:04] even mre interesting, setting it to html5 only still generated both spans and soes not work for me. [12:53:14] kinda sad that its 2022 and encoding characters ouside of ascii still is a problem... [14:06:02] bye everybody! [19:09:21] hi, is it possible to pass arguments to a module via API call (for example, i am looking at Module:en-headword function on wiktionary)? either it is not possible or i am missing something [19:14:36] like, can i get the results of evaluating this with some arguments https://en.wiktionary.org/w/index.php?title=Module:en-headword&action=raw ? [19:14:54] other than by making a template with it [19:15:48] no [19:15:55] to answer the first question [19:16:02] modules do not have access to the php API [19:16:25] (Javascript does of course) [19:17:53] wait i got it [19:18:07] it calls the current title so i passed title= [19:18:47] oh [19:18:48] no [19:18:50] that just [19:18:52] does what you'd expect [19:19:04] oh well [19:19:12] what are you actually trying to do? [19:20:23] i'm using wiktionary data for a parts of speech labeler, ... what i was doing before was working fine (just looking up words and getting their part of speech from en-verb, en-noun, etc templates), ... i was just exploring and wondering what is possible really [19:21:00] there's so much stuff and some of it is really messy so i got a little overwhelmed and wanted to get a quick answer before i kept looking ... thank you [19:21:55] ah, ok, as long as you're, uh, 'happy' [19:21:56] :) [19:22:06] soldier on! [19:23:25] lol, ty .. i hope the results will be useful or interesting to someone someday :) [20:07:59] Hola, cómo podría eliminar una cuenta de Phabricator?, ¿Alguien? [20:24:50] Guest60: Solicítalo aquí (deberás iniciar sesión con tu cuenta de MediaWiki): https://www.mediawiki.org/wiki/Talk:Phabricator/Help [20:31:46] Vulpix: Muchas gracias por la respuesta