Re: [Wikitech-l] I hate to be that guy
This is linked from their but just to make it easier to find http://en.wikipedia.org/wiki/Jenkins_(software). Jenkins is actually very cool and also helps run (and keep track of) the consumers for our donation service for example. James On Wed, Jun 27, 2012 at 2:16 PM, Chris McMahon cmcma...@wikimedia.orgwrote: On Wed, Jun 27, 2012 at 2:06 PM, Derric Atzrott datzr...@alizeepathology.com wrote: So I hate to be that guy who doesn't know the simple things, but what is Jenkins? The server has come up in discussion a few times since I joined this mailing list about a month ago. And since no one has mentioned it yet, you might want to read http://en.wikipedia.org/wiki/Continuous_integration. Jenkins is an open source system for doing CI. It used to be called Hudson. (Those are both names of butlers, which has always been the mascot of the project.) Over time, Jenkins has become a very powerful hub for automated testing and deployment, and most serious software projects integrate with Jenkins via plugins. (Although some of those projects don't do it very well, Fitnesse for example.) -C ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- James Alexander Manager, Merchandise Wikimedia Foundation (415) 839-6885 x6716 @jamesofur ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I hate to be that guy
Le 27/06/12 22:06, Derric Atzrott a écrit : So I hate to be that guy who doesn't know the simple things, but what is Jenkins? The server has come up in discussion a few times since I joined this mailing list about a month ago. Actually if there is a Wiki page where these sorts of things are documented. that would be fantastic. There was not wiki page until someone asked for one :-] I have wrote a very quick description on: https://www.mediawiki.org/wiki/Continuous_integration/Jenkins Basically, Jenkins is a tool to automatically run tasks and report its status. The typical example is to build packages or execute a test suite. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sorry if inconvenient : SVG-to-png rendering on Wikimedia
I just wonder: Why do we not simply transmit the SVG image, but render a png for an SVG-file to the browser? Historic reasons? I think it is because there is no good way for us to know if a browser supports SVG images other than having a list of user-agents that do and checking that way. We don't want to send an SVG image to a browser that is unable to render it. Someone correct me if that was wrong. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sorry if inconvenient : SVG-to-png rendering on Wikimedia
I just wonder: Why do we not simply transmit the SVG image, but render a png for an SVG-file to the browser? Historic reasons? I think it is because there is no good way for us to know if a browser supports SVG images other than having a list of user-agents that do and checking that way. We don't want to send an SVG image to a browser that is unable to render it. Someone correct me if that was wrong. I c. So historic reasons. Do we keep a list of user-agents able of supporting png images? ;-) Thank you, I have to thank, Achim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sorry if inconvenient : SVG-to-png rendering on Wikimedia
On 27 June 2012 14:38, Petr Kadlec petr.kad...@gmail.com wrote: On 27 June 2012 13:33, Achim Flammenkamp ac...@uni-bielefeld.de wrote: 2) I wonder why the SVG-graphic devolpers use such an improper(?) rendering- philosophy. All these articfacts on the Iran-flag would have been avoided, if the rendering is divided up logical into two steps: Firstly render the SVG-code to the size given in this SVG-code (or an integer multiple for large final sizes) to a pixel (discret) map. I can imagine how this can be a problem. Thin lines than in your original render have 1 pixel width, will be removed or suffer a strong antialias wen reduced down. Re-rendering a image on a smaller resolution will result on a pixel perfect image (except thick eyebrows), where 1 pixel width is still 1 pixel. (no related) http://www.imagemagick.org/script/command-line-options.php?#liquid-rescale Technical remark: The width/height specified in the SVG file is a generic “length” value [1], which can be in other units than pixels [2] and also can take non-integral values. [3] ...and the situation is even more complex than that. So more things that thing can go wrong. -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sorry if inconvenient : SVG-to-png rendering on Wikimedia
On 28/06/12 12:13, Derric Atzrott wrote: I just wonder: Why do we not simply transmit the SVG image, but render a png for an SVG-file to the browser? Historic reasons? I think it is because there is no good way for us to know if a browser supports SVG images other than having a list of user-agents that do and checking that way. We don't want to send an SVG image to a browser that is unable to render it. Someone correct me if that was wrong. Thank you, Derric Atzrott Computer Specialist Alizee Pathology Here's the Mozilla developers' take on this, as of April this year: https://bugzilla.mozilla.org/show_bug.cgi?id=240493 I'm not sure I agree with them, as this seems to defeat the entire point of the Accept: header, and makes browser-sniffing compulsory if you want to use SVG (or you risk breaking all old browsers), but there we are. -- N. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Speed up tests, make @group Database smarter
P.S.: On a related note ... one could think about mocking the database as a whole for PHPUnit tests. Thereby, one would get rid of unnecessary database coupling for unit testing, get better control/detection of side effects, and really solve the database performance problem for unit tests in one go. I'd like to hear more about this. -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
You can always have a line on the bottom of a mobile page, with Do the page render correctly?. And somehow use it to flag pages that render incorrectly. Wooot, perhaps this flagging may even save the user agent of the visitor using the link. -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
On Thu, Jun 28, 2012 at 4:32 PM, Tei oscar.vi...@gmail.com wrote: You can always have a line on the bottom of a mobile page, with Do the page render correctly?. And somehow use it to flag pages that render incorrectly. Wooot, perhaps this flagging may even save the user agent of the visitor using the link. -- -- ℱin del ℳensaje. You and what privacy policy/Access to nonpublic data policy are going to process that user agent? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sorry if inconvenient : SVG-to-png rendering on Wikimedia
I can imagine how this can be a problem. Thin lines than in your original render have 1 pixel width, will be removed or suffer a strong you misunderstood. In the original SVG there are no thin lines. The thin line was introduced/inserted by buggy down-rendering to the wanted size. (There are coincident lines in the SVG). antialias wen reduced down. Re-rendering a image on a smaller resolution will result on a pixel perfect image (except thick eyebrows), where 1 pixel width is still 1 pixel. Also the double drawing would be mostly irrelvant, if first render to the original given SVG size. It seems many problems are only introduced artifically by this toughtless(?) rendering-philosophy of RSVG (or Imakemagic), IMHO. :-/ ...and the situation is even more complex than that. So more things that thing can go wrong. Surely Achim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
On 28 June 2012 16:37, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Thu, Jun 28, 2012 at 4:32 PM, Tei oscar.vi...@gmail.com wrote: You can always have a line on the bottom of a mobile page, with Do the page render correctly?. And somehow use it to flag pages that render incorrectly. Wooot, perhaps this flagging may even save the user agent of the visitor using the link. You and what privacy policy/Access to nonpublic data policy are going to process that user agent? Oops... :-O I have no idea whatsoever. (Note: I will not use here the 'I was just make a suggestion' card). Maybe you can store information this way: path_page | browser | browser version | number of reports So if two persons with the exact same user agent report on page Y the result may look like that (not actually a log, but 4 fields in a database). page/Y | FooBrosers | 3.21 | 2 Do this will make the law gods angry?. -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sorry if inconvenient : SVG-to-png rendering on Wikimedia
On Thu, Jun 28, 2012 at 4:13 AM, Derric Atzrott datzr...@alizeepathology.com wrote: I just wonder: Why do we not simply transmit the SVG image, but render a png for an SVG-file to the browser? Historic reasons? I think it is because there is no good way for us to know if a browser supports SVG images other than having a list of user-agents that do and checking that way. We don't want to send an SVG image to a browser that is unable to render it. Someone correct me if that was wrong. Pretty much. Back in the day (2003-2005 era) SVG support was very limited in common browsers -- only very recently did Internet Explorer 9 add it, and most Android devices still don't support it. We did some experimentation with using the object tag and fallbacks so that supporting browsers browsers with plugins could get native SVG but it had negative effects, such as throwing up annoying prompts and not always showing the fallback content if there was no SVG support available. Since object fallback is wonky and Accept headers can't be used reliably, we'll likely end up using different tools. In these modern days, it's likely we'll end up with something like this: * load the PNG as a default * in JS, detect native SVG support and swap the SVG original in in place following similar logic as we'll probably end up using for raster images on high-resolution screens (such as the new MacBook Pro and iPad Retina screens, the upcoming Nexus 7 and Transformer Infinity tablets, the higher-resolution version of Microsoft's upcoming Surface tablet, etc). Sending the low-res rasterization first feels like a waste of bandwidth, but usually shouldn't be too extreme, and basically will look and feel like progressive loading. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklem...@gmail.com wrote: So, stripping inline styles: * will not fix bad layouts made with tables (which are probably at least as common as bad layouts made with inline styles). * will break unrelated things, because inline styles are not directlty related to layout, they're used for many things. I think provided that there is the following documentation: * which layout patterns are problematic (whether with inline styles, tables or by other means), * why/how they cause problems * how to solve that (and how the solution is indeed better for everyone) ... then is is a matter of spreading links to that documentation and waiting for it to be incorporated on the 700+ wikis with the many many portal pages, and other structures that have bad layouts. I'm generally in agreement with Krinkle on this. But I have to warn that just spreading documentation doesn't magically make things happen -- we probably have to put some actual human effort into finding and fixing broken layouts. A one-button report bad layout on this page thingy might well be nice for that; as could an easy preview this page for mobile from the edit page. (Though to be fair, people can switch from desktop to mobile layout with one click -- worth trying out!) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
To summarise my position: # I think the beta of the mobile site is a great place to __review__ the styles we have across Wikipedia and as well as resolving many of the problems of the mobile site it would also result in a much more maintainable Wikipedia. # I dislike inline styles and don't think they should be supported. I have been taught to always separate layout from HTML to avoid duplication and keep things maintainable. (Helder thanks for the link to the bug [1]). Currently to fix portal page layouts we have to change all these pages [2]. If they were using a class instead it would only take a change in one wiki page (MediaWiki:Common.css). I thus believe we should be paving a path to move away from them. # things rely on those inline styles whether we like it or not. No... They rely on styles not //inline// styles. This is my main problem with the current setup! I believe the majority of things done in inline styles that are essential would be better done in MediaWiki:Common.css - if we have text that is red this would be better down with a class markedRed otherwise some text risks being red or and other text #BE3B3B despite meaning the same thing. Most layout problems on mobile can be fixed with media queries. You can't do these in inline styles. ## (The fact MediaWiki:Common.css can only be edited by admins is another concern for me but off topic.) # I believe people are motivated to fix things when there are agreed deadlines and things they care about are broken rather than vice versa. Out of date layout styles will remain out of date as no-one probably cares about them anymore and it's not a fun or rewarding task to fix them for anyone. On the other hand important problems such as why is this text not marked red in the mobile site and working on styling convention documentation for Wikipedia are more motivating to fix in my opinion. # I believe beta users of the mobile is a very small number of dedicated Wikipedians. The nostyle=true suggestion by MZMcBride would be a great idea but my only worry is with it that no one would use it as users would have to add the query string to every page. This is why I suggested the beta as the problem would be in front of people's faces on every page view and the problems would get surfaced better. FWIW I was thinking more of a javascript implementation - $([style]).removeAttr(style) - this way disabling javascript would get people back their styles in a worst case of scenario and it would not effect performance on the server. # A report bad layout button on each page as suggested by Brion would be highly useful but that's going to take design and coding which I don't believe can be achieved any time soon. Currently users can use the contact us page to report problems but I'm yet to see anyone report bad layout. I'm not sure what else to say really... I could understand backlash if I was suggesting turning off inline styles on the desktop site or even the mobile site - but all I'm suggesting here is targeting the beta of mobile. Thanks for everyones contributions so far on this long thread! I really do appreciate this discussion and your patience with me :-). [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=15075 [2] http://www.mediawiki.org/wiki/List_of_Problematic_portal_pages_with_two_column_layouts On Thu, Jun 28, 2012 at 9:37 AM, Brion Vibber br...@pobox.com wrote: On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklem...@gmail.com wrote: So, stripping inline styles: * will not fix bad layouts made with tables (which are probably at least as common as bad layouts made with inline styles). * will break unrelated things, because inline styles are not directlty related to layout, they're used for many things. I think provided that there is the following documentation: * which layout patterns are problematic (whether with inline styles, tables or by other means), * why/how they cause problems * how to solve that (and how the solution is indeed better for everyone) ... then is is a matter of spreading links to that documentation and waiting for it to be incorporated on the 700+ wikis with the many many portal pages, and other structures that have bad layouts. I'm generally in agreement with Krinkle on this. But I have to warn that just spreading documentation doesn't magically make things happen -- we probably have to put some actual human effort into finding and fixing broken layouts. A one-button report bad layout on this page thingy might well be nice for that; as could an easy preview this page for mobile from the edit page. (Though to be fair, people can switch from desktop to mobile layout with one click -- worth trying out!) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing
Re: [Wikitech-l] Inline styles trouble on the mobile site
2012/6/28 Jon Robson jdlrob...@gmail.com: # things rely on those inline styles whether we like it or not. No... They rely on styles not //inline// styles. This is my main problem with the current setup! I believe the majority of things done in inline styles that are essential would be better done in MediaWiki:Common.css - if we have text that is red this would be better down with a class markedRed otherwise some text risks being red or and other text #BE3B3B despite meaning the same thing. Most layout problems on mobile can be fixed with media queries. You can't do these in inline styles. This makes no sense. Are you suggesting we create CSS classes markedX for every one of the approx. 150 color names accepted by browsers, as well as for every possible capitalization of these names? Because that's what we should do to avoid having markedRed word but markedPurple not for no user-visible reason. (And I didn't even start to mention how this makes even less sense semantically than inline styles. What if one text is marked with markedRed and other is marked the same way despite meaning *different* things?) What would sort of make sense would be classes like wrong, no or decrease, which would all have the same red color, but would mean different things. But now we're heading for unnecessary obstacles to editors... -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
What would sort of make sense would be classes like wrong, no or decrease, which would all have the same red color, but would mean different things. But now we're heading for unnecessary obstacles to editors... Yes. Agreed. I just picked an arbitrary class name here. The only point I was trying to make is moving inline styles to a class gives us more consistency. If the color red means 'wrong' we should call the class wrong. I wasn't for one minute suggesting we should introduce classes for every specific color.. that would just be stupid :P ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
What would sort of make sense would be classes like wrong, no or decrease, which would all have the same red color, but would mean different things. But now we're heading for unnecessary obstacles to editors... Yes. Agreed. I just picked an arbitrary class name here. The only point I was trying to make is moving inline styles to a class gives us more consistency. If the color red means 'wrong' we should call the class wrong. I wasn't for one minute suggesting we should introduce classes for every specific color.. that would just be stupid :P I like the idea of class names for different things, and I don't think that it would unduly burden the editor. As they are already using inline styles, I think that using classes shouldn't be an undue burden. It is no harder to say class=someClass than it is to say style=color: #123456, in fact, I would argue it is easier. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
2012/6/28 Derric Atzrott datzr...@alizeepathology.com: I like the idea of class names for different things, and I don't think that it would unduly burden the editor. As they are already using inline styles, I think that using classes shouldn't be an undue burden. It is no harder to say class=someClass than it is to say style=color: #123456, in fact, I would argue it is easier. Assuming you remember all the class names, which ones will work and which will not (or, worst case, you have documentation handy). People usually already know some color names, and only need to learn the syntax once. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
Assuming you remember all the class names, which ones will work and which will not (or, worst case, you have documentation handy). I'd hope documentation would help with identifying class names and one could imagine extending the visual editor for the most common ones in future. Why would certain ones work and certain ones not? With a stylesheet solution every class should work... (there would possibly just be different styling rules for those elements for mobile / print etc.. ) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
Derric Atzrott wrote:
I like the idea of class names for different things, and I don't think that
it would unduly burden the editor. As they are already using inline styles,
I think that using classes shouldn't be an undue burden. It is no harder to
say class=someClass than it is to say style=color: #123456, in fact, I
would argue it is easier.
Well, kind of.
Ideally these classes would be wrapped in (centralized) MediaWiki templates.
MediaWiki templates support redirects, localization, and have built-in
tracking. CSS classes, on the other hand, cannot be easily renamed, don't
support redirects/aliases, and they have no built-in tracking (it requires
scanning XML dumps to find them).
So instead of class=someClass or style=color:#CC;, it'd be nice to
have {{make this row red}} (which probably already exists somewhere).
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Technical hurdles for enabling $wgHtml5 on Wikimedia sites?
Hi all, We have a longstanding request to enable HTML5 on all sites: https://bugzilla.wikimedia.org/show_bug.cgi?id=27478 We've had it enabled on mediawiki.org for ages, with minimal death and mayhem. There are two issues listed as blockers: Bug 30525: Search bar icon/button slightly lower when html5 mode is enabled https://bugzilla.wikimedia.org/show_bug.cgi?id=30525 Bug 36495: Sanitizer incorrectly converts align=right for elements that are not table-cells https://bugzilla.wikimedia.org/show_bug.cgi?id=36495 Bug 30525 doesn't seem like a blocker to me (but patches definitely welcome). Bug 36495 seems more likely to cause problems, though I'd like to nudge Krinkle to explain Comment 9. Assuming we can either get these fixed, or agree they aren't blockers, I say we set a date and go. Should we plan on sometime in July (say a week or two after Wikimania)? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
Replies inline: On Jun 28, 2012, at 7:38 PM, Jon Robson wrote: # things rely on those inline styles whether we like it or not. No... They rely on styles not //inline// styles. This is my main problem with the current setup! I believe the majority of things done in inline styles that are essential would be better done in MediaWiki:Common.css - if we have text that is red this would be better down with a class markedRed otherwise some text risks being red or and other text #BE3B3B despite meaning the same thing. Most layout problems on mobile can be fixed with media queries. You can't do these in inline styles. Hold on, we're in misunderstanding :). We agree. So, they *do* rely on inline styles. But when I said they rely I meant: they currently use them to do something that should not be removed. You won't hear me say we need inline styles (there is not a single layout best done through inline styles). I'm saying they are in use - right now - and fulfilling valid needs to the point that they can break or make an article. Obviously they should become css classes loaded through modules like MediaWiki:Common.css and what not. I will +1 any movement towards deprecating them entirely from wikitext in MediaWii core. But not for just for mobile and not without at least a year of migration time for live sites (possibly with an opt-in feature before that for users to preview articles without inline styles to help fixing them). Indeed, media queries work best for classes as well. But even then, those media queries belong where the styles are defined (whether or not in a seperate mobile wiki css page), but *not* in MobileFrontend, so this should not be a concern here. # I believe beta users of the mobile is a very small number of dedicated Wikipedians. The nostyle=true suggestion by MZMcBride would be a great idea but my only worry is with it that no one would use it as users would have to add the query string to every page. This is why I suggested the beta as the problem would be in front of people's faces on every page view and the problems would get surfaced better. FWIW I was thinking more of a javascript implementation - $([style]).removeAttr(style) - this way disabling javascript would get people back their styles in a worst case of scenario and it would not effect performance on the server. From JavaScript it is a lot easier to implement, but does bring issues with interactive states (such as display: none; ) - which, although even those could be done as a css classes, are even more common. I'm not sure what else to say really... I could understand backlash if I was suggesting turning off inline styles on the desktop site or even the mobile site - but all I'm suggesting here is targeting the beta of mobile. I'm not doubting your judgement. If you believe it is useful to experiment with this in the beta. I'd say go ahead, deploy it today (its not like you need our permission or anything :-P). But as I mentioned earlier, I'm not sure what we would get out of such experiment, since we already seem to know what it will break and make. Thanks for everyones contributions so far on this long thread! I really do appreciate this discussion and your patience with me :-). Thanks for making the mobile site awesome! -- Krinkle On Thu, Jun 28, 2012 at 9:37 AM, Brion Vibber br...@pobox.com wrote: On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklem...@gmail.com wrote: So, stripping inline styles: * will not fix bad layouts made with tables (which are probably at least as common as bad layouts made with inline styles). * will break unrelated things, because inline styles are not directlty related to layout, they're used for many things. I think provided that there is the following documentation: * which layout patterns are problematic (whether with inline styles, tables or by other means), * why/how they cause problems * how to solve that (and how the solution is indeed better for everyone) ... then is is a matter of spreading links to that documentation and waiting for it to be incorporated on the 700+ wikis with the many many portal pages, and other structures that have bad layouts. I'm generally in agreement with Krinkle on this. But I have to warn that just spreading documentation doesn't magically make things happen -- we probably have to put some actual human effort into finding and fixing broken layouts. A one-button report bad layout on this page thingy might well be nice for that; as could an easy preview this page for mobile from the edit page. (Though to be fair, people can switch from desktop to mobile layout with one click -- worth trying out!) -- brion -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical hurdles for enabling $wgHtml5 on Wikimedia sites?
On 29.06.2012, 1:11 Rob wrote: We have a longstanding request to enable HTML5 on all sites: https://bugzilla.wikimedia.org/show_bug.cgi?id=27478 We've had it enabled on mediawiki.org for ages, with minimal death and mayhem. There are two issues listed as blockers: Bug 30525: Search bar icon/button slightly lower when html5 mode is enabled https://bugzilla.wikimedia.org/show_bug.cgi?id=30525 Doesn't look that scary. Bug 36495: Sanitizer incorrectly converts align=right for elements that are not table-cells https://bugzilla.wikimedia.org/show_bug.cgi?id=36495 I could poke at it as part of my 20% time. Bug 30525 doesn't seem like a blocker to me (but patches definitely welcome). Bug 36495 seems more likely to cause problems, though I'd like to nudge Krinkle to explain Comment 9. Assuming we can either get these fixed, or agree they aren't blockers, I say we set a date and go. Should we plan on sometime in July (say a week or two after Wikimania)? I say go for it. Some people are always going to whine, but we shouldn't wait forever for a few XML-loving bots to upgrade. We recently added IPv6 support, yet Wikipedia didn't die in pain while some anti-vandalism tools were broken. Same thing here. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Speed up tests, make @group Database smarter
Am 28/06/12 01:41, Christian Aistleitner schrieb: Hi Daniel, On Wed, Jun 27, 2012 at 09:59:19PM +0200, Daniel Kinzler wrote: * MediaWikiTestCase will notice this group and use temporary tables instead of the wiki database's actual tables. The temporary tables are re-created for every test. This protected the wiki from modifications through test cases, and isolates test. So far, so good. The picture you're painting here is a bit too pessimistic ... ... performance-wise. Daniel, which db backend are you using for your tests? It can matter where the data resides. Even for temporary tables, you can end up paying the fsync() penalty of storing the data into disk (when you really don't care). Maybe attacking those parser tests directly will solve the database-caused performance problem for you without going through the trouble of adding read-only Database tests? You can just run the parser tests with parserTests.php, which doesn't recreate tables and is much faster. (you'll need to apply https://gerrit.wikimedia.org/r/#/c/4111/ under mysql) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sorry if inconvenient : SVG-to-png rendering on Wikimedia
It is not an SVG! It is a band-width problem, in this case. I needed about 10 minutes real-time to download this image at full-size to my computer, but can work anyway in parallel. Vector-grafics should have been FAR MORE compressibale then jpeg or other snapshots from random/real-word scenery! Thus, an irreal example. I know, but the point stands. Who would want it embedded full size in their browser? The problem with that image is not (only) the bandwidth needed to download, that could be overcomed by waiting longer. The browser can freeze simply from trying to load it all into memory. Not so long ago desktop computers wouldn't even fully hold it into memory (and it's probably still the case on some less computer-developed countries). Plus, vector graphics compress *much better* than raster, but they are *much slower* presenting them. Try filling a web page of svg flags, and see how much it takes to load. Or compare times showing times for raster and vectorial. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical hurdles for enabling $wgHtml5 on Wikimedia sites?
On Fri, Jun 29, 2012 at 7:11 AM, Rob Lanphier ro...@wikimedia.org wrote: We've had it enabled on mediawiki.org for ages, with minimal death and mayhem. There are two issues listed as blockers: We don't have half of the delautomated crap/delinsAnti-vandal and random other tools/ins running around on mw wiki. As far as my view, We have given them enough warnings, If they still aren't fixed to use the API (and/or not suck in HTML5 mode) it's their loss and not ours if they break. Bug 30525: Search bar icon/button slightly lower when html5 mode is enabled https://bugzilla.wikimedia.org/show_bug.cgi?id=30525 Bug 30525 doesn't seem like a blocker to me (but patches definitely welcome). It isn't a blocker, that is just the best way to link stuff in BZ, I filed it just as a note bug to look at when we change to the world of tomorrow (HTML5). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sorry if inconvenient : SVG-to-png rendering on Wikimedia
Plus, vector graphics compress *much better* than raster, but they are *much slower* presenting them. Try filling a web page of svg flags, and see how much it takes to load. Or compare times showing times for raster and vectorial. Exactly this I do often: Displaying the 208+30 national flags all as SVG on one browser-page! :-) It takes about hmm ... about 62 seconds. I just made a first time time-measurement. My hardware uses an Athlon-Thunderbird 2 GHz with 4 GB RAM running FireFox 3.6.17. Chears Achim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical hurdles for enabling $wgHtml5 on Wikimedia sites?
Anomie pointed out on enwiki's Village Pump[1] the problem with the Cite extension mentioned on https://bugzilla.wikimedia.org/show_bug.cgi?id=27478#c12 Will $wgExperimentalHtmlIds be set to false? How is it configured on mw.org? Best regards, Helder [1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)?oldid=499831134#HTML5_is_comming_.28again.29 On Thu, Jun 28, 2012 at 7:51 PM, K. Peachey p858sn...@gmail.com wrote: On Fri, Jun 29, 2012 at 7:11 AM, Rob Lanphier ro...@wikimedia.org wrote: We've had it enabled on mediawiki.org for ages, with minimal death and mayhem. There are two issues listed as blockers: We don't have half of the delautomated crap/delinsAnti-vandal and random other tools/ins running around on mw wiki. As far as my view, We have given them enough warnings, If they still aren't fixed to use the API (and/or not suck in HTML5 mode) it's their loss and not ours if they break. Bug 30525: Search bar icon/button slightly lower when html5 mode is enabled https://bugzilla.wikimedia.org/show_bug.cgi?id=30525 Bug 30525 doesn't seem like a blocker to me (but patches definitely welcome). It isn't a blocker, that is just the best way to link stuff in BZ, I filed it just as a note bug to look at when we change to the world of tomorrow (HTML5). ___ 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
