--withdrawing--
User Details
- User Since
- Oct 6 2014, 11:25 PM (520 w, 5 d)
- Availability
- Available
- LDAP User
- AuFCL
- MediaWiki User
- AuFCL [ Global Accounts ]
Dec 26 2018
Apr 16 2017
Nov 21 2016
Oct 31 2016
@Ineuw: For my money this glitch is entirely related to browser-end caching and not at all related to Gadget or Purge alternatives. (I have no idea why one of my machines occasionally requests the Serbian version of Dynimg.css; a different machine never once seems to.) May I recommend a more conservative encoding within https://en.wikisource.org/wiki/MediaWiki:Common.css, re-expressing:
Oct 29 2016
Some background if I may:
Oct 14 2016
Thanks echoed. (Now please take care in case T146160 repeats this saga.)
Sep 29 2016
@Samwilson: technically Yes, as Change 311769 was incorporated into both 1.28.0-wmf.18 and 1.28.0-wmf.20 via (still open) T145724. Clearly this process has occurred in reality.
@Samwilson: If you are getting concerned over things like this then compare with this which occurred long before your changes.
Sep 17 2016
@Alex_brollo Presumably you are aware that the default height is set (for both horizontal and vertical layouts) in Preference setting [[Special:Preferences#mw-input-wprows]]? Are you suggesting there ought to be two independent configuration values?
Aug 5 2016
Aug 4 2016
Thanks @Tpt for making this change apparently painless (now please tell me if you had to fix up too many of my mistakes!) Seems to be working correctly—as far as I can tell—on each of test2wiki, enws and frws.
Jul 31 2016
@Tpt : Thanks for the review. Regarding your comment:
Jul 30 2016
Jul 29 2016
There is a similar issue raised on the English Wikisource (see: What is this tooltip trying to say? on Scriptorium.)
Jul 7 2016
Tentative assignments to each of MediaWiki-extensions-Poem and Mobile-Content-Service. Please review and correct as appropriate.
Jun 25 2016
May 29 2016
To cut right to the chase, ShakespeareFan00 wants to do things with ProofreadPage's <pages> tag (e.g. embedding header-less and/or footer-less table content) which are incompatible with the hard-coded <div> wrappage of embedded content enforced here: (near end of PagesTagParser.render), and wants to open up a discussion on the possibilities of relaxing this requirement.
May 10 2016
Please do not worry about this. It was a (perhaps misguided) attempt to point out how including or excluding empty elements—here [] rather than {}—ideally should not affect the resultant rendering. Pardon adding to the confusion.
May 8 2016
@Physikerwelt I do quite agree on the syntax detail. Unfortunately the prior behaviour (accepting optional closure in {} even though not demanded after a \displaystyle, \scriptstyle, or \textstyle directive) happened to be gracefully handled by the prior codebase, which sets a certain expectation that future developments not change this behaviour.
May 7 2016
Thanks for opening T134652—in hindsight that is what I should have done.
@Physikerwelt:
I am guessing here but there likely are only a few legacy usages of \…{}—and those probably result from poor template or editing choices and will be picked up and addressed soon enough on a needs basis.
May 6 2016
Apr 22 2016
I hope that nobody reading this is so naïve as to expect each 'entry pane' to contain balanced HTML. Assemblages (such as Page:-as-a-whole; or results of <pages/> transclusion ) yes; but normal practice in the wikisources is that individual templates, modules or page sections frequently contain unbalanced HTML which is only resolved at a higher level structure. See for instance hanging indent inherit template usage on enWS alone (around 3600 uses).
Apr 21 2016
This may just be a "lookalike" case but posting in case it may be of use:
Apr 12 2016
@sirens_of_mimas: This would appear to be a manifestation of T122400; I applied the local "temporary fix" described there there and it worked (for an equivalent case for me at least.)
@Billinghurst O.K. Pardon my confusion but how, then is this proposal not a re-statement of (nominally already resolved T129077)? Unless I misunderstand this boils down to whether the wiki "controlling" notifications is the individual user's Home wiki, or (always) Meta?
Isn't this just a special case/suggested implementation of T130655?
Mar 23 2016
"Traditionally" (by which I mean at least for the last couple of years) \mbox{} has not accepted most Unicode content and instead thrown the errors originally detailed.
Mar 15 2016
Mar 14 2016
Thanks @Mattflaschen. All good to know and makes sense now the topic is "hot."
Mar 13 2016
Although in hindsight this error message now makes more sense than initially may I urge that the error text be modified to more suggest that the root cause is the user's browser rather than somewhere between host servers? Even stating that javascript execution is being blocked (if detecting such is even possible—is this a "catch-all" situation?) might considerably help diagnose similar circumstances next time they arise.
Mar 10 2016
Mar 4 2016
Jan 20 2016
Thanks Andre for the good advice. I removed the comment as subsequent discussion with @GOIII pointed up the fact that technically "solving" this involves a political/expectation aspect I had not considered.
Jan 19 2016
Prior comment removed. Good intentions but further discussion reveals proposed patch answers wrong question.
Nov 12 2015
Aug 17 2015
Aug 16 2015
With regards the comment above at no point to the best of my knowledge was the old ("legacy"?) toolbar affected.
Aug 9 2015
Apr 21 2015
@Hrishikes, @Nasirkhan: What follows is my best attempt for mashing everything together in what (I hope) is the correct format. I have no way of even validating whether the result is legal JSON so please clean up any errors you spot! prototype specialcharacters.json
Jan 14 2015
No fault apparent using Firefox 34.0 (& 35.0 - browser auto-updated during trial; unexpected two-for-one result) under GNU/Linux; both logged-out and in.