Re: [Wikitech-l] [Wikimedia-l] Travel Project - Next Steps
As Erik mentions, there is a straw poll regarding naming at http://meta.wikimedia.org/wiki/Travel_Guide/Naming_straw_poll. It is initially framed as whether the project shall be called WikiVoyage. This is just for simplicity's sake: the domain names are already secured (obviously, by the extant site), owned and have a history. If the community prefers not to use that name, the Foundation is perfectly happy to run an alternative naming process. Please weigh in at http://meta.wikimedia.org/wiki/Travel_Guide/Naming_straw_poll. Your voice is needed. pb ___ Philippe Beaudette Director, Community Advocacy Wikimedia Foundation, Inc. 415-839-6885, x 6643 phili...@wikimedia.org On Wed, Sep 19, 2012 at 5:38 PM, Erik Moeller e...@wikimedia.org wrote: Hello all, As recently announced [1], WMF will move forward in creating a Wikimedia travel project based on community request and support. We’re currently in discussions with the Wikivoyage community, who’ve expressed interest in joining Wikimedia’s project family as part of this launch. We’re coordinating certain practical issues, such as content migration, account reconciliation, and attribution, with them directly. Please note that the new project will be subject to Wikimedia’s terms of use, privacy policy, and licensing policy. Like with any of our projects, the bulk of content-related policies and practices will be designed and managed by the community. Launch discussions are continuing here: https://meta.wikimedia.org/wiki/Talk:Travel_Guide An additional open question is the project name. Wikivoyage has offered to contribute its name. So, we could stick with Wikivoyage, which is already established, and has a non-profit organization supporting it. We have also obtained a number of alternative domain names, as have individual community members. We’ll initially straw poll the Wikivoyage yes/no question as this seems like the simplest path forward if there’s wide agreement in favor; more on that in a separate note by Philippe. For the Wikivoyage content import and project launch, our current plan is to do an in-person sprint in San Francisco in late October to support the project launch (we may defer this based on everyone’s availability). There’s also plenty of work ahead of time. If you’d like to be part of the technical launch team, please sign up here: https://meta.wikimedia.org/wiki/Travel_Guide/Technical_coordination We’ll also continue to monitor comments on https://meta.wikimedia.org/wiki/Talk:Travel_Guide and will engage there as the process continues. For the time being, I am coordinating the overall project launch, supported by Philippe. Questions/comments welcome. I look forward to getting this project off the ground. :-) As we’ve said before, we don’t view ourselves in competition with other providers of free knowledge, nor do we encourage anybody to leave any other site. The beautiful thing about free culture is that anyone who wishes to contribute to the corpus of freely available information about travel (or indeed any subject) can do so anywhere, and both information and people can flow freely between projects. All best, Erik [1] http://lists.wikimedia.org/pipermail/wikimedia-l/2012-September/121897.html -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to add an API/Developer/Developer Hublink to the footer of Wikimedia wikis
Le 20/09/12 02:12, Tomasz Finc a écrit : I really wish I could just got to http://developer.wikimedia.org/ and/or http://developer.wikipedia.org The necessary Apache change is now in Gerrit: https://gerrit.wikimedia.org/r/24419 If we get consensus, we can get op to deploy that :) -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTML5 and non valid attributes/elements of previous versions (bug 40329)
On Wed, Sep 19, 2012 at 9:15 PM, Derric Atzrott
datzr...@alizeepathology.com wrote:
DJ would you mind explaining again (in different terms) why we can't do
both #1
and #4 (#1 as a temporary measure while we achieve #4)? I don't think I
quite
understood your first explanation.
I'll try. Before HTML4, the align attribute (other than for 'table') with
the value center meant Center all of my content. Since the attribute
has been removed from the spec, you need to replace it with CSS rules.
Unfortunately however there are no CSS rules that are able to exactly
reproduce the behavior of the attribute.
You have text-align:center; but this only applies to content that is
inline. It does not center a div inside a table cell for instance, where
align=center would have done this. To get this behavior, you need to
apply margin-left:auto; margin-right:auto; on the div.
So the pseudo CSS rules would be something like:
table[align=center] {
text-align: center;
}
table[align=center] *[display=block or table]{
margin-left: auto;
margin-right: auto;
}
The problem is that as far as I know, that last one is not possible with
CSS. You cannot say: apply this style to all direct children that are in
block mode.
If you look at the internals of mozilla and webkit, then you will note they
have the same problem (they also transform the align attribute). Therefore
they have the following browser specific text-align attributes:
-webkit-right, -moz-right, -webkit-center etc... which bypass the default
behavior of text-align to apply to just inline elements to include block
elements as well. How other browser vendors do this, I'm not sure of.
DJ
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTML5 and non valid attributes/elements of previous versions (bug 40329)
Small mistake in the example, I meant td instead of table.
td[align=center] {
text-align: center;
}
td[align=center] *[display=block or table]{
margin-left: auto;
margin-right: auto;
}
On Thu, Sep 20, 2012 at 10:10 AM, Derk-Jan Hartman
d.j.hartman+wmf...@gmail.com wrote:
On Wed, Sep 19, 2012 at 9:15 PM, Derric Atzrott
datzr...@alizeepathology.com wrote:
DJ would you mind explaining again (in different terms) why we can't do
both #1
and #4 (#1 as a temporary measure while we achieve #4)? I don't think I
quite
understood your first explanation.
I'll try. Before HTML4, the align attribute (other than for 'table')
with the value center meant Center all of my content. Since the
attribute has been removed from the spec, you need to replace it with CSS
rules. Unfortunately however there are no CSS rules that are able to
exactly reproduce the behavior of the attribute.
You have text-align:center; but this only applies to content that is
inline. It does not center a div inside a table cell for instance, where
align=center would have done this. To get this behavior, you need to
apply margin-left:auto; margin-right:auto; on the div.
So the pseudo CSS rules would be something like:
table[align=center] {
text-align: center;
}
table[align=center] *[display=block or table]{
margin-left: auto;
margin-right: auto;
}
The problem is that as far as I know, that last one is not possible with
CSS. You cannot say: apply this style to all direct children that are in
block mode.
If you look at the internals of mozilla and webkit, then you will note
they have the same problem (they also transform the align attribute).
Therefore they have the following browser specific text-align attributes:
-webkit-right, -moz-right, -webkit-center etc... which bypass the default
behavior of text-align to apply to just inline elements to include block
elements as well. How other browser vendors do this, I'm not sure of.
DJ
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikidata blockers
Daniel, regarding the sites management: Since the last activity on the discussion page was from August 26, and the last substantial change to the RFC itself was from August 21, and the patch set has been there since September 12 -- without any comments, by the way -- I hope you find it understandable when I express a certain frustration with a comment like it still needs discussion. This change to the code is blocking us. If it needs discussion, then please discuss it. But being silent for several weeks, even a month, while people are working on this and spending resources at this, and then suddenly saying oh wait, I think it still needs some discussion is not very respectful of the work done by others. We have invited for discussion several times, and you have been one of the most active in the discussions. So, please, at least be as helpful as to say what imperfection in the current state of affairs irks you, so that we can discuss them and work on them. Otherwise your comment merely leads to an increase in frustration, and I do not see how it helps us improve MediaWiki. Sorry if the words are received as harsh, Denny 2012/9/20 Daniel Friesen dan...@nadir-seen-fire.com: On Wed, 19 Sep 2012 12:53:54 -0700, Denny Vrandečić denny.vrande...@wikimedia.de wrote: Hi all, here's our weekly list of Wikidata review items. Due to the hands-on meeting last week we refrained from sending it earlier. Now that most should be back home, I wanted to give an overview of the open items before our telco tomorrow. * ContentHandler. This one is seriously blocking us now, and we would need to get it reviewed. It is our highest priority right now. The review was promised for this week. We are eagerly awaiting the review and further input. Here's the bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=38622 * Sites. The RFC seems to be stable: https://www.mediawiki.org/wiki/Requests_for_comment/New_sites_system Chad was reminded one and half weeks ago to take a look, and since no further input has come in we assume that it is acceptable, which is why we started with the implementation work. Here's the link to the patch: https://gerrit.wikimedia.org/r/#/c/23528/ The Sitelinks topic still needs discussion. * jQuery table sorting improvements. This improves the UI on initial display of a sorted table. There has been some comments and updates, thanks to Krinkle for the review and comments. The work is ongoing here, the ball is in our courtyard, we are working on the new patchset: https://gerrit.wikimedia.org/r/#/c/22562/ * Towards nested transactions (2): https://gerrit.wikimedia.org/r/#/c/21584/ open with comments from Aaron Schulz. Got merged since last mail: * userWasLastToEdit improvement. https://gerrit.wikimedia.org/r/#/c/22049/ Yay! Thanks to Demon. * Towards nested transactions (1): https://gerrit.wikimedia.org/r/#/c/21582/ got merged! Yay! Thanks to Aaron Schulz. Thanks for everyone, especially to Demon, Krinkle, The DJ, Dantman, Matmarex, and Aaron Schulz for reviewing, and Rob, Tim, and Chad who participated in the phone conference last week. It would be crucial to get the first two items off this list as soon as possible. Cheers, Denny -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikidata blockers
On Thu, 20 Sep 2012 01:26:43 -0700, Denny Vrandečić denny.vrande...@wikimedia.de wrote: Daniel, regarding the sites management: Since the last activity on the discussion page was from August 26, and the last substantial change to the RFC itself was from August 21, and the patch set has been there since September 12 -- without any comments, by the way -- I hope you find it understandable when I express a certain frustration with a comment like it still needs discussion. This change to the code is blocking us. If it needs discussion, then please discuss it. But being silent for several weeks, even a month, while people are working on this and spending resources at this, and then suddenly saying oh wait, I think it still needs some discussion is not very respectful of the work done by others. We have invited for discussion several times, and you have been one of the most active in the discussions. I already started the discussion ages ago. No-one replied. So, please, at least be as helpful as to say what imperfection in the current state of affairs irks you, so that we can discuss them and work on them. Otherwise your comment merely leads to an increase in frustration, and I do not see how it helps us improve MediaWiki. Sorry if the words are received as harsh, Denny 2012/9/20 Daniel Friesen dan...@nadir-seen-fire.com: On Wed, 19 Sep 2012 12:53:54 -0700, Denny Vrandečić denny.vrande...@wikimedia.de wrote: Hi all, here's our weekly list of Wikidata review items. Due to the hands-on meeting last week we refrained from sending it earlier. Now that most should be back home, I wanted to give an overview of the open items before our telco tomorrow. * ContentHandler. This one is seriously blocking us now, and we would need to get it reviewed. It is our highest priority right now. The review was promised for this week. We are eagerly awaiting the review and further input. Here's the bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=38622 * Sites. The RFC seems to be stable: https://www.mediawiki.org/wiki/Requests_for_comment/New_sites_system Chad was reminded one and half weeks ago to take a look, and since no further input has come in we assume that it is acceptable, which is why we started with the implementation work. Here's the link to the patch: https://gerrit.wikimedia.org/r/#/c/23528/ The Sitelinks topic still needs discussion. * jQuery table sorting improvements. This improves the UI on initial display of a sorted table. There has been some comments and updates, thanks to Krinkle for the review and comments. The work is ongoing here, the ball is in our courtyard, we are working on the new patchset: https://gerrit.wikimedia.org/r/#/c/22562/ * Towards nested transactions (2): https://gerrit.wikimedia.org/r/#/c/21584/ open with comments from Aaron Schulz. Got merged since last mail: * userWasLastToEdit improvement. https://gerrit.wikimedia.org/r/#/c/22049/ Yay! Thanks to Demon. * Towards nested transactions (1): https://gerrit.wikimedia.org/r/#/c/21582/ got merged! Yay! Thanks to Aaron Schulz. Thanks for everyone, especially to Demon, Krinkle, The DJ, Dantman, Matmarex, and Aaron Schulz for reviewing, and Rob, Tim, and Chad who participated in the phone conference last week. It would be crucial to get the first two items off this list as soon as possible. Cheers, Denny -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to add an API/Developer/Developer Hublink to the footer of Wikimedia wikis
On Wed, Sep 19, 2012 at 10:40 PM, Quim Gil quim...@gmail.com wrote: For instance, Twitter, Facebook etc are actually pushing open source projects themselves, but they don't mix those in their developer pages unless you dive deep and almost knowing what you are looking for. Can I haz Facebook tarball? In seriousness, the utter open sourceness of our codebase is what sets us apart, so we should make it clear pretty prominently on our dev hub. For most platforms, cool open source side projects notwithstanding, the API/SDK is all you get to talk to the core platform - in our case you get the platform itself. So I don't agree that we should point folks to the API first, and to the platform second. With that said, I agree that the dev hub currently is pretty much inside baseball and we should try to make it more understandable if we prominently link it from every footer of every page. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikidata blockers
2012/9/20 Daniel Friesen dan...@nadir-seen-fire.com: I already started the discussion ages ago. No-one replied. Daniel, can you please point to the discussion that you started where no one replied? As far as I can tell, I can find discussions that you started on-wiki, on this mailing list, and I see comments by you on Gerrit. I found these discussions enlightening and I think they improved the design and the code - but in all these discussion threads there have been replies. If there are discussions you have started where no one replied, can you please provide links to them? I cannot find them. Denny ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GLAMwiki Toolset Project : Request for Comments - Technical Architecture
dear all, as some of you may already know, the GLAMwiki Toolset Project, http://outreach.wikimedia.org/wiki/GLAM/Toolset_project, is a collaboration between Wikimedia Nederland, Wikimedia UK, Wikimedia France and Europeana, with the goal of providing a set of tools to get materials from GLAM institutions onto Wikimedia Commons in a way that reuse can easily be tracked, and that Commons materials can easily be integrated back into the collection of the original GLAM or even other GLAMs. as part of our initial goal of creating a GLAM Upload System, we are looking to gather Wikimedia community input on the proposed architecture and technologies. if you have time and interest, please take a look and let us know your thoughts, http://outreach.wikimedia.org/wiki/GLAM/Toolset_project/Request_for_Comments/Technical_Architecture. with kind regards, dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikidata blockers
On Wed, Sep 19, 2012 at 3:53 PM, Denny Vrandečić denny.vrande...@wikimedia.de wrote: * Sites. The RFC seems to be stable: https://www.mediawiki.org/wiki/Requests_for_comment/New_sites_system Chad was reminded one and half weeks ago to take a look, and since no further input has come in we assume that it is acceptable, which is why we started with the implementation work. Here's the link to the patch: https://gerrit.wikimedia.org/r/#/c/23528/ The RFC I pretty much agree with in full. It fixes a lot of long-standing issues with our current interwiki/languagelink format and makes it more future-proof to later things we may want to tack on. I have not reviewed the patch in-depth yet because it's almost 2,900 lines of text and I just haven't found the time. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to add an API/Developer/Developer Hublink to the footer of Wikimedia wikis
On Thu, Sep 20, 2012 at 2:11 AM, Erik Moeller e...@wikimedia.org wrote: the utter open sourceness of our codebase is what sets us apart, so we should make it clear pretty prominently on our dev hub. (...) With that said, I agree that the dev hub currently is pretty much inside baseball and we should try to make it more understandable if we prominently link it from every footer of every page. Alright, let's move onto the next round: which dev hub? http://meta.wikimedia.org/wiki/Wikimedia_developer_hub http://www.mediawiki.org/wiki/Developer_hub mediawiki.org is a better default landing place for developers than Meta, do you agree? Is it worth considering the merge of both pages, as it has been suggested? And in any case the API should be promoted upfront. Now the Meta hub has no mention (I could find) while the dense MediaWiki hub features the link if you are patient to find it (or you use the search, as I did). -- Quim -- Quim Gil /// http://espiral.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to add an API/Developer/Developer Hublink to the footer of Wikimedia wikis
On 20 September 2012 08:54, Quim Gil quim...@gmail.com wrote: On Thu, Sep 20, 2012 at 2:11 AM, Erik Moeller e...@wikimedia.org wrote: the utter open sourceness of our codebase is what sets us apart, so we should make it clear pretty prominently on our dev hub. (...) With that said, I agree that the dev hub currently is pretty much inside baseball and we should try to make it more understandable if we prominently link it from every footer of every page. Alright, let's move onto the next round: which dev hub? http://meta.wikimedia.org/wiki/Wikimedia_developer_hub http://www.mediawiki.org/wiki/Developer_hub mediawiki.org is a better default landing place for developers than Meta, do you agree? Is it worth considering the merge of both pages, as it has been suggested? And in any case the API should be promoted upfront. Now the Meta hub has no mention (I could find) while the dense MediaWiki hub features the link if you are patient to find it (or you use the search, as I did). Of course, we already have a link to the mediawiki.org front page on every page we serve - that's what the Powered by MediaWiki button links to. There, the four most prominent links are: * https://en.wikipedia.org/wiki/Wiki * https://www.mediawiki.org/wiki/Installation * https://www.mediawiki.org/wiki/Manual:Configuration * https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker I assumed that the point of this additional link was to take people to our API because we already use our bully-pulpit to ask for more developers quite strongly, but people who want to use us as a service need to dig further to even know we have one. If all we're doing is duplicating the general hey, you're a techy person link with another text label, this exercise will have lost its value. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester | +1 415-839-6885 x6844 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Code review meeting notes
Niklas, Aaron S., Siebrand, Santhosh, Amir, Alolita had a discussion about code review. Here are the notes. It might repeat some things Sumana sent earlier and you might not agree on everything. Problems: * Having tags in Gerrit would be nice. Commit summary lines are sometimes abused for this. * Changes and rebases are combined. * We are concerned that dashboards will become private in future. Currently it's possible to see everyone's dashboards. * Time is wasted scanning for stuff to review in different Gerrit listings. * Unowned code rotting around. Result of bad bus factor. * There is no stylize.php for JavaScript. * Lack of tools to effectively debug PHP code without print/var_dump/error_log etc. Notes: * Not always testing manually. Depends on how big failure can be and whether there are good unit tests for it. * Drafts-feature is (sometimes) good for work-in-progress, but tests need to be triggered manually by adding Jenkins to reviewers and triggering new patchset. * We own/watch certain extensions and review new patches against them. * JavaScript code needs more documentation than PHP. * Sadly, automatic code formatting tools are rarely used. * Post-commit review does not yet have a process, but cases seem to be relatively rare. * We love the continous integration systems running our phpunit tests, looking forward to QUnit tests too. * Use wfProfilneIn/Out for things like reading or writing to files, shell calls, http calls. Our quick tips (what we usually complain in code review) * Commit should message describe what and why. What was the problem? How does the fix resolve it? How to test that it actually works? * Commits should come with unit tests when possible. * Make methods public/protected/private (think what makes sense). Don't just make everything public! * Follow coding style (whitespace is important). * Spelling mistakes. * Avoid long functions (100+ lines). * Document all methods (even if protected) in general. Describe what they do rather than documenting the obvious @param $title Title Title object. * New public methods and classes should have @since tags. Extension developers will love you. * Avoid saying patchset x: ... in the commit summary, use gerrit comments instead * Use type hinting when applicable * If you need some additional functionality of a core module (or you need a function that does something similar but a different), actually improve the core module. Don't just copy+paste and modify the code * in another place. * Avoid static inheritance (late static binding) unless it's perhaps for a factory function * Smaller commits are easier to review * Extensions that assume direct file system access for shared storage can't be used on WMF * Refactor code as changes are made (but use separate commits if the refactoring is large). Don't let the code keep getting worse with each change. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Breaking changes in the Wikidata API
There are a few upcoming breaking changes in the Wikibase API. * The items id as exposed to the outer world is now a numeric id. This will be prefixed with a letter and this letter will be used internally during lookup. Do not hardcode interpretation of this letter as it can be configured, but once configured it will be type-specific for the type of entity. https://bugzilla.wikimedia.org/show_bug.cgi?id=40381 * The encapsulating items/item in the reply will be replaced by entities/entity and it will be a new type-field in each entity. This field will have an identifier that says which kind of entity is in there. https://bugzilla.wikimedia.org/show_bug.cgi?id=40407 https://bugzilla.wikimedia.org/show_bug.cgi?id=40408 John Erling Blad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code review meeting notes
* Changes and rebases are combined. It should be said, this is part of the recent five tips to get your code reviewed faster. You should never combine a rebase with an actual substantial change, because it makes it very hard to compare between patchsets. (I didn't see this in the quick tips list, thought I should mention it) And if you can, try to use the rebase button as much as possible! -- Mark Holmquist Software Engineer, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Initial stab at responsive images for high-density displays
On Sep 18, 2012, at 5:47 PM, Jon Robson jdlrob...@gmail.com wrote: Awesome! Correct me if I'm wrong but the way this is currently written an image for foo.jpg will first load foo.jpg then replace the src attribute for this element then load the image foo-2.0.jpg ? It did that because the javascript function was hooked on window.load, which by design does not fire until all images are downloaded. The patch [1] has been revised and now fires on document ready, which should be early enough to not waste much bandwidth. I suggest we built-upon or write or own module further and integrate the lazy-load principle. In other words, on document ready fix the images above the fold, which may or may not have started downloading yet. Then cancel the rest and set those appropriately just before they come into view. That saves bandwidth in general (by not loading images when they are not visible), and makes sure to download the right image based on the environment at that point in time. When a standard for srcset (or whatever it will be called) is ready and actually implemented in some browser we could also opt to keep it without javascript. Assuming plans won't get worse, the standard will include a natural fallback by storing the 1-0 ratio image in the src attribute. Which is what we'd want on older browsers/devices anyway. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code review meeting notes
On Thu, Sep 20, 2012 at 3:42 PM, Mark Holmquist mtrac...@member.fsf.org wrote: * Changes and rebases are combined. It should be said, this is part of the recent five tips to get your code reviewed faster. You should never combine a rebase with an actual substantial change, because it makes it very hard to compare between patchsets. (I didn't see this in the quick tips list, thought I should mention it) And if you can, try to use the rebase button as much as possible! Couple of changes coming in Gerrit upstream that will make this better: - Gerrit won't perform the rebase if it's not necessary - Changes as a result of a rebase aren't shown in the changes list when comparing to an old patchset I believe the former made it into 2.5 (need to double check). Pretty sure the latter didn't, unfortunately. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code review meeting notes
- Gerrit won't perform the rebase if it's not necessary Cool! I think the only reason this will be better is reduced number of patchsets, but that's a good thing nevertheless. - Changes as a result of a rebase aren't shown in the changes list when comparing to an old patchset Hm. Will this be file-level whitelisting (i.e., this file changed from the master branch in this patchset, so we'll show the changes) or is it line-level? If the latter, how? Because I'm not sure it's trivial Well, unless this is only applicable to Gerrit-performed rebases, and won't be helpful for conflict-induced manual ones, which wouldn't be nearly as useful. -- Mark Holmquist Software Engineer, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Notification bubble system
On Sep 19, 2012, at 8:41 PM, Trevor Parscal tpars...@wikimedia.org wrote: I'm glad this area is getting a lot of interest - unfortunately I haven't been able to keep up on this thread but I wanted to give a suggestion related to adding icons. It's reasonable to take an option that provides a URL to an icon image, but we should have a common (customizable per skin and language) set of icons that can be used by symbolic name, like success, failure, information, error, etc. This helps in a few ways: - We can make sure they match the skin they are being used in - We can internationalize them - We can avoid having multiple icons for the same purpose - It makes it easier to use the icon feature - Trevor Interesting idea. Though I must say I was (so far) thinking quite the opposite. I like your idea as well. I was thinking not to use icons for the type of message. For one because it would have to be very well controlled to allow for adaption to skin, language and avoid duplication (though your proposal seems to handle that quite well). But also because: * it is hard to categorize a message in such a specific category * if possible, avoiding icons is a good thing in my opinion. Icons are nice, but sometimes a simple message suffices. But having some messages with and others without an icon doesn't seem nice either as it would break the grid and user expectation. Would we have a default icon? * it means we can't have an icon for source, only for type (because I believe having 2 icons is not an option) I think source is more important than type. Where (groups of) modules in an extension, gadgets or core are sources. Examples of sources that could be identified by their own icon: Watchlist: * Added X to your watchlist. * An error occurred while removing X from your watchlist. * John edited X \ (snippet from edit summary) Discussion: * John sent you a personal message. # edit on user talk page.. * John started a discussion on subject. * John commented on thread name. Countervandalism Network gadgets: * Blacklisted Jack renamed X to Y. \ (log message) * John edited monitored page X. (edit summary) As for messages confirming a user's own page and user actions, I've been thinking a bit lately. Maybe a notification bubble is not the right way to communicate confirmations of user's direct own actions. Here's a brief list of such messages (similar to the kind of messages one would see in the yellow bar of Google products like Gmail and Gerrit). * Loading edit screen... * The conversation has been archived. [learn more] [undo] * Edit saved! * The page has been renamed. [undo] It feels to me like these kind of messages would only be appropiate to appear through a notification bubble if they happened externally. Or if it was like a scheduled event, (so the messages lets the user know that the scheduled action took place and that it succeeded (or failed)). If they happened as a direct consequence of a user action, maybe it should appear inside the interface where it was performed? Anyway, just my 2 cents :) -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTML5 and non valid attributes/elements of previous versions (bug 40329)
On Sep 19, 2012, at 6:23 PM, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote: I would like to open some discussion about https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 This bug is about the fact that we currently do a 'partial' transform of the HTML5-invalid attribute 'align'. We all agree that this is bad, what we need to figure out is what to do next: 1: Disable the transform and output the align attribute even though it's not valid HTML5. Solve validness later. 2: Remove the attribute from HTML5 and 'break' the content. Fix by users (or bot). 3: Disable HTML5, correct the content of the wiki's (possibly with a bot) and remove the attribute in HTML5 mode, reenable HTML5. 4: Fix the transform (not that easy) My personal preference is with 1, since this is causing trouble now and with 1 we solve immediate problems, we just add to the lack of valid HTML5 output that we already have. In my opinion 2 would be too disruptive and 3 would take too long. Danny is of the opinion that we should never transform at the parser side and that we should fix the content instead (2 or 3). So, how best to fix the issue/what should be our strategy with regard to content that is not HTML 5 valid in general ? Discuss I agree with others, #1 seems to be the best choice. The W3C validator is not a visitor nor a user of the software. It's a useful tool to find problems, but as long as browsers are not standards compliant, and the W3C validator stays ignorant of that fact, we have very good reason to choose to optimize for real browsers, and not the hypothetical browser in the eyes of the validator. The HTML output of the MediaWiki software is meant for users. Users that have browsers in front of them. All relevant browsers support align, regardless of whether the page is in HTML5 made. Having said that, word shall be spread to users to stop using align and make layouts in CSS instead (through classes), which by design will make use of align impossible and require usage of text-align and margin instead. Even if we could transform it correctly, I would oppose automatic transformation (be it from output-only in the parser, or by a bot changing the actual wikitext). Because the align attribute is a means to an end that has lots of implications and possible unintended side-effects. Contrary to text-align and margin, which are very specific and targeted at their purpose. By replacing a single align attribute with all kinds of inline styles the original intention of that align attribute will be lost at the cost of a lot of bloat in the output that we don't really need anyway. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTML5 and non valid attributes/elements of previous versions (bug 40329)
To solve validness I'd suggest creating styles for this in MediaWiki:Common.css and on a regular basis running reports to surface which articles use the text-align property. It would be great to have a dedicated wiki page linking to these articles and asking editors to fix them. It would give people who care about Wikipedia an easy way to contribute. I have a similar problem in mobile - at some point I'd like us to deprecate use of the style attribute in wikitext in favour of using stylesheets and the class attribute which is much more manageable and would be interested in whatever solution you come to here. On Thu, Sep 20, 2012 at 4:12 PM, Krinkle krinklem...@gmail.com wrote: On Sep 19, 2012, at 6:23 PM, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote: I would like to open some discussion about https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 This bug is about the fact that we currently do a 'partial' transform of the HTML5-invalid attribute 'align'. We all agree that this is bad, what we need to figure out is what to do next: 1: Disable the transform and output the align attribute even though it's not valid HTML5. Solve validness later. 2: Remove the attribute from HTML5 and 'break' the content. Fix by users (or bot). 3: Disable HTML5, correct the content of the wiki's (possibly with a bot) and remove the attribute in HTML5 mode, reenable HTML5. 4: Fix the transform (not that easy) My personal preference is with 1, since this is causing trouble now and with 1 we solve immediate problems, we just add to the lack of valid HTML5 output that we already have. In my opinion 2 would be too disruptive and 3 would take too long. Danny is of the opinion that we should never transform at the parser side and that we should fix the content instead (2 or 3). So, how best to fix the issue/what should be our strategy with regard to content that is not HTML 5 valid in general ? Discuss I agree with others, #1 seems to be the best choice. The W3C validator is not a visitor nor a user of the software. It's a useful tool to find problems, but as long as browsers are not standards compliant, and the W3C validator stays ignorant of that fact, we have very good reason to choose to optimize for real browsers, and not the hypothetical browser in the eyes of the validator. The HTML output of the MediaWiki software is meant for users. Users that have browsers in front of them. All relevant browsers support align, regardless of whether the page is in HTML5 made. Having said that, word shall be spread to users to stop using align and make layouts in CSS instead (through classes), which by design will make use of align impossible and require usage of text-align and margin instead. Even if we could transform it correctly, I would oppose automatic transformation (be it from output-only in the parser, or by a bot changing the actual wikitext). Because the align attribute is a means to an end that has lots of implications and possible unintended side-effects. Contrary to text-align and margin, which are very specific and targeted at their purpose. By replacing a single align attribute with all kinds of inline styles the original intention of that align attribute will be lost at the cost of a lot of bloat in the output that we don't really need anyway. -- Krinkle ___ 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 list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki 1.20 release candidate
Last week, I announced the MediaWiki 1.20 release candidate that I created on wikitech-l (http://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063226.html shortened: http://hexm.de/lo). A few people have downloaded it and, so far, I don't know of any problem reports, but maybe that is because the people on wikitech-l are already using newer versions MediaWiki. Today I'd like to get more people looking at it, so I'm announcing it on mediawiki-l and mwusers.com. Download: http://mah.everybody.org/mediawiki-1.20.0beta0.tar.gz Release Notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RELEASE-NOTES-1.20 shortened: http://hexm.de/ln GPG signatures: http://mah.everybody.org/mediawiki-1.20.0beta0.tar.gz.sig Public key: http://mah.everybody.org/contact-info http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x7956EE477F901A30 (If there there is anyone with a PGP key in the Philadelphia/New York City area who can sign my key, let me know. I have to get some more signatures.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTML5 and non valid attributes/elements of previous versions (bug 40329)
Jon Robson wrote: To solve validness I'd suggest creating styles for this in MediaWiki:Common.css and on a regular basis running reports to surface which articles use the text-align property. It would be great to have a dedicated wiki page linking to these articles and asking editors to fix them. It would give people who care about Wikipedia an easy way to contribute. I have a similar problem in mobile - at some point I'd like us to deprecate use of the style attribute in wikitext in favour of using stylesheets and the class attribute which is much more manageable and would be interested in whatever solution you come to here. Finding specific text strings like these requires scanning XML dumps. There are a few projects dedicated to this on various wikis. English examples: * https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Check_Wikipedia * https://en.wikipedia.org/wiki/Wikipedia:Dump_reports Scanning dumps (or really dealing with them in any form) is pretty awful. There's been some brainstorming in the past for how to set up a system where users (or operators) could run arbitrary regular expressions on all of the current wikitext regularly, but such a setup requires _a lot_ of anything involved (disk space, RAM, bandwidth, processing power, etc.). Maybe one day Labs will have something like this. It's a well-known fact that if you give Wikimedians lists of things to do, they will eventually get done. I've done this for years with https://en.wikipedia.org/wiki/Wikipedia:Database_reports. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikidata blockers
On Thu, 20 Sep 2012 05:54:02 -0700, Denny Vrandečić denny.vrande...@wikimedia.de wrote: 2012/9/20 Daniel Friesen dan...@nadir-seen-fire.com: I already started the discussion ages ago. No-one replied. Daniel, can you please point to the discussion that you started where no one replied? As far as I can tell, I can find discussions that you started on-wiki, on this mailing list, and I see comments by you on Gerrit. I found these discussions enlightening and I think they improved the design and the code - but in all these discussion threads there have been replies. If there are discussions you have started where no one replied, can you please provide links to them? I cannot find them. Denny https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/New_sites_system/Sitelinks -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: WLM Android app v1.2.4 Daigo-ji
FYI -- Forwarded message -- From: Philip Chang pch...@wikimedia.org Date: Thu, Sep 20, 2012 at 8:53 PM Subject: WLM Android app v1.2.4 Daigo-ji To: Wiki Loves Monuments Photograph Competition wikilovesmonume...@lists.wikimedia.org Dear WLM Members, The WLM Android app has been updated to v1.2.4, named Daigo-ji. Release notes: * Dynamically loads localization updates * Clears large image previews before taking another photo - may help with out of memory errors * Stops Mobile to desktop upload category from being added to uploads from the app - this category should be limited to desktop uploads from a mobile upload Please note: there are issues with the Cordova interface to the camera that are outside of our control (Cordova is the app framework used to build our mobile apps). There are a significant number of users experiencing crashes and we are limited in our ability to debug these problems, for several reasons: * We are not able to reproduce these problems on the same devices that seems to be experiencing the problems * Google Play captures a part of the error which does not include the Cordova aspects * Google Play does not allow us to contact reviewers or people reporting crashes Therefore, if you hear of any users having such problems, please have them contact us by email at: mobile-feedbac...@lists.wikimedia.org. Thanks for your support. Phil -- Phil Inje Chang Product Manager, Mobile Wikimedia Foundation 415-812-0854 m 415-882-7982 x 6810 -- Phil Inje Chang Product Manager, Mobile Wikimedia Foundation 415-812-0854 m 415-882-7982 x 6810 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Notification bubble system
On Thu, 20 Sep 2012 15:48:27 -0700, Krinkle krinklem...@gmail.com wrote: On Sep 19, 2012, at 8:41 PM, Trevor Parscal tpars...@wikimedia.org wrote: I'm glad this area is getting a lot of interest - unfortunately I haven't been able to keep up on this thread but I wanted to give a suggestion related to adding icons. It's reasonable to take an option that provides a URL to an icon image, but we should have a common (customizable per skin and language) set of icons that can be used by symbolic name, like success, failure, information, error, etc. This helps in a few ways: - We can make sure they match the skin they are being used in - We can internationalize them - We can avoid having multiple icons for the same purpose - It makes it easier to use the icon feature - Trevor Interesting idea. Though I must say I was (so far) thinking quite the opposite. I like your idea as well. I was thinking not to use icons for the type of message. For one because it would have to be very well controlled to allow for adaption to skin, language and avoid duplication (though your proposal seems to handle that quite well). But also because: * it is hard to categorize a message in such a specific category * if possible, avoiding icons is a good thing in my opinion. Icons are nice, but sometimes a simple message suffices. But having some messages with and others without an icon doesn't seem nice either as it would break the grid and user expectation. Would we have a default icon? * it means we can't have an icon for source, only for type (because I believe having 2 icons is not an option) I think source is more important than type. Where (groups of) modules in an extension, gadgets or core are sources. Examples of sources that could be identified by their own icon: Watchlist: * Added X to your watchlist. * An error occurred while removing X from your watchlist. * John edited X \ (snippet from edit summary) Discussion: * John sent you a personal message. # edit on user talk page.. * John started a discussion on subject. * John commented on thread name. Countervandalism Network gadgets: * Blacklisted Jack renamed X to Y. \ (log message) * John edited monitored page X. (edit summary) As for messages confirming a user's own page and user actions, I've been thinking a bit lately. Maybe a notification bubble is not the right way to communicate confirmations of user's direct own actions. Here's a brief list of such messages (similar to the kind of messages one would see in the yellow bar of Google products like Gmail and Gerrit). * Loading edit screen... * The conversation has been archived. [learn more] [undo] * Edit saved! * The page has been renamed. [undo] It feels to me like these kind of messages would only be appropiate to appear through a notification bubble if they happened externally. Or if it was like a scheduled event, (so the messages lets the user know that the scheduled action took place and that it succeeded (or failed)). If they happened as a direct consequence of a user action, maybe it should appear inside the interface where it was performed? Those notifications on Google make sense because the saving is done dynamically and the user remains on the page itself with no other way to know that their action was completed. Naturally they don't make sense in most of our cases because we aren't using ajax, you end up getting sent to the result/another page, etc... But say if we start offering a Safe draft button and instead of sending the user to another page we save that draft dynamically and leave the user on the same page to continue writing the draft. Then a Your draft has been saved. notification will make sense. Anyway, just my 2 cents :) -- Krinkle -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] #switch limits
Over the last week, we have noticed very heavy apache memory usage on the main Wikimedia cluster. In some cases, high memory usage resulted in heavy swapping and site-wide performance issues. After some analysis, we've identified the main cause of this high memory usage to be geographical data (données) templates on the French Wikipedia, and to a lesser extent, the same data templates copied to other wikis for use on articles about places in Europe. Here is an example of a problematic template: https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Donn%C3%A9es_PyrF1-2009action=edit That template alone uses 47MB for 37000 #switch cases, and one article used about 15 similarly sized templates. The simplest solution to this problem is for the few Wikipedians involved to stop doing what they are doing, and to remove the template invocations which have already been introduced. Antoine Musso has raised the issue on the French Wikipedia's Bistro and some of the worst cases have already been fixed. To protect site stability, I've introduced a new preprocessor complexity limit called the preprocessor generated node count, which is incremented by about 6 for each #switch case. When the limit is exceeded, an exception is thrown, preventing the page from being saved or viewed. The limit is currently 4 million (~667,000 #switch cases), and it will soon be reduced to 1.5 million (~250,000 #switch cases). That's a compromise which allows most of the existing geographical pages to keep working, but still allows a memory usage of about 230MB. At some point, we would like to patch PHP upstream to cause memory for DOM XML trees to be allocated from the PHP request pool, instead of with malloc(). But to deploy that, we would need to reduce the limit to the point where the template DOM cache can easily fit in the PHP memory limit of 128MB. In the short term, we will be working with the template editors to ensure that all articles can be viewed with a limit of 1.5 million. That's not a very viable solution in the long term, so I'd also like to introduce save-time warnings and tracking categories for pages which use more than, say, 50% of the limit, to encourage authors to fix articles without being directly prompted by WMF staff members. At some point in the future, you may be able to put this kind of geographical data in Wikidata. Please, template authors, wait patiently, don't implement your own version of Wikidata using wikitext templates. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to add an API/Developer/Developer Hub link to the footer of Wikimedia wikis
James Forrester wrote: On 20 September 2012 08:54, Quim Gil quim...@gmail.com wrote: Alright, let's move onto the next round: which dev hub? http://meta.wikimedia.org/wiki/Wikimedia_developer_hub http://www.mediawiki.org/wiki/Developer_hub mediawiki.org is a better default landing place for developers than Meta, do you agree? Is it worth considering the merge of both pages, as it has been suggested? And in any case the API should be promoted upfront. Now the Meta hub has no mention (I could find) while the dense MediaWiki hub features the link if you are patient to find it (or you use the search, as I did). Of course, we already have a link to the mediawiki.org front page on every page we serve - that's what the Powered by MediaWiki button links to. There, the four most prominent links are: * https://en.wikipedia.org/wiki/Wiki * https://www.mediawiki.org/wiki/Installation * https://www.mediawiki.org/wiki/Manual:Configuration * https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker I assumed that the point of this additional link was to take people to our API because we already use our bully-pulpit to ask for more developers quite strongly, but people who want to use us as a service need to dig further to even know we have one. If all we're doing is duplicating the general hey, you're a techy person link with another text label, this exercise will have lost its value. Hi! Sorry for starting this thread and then disappearing for a bit; it's been a busy week. I've taken the (wonderful!) comments in this thread and on bug 33464 and synthesized them into a requests for comment here: https://www.mediawiki.org/w/index.php?curid=99106. To address your point specifically, the Powered By MediaWiki button is a bit of promotion (or advertising, branding, whatever) for the MediaWiki software. What we're discussing here is something different. Based on how other sites behave, I think there's a reasonable expectation that if you want to figure out, generically, how to get involved, looking in the footer of the Web site is a reasonable place to start. Most of my thoughts are in the RFC now on mediawiki.org, but my big revelation earlier this week was that I don't think we really have an audience problem as some have suggested. The people we want to attract are all developers (which is why I suggested using Developers as the link text). That said, I think the first step in the landing page should be to split _by motivation_: * are you wanting to re-use Wikimedia wikis' content; or * are you wanting to contribute code to Wikimedia/MediaWiki? From there, you can sub-divide based on programming language, component (user interface, ops, etc.), and a bunch of other variables. My mock-up for the tree/matrix/wizard is here: https://www.mediawiki.org/w/index.php?oldid=585564#Blueprint. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
