Aug 8 2021
If Lua on MediaWiki can't be upgraded to 5.2 or later (T178146 is stalled, with "re-evaluation in 2024"), maybe just the GC changes could be backported to 5.1, to have at least some predictable GC behaviour?
Apr 11 2021
Thanks for investigating. I'm running a Spark job to parse some CBOR files (~ 100MB) to generate a list of missing words on Wiktionary. It really should not take so much memory but I noticed in the logs that Spark seems to aggressively request a lot of memory up front as some sort of buffer space/working memory. I'll see if I can tweak this. Update: solved.
Apr 10 2021
I'm running into more problems with Java on the grid: the JVM gets killed (exit code 137 = SIGKILL), but if I do a qacct -j jobid I don't see any enforced limits:
Mar 29 2021
The problem seems to be that the version of Lua used by Scribunto does not run the garbage collector when a memory allocation fails, so memory is not reclaimed when it is needed most. I would consider that a bug of the the implementation. With that behaviour it's hard to tell if we're really out of memory, or if we're just out of luck, because the GC didn't run in time.
Nov 23 2020
In this case it's obviously not Zotero's fault, even when setting a modern user agent in the header the server/CDN sometimes returns different content.
SQLite might not be your typical production setup, but it's very handy for getting a MediaWiki instance up and running in a docker container, I'm using it to process Wiktionary data. After switching to Parsoid the performance suffered quite noticeably, related to the aggressive write locking mentioned above.
Nov 9 2020
If there's no caching, perhaps the problem lies at the source: GETs on the source url also return different results:
Nov 8 2020
Nov 7 2020
I agree it's annoying that VE inserts empty parameters which have not been touched at all by the user. It's unnecessary baggage in the page text, and complicates the diff. Ideally VE should produce a diff similar to whatever the equivalent non-Visual ("human") edit would have produced: don't change whitespace, parameter order, or add any superfluous parameters.
Sep 17 2020
You're right, this is confusing – the order of the languages listed in the subtitle circled in your screenshot should match the order on the "Wikipedia languages" page to help make it more clear what the expected display language in the widget will be. I'll make a separate ticket for us to look into this.
@jberkel Thanks for testing them! Currently, the widgets display content in the "Primary" language you select in Settings > My languages in the app. Seeing all the languages you've added in the larger widget families is an interesting idea. But I think the ideal scenario for us is to utilize what Apple refers to as customizable intents in order to make each individual widget customizable to whatever language you'd like. These widgets seem like a fine candidate for customization, especially when considering the challenge of trying to mix both LTR and RTL language results into a single widget.
Sep 15 2020
Nice work on the widgets, been testing with iOS 14 beta. I have a question regarding multiple languages, in the preferences I can set several languages for the "Top read" widget, but in practice I only see items in one language (the first in the list). I'd expect to see a mix of entries for all languages, maybe the top read in each language.
Aug 28 2020
Looks like this is related/a duplicate: https://phabricator.wikimedia.org/T251664
I agree this is a good UX improvement to make. Perhaps the autocapitalize attribute of the input field could be based on the case sensitivity of the underlying Mediawiki installation? Most (if not all) Wiktionaries are configured as case sensitive.
May 18 2020
In my case the error message doesn't include a code, it just says "WMF.WikidataAPIResult.APIError error" (perhaps the view is clipped), and the error doesn't seem to get logged. Only with a debugger attached I was able to get more details ("permissiondenied").
The edit dialog is still accessible via long press on description, then "Edit" (1742)
May 12 2020
I've just noticed this as well, good to see that it's already been reported. When you make a change in that dialog, the Wikidata item gets updated, overwriting the previous value with the version from Wikipedia. This whole Wikidata/Wikipedia description duplication thing is a mess. Are local overrides only used in the English edition?
Mar 14 2020
I'm not sure if this is feasible without negative impact in performance.
Sep 21 2019
Jul 1 2019
thanks, with qacct -j jobid I get:
... failed 37 : qmaster enforced h_rt, h_cpu, or h_vmem limit maxvmem 16.558GB category -q task -l h_vmem=16777216k
Jun 29 2019
Sorry if this isn't directly related to the reported bug, but is there any way to find out why a process got sigkilled on the grid? I have a Java process getting terminated without traces of hserr*.log, and I suspect it is related to some native libraries allocating too much off-heap memory. I'd like to confirm that it's due to the OOM killer (or perhaps quota related?)
May 17 2019
Ok, but the Gadget's change to the body tag must still be kept, otherwise the display: none would be active again? So VE just replaces the content inside div#content I suppose?
thanks for the research and recommendation. I'm a bit unclear on what exactly happens when the VE is loaded. If there's is logic inside the gadget which hides quotes or other content, won't that get applied in VE as well?
Mar 9 2019
A year has passed, and this bug hasn't even been triaged. The memory problems on the English Wiktionary are still there, and ugly workarounds are needed to get some pages to render without errors.
Mar 6 2019
Feb 20 2019
Fix was deployed a long time ago; closing this now.
Jan 20 2019
I pinged some editors who work with hieroglyphs on the English Wiktionary and got a reply from @Vorziblix:
Jan 19 2019
Oct 1 2018
I am very curious about this statement. How do you think you can convinced 100+ communities to change the way data are structured?
Sep 29 2018
Sep 5 2018
what's missing? frwikt support?
Sep 2 2018
Aug 31 2018
Bot approval vote passes 11-0-0.
Aug 23 2018
Then, do a test run (under the bot account) on some 10-50 entries until you’re certain everything goes well (bots with a single function, like interwiki, should not run more than 25 edits). If the edits are minor (as most bot-performed tasks should be), please mark the edits as minor so that they do not swamp the Recent Changes list. If all goes well, post a request for bot status at the votes page.
Jul 11 2018
Sorry for the confusion, yes this is correct (I have not been through the process).
Jul 10 2018
Jun 7 2018
@Cyberpower678 do you only need translations for frwikt? Is anything else needed from enwikt?
May 15 2018
@Lea_Lacroix_WMDE my main planned use case right now is T190210. Maybe it could also be used to automate the "See also" section at the top of the page (currently maintained manually with Template:also + bot).
Apr 13 2018
Looks like the storage part of RESTBase isn't conceptually a cache which can be "thrown away" (that was my assumption). Maybe this has to do with a requirement to serve older revisions for other endpoints (not applicable for definitions)?
I think I still don't understand some parts of the service architecture. Why do all 5+ million entries have to be cached in one go? If the cache gets purged, won't it automatically/lazily repopulate the most requested ones? Some entries will probably never/rarely get requested, why should they get pre-cached?
Also, if I make a normal change to a Wiktionary page, shouldn't that invalidate the cache and return the new schema? What are the typical delays for the change propagation?
Is there no way to just invalidate the entire cache? seems quite complicated to make changes to the API.
why not clear the whole cache on schema change?
yes, maybe T131092, that shouldn't take too long. it would also be good to get a sense of what else is needed from a client's perspective.
Apr 12 2018
reopened this task since the API still returns duplicates
Apr 9 2018
@bearND ok, thanks. if the new code is deployed, where would the old responses come from? or is the header change required for the cache invalidation? is the cache invalidated on source page change (e.g. /wiki/fazer) ? what about changes in dependent templates?
Maybe a duplicate of T131092?
Apr 8 2018
@bearND Looks like the change hasn't been deployed yet? Still getting duplicate sentences
Apr 3 2018
Apr 1 2018
I've been a few times now in this situation where unwanted changes were recovered.
Mar 30 2018
I had a look through the codebase to see how hard it would be to restore iOS9 compatibility. Sadly, iOS 10+ calls are a bit all over the shop.
Mar 27 2018
It always displays "Discard my changes and switch", even without changes. Which means that you need two clicks to switch to visual editor.
Mar 26 2018
Mar 20 2018
Mar 18 2018
Ok, thanks. For reference, T55784 seems to be the ticket to follow.
@Halfak ah ok, that makes sense. how many edits need to be labeled? how sensitive is the whole approach to template/code level changes?
Mar 16 2018
@Halfak ok, so it's separate from a user's normal patrolling activity, meaning you work on an older sample instead of labeling recent changes? I think the participation rate could be a lot higher if it is integrated into the "normal" patrolling activity (opt-in, of course).
Mar 14 2018
@bearND I can handle Gerrit, just remembered that I made some contributions to the Wikipedia iOS app using GH a while back, it's just so much easier.
I have a first patch ready for review. Can I submit PRs via Github or do I have to go through gerrit 😱?
Mar 8 2018
Feb 28 2018
Feb 23 2018
@ArielGlenn so these would include the output from RestBase, with parsoid-annotated DOM? That would be very helpful for all sorts of processing tasks.
Feb 20 2018
@bearND I think it would be preferable to extract the definition from the glossary and not the linked Wiktionary definition page (which might contain some other unrelated content). But I also understand that you don't want to add extra parsing code, so it might be a good first compromise. Maybe there's something simple we could do on Wiktionary to make things easier?
Feb 15 2018
Jan 9 2018
@Mholloway an approximation for the primary definition could be the first gloss/sense of an entry, skipping all obsolete/archaic senses which are sometimes listed first (presumably to illustrate the semantic development). in case of several part of speech headers this is trickier, since there's often no clear ordering
Dec 18 2017
@Noe There are a lot of dictionaries in Wikisource, but most of them are "scan-only". By "tagging", you mean creating an index to entries, so you can quickly navigate to the scanned page?
Dec 16 2017
@Noe excellent, one stone, two birds (une pierre deux coups?)
Dec 15 2017
Dec 8 2017
there's consensus to use IABot: https://en.wiktionary.org/wiki/Wiktionary:Beer_parlour#Inviting_IABot
Dec 3 2017
Dec 2 2017
Nov 21 2017
I really don’t see how having enough technical debt already justifies adding it. There is literally no ability to turn off a skin from a Wikimedia project, so local technicians end up supporting Modern for those three people using it and now will be expected to support Timeless for those five people that would experiment with it.
Nov 7 2017
enwikt's multistream is still missing, or just late?
Would just like to add that it's not just dying connections, but all sorts of backend errors (timeouts etc). Anyway, I've been hitting this bug more frequently recently.