Oct 1 2020
Sep 30 2020
Note on my change to the title: mw.title.new("#") returns an object, but accessing any of the expensive fields causes an error to be thrown in mw.title.lua. When I type the following lines one-by-one into the console, the field accesses on the title object all throw the same error:
Sep 25 2020
Aug 2 2020
Jun 17 2020
Jun 16 2020
May 5 2020
The problem has disappeared for me (the search and replace dialog shows up again), maybe at the same time that diffs became monospace again.
Apr 30 2020
I am not able to bring up the search and replace dialog in CodeEditor in the English Wiktionary modules that I'm currently editing, either by pressing Ctrl+F or by clicking the icon in the toolbar. This is very troublesome and annoying because I normally constantly use the search and replace dialog to jump to the right place in the code.
Apr 29 2020
Apr 28 2020
I don't know why the task was marked as Done, but the bug remains for me at least.
Apr 6 2020
Also encountered on English Wiktionary at Module:kum-decl:
Mar 28 2020
@Aklapper: I've corrected and updated the description and the title because the error is probably a general MediaWiki thing: it occurs in English Wiktionary and Wikipedia.
Feb 4 2020
I've been getting sporadic errors like [XjoBKQpAAD8AAIE3bO4AAAAN] 2020-02-04 23:41:29: Fatal exception of type "TypeError" after being redirected from a Special:MyLanguage subpage linked from Template:Databases on MediaWiki wiki. For instance, I clicked a link to Special:MyLanguage/Manual:Langlinks_table from the template, was redirected to Manual:Langlinks_table, and saw the error there. Reloading usually gets the page to display.
Jan 3 2020
Okay, so an additional request must be sent to actually construct the Category objects.
Jan 2 2020
My script seems no faster with the patch, even with categories = True in the call to APISite.preloadpages. Commented on the part of api.py where separate requests are being sent for each page's categories.
Jan 1 2020
Dec 22 2019
@zhuyifei1999 Yes. Thank you so much!
Dec 21 2019
Just to confirm, this request for fish to be installed to the grid exec nodes right?
Dec 11 2019
@bd808: Thanks for your help! If only I'd asked sooner, this spring when the problem arose. :-)
Nov 7 2019
It seems the reason is that the search engine doesn't search every page. Probably it times out at a certain point when searching through mainspace pages, and if no the Anatolian hieroglyphs are found by that point, no results are shown.
Nov 4 2019
Oct 28 2019
Oct 27 2019
Oct 8 2019
Oct 7 2019
I renamed the task because for me, and presumably for others, the link doesn't jump to the top of the source code either. Perhaps something in my settings prevents the link from going to the top of the source code.
Oct 5 2019
Sep 2 2019
@Aklapper: The original poster linked to Modèle:MdTests/documentation on French Wikisource, where Module:MdTests is invoked, generating a module error: "Erreur Lua dans Module:MdTests à la ligne 15 : attempt to index global 'frame' (a nil value)." A minimal version of Module:MdTests that would generate the error:
Aug 16 2019
LPeg would be great because it could make many string-related tasks easier, though it has a steep learning curve and I am not sure if it would use more or less memory and processing time than the less sophisticated methods that we use now. It might not be possible to cache LPeg patterns, because they can contain references to arbitrary Lua values, including functions (which are prohibited in modules loaded with mw.loadData because they can cause T67258: Information can be passed between #invoke's (tracking)), in which case patterns would have to be newly generated for each module invocation.
Aug 15 2019
However, we are in the process of upgrading to PHP7, which uses a newer version of Unicode that may include case mappings for the characters you're concerned about.
Jul 27 2019
The two bug locations that I've reported here are 1. in Scribunto (the functions mw.ustring.upper and mw.ustring.lower) and 2. in whatever generates the headers in category pages. At least the Scribunto bug involves PHP because mw.ustring.upper and mw.ustring.lower seem to be implemented using the PHP functions mb_strtoupper and mb_strtolower, and categories probably involve PHP as well. If the title and tags need edits, I would appreciate some help as I don't have much energy right now and it is possible I am not doing Phabricator right.
Jul 25 2019
Jun 28 2019
May 9 2019
I am seeing what might be the same error on the English Wiktionary. The diff for what is currently the latest revision of MediaWiki:Common.css shows the error [XNPAewpAAEMAADungXAAAAAS] 2019-05-09 05:54:03: Fatal exception of type "Wikimedia\Assert\ParameterTypeException". I'm the author of both revisions and my username is not invalid, so this seems not to be an example of T200055.
Apr 15 2019
Yes, plugging pure-Lua ustring into my example does work:
Apr 12 2019
Jan 5 2019
On English Wiktionary, this extension could be used to transclude a template at the top of pages in the Reconstruction namespace. At the moment, we have to manually add the template to every page. See for instance Reconstruction:Proto-Indo-European/dn̥ǵʰwéh₂s.
Oct 22 2018
Oct 3 2018
This feature would be useful, but using language codes would be complex.
Jul 1 2018
May 3 2018
Update regarding topic category structure, as it is no longer true, as the original post states, that Category:Fruits contains English words related to fruit. The category structure has changed so that Category:Topicname is an umbrella category that only contains categories: language-specific categories prefixed by a language code (Category:languagecode:Topicname) as well as other umbrella categories (Category:Subtopicname). Here, replace "Topicname", "topicname", and "Subtopicname" with things like "Fruits", "fruits" and "Apple cultivars". To use the example in the original post, now Category:Fruits only contains categories such as Category:en:Fruits, Category:fr:Fruits, Category:Apple cultivars, Category:Banana cultivars. English words related to fruit are now found in Category:en:Fruits.