Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
152 discussions

RFC: Refactoring the Title object
by Rob Lanphier 31 Oct '13

31 Oct '13

Hi folks, I think Daniel buried the lede here (see his mail below), so I'm mailing this out with a subject line that will hopefully provoke more discussion. :-) This is an RFC we originally conceived at the Hong Kong Wikimania architecture discussion. The notes from that are here: https://www.mediawiki.org/wiki/Architecture_guidelines/Meetings/Wikimania_2… There has been discussion on this RFC here, so far only between Tim and Daniel: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/TitleValue It would be good to get some other voices in that conversation. Rob ---------- Forwarded message ---------- From: Daniel Kinzler <daniel(a)brightbyte.de> Date: Tue, Oct 1, 2013 at 10:18 AM Subject: [Wikitech-l] RFC: TitleValue To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> [Re-posting, since my original post apparently never got through. Maybe I posted from the wrong email account.] Hi all! As discussed at the MediaWiki Architecture session at Wikimania, I have created an RFC for the TitleValue class, which could be used to replace the heavy-weight Title class in many places. The idea is to show case the advantages (and difficulties) of using true "value objects" as opposed to "active records". The idea being that hair should not know how to cut itself. You can find the proposal here: <https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue> Any feedback would be greatly appreciated. -- daniel PS: I have included the some parts of the proposal below, to give a quick impression. ------------------------------------------------------------------------------ == Motivation == The old Title class is huge and has many dependencies. It relies on global state for things like namespace resolution and permission checks. It requires a database connection for caching. This makes it hard to use Title objects in a different context, such as unit tests. Which in turn makes it quite difficult to write any clean unit tests (not using any global state) for MediaWiki since Title objects are required as parameters by many classes. In a more fundamental sense, the fact that Title has so many dependencies, and everything that uses a Title object inherits all of these dependencies, means that the MediaWiki codebase as a whole has highly "tangled" dependencies, and it is very hard to use individual classes separately. Instead of trying to refactor and redefine the Title class, this proposal suggest to introduce an alternative class that can be used instead of Title object to represent the title of a wiki page. The implementation of the old Title class should be changed to rely on the new code where possible, but its interface and behavior should not change. == Architecture == The proposed architecture consists of three parts, initially: # The TitleValue class itself. As a value object, this has no knowledge about namespaces, permissions, etc. It does not support normalization either, since that would require knowledge about the local configuration. # A TitleParser service that has configuration knowledge about namespaces and normalization rules. Any class that needs to turn a string into a TitleValue should require a TitleParser service as a constructor argument (dependency injection). Should that not be possible, a TitleParser can be obtained from a global registry. # A TitleFormatter service that has configuration knowledge about namespaces and normalization rules. Any class that needs to turn a TitleValue into a string should require a TitleFormatter service as a constructor argument (dependency injection). Should that not be possible, a TitleFormatter can be obtained from a global registry. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

11 20

Wikimedia Bugzilla Guided Bug Entry Form available
by Andre Klapper 31 Oct '13

31 Oct '13

Since last Friday, Bugzilla has a guided bug entry form. Together with documentation at https://www.mediawiki.org/wiki/How_to_report_a_bug (which needs an update now) this should make it easier for users to create better bug reports. You can link to and access the guided form by attaching ?format=guided to the enter_bug.cgi URL, like e.g. https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia&component=Bu… If you don't pass product/component parameters in the URL & link to https://bugzilla.wikimedia.org/enter_bug.cgi?format=guided the first page (where a bug reporter has to choose a product) still looks the same as usual. I would like to thank the WMF design team and community liaisons for reviews and early feedback. Happy bug reporting, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Page title length
by Élie Roux 31 Oct '13

31 Oct '13

