Re: [Wikitech-l] New git-review lets you configure 'origin' as the gerrit remote
Hey, Did you add this useful documentation on meta? If yes, please provide me the link so I can add this to my toread/todo list. Le vendredi 31 mai 2013 à 15:14 -0700, Ori Livneh a écrit : Hey, The new version of git-review released today (1.22) includes a patch I wrote that makes it possible to work against a single 'origin' remote. This amounts to a workaround for git-review's tendency to frighten you into thinking you're about to submit more patches than the ones you are working on. It makes git-review more pleasant to work with, in my opinion. To enable this behavior, you first need to upgrade to the latest version of git-review, by running pip install -U git-review. Then you need to create a configuration file: either /etc/git-review/git-review.conf (system-wide) or ~/.config/git-review/git-review.conf (user-specific). The file should contain these two lines: [gerrit] defaultremote = origin Once you've made the change, any new Gerrit repos you clone using an authenticated URI will just work. You'll need to perform an additional step to migrate existing repositories. In each repository, run the following commands: git remote set-url origin $(git config --get remote.gerrit.url) git remote rm gerrit git review -s Hope you find this useful. ___ 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
Re: [Wikitech-l] Centralized Lua modules for Wikisource (OPW mentor needed)
Le vendredi 31 mai 2013 à 11:15 -0400, David Cuenca a écrit : Hi all, After a talk with Brad Jorsch during the Hackathon (thanks again Brad for your patience), it became clear to me that Lua modules can be localized either by using system messages or by getting the project language code (mw.getContentLanguage().getCode()) and then switching the message. This second option is less integrated with the translation system, but can serve as intermediate step to get things running. Interesting, but why make a central code repository only for Wikisource ? For Wikisource it would be nice to have a central repository (sitting on wikisource.org) of localized Lua modules and associated templates. The documentation could be translated using Extension:Translate. These modules, templates and associated documentation would be then synchronized with all the language wikisources that subscribe to an opt-in list. Users would be then advised to modify the central module, thus all language versions would benefit of the improvements. This could be the first experiment of having a centralized repository of modules. What do you think of this? Would be anyone available to mentor an Outreach Program for Women project? Thanks, David Cuenca --Micru ___ 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
Re: [Wikitech-l] Centralized Lua modules for Wikisource (OPW mentor needed)
Yeah, let's make them configurable so people can set the scope of projects (all wikis, specific families, etc... languages?). On Sun, Jun 2, 2013 at 2:21 PM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Le vendredi 31 mai 2013 à 11:15 -0400, David Cuenca a écrit : Hi all, After a talk with Brad Jorsch during the Hackathon (thanks again Brad for your patience), it became clear to me that Lua modules can be localized either by using system messages or by getting the project language code (mw.getContentLanguage().getCode()) and then switching the message. This second option is less integrated with the translation system, but can serve as intermediate step to get things running. Interesting, but why make a central code repository only for Wikisource ? For Wikisource it would be nice to have a central repository (sitting on wikisource.org) of localized Lua modules and associated templates. The documentation could be translated using Extension:Translate. These modules, templates and associated documentation would be then synchronized with all the language wikisources that subscribe to an opt-in list. Users would be then advised to modify the central module, thus all language versions would benefit of the improvements. This could be the first experiment of having a centralized repository of modules. What do you think of this? Would be anyone available to mentor an Outreach Program for Women project? Thanks, David Cuenca --Micru ___ 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 -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Centralized Lua modules for Wikisource (OPW mentor needed)
On Sun, Jun 2, 2013 at 7:21 AM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Interesting, but why make a central code repository only for Wikisource ? There are several reasons for this. - trying to support all projects at once might be too much for a grantee to do in 3 months. - it is an experience to learn from, and it will have to be decided if it can be applied broadly or substituted for some better method - wikisource has a central location that can be used for this purpose, other projects don't have it specifically. It could be meta, but that should be discussed Micru ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension:OpenID 3.00 - Security Release
On Sat, Mar 9, 2013 at 3:49 AM, Ryan Lane rlan...@gmail.com wrote: On wikitech the blockers were the switch of the wiki name (from labsconsole to wikitech) and this. There's still some issues that need to be worked out for deployment on the main projects. Also, it needs a full review before deployment to the projects, and we need to work out how this will affect the OAuth plans. We have a kickoff meeting for this coming up soon. I'll send updates when that occurs. Did anything come out of the Kickoff Meeting? -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] showing videos and images in modal viewers within articles
Le 31/05/13 00:28, Ryan Kaldari a écrit : OK, I decided to be slightly bold. I changed the modal video threshold on en.wiki from 200px to 800px. This means all video thumbnails that are 800px or smaller will open a modal player when you click on the thumbnail. If there are no complaints from people, we can switch the modal behavior to just be the default everywhere. Try it out and let me know what you think: https://en.wikipedia.org/wiki/Congenital_insensitivity_to_pain#Presentation That is a huge improvement to the user experience (tm © ..). It would be great to have the video to start playing whenever it expands. Might want to select a small video whenever the browser windows size is small (I use a low resolution). Overall, nice. Thanks! -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Centralized Lua modules for Wikisource (OPW mentor needed)
On 06/02/2013 10:38 AM, David Cuenca wrote: - wikisource has a central location that can be used for this purpose, other projects don't have it specifically. It could be meta, but that should be discussed mediawiki.org is a better central location for code. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] kraken available?
hi, magnus mentioned on the cultural partners list that there should be a non-overloaded alternative (kraken) to stats.grok.se to have tracking for baglama and other view trackers? when is this available? rupert. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] kraken available?
Specifically, availability to the tools of wmflabs. On Sun, Jun 2, 2013 at 9:23 PM, rupert THURNER rupert.thur...@gmail.comwrote: hi, magnus mentioned on the cultural partners list that there should be a non-overloaded alternative (kraken) to stats.grok.se to have tracking for baglama and other view trackers? when is this available? rupert. ___ 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
Re: [Wikitech-l] kraken available?
On 06/02/2013 04:23 PM, rupert THURNER wrote: hi, magnus mentioned on the cultural partners list that there should be a non-overloaded alternative (kraken) to stats.grok.se to have tracking for baglama and other view trackers? when is this available? It already exists with some functionality, but I don't know the details on how it can be used from Labs. If you don't get an answer here, you can email https://lists.wikimedia.org/mailman/listinfo/analytics . Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] PDF Download function for mobile version for storage on sdcards, Androids
Dear developpers, I think my idea is as interesting for authorship as for the users on androids and tablets. As especially excellent contributions, you want to save on your device for quotation or adding your own ideas, commentaries, etc. are just prepared for storage on demand, I found this only in classical website, on the search for PDFDownload. My problem or idea was, to do this by SmartphoneHTC, but after packing the file archive and then touch for download (onclick) the Download on SDChipcard does not launch or initialize. The device then stops there and waits Comfortable und desirable is the PDF function for Mobil devices and the Mobile version of the Contents, as well, as it exists on the classical site. Possibly an appfunction? Perhaps you have a solution for this, or you are in preparation? Looking forward to your answer, sincerely yours Ursula Fuchs ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for May 27, 2013 - June 03, 2013 Status changes this week Reports changed/set to UNCONFIRMED: 1 Reports changed/set to NEW: 5 Reports changed/set to ASSIGNED : 28 Reports changed/set to REOPENED : 19 Reports changed/set to RESOLVED : 151 Reports changed/set to VERIFIED : 1 Total reports still open : 10414 Total bugs still open : 5715 Total non-lowest prio. bugs still open: 5532 Total enhancements still open : 4699 Reports created this week: 222 Resolutions for the week: Reports marked FIXED : 91 Reports marked DUPLICATE : 16 Reports marked INVALID : 11 Reports marked WORKSFORME: 14 Reports marked WONTFIX : 14 Specific Product/Component Resolutions User Metrics Created reports per component tools 20 WikidataRepo17 MobileFrontend 12 Sources 7 Android 6 Created reports per product MediaWiki 45 Wikimedia 24 MediaWiki extensions75 Security2 Tools 3 Top 5 bug report closers benapetr [AT] gmail.com 22 aklapper [AT] wikimedia.org 10 jforrester [AT] wikimedia.org 8 jrobson [AT] wikimedia.org 6 amir.aharoni [AT] mail.huji.ac.il 6 Most urgent open issues Product | Component | BugID | Priority | LastChange | Assignee | Summary -- Analytics | User Metrics | 47269 | Highest | 2013-04-16 | wikibugs-l[AT]lists. | Jobs idling in production, no way to MediaWiki | Installer | 47191 | Highest | 2013-05-25 | wikibugs-l[AT]lists. | [Regression] Installer: MySQL Fatal E MediaWiki ext | Echo | 47094 | Highest | 2013-05-30 | ebernhardson[AT]wiki | Notification preferences update (tool MediaWiki ext | Echo | 48183 | Highest | 2013-05-30 | wikibugs-l[AT]lists. | Show diff link when appropriate on ta MediaWiki ext | OpenID| 44819 | Highest | 2013-05-07 | mail[AT]tgries.de| [SUGGESTION] change $wgOpenIDConsumer MediaWiki ext | PdfHandler| 48834 | Highest | 2013-05-29 | wikibugs-l[AT]lists. | PdfHandler Fatal exception when used MediaWiki ext | UniversalLang | 45958 | Highest | 2013-06-01 | wikibugs-l[AT]lists. | jquery.i18n does not work in Internet MediaWiki ext | UniversalLang | 47821 | Highest | 2013-06-02 | santhosh.thottingal[ | Scrolling should not be needed to see MediaWiki ext | ValueFormatte | 48937 | Highest | 2013-05-31 | wikibugs-l[AT]lists. | Implement value formatter for time da VisualEditor | ContentEditab | 48385 | Highest | 2013-05-14 | inez[AT]wikia-inc.co | VisualEditor: Delete contents of slug VisualEditor | ContentEditab | 48526 | Highest | 2013-05-20 | inez[AT]wikia-inc.co | VisualEditor: Pressing Enter in a hea VisualEditor | ContentEditab | 48468 | Highest | 2013-06-02 | inez[AT]wikia-inc.co | VisualEditor: Pawn appears when creat VisualEditor | Data Model| 48769 | Highest | 2013-05-24 | roan.kattouw[AT]gmai | VisualEditor: Link corruption oddity VisualEditor | General | 39599 | Highest | 2013-05-14 | jforrester[AT]wikime | VisualEditor: Support references ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Planning to add RDFa link rel= support to WikiText
Along with supporting RDFa 1.1 I'm planning to add support for link and rel= in our RDFa code. To protect against injection of HTML rel values (including rel=stylesheet) I'm going to be converting all RDFa terms like foo to CURIEs like :foo (these are almost exactly the same, and the edge case shouldn't happen at all in RDFa 1.1). ((I really wanted to wrap everything except protocol whitelisted AbsIRIs in safe CURIEs making that [rdf:type] and [:stylesheet] but unfortunately it seems safe CURIEs are only valid in about and resource)) Anyone worried about the possibility that there's a badly written browser out there that'll treat link rel=:stylesheet href=... as a valid stylesheet and include it is welcome to try out any browser they can think of and bring it up. I've written a test case for it http://bl.ocks.org/dantman/5695980 if the bg there is red instead of blue then it's unsafe. I've tested IE 6, IE 7, IE 8, IE 9, IE 10, Opera 10, Opera 12, Safari 5 (Windows), iOS 6's browser, Firefox 3.0, Firefox 21.0, Android 4's stock browser, and Chrome 27. They're all safe. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architecture Guidelines: Writing Testable Code
On 31/05/13 20:15, Daniel Kinzler wrote: When looking for resources to answer Tim's question at https://www.mediawiki.org/wiki/Architecture_guidelines#Clear_separation_of_concerns, I found a very nice and concise overview of principles to follow for writing testable (and extendable, and maintainable) code: Writing Testable Code by Miško Hevery http://googletesting.blogspot.de/2008/08/by-miko-hevery-so-you-decided-to.html. It's just 10 short and easy points, not some rambling discussion of code philosophy. As far as I am concerned, these points can be our architecture guidelines. Beyond that, all we need is some best practices for dealing with legacy code. MediaWiki violates at least half of these principles in pretty much every class. I'm not saying we should rewrite MediaWiki to conform. But I'd wish that it was recommended for all new code to follow these principles, and that (local) just in time refactoring of old code in accordance with these guidelines was encouraged. I'm not convinced that unit testing is worth doing down to the level of detail implied by that blog post. Unit testing is essential for certain kinds of problems -- especially complex problems where the solution and verification can come from two different (complementary) directions. But if you split up your classes to the point of triviality, and then write unit tests for a couple of lines of code at a time with an absolute minimum of integration, then the tests become simply a mirror of the code. The application logic, where flaws occur, is at a higher level of abstraction than the unit tests. Even if you test code in larger chunks, very simple code tends to fail in ways that are invisible to unit tests. For example, you can get 100% test coverage of some code that generates an HTML form by confirming that it generates the HTML you wanted it to generate, but that's trivial. The most likely place for a flaw is in the specification -- i.e. in the HTML code which you typed into the unit tests and then typed again (perhaps with a trivial transformation) into the implementation. So my question is not how do we write code that is maximally testable, it is: does convenient testing provide sufficient benefits to outweigh the detrimental effect of making everything else inconvenient? As for the rest of the blog post: I agree with items 3-8. I would agree with item 1 with the caveat that value objects can be constructed directly, which seems to be implied by item 9 anyway. The rest of item 9, and item 2, are the topics which I have been discussing here and on the wiki. Regarding item 10: certainly separation of concerns is a fundamental principle, but there are degrees of separation, and I don't think I would go quite as far as requiring every method in a class to use every field that the class defines. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
