[Wikitech-l] Thoughts for handy features
Hey there. I love MediaWiki and have been using it everywhere for years. Recently I've been doing some rather major documentation and I realised there were three features which would be really handy for me (if these or similar already exist I would love to know!): 1. For links to articles in sections on the same page it would be really handy if we had syntax like: [[#unity|]] which would auto-complete to [[#unity|unity]] for you. 2. For duplicated content it would be handy if you could define a bunch of "variables" down the bottom of a page and then reference them from elsewhere. I am aware of templates, but those are overkill and difficult to maintain per my use case (my use case is documenting the "purpose" of a computer, I duplicate this in various places, but don't want to maintain templates for that). 3. It would be cool if for any given wiki page an "estimated reading time" could be provided. Along with maybe a word count, character count, etc. Since I'm here, quick thanks to the MediaWiki community for creating such wonderful wiki software! Regards, John Elliot V -- E: j...@jj5.net P: +61 4 3505 7839 W: https://www.jj5.net/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
I don't know who Brandon is. I'm planning on bundling MediaWiki with a product of mine and I'd like it to work well with smart phones and other mobile devices. I'm not sure that I would have the time or expertise to get the Athena theme done by myself and just wanted to know if it was on the agenda. Look forward to seeing it when it ships. On 2012-07-28 08:36, Terry Chay wrote: Are you a Brandon plant trying to get us to resource Athena again? :-) On Jul 27, 2012, at 3:01 AM, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Responsive web design
Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
On 2012-07-27 23:52, Jon Robson wrote: The Wikipedia mobile site is being made mobile first using responsive design techniques. The plan is for it to eventually mature into a responsive Athena skin that can also be used on desktop. Any idea about when the responsive Athena skin might be ready? 1 month, 3 months, a year? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] We need to make it easy to fork and leave
On 12/08/2011 8:55 PM, David Gerard wrote: THESIS: Our inadvertent monopoly is *bad*. We need to make it easy to fork the projects, so as to preserve them. I have an idea that might be practical and go some way toward solving your problem. Wikipedia is an impressive undertaking, and as you mentioned on your blog it has become part of the background as a venerable institution, however it is still dwarfed by the institution that is the World Wide Web (which, by the way, runs on web-standards like HTML5 :). To give a little context concerning the start of the art, a bit over a week ago I decided to start a club. Within a matter of days I had a fully functioning web-site for my club, with two CRM systems (a wiki and a blog), and a number of other administrative facilities, all due to the power and availability of open-source software. As time goes by there are only going to be more, not less, people like me. People who have the capacity to run their own content management systems out of their own garages (mine's actually in a slicehost.net datacenter, but it *used* to be in my garage, and by rights it could be, except that I don't actually *have* a garage any more, but that's another story). The thing about me, is that there can be hundreds of thousands of people like me, and when you add up all our contributions, you have a formidable force. I can't host Wikipedia, but there could be facilities in place for me to be able to easily mirror the parts of it that are relevant to me. For instance, on my Network administration page, I have a number of links to other sites, several of which are links to Wikipedia: http://www.progclub.org/wiki/Network_administration#Links Links such as: http://en.wikipedia.org/wiki/Subversion Now by rights there could be a registry in my MediaWiki installation that recorded en.wikipedia.org as being another wiki with a particular content distribution policy, such as a policy permitting local mirroring. MediaWiki, when it noticed that I had linked to such a facility, could replace the link, changing it to a link on my local system, e.g. http://www.progclub.org/wiki/Wikepedia:Subversion There could then be a facility in place to periodically update the mirrored copies in my own system. Attribution for these copies would be given to a 'system user', such as the 'Interwiki Update Service'. The edit history for the version on my system would only show versions for each time the update service had updated the content. Links for the 'edit' button could be wired up so that when someone tried to edit, http://www.progclub.org/wiki/Wikipedia:Subversion on my server, they were redirected to the Wikipedia edit facility, assuming that such a facility was still available. In the case that Wikipedia was no more, it would be possible to turn off mirroring, and in that case the 'edit' facility would allow for edits of the local content. That's probably a far more practical approach to take than say, something like distributing the entire English database via BitTorrent. By all means do that too, but I'd suggest that if you're looking for an anarchically-scalable distributed hypermedia solution, you won't have to look much past the web. John. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] We need to make it easy to fork and leave
On 12/08/2011 10:31 PM, David Gerard wrote: This one's tricky, because that's not free content, for good reason. It would need to be present for correct attribution at the least. I don't see anything intrinsically hard about that - have I missed anything about it that makes it hard? Well you'd need to have namespaces for username's, and that's about it. Or you could pursue something like OpenID as you mentioned. Of course if you used the user database as is and pursued my proposed model for content mirroring, you could have an 'Attribution' tab for mirrored content up near the 'Page' and 'Discussion' tabs, and in that page show a list of everyone who had contributed to the content. You could update this list from time-to-time, at the same time as you did your mirroring. You could go as far as mentioning the number of edits particular users had made. It wouldn't be the same type of blow by blow attribution that you get where you can see a log of specifically what contributions particular users had made, but it would be a suitable attribution nonetheless, similar to the attribution at: http://en.wikipedia.org/wiki/Special:Version ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] We need to make it easy to fork and leave
On 12/08/2011 10:44 PM, John Elliot wrote: It wouldn't be the same type of blow by blow attribution that you get where you can see a log of specifically what contributions particular users had made Although I guess it would be possible to go all out and support that too. You could leave the local user database as-is, and introduce a remote user database that included a namespace, such as en.wikipedia.org, for usernames. For mirrored content you'd reference the remote user database, and for local content reference the local user database. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] W3C validation links, and extended edit links
Hi there. I've made some modifications to MediaWiki 1.17.0 that others might be interested in. I'd be flattered if some or all of them made it into the official MediaWiki release. Firstly, I've added links to the W3C HTML validation service hosted by MIT. These show up as 'W3C HTML 5.0' icons next to the 'Powered by MediaWiki' icon at the bottom of the page, and link the user to the HTML validation service. I've found having this feature invaluable in helping me to get my wiki text that includes HTML valid. Unfortunately I've had to disable some features of MediaWiki in order for the validation service to pass the generated HTML. You can read about how I modified MediaWiki for W3C HTML validation at: http://www.progclub.org/wiki/Pcwiki#W3C_validation_icon Secondly, and more importantly I feel, I've added extended links to the 'section edit' links section. In addition to showing an 'edit' link, I include a 'link' link, and a 'top' link. 'top' just links to #top, nothing remarkable there. 'link' provides a link to the canonical URL for that section. My web-site is available via several domain names, www.progclub.org, progclub.org, progclub.info, etc. I have nominated 'www.progclub.org' as the 'canonical' domain name to be used when publishing links, and nominated 'http' (rather than 'https') as the 'canonical' scheme. In order to support canonical section links I had to make a few changes to the settings files, and update the linker, etc., as explained at: http://www.progclub.org/wiki/Pcwiki#Extended_edit_links Anyway, that's it. Thought some of you might like to know. If you like the ideas but don't like the implementation, then please feel free to BYO implementation. Mine's a little bit less than perfect owing to no i18n support and me not knowing the best file to put my functions in. So, I'd be happy if someone else gave my code a spruce up. Thanks! John. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 6:43 AM, Platonides wrote: Theoretically, the wiki should never generate invalid HTML, but it's not perfect. It was pretty close to perfect. I only had to comment out two features to get conformance with the (experimental) HTML5 validator. I assumed HTML5 output in my code, although AIUI MediaWiki also supports other varieties of HTML. You could have also just used the hook. Ah, but I don't know how to use the hook (yet), do I? :P I'll figure it out and fix up my code. Thanks for sharing! No worries. I did a fast review of it below: You have an html injection problem in the extended links. OK, I'll look into that. What I don't understand is why you worked so hard to make the extended link use the canonical domain. A relative link would have worked fine. Yeah, I have relative links if the canonical domain features aren't specified. (I added that as an after-thought, and you might have reviewed my code before I'd posted the update.) Also, all the $wgCanonical* pieces could have been replaced with setting $wgServer to the chosen domain and a few calls to getFullUrl. (if $wgCanonicalSecureHost != $wgCanonicalHost, $wgServer can be set conditionally) Ah, I didn't know about $wgServer. Finally, if you wanted to mark one of them as canonical, IMHO you should have added alink rel=canonical (but be careful with redirects, when MediaWiki adds one itself). I don't know anything about link rel=canonical, nor do I really know how/where to go about adding it. Maybe I'll look into that. Thanks. John. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 6:53 AM, Daniel Friesen wrote: Please don't edit DefaultSettings.php; Your $wgFooterIcons change could have been done in LocalSettings.php without causing trouble for yourself when you upgrade. Ah, didn't realise LocalSettings.php was the right place to do my edits. I guess I was coming from the perspective that I was contributing to core. We have a DoEditSectionLink hook, adding those links should be possible without any modifications to core. Yep, got that now. I'll fix that up. Thanks. Though I don't really see anything we could add to MediaWiki. Most can already be done with hooks and config and fit more as extensions than default core features. Fair enough. And removing functionality of MediaWiki doesn't really count as adding something to core. I kinda felt like I was adding more than I was taking away. I can't comprehend the obsession with killing de-facto standardized patterns just to shove a button on a site to a picky validator that only takes into account a single relevant standard. I'd rather not confuse my users who are trying to validate the HTML in their wiki text with noise from the platform. I don't control the validator, but I think it's a useful tool to incorporate on my web-site. Maybe there should be a setting for 'strict html' which leaves out features that services like validator.w3.org don't accept. John. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 6:50 AM, Roan Kattouw wrote: On Tue, Aug 9, 2011 at 10:43 PM, Platonidesplatoni...@gmail.com wrote: ResourceLoaderDynamicStyles was purposefully added even though it is not conforming. AFAIKmeta tags with made-up name= attributes are perfectly legal, at least in HTML5. There's a list: http://wiki.whatwg.org/wiki/MetaExtensions There's a bug filed in the validator.w3.org bug-tracker about the fact that some items that are on the list aren't being accepted: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12928 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 6:53 AM, Daniel Friesen wrote: I can't comprehend the obsession with killing de-facto standardized patterns just to shove a button on a site to a picky validator that only takes into account a single relevant standard. One reason would be to help avoid embarrassments like this: http://validator.w3.org/check?uri=http://en.wikipedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 8:47 AM, Chad wrote: I guess that's only embarrassing if those sorts of things bother you. I think it would be fair to have it both ways. There are a class of people who are bothered by things of that sort. I'm sure I'm not alone, at least on this issue. :P I'm with Dan on this one, I've never thought those validator buttons are very nice additions to a website. Remind me a little too much of the Optimized for NN4 buttons of old. I think there's a pretty big difference between providing a feature whereby a user can validate the HTML they've just authored and proclaiming browser patronage. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 8:55 AM, Chad wrote: Most of our users won't know or care whether their pages validate. Those that do presumably know how to use a validator already. Isn't an unstated goal of MediaWiki/Wikipedia to decrease ignorance? If you already know how to use a validator you might still be pleased to have it easily integrated for you. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 9:08 AM, Daniel Friesen wrote: On 11-08-09 03:37 PM, John Elliot wrote: http://validator.w3.org/check?uri=http://en.wikipedia.org Embarrassing? You do realize that the validator is complaining that it sees `ul/ul`, right? I hadn't realised that. I can't even find the spot in the HTML4 or XHTML1 spec where it says that a perfectly fine marked up list is invalid if it doesn't contain any items. Well you could save yourself some trouble and let validator.w3.org guide you in that matter. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 9:13 AM, Platonides wrote: John Elliot wrote: Ah, but I don't know how to use the hook (yet), do I? :P I'll figure it out and fix up my code. See docs/hooks.txt from your mediawiki folder. Will do. Thanks! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 9:49 AM, Daniel Friesen wrote: WikiText is loose so instead of errors, if the parser doesn't like something you inputted it's not going to pass that through raw and let a html validator say it's wrong, it's going to decide it doesn't like it and treat it as plaintext. Well, the validation feature that I added to my web-site helped me catch a bug for you. If you are outputting WikiText that includes the HTML-like h1, h2, etc., tags, then make sure you're not outputting them in the context of table content, because that is invalid. In order to turn such WikiText into compliant HTML, the h1 WikiText should be converted to a span class=h1 HTML element, and so forth. The various skins should be updated to do something sensible with the h* classes. I'll let you know if my HTML validator helps me to easily catch any other bugs like this for you. We've already established that MediaWiki is broken because it's outputting empty ul elements, so maybe you can have a look at fixing that up too. Thanks. John. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 10:16 AM, Daniel Friesen wrote:
On 11-08-09 04:14 PM, John Elliot wrote:
On 10/08/2011 9:08 AM, Daniel Friesen wrote:
I can't even find the spot in the HTML4 or XHTML1 spec where it says
that a perfectly fine marked up list is invalid if it doesn't contain
any items.
Well you could save yourself some trouble and let validator.w3.org guide
you in that matter.
Guide?
You mean link to that information so I have the actual words of the spec
that browsers are supposed to implement? It doesn't give any link.
Why are you telling me?
http://validator.w3.org/feedback.html
You mean take the validator's interpretation as the absolute an
unequivocal authority that it's wrong without seeing the information in
the actual spec saying it's wrong? Like hell... If I accepted a
validator's narrow (potentially incorrectly implemented) interpretation
of something I wouldn't be using CSS vendor prefixes like
-moz-border-radius since last time I checked the css validator says
they're wrong, even though vendor prefixes are a valid part of the spec.
If you'd seen Pirates of the Caribbean, you'd understand that there's a
difference between rules and guidelines.
Of course some of us take the guidelines rather seriously.
That's actually a pretty good direction to take explaining the fallacy
of validators and badges for them.
Our css includes output like:
.foo { background-image: url(data:...); background-image: url(...) !ie;}
Strict interpretation wise, that's invalid css because !ie is not valid
inside the background-image. Are we going to remove that? Hell no, if we
did versions of IE people are still using would stop displaying
background images because they can't handle data uris.
Again, I think it's reasonable to engineer a system where policy
decisions such as this are at the option of the user.
I'm a user of MediaWiki, and I care more about strict compliance with
open-standards than I do about supporting antiquated browsers, so I
should be able to take the decision to not support that.
Likewise with HTML what matters is NOT that a strict validator says it's
ok, but that it's well-formed so that all browsers have the same
interpretation of it, and conforms to understandable patterns either
de-facto or detailed in external specs (like the RSD spec, Universal
Edit Button, etc...).
Again, there will be a class of MediaWiki users who have a different
opinion.
eg: EditURI is part of RSD [Really Simple Discovery], it's a standard
way of letting software discover the api endpoint(s) for a page. In the
future not having that could mean that a tool one of your users may use
could break because it can't find the api.
There is a process for this defacto standard to be integrated with
web-standards, and by not supporting it until it has gone through that
process you provide incentives for its proponents to ensure they do
things in an amiable and collaborative fashion.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 11:19 AM, Daniel Friesen wrote: Would you like to argue for a $wgStricterParsing bool that will sacrifice parser output consistency for things like folding == headers into parent th's (perhaps turn into a span if they explicitly use ah# instead of ==), and other things we haven't been able to do to the parser for compat reasons? Sure. I'll argue for that. :) That was a HTML4/XHTML1 rule that's been removed. An emptyul/ul is valid HTML5. I wasn't sure if the empty ul was valid HTML5, or if the validator wasn't strict enough about it yet. In any event, I'm happy to take your word for it. If XHTML support is being deprecated, I won't argue for fixing the empty ul elements. As I mentioned, the only two features that were a concern for me in providing valid HTML(5) were the two meta elements, and it's been suggested that each of these can be removed. I still think that having 'link' and 'top' anchors on section headings next to edit links would be a good thing to have on by default in core. There is provision for disabling them, and having them available by default is a sensible and productive course of action in my opinion. It's handy to be able to right-click on the 'link' anchor and copy the canonical URL of the section you're looking at, and it's handy to be able to jump back to the top of the page (indeed, I discovered that the #top functionality was already half implemented, so presumably there is a plan for something like this). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] W3C validation links, and extended edit links
On 10/08/2011 12:19 PM, Daniel Friesen wrote: Oh right, one the 'other' things I had one mind but couldn't remember while writing was converting things like valign, width/height, etc... into css styles. That'd be nice. Though given the fact that block content in a th in XHTML was valid and is essentially a regression in the unfinished html5 and there is an open bug report on it I'll opt for the stance that folding headers there should wait till we see what the decision on that is. I'm happy with that. As I tried to point out in my first post, the whole HTML validation icon was just a bit of fun (it pleased at least one person [1] :P), and the feature I actually care about is the extended section edit links. [1] http://www.progclub.org/wiki/User_talk:Sclaughl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
