[00:07:15] DSquirrelGM: could you please pass me names of these ones which used to? or ask them what they used [00:08:52] I don't even remember now, or I would have mentioned them, they weren't sites I used regularly, just some random search results years ago [00:33:59] ok, thank you [00:36:34] Well i think wikimedia does that, in order to implement cross-wiki notifications (not 100% sure how it really works) [00:37:11] I think their existing software updates the notifications only on page reload, not on the fly? [00:38:26] Oh, you mean that on the fly (I was thinking on the fly in the sense of not coming from the normal backend) [00:38:40] Umm, i think there was also some work on updating notifications in real time [00:39:17] Maybe i'm thinking about https://phabricator.wikimedia.org/T113125 which might be a bit different [00:40:40] they overlap quite significantly [05:02:46] [[Tech]]; 109.240.40.206; /* Automaticly switch to mobile/desktop mode based on browser OS. */ new section; https://meta.wikimedia.org/w/index.php?diff=19803537&oldid=19767532&rcid=14873246 [05:05:44] [[Tech]]; Gryllida; /* Automaticly switch to mobile/desktop mode based on browser OS. */ examples? timeless; https://meta.wikimedia.org/w/index.php?diff=19803542&oldid=19803537&rcid=14873255 [19:22:58] hi, I have a question about a particular feature I've implemented on an independent mediawiki install at palmleaf.org. there is a thing that automatically transliterate text in Balinese script to latin, for example: https://palmleaf.org/wiki/carcan-kucing [19:24:32] my question is basically how something comparable could be achieved on wikisource. the current implementation is probably not tenable -- basically it gets stored in the wikitext using a custom tag , but there's an extension which makes sure that that tag gets stripped out from the edit box (since it isn't supposed to be user editable) and then regenerated from the Balinese source [19:24:38] text on save [19:25:03] it feels like a "proper" implementation would not save the transliteration as part of the page at all, but rather be generated client-side [19:25:42] it would be nice if that could be cached and not regenerated every time, for slow connections (which among other reasons is why I did it the way I did on palmleaf.org) [19:26:04] anyway, I would appreciate any pointers. fwiw I already made a tool on toolforge for the transliteration backend. [19:27:32] or, I guess make it part of LanguageConverter [19:28:44] the thing is, we don't want these two to be alternatives -- we'd want to include just the original, or both, but not just the latin [19:36:41] Any GCI 2019 org admins around for a pm? [19:36:49] * Urbanecm here [19:38:38] oh - since you're here - what's with that 900MB+ .sql file in the scratch directory that hasn't been touched since 2017? @ Urbanecm [19:39:33] the one for one of your tools [19:40:22] DSquirrelGM: good question. Let me check [19:42:28] DSquirrelGM: probably a relict from an old version of that tool, maybe a backup before a rewrite. I'll delete it. Thanks for the info. [19:43:34] was looking around in the shared data area, went to view it, saw a LOT of repetetive insert calls on it... seemed odd [19:44:02] I'm really not sure why I created it, but it doesn't appear to have anything useful :-) [20:32:08] ningu: probably languageconverter is the "right" answer [20:32:16] i could probably help consult on that if you like [21:24:24] did anyone see my transliteration question from earlier? [21:24:36] [13:32:08] ningu: probably languageconverter is the "right" answer [21:24:36] [13:32:16] i could probably help consult on that if you like [21:25:28] thanks [21:26:38] cscott: how would languageconverter work for the use case I described? [21:31:42] cscott: incidentally it seems like this functionality really should go through ICU anyway since that's based on stuff already in CLDR and arguably more standard. plus CLDR has a ton of transliteration rules [21:31:58] just something to think about for the future of LanguageConverter type stuff [21:32:02] but I'm wondering how it should be done for now [22:06:26] On Wiktionary someone posted about visited links (a:visited) changing color so that they're hard to distinguish from un-visited links. [22:06:29] https://en.wiktionary.org/wiki/Wiktionary:Information_desk/2020/February#Sudden_changes_to_interface [22:06:53] There were no edits to Wiktionary's CSS; could this be a MediaWiki change? [22:08:23] does the css explicitly set both colors? could also be user agent change in some browser [22:10:19] Yes, I checked in Inspector and the colors for `a` and `a:visited` are both set by a stylesheet from .../load.php [22:10:43] It kinda sounds related to a deploy [22:12:52] But both enwiki and mediawiki.org seem to have the same behaviour for me [22:14:36] Which AFAIK has been the colour change for a lont time [22:15:05] Yeah, the colors for `a` and `a:visited` on both those sites are the same as on Wiktionary [22:15:43] They're not for me [22:15:43] https://imgur.com/a/vyIONPd [22:15:54] It's not a lot of difference, but clicked/visited are darker [22:16:06] see shock stall and wings vs the rest [22:18:38] For me the color values are #0645ad and #0b0080 for unvisited and visited [22:19:52] I'm using the Vector skin; though I don't know if that has any relevance [22:23:46] It looks like your visited links are purpler than mine [22:24:48] Meh, I don't know