Re: [Wikitech-l] Fwd: Breaking changes in the Wikidata API
On Fri, Sep 28, 2012 at 8:53 AM, John Erling Blad jeb...@gmail.com wrote: The token handling through use of a special url-argument gettoken and the special itemtoken has died in flames. Use edittoken from actione=tokens (http://wikidata-test-repo.wikimedia.de/w/api.php?action=tokenstype=editformat=jsonfm) How does this change relate to the 'prop=infointoken=edit' method of getting edit tokens? - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Some tag for attribution within the article
On Fri, Apr 13, 2012 at 9:35 AM, Strainu strain...@gmail.com wrote: Actually, I find bug 27629 to be insufficient, since each author might ask for a specific way to be quoted (e.g. some disclaimer associated with the content). It is understandable why they might ask for such a disclaimer, but it isn't clear why we would agree to put it on the article, unless we also give every Wikipedia editor who edits the article the ability to add their own disclaimer. The point of free content is that content incorporated from other sources is not different than content written directly for our project. Each source of content should ideally be credited in a similar way, whether the source is another free-content project or a local editor. On English Wikipedia, we often credit external authors in the article itself (see [[:en:Category:Attribution templates]]). These do show up in a PDF created from the article. If there was a way to move these into metadata for the article, that would also work, but the idea of adding a disclaimer to the article itself seems to differ from usual practice which is just to list the source. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MathJax integration to stock MediaWiki Math extension? (was RFC: math options)
On Mon, Nov 28, 2011 at 7:42 PM, Brion Vibber br...@pobox.com wrote: I've done a quick experimental mode commit: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104521 This sounds great. MathJax is used on some other math-intensive sites, e.g. MathOverflow.net, and in general it does a very nice rendering job. When the Mediawiki support for MathJax gets to the right stage, it would be helpful to have it enabled on the labs wiki, so people can test it out. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikipedia lacks a share' button
On Fri, Oct 21, 2011 at 12:15 PM, Mark A. Hershberger mhershber...@wikimedia.org wrote: Posted this issue at http://hexm.de/8m. The above link is to : http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Does_Wikipedia_need_a_.E2.80.9Cshare.E2.80.9D_button.3F URL shorteners are evil in general, and especially so on archived mailing lists. * Shortened URLs make it difficult to search for link substrings in the list archives * Users cannot tell the true destination of the link without loading it * To load the link, users are forced to share their IP address with the server that does the URL expansion * A random server for the shortened URLs is not likely to be as reliable as Wikipedia in the long term. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: Should we drop the rendering preferences for math?
On Mon, Jul 18, 2011 at 8:38 PM, Brion Vibber br...@pobox.com wrote: It's conceivable that a few folks really honestly prefer to see the latex source in their graphical browsers (should at least do a quick stat check to see if anybody uses it on purpose), but I wouldn't mind removing that either. Some people are using this method to have MathJax render the math on Wikipedia pages, by installing the MathJax javascript in their user javascript. Disabling the text-only option would also break this. It would really be worthwhile for us to look into making MathJax available as an option for all users without forcing them to modify their user javascript. It's basically just a few javascript files and some static files on a webserver. They claim very broad browser compatibility ( http://www.mathjax.org/resources/browser-compatibility/ ) , and everything is released under the Apache license IIRC. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: Should we drop the rendering preferences for math?
On Tue, Jul 19, 2011 at 4:03 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Sounds like someone should propose MathJax as a gadget: http://en.wikipedia.org/wiki/Wikipedia:Gadget/proposals That solves some of the problems, but making it a gadget isn't technically very different from just putting it in user javascript. Not all the MathJax files are javascript: there are also web fonts and fallback image fonts. Ideally these would be served from Wikimedia servers. The system they are using right now loads them from off-site somewhere, and that would not be fixable by the gadget system. Users can also install the fonts locally but that is not a good solution for a widespread roll-out. The ideal implementation would be a system that detects whether the user has javascript enabled and a decent browser, and if so rolls them over to MathJax automatically. Users who fail that test or who intentionally opt out would receive images only. This would completely replace the current system (but re-use texvc to make the images). This system would not be hard to implement, but there is little incentive for anyone to spend time on it without some pre-commitment from the site admins to make it live. If we just want something that users can opt in to get, we already have that. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Rendering preferences for math - PDFs
A second issue that has been raised on the wiki is the poor quality of math in PDFs generated from articles. The math shows up as a low-quality bitmap which is very pixelated and noticeably different from the body text. I wanted to pass it along to the list. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] search=steven+tyler gets Steven_tyler
On Fri, May 13, 2011 at 12:25 AM, Jay Ashworth j...@baylink.com wrote: They're not the same page. Wikipedia page titles are case sensitive -- except that the first character is forced to upper case by the engine. Does that search not return both? Why would we have both? Like you said, the system is case sensitive. These redirects are created because the software doesn't handle case changes correctly otherwise. For example the following link leads to a no such page error because the appropriate redirect does not exist: http://en.wikipedia.org/wiki/Sterling_heights,_Michigan . It would be possible to code around this, so that the redirects would be simulated if they don't exist, but it hasn't happened. In practice, people like me like to type a title in all lower case, and so we have redirects to make it work. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MATH markup question
On Wed, Jan 19, 2011 at 8:54 AM, Alex Brollo alex.bro...@gmail.com wrote:
You can force png rendering both by preferences and by code. But what's
more interesting is the use of badly documented \scriptstyle TeX tag, which
generates a much smaller and less invasive display of pngs:
The use of scriptstyle to control font size is an ugly hack that makes
many formulas less readable. For example, math2^{A_C}\,/math and
math2^{A}C\,/math become much harder to distinguish in
scriptstyle.
In a custom installation, you can tweak the font size in images by
changing the value of the -D parameter in line 8 of render.ml and
recompiling texvc.
The ideal solution for Wikipedia would be to move to a system in which
users with relatively modern browsers don't see images at all. There
is already a candidate for that system: MathJax. This has extensive
browser compatibility [1] and is actively maintained, with some
big-name sponsors behind it [2]. The main difficulties enabling it on
WIkipedia would be configuration and checking for any inconsistencies
with texvc (so the main limitation is developer interest). On a
custom install without a huge base of existing text, you could
probably just use Extension:MathJax, although I haven't tried it.
- Carl
1: http://www.mathjax.org/resources/browser-compatibility/
2: http://www.mathjax.org/sponsors/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] StringFunctions on enwiki?
On Tue, Dec 28, 2010 at 4:22 PM, MZMcBride z...@mzmcbride.com wrote: https://bugzilla.wikimedia.org/show_bug.cgi?id=6455#c92 (and subsequent comments) Thanks, that's very helpful. What I was hoping for here was a response from one of the WMF staff about whether the position has changed on StringFunctions and (if not) whether templates like [[Template:str len]] are acceptable. Having a clear statement in place to link to would be ideal. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] StringFunctions on enwiki?
At some point in the past, it was determined that the StringFunctions extension (now part of the ParserFunctions extension) would be disabled on enwiki. I know saw a comment to the effect of: if StringFunctions was turned on, it would only encourage people to start writing parsers in wikicode. Maybe other people were already aware, but not me, that we have a set of hacked-up string functions on enwiki, for example [[Template:Str len]]. There's a whole category of them at [[Category:String manipulation templates]]. I'd like to know the current opinion of the server ops about these things. Is there any chance of StringFunctions being enabled? If not, should we feel free to work around it as these templates do? I'm writing to this list so it will be possible to link from enwiki to the mailing list archives, so responses on-list would be best. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Mon, Aug 2, 2010 at 10:16 AM, Lane, Ryan ryan.l...@ocean.navo.navy.mil wrote: Please Debian, keep your version of MediaWiki up to date at least to the oldest stable release, and please send your fixes upstream when you find unfixed bugs. I am not a Debian developer, and I agree that sending fixes upstream is good. But surely you're aware that the whole point of Debian stable is that it does ***not*** change to newer versions of programs after release, apart from security fixes? Debian is well known for taking the word stable seriously (e.g. [1]) and it's a reason people choose them. - Carl [1]: http://www.debian.org/doc/manuals/debian-faq/ch-getting.en.html#s-updatestable ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Mon, Aug 2, 2010 at 7:35 PM, Ryan Lane rlan...@gmail.com wrote: Are they also backporting security fixes for all extensions as well? I would assume that Debian, ideally, applies security patches for extensions they distribute themselves. Programs a user has installed outside the Debian system are always going to be the responsibility of the user. Of course, if Debian upgraded their stable version of Mediawiki to the newest version, and my production server was running a custom extension that only worked with the previous version of Mediawiki that Debian called stable, I'd be pissed. If Debian doesn't feel they should keep supported versions in their repos, maybe they shouldn't distribute MediaWiki. That is, seriously, an absurd attitude for a Mediawiki Developer to have. It reflects a fundamental misunderstanding of the meaning of Debian's stable version system. Note that Debian stood up to Mozilla corp. when Mozilla attempted to stop Debian uploading security patches to stable versions [1]. Surely Mediawiki would have much less persuasive power telling them to stop. I'm exiting of this discussion at this point. I've made the point I wanted to make, compelling or not, and I'm afraid I'm drifting off topic. - Carl [1]: http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reject button for Pending Changes
On Sun, Jun 27, 2010 at 11:11 PM, Rob Lanphier ro...@wikimedia.org wrote: I just don't think there's a clean way to reject an intermediate pending revision. Accepting? Sure, wonderful, that will work well. There's a reasonably strong argument for encouraging acceptance of intermediate revisions as part of the review process (so long as it always involves comparison to the latest accepted revision). But encouraging undo on intermediate revisions leaves things in a really weird place. And that's in the cases when the undo is even possible. If there are three unreviewed edits P1, P2, P3 in order, it may be impossible to undo P2 without simply reverting to P1, which loses the content of P3. That is a situation we do not want to encourage. I view all this as a strong reason not to have an reject button. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reject button for Pending Changes
On Mon, Jun 28, 2010 at 12:46 AM, Rob Lanphier ro...@wikimedia.org wrote: Unaccept seems suitably rare that I think we should consider a confirmation screen which shows the effect of unaccepting (i.e. a diff between the latest accepted revision and the penultimate accepted revision). Does that seem like a reasonable enough failsafe to keep this from being used unintentionally? This seems beneficial even in the case where the reviewer knew they were hitting unaccept. I had the impression that unaccept does not add a new revision to the page, it simply removes the db entry that the revision in question was accepted. Is that wrong? There are two reasons why that ''should'' be the behavior: (1) If I go back and unaccept a revision from two days in the past that was mistakenly accepted, I should not have to edit the page again to restore the previous content. (2) Accept does not add a revision to the page, and unaccept should only undo what accept does. That is, the sequences accept = unaccept and unaccept = accept should be able to be iterated as many times as desired, leaving everything in exactly the same state apart from log entries. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problem with the pending changes review screen.
On Tue, Jun 15, 2010 at 11:30 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Consider the following edit sequence: A, B, C, D, E A is a previously approved version. B, and D are all excellent edits. C and E are obvious vandalism. E even managed to undo all the good changes of B,D while adding the vandalism. The only way to handle this sort of thing is to actually look at the intermediate edits. I don't know if there is a nice way to simplify that workflow, but it points me towards the idea that reviewing should be done off the history page, not directly off a list of unreviewed pages. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] importing enwiki into local database
On Sun, Feb 14, 2010 at 7:34 PM, Marco Schuster ma...@harddisk.is-a-geek.org wrote: What about turning wgUseTidy off for some time? The doctype that we serve is XHTML, and various AJAX tools rely on being able to parse the DOM tree as an XML document. But there are certain valid wikitext constructions that are ''guaranteed'' to generate invalid XML without tidy, because of mediawiki bugs. For example, putting a list inside a table cell (bug 17486). So tidy seems to be a requirement for the time being. I hope that, before the doctype is changed to html5, a substantial grace period is given for people to change to an HTML5 parser in their javascript code. One high-profile use case here is the Twinkle script. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] CSS/javascript injection for AJAX requests
I noticed today that livepreview does not pick up the dynamically-generated CSS from the SyntaxHighlight_Geshi extension. The same problem occurs in liquidthreads: when you add a comment with a Geshi call in it, the CSS will not be picked up when the comment is initially saved. The first full reload of the page will pick up the css correctly neither case. After some investigation, this is really an issue in core and will apply to any extension that needs to add CSS and/or javascript to the output HTML. To fix the bugs with livepreview, we would need some mechanism where AJAX calls receive not only new HTML, but also new CSS and/or javascript, and can add that CSS and javascript to the current page without a reload. Adding the CSS and javascript dynamically may be tricky from a compatibility standpoint, but having library functions in our site javascript would help with that. I have not investigated the cause of the problem in liquidthreads. The code in EditPage.php shows scars from similar problems, in a commented-out call to send a list of categories back to an AJAX preview request. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