Dear MediaWiki developers, I'm responsible for the development of a new Wiki that will contain many Tibetan resources. Traditionnaly, Tibetan titles of books or even parts of books are extremely long, as you can see for instance here : http://www.tbrc.org/#!rid=W23922, and sometimes too long for Mediawiki, for instance the title of http://www.tbrc.org/?locale=bo#library_work_ViewByOutline-O01DG1049094951|W… , which is ཤངས་པ་བཀའ་བརྒྱུད་ཀྱི་གཞུང་བཀའ་ཕྱི་མ་རྣམས་ཕྱོགས་གཅིག་ཏུ་བསྒྲིལ་བའི་ཕྱག་ལེན་བདེ་ཆེན་སྙེ་མའི་ཆུན་པོ་ . This title is around 90 Tibetan characters, but each caracter being 3 bytes, it exceeds the limit for title length of 256 bytes that MediaWiki has. So I have two questions: 1. If I change this limit to 1023 in the structure of the database ('page_title' field of the 'page' base), will other things (such as search engine) break? Is there a way to change it more cleanly? 2. Could I propose you to make this limit 1023 instead of 255 (or to make it configurable easily)? This would allow at least 256 characters (even for asian languages) instead of 256 bytes, which seems more consistant with the fact that MediaWiki is well internationalized. Thank you in advance, -- Elie

6 10

Fwd: [wikimedia #6138] etherpad.wikimedia.org downtime due to upgrade
by Alexandros Kosiaris 31 Oct '13

31 Oct '13

FYI, ---------- Forwarded message ---------- From: Core operations via RT <core-ops(a)rt.wikimedia.org> Date: Thu, Oct 31, 2013 at 12:18 PM Subject: [wikimedia #6138] etherpad.wikimedia.org downtime due to upgrade To: akosiaris(a)wikimedia.org Scheduling a downtime for etherpad.wikimedia.org on Wednesday 06/11/2013 in order to upgrade it to the latest released version. The downtime is scheduled to last one (1) hour and will start in 09:00 UTC. We will be upgrading from 1.2.11 (released 3 months ago) to 1.3 (released 10 days ago). Package will be created and will be made available on apt.wikimedia.org during the upgrade. This upgrade will reportedly solve some issues with pad corruption experienced by the Language Engineering team. -- (ticket has been created) -- Alexandros Kosiaris <akosiaris(a)wikimedia.org>

1 0

Re: [Wikitech-l] [Design] Are external link icons useful
by Brion Vibber 31 Oct '13

31 Oct '13

A few background notes: * The generic external link icon is applied by virtual of existence of the 'external' class, which is a nice simple implementation. I kinda like it. :) * In contrast, the CSS rules used to mark certain external links with the PDF, IRC, SSL, etc "specific" icon types are relatively ugly and hard to maintain. These use inefficient client-side attribute value matching. There is a desire to clean these up in the style sheets, which would of course be easiest if they're simply removed. * If it's useful to keep those subtypes, it may be more desirable to implement them differently (for instance by having the parser apply the matching rules and output a class). This would simplify the CSS rules for maintenance, since they would be able to just use the classes. * Note that some of the rules such as PDF detection can misidentify resource types (for instance the rules would mark a File:Blah.pdf file *page* on Commons as "PDF" even though it's not actually a PDF download, but an HTML web page). This would not necessarily change under the above proposal to change implementation, as the basic problem is that you can't really reliably determine a file type from a "file extension" on a URL (the only real way to check is to try fetching the resource, or at least its HTTP headers, and report back what type was received). -- brion On Tue, Oct 29, 2013 at 1:11 PM, Quiddity <pandiculation(a)gmail.com> wrote: > As Bartosz says, and I think most of the communities would agree if asked > on their respective village pumps - we value the external link icon in > particular, and most of the other icons in general (with the possible > exception of the https padlock). We think they are useful for both editors > and readers. > > Re: Gadget - This isn't a particular workflow - this is: > "I'm reading a random article, and I notice an external link icon, so, as > a wikignome, I either: (if spam) remove it, (if citation) fix it, (if > [subjective decision about its relevance/worth and adherence to [[WP:EL]] > guideline) move it into the External links section." > A gadget would not be a good replacement. > > By all means clean up the CSS, but do not consider removing the icons > without seeking much much wider input. > > > > On 13-10-29 11:57 AM, Jared Zimmerman wrote: > >> Nick, good points, for the particular use case sounds like a gadget for >> showing external links called out for workflows around fixing them would >> be a good idea. After hearing everyone's thought i'm leaning toward no >> icons for the average user. >> >> * >> * >> * >> * >> *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation >> M : +1 415 609 4043 | : @JaredZimmerman <https://twitter.com/** >> JaredZimmerman <https://twitter.com/JaredZimmerman>> >> >> >> >> >> On Tue, Oct 29, 2013 at 11:41 AM, quiddity <pandiculation(a)gmail.com >> <mailto:pandiculation@gmail.**com <pandiculation(a)gmail.com>>> wrote: >> >> +1 for more discussion, and onwiki discussion to find out why >> we/they've each kept them in the individual CSS payloads for so many >> years... >> >> >> On 10/24/2013 02:48 PM, Jared Zimmerman wrote: >> >>> Its definitely a less heavy handed way of doing >>> the thing many (annoying) sites do when they warn >>> you that you're leaving their site. I just wonder >>> is the signal to noise it worth it. I don't know >>> that modern web users have any expectations that >>> link within a site always point to local site urls. >>> >>> >> Wikis are special, in relation to most sites, because of the density >> of internal links (many per paragraph), and the expectation that >> most links are internal and will lead to a similar quality/style of >> information. That applies from Wikisource, to Wookiepedia. >> >> In wikis that don't mix external links in the main content (eg most >> Wikipedias), the icons are also useful /for editors/ as they can >> >> easily notice that something needs to be moved/fixed. >> >> See https://en.wikipedia.org/wiki/**Help:External_link_icons<https://en.wikipedia.org/wiki/Help:External_link_icons>for a >> good list of what the English Wikipedia has. >> >> See also recent discussion at >> https://bugzilla.wikimedia.**org/show_bug.cgi?id=54604<https://bugzilla.wikimedia.org/show_bug.cgi?id=54604>("Ridiculous >> amount of CSS rules for external links") >> >> >> The only icon that seems (afaik) completely unnecessary, and >> bright/distracting, is the https padlock, which possibly >> could/should be replaced with the standard external link icon. >> (Unless there's a rationale for it that I'm forgetting/unaware of.) >> >> See this 2009 discussion where Davidgothberg created a blue (less >> distracting) replacement, if we need to keep a padlock for some >> reason. >> https://en.wikipedia.org/wiki/**MediaWiki_talk:Common.css/** >> Archive_11#Secure_links_**padlock<https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_11#Secure_l…> >> https://www.mediawiki.org/**wiki/Special:Code/MediaWiki/**60320<https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320> >> >> HTH. Quiddity >> >> ______________________________**_________________ >> Design mailing list >> Design(a)lists.wikimedia.org <mailto:Design@lists.**wikimedia.org<Design(a)lists.wikimedia.org> >> > >> https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design> >> >> >> >> >> >> ______________________________**_________________ >> Design mailing list >> Design(a)lists.wikimedia.org >> https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design> >> >> > > ______________________________**_________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design> >

2 1

Re: [Wikitech-l] Deployment postmortem
by Greg Grossmeier 31 Oct '13

31 Oct '13

First: Thanks for responding to this and writing it up. <quote name="Yuri Astrakhan" date="2013-10-31" time="04:53:44 +0400"> > == Recomendations == > * Allow a bit more time between deployments and observe fatalmonitor before > and after Agreed. I put a ton of blame on myself for not slowing down the cadence of LD slots when a bunch of people are trying to get in on the same day. For future LDs I am going to explicitly ask everyone to do what Yuri suggests (monitor fatals after your deploy) before saying that you're done. 5 minutes post-deploy of watching the fatalmonitor isn't unreasonable, I don't think. Relatedly, I think we should reassess the Lightning Deploys :) Not necessarily to get rid of them (probably not), but: 1) how many deploys can go in one LD? How many do we *want* to go? 2) from 1, is the length of the LD long enough/too long? 3) LD management is still pretty high-communication ("Alright, who's in line? Who's up next? Are you done yet?") There are basic tools that can help with this (Etsy has an IRC "pushbot" that manages the queue mostly automatically, for instance); I'll look into those/test them. 4) probably more, aka: your thoughts? Greg PS: graph of the fatals attached, just for completenesses sake. -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

First round of loggable javascript deprecations
by Krinkle 31 Oct '13

31 Oct '13

TL;DR: We're starting to remove long-deprecated methods. First, they'll be wrapped in mw.log.deprecate (possibly replaced with dummy values) which will produce a stacktrace to the console when used. Example: http://cl.ly/image/3W0o131K0D3j Pre-amble: * As of MediaWiki 1.17 we started actively developing new javascript features. * Any code from before that point has been tagged "legacy" and deprecated as of v1.17.0 back in 2011. Problems: * There is no easy way to see whether a page is using any of these deprecated interfaces. * We still haven't removed any of the legacy code. * Though we've added new things (jQuery, jQuery UI, mw.Title, mw.Uri etc.). We've been reluctant to iterate further on these "new" things and haven't been able to really refactor or improve them. We've upgraded jQuery and jQuery UI a few times. But only because there were no major changes in backwards compatibility. This changed in 1.9 and that's why we're still on 1.8. It would seem we're in a fixed position – unable to move up, only sideways. On the server-side of MediaWiki, deprecation has been a natural process enforced socially (plugins not maintained for several release cycles will simply have to be disabled). We introduce the new, we migrate uses of the old, we deprecate the old, we support both for uses for a while to allow others to migrate their stuff, then we remove the old. In the front-end we never completed such a cycle. But, we're getting close to the completion of our first first cycle now. The legacy scripts deprecated as of v1.17.0 have all been removed or wrapped in mw.log.deprecate. Please go to your favourite wiki in debug=true mode with a modern browser (recent Chrome, Firefox or Opera) and look at the console. Look for any uncaught exceptions, deprecation notices or other messages and try to address them soon (or report it to the maintainers of the gadgets triggering them). -- Krinkle [1] https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.log-method-dep…

1 0

Fwd: Participation in an Aaron Swartz Hackathon event
by Quim Gil 31 Oct '13

31 Oct '13

There is a plan for a worldwide round of Aaron Hackathons, on the upcoming Nov 8-10 weekend. http://aaronswartzhackathon.org/ Coordination: https://www.noisebridge.net/wiki/Worldwide_Aaron_Swartz_Memorial_Hackathon_… We have been invited to run a hackathon. Can we organize it? We would need to find a project and a critical mass of contributors willing to document and coordinate the hackathon. One possibility could be to kick-off the hackathon on Friday 8 Nov in a physical location (San Francisco), and focus initially on the distribution of tasks. Then remote participants could also participate taking tasks, participating with the rest of the group on some IRC channel and occasional videoconferences. About the project, I personally think that it should have a link with the motivation of the hackathon: "We were part of an inchoate, ad-hoc community of collaborators who helped each other learn how to code. No, not how to write code ‒ how to write code for the purpose of changing the world." - Zooko, on memories of Aaron See also https://en.wikipedia.org/wiki/Aaron_Swartz#Life_and_works On Sat, 5 Oct 2013, Noah Swartz wrote: > Hey assorted Wikimedia people, > As I may have mentioned to some of you previously, we're running another > round of Aaron Hackathons, on the upcoming Nov 8-10 weekend. I was > wondering if WMF would be interested in providing a project for people to > work on. For each event we're hoping to have one well structured project > that people - both technical and non - can work on that can have some > support from people who have worked on it or related projects previously, > so that participants can jump right in. > Would you be willing to structure something for people to work on? If not > are there other WMF related things that people can do? Maybe go through a > list of open bugs or feature requests? Or maybe just writing documents, or > doing outreach, any project is welcome. > Currently we have two tentative events in SF and ~5 more confirmed > locations elsewhere around the world. We have a very basic landing page up > at http://aaronswartzhackathon.org/ which might give you more of a sense of > what's going on. I assume that SF is the location that works best for you > but let me know if you think somewhere else would be good. I'd really love > to see you all participate so let me know if there's anything I can do to > help. > As always feel free to pass this along to anyone else who you think might > be interested, and I'm happy to answer any and all questions you have. > Looking forward to hearing back soon! > Noah >

5 6

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?
by Quim Gil 30 Oct '13

30 Oct '13

On 10/29/2013 03:30 PM, S Page wrote: > Quim: > > And if we want to specify any fonts in our works, they should be free. > > Uh, why? Mac users actually have Helvetica Neue, the nicest-looking > font, Windows users have Georgia. The presence of these names in our CSS > does nothing to hinder the cause of free fonts. Yes, it does hinder the cause of free fonts. We won't help scratching the itch because in practice we will rely on a proprietary solution for our UX work targeting the majority of users. While not forcing anybody to use free fonts, our mockups, tests, reviews, screenshots and what not will all assume the happy coincidence that Helvetica Neue ("the most ubiquitous in advertising copy and logos") and Georgia (Microsoft Corporation) are everywhere. Now compare with this hypothetical scenario: we actually bet on a set of optional free fonts, because we care about typography as much as we care about freedom. We use them as default in our mockups, tests, reviews, screenshots and what not. We serve them as web fonts, we bundle them in our apps and offline versions, we promote them to the users missing them in their systems. We take note of our own itches and user feedback, and we file bugs and enhancement requests upstream, or send/commission improvements. This way we contribute spreading free typography, just like we contribute spreading other areas of free knowledge, free culture and free software. > Removing them would be detrimental for most of our users. Detrimental... they would still be able to access all our content and functionality without losing a single readable character, right? A lot less "detrimental" than not serving them conveniently mp3, mpeg, flash, Facebook/Twitter/Google login, and other proprietary options already installed in your average Mac / Windows desktop that we decided not to support. If the above scenario to improve the MediaWiki/Wikimedia UX by improving free fonts is not exciting, or a priority, then at least we could be neutral and not promote actively any proprietary font either. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

4 3

Google Code-in: are you in?
by Quim Gil 30 Oct '13

30 Oct '13

Google Code-in has been announced: http://www.google-melange.com/gci/homepage/google/gci2013 This is about 13-17 year old students performing tasks that can be isolated and a skilled contributor would complete in a couple of hours. The tasks mjust have a mentor and can be related to code, documentation, outreach, QA or UX. Participants get one point for each task completed and they can complete as many as they can between 18 November and 6 January. Wikimedia can apply thanks to our participation on GSoC 2013. The deadline is 28 October. Only 10 organizations will be accepted. I think we should apply. Main reasons: * The definition of a Code-in task fits very well with our ideal definition of an annoying little bug: https://www.mediawiki.org/wiki/Annoying_little_bugs * The typical Code-in participant needs what most potential new contributor also need from us: an insightful landing page, straight connections to first tasks and friendly community support. * Just like GSoC / OPW, it is a good chance for non-primetime projects to raise their hands, get some help and hopefully some new contributors. * Good exercise for first-time mentors, practicing for more co plex internship projects. * Good exercise for any open source project, meaning just any MediaWiki / Wikimedia tech project. But of course this will only work if many projects want to step in with a task and a mentor for it. So what do you think? -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

10 17

← Newer
1
2
3
4
5
6
7
...
16
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l October 2013