Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
On Fri, Apr 26, 2013 at 9:42 AM, James Forrester jforres...@wikimedia.org wrote: The report a problem link sends the report privately to a Parsoid server. From your video, it appears that the API call to do so failed - could you file a Bugzilla item with more details so we can investigate? It's sending information to parsoid.wmflabs.org, and for now that's intended behavior. We may change the way this information is collected later, but for now it lives on labs, where the Parsoid developers collect and analyze the information. Even though Lukas's video shows a failed XHR request in the console, the data was most likely submitted successfully. This is because we use cross-domain AJAX to POST the data, and jQuery's attempt to read the response (which is empty anyway) is blocked because of same-origin restrictions, which causes the error you're seeing. At this point the information has already been submitted, though, so the error is a red herring. This behavior is clearly suboptimal and misleading, but it's a minor issue at this point. It's tracked as https://bugzilla.wikimedia.org/show_bug.cgi?id=42974 . Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
On Fri, Apr 26, 2013 at 11:37 AM, Claudia Müller-Birn c...@inf.fu-berlin.de wrote: Hi James, Thanks for clarifying. I am just wondering why the two feedback mechanisms send to different targets which I personally find a bit confusing. What has been the decision behind it? They are different feedback mechanisms with different privacy expectations. The Leave feedback flow collects general, free-form feedback about the editor and posts it publicly. Only the text the user types into the form is collected and published. The Something is wrong flow is intended to collect data about cases where users see a diff they don't expect. It collects a lot of information to help us figure out what happened and why; this not only helps us find bugs, but it also collects the information we need to track it down and fix it. Because the information collected includes the text the user was attempting to save but apparently chose not to save, we treat it as private information. So one flow collects general feedback and the text field is all we collect, whereas the other collects data about a specific failure and the text field just serves as a footnote on a lot of technical data we collect along with it and is narrowly focused on the specific problem at hand: what did the user do to trigger the bug. In the general feedback flow, we communicate to the user that what they submit will be public, and it's very easy to explain what will be public (the text they put into the field). In the bad diff report flow, the data we collect (editor contents with an unsubmitted edit, among other things) is a bit more privacy-sensitive and it's hard to explain to the user what we'll be collecting. And why is the Something is wrong or Etwas ist schief gelaufen a privately sent feedback? Wouldn't be great to have here an open process and not sending the feedback to a black hole? This flow is mostly for reporting bugs, and the form asks them to provide details about the specific bug they encountered rather than general feedback. These comments wouldn't be particularly useful without the associated debugging data. The debugging data isn't particularly interesting to the general public, only to developers (that's not an argument for why it shouldn't be public, just one for why it doesn't hurt too much that it's not public). We feel like it would be against the spirit if not the letter of the privacy policy to publish this data without telling the user what we're publishing (especially since unsaved editor contents are privacy-sensitive: there is no expectation they'll be published because they're unsaved). But it's also difficult to explain to the user what exactly it is that we would be publishing. Contrary to the confusion and other reports on this thread, I can assure you that the data submitted through the Report problem interface isn't sent to a black hole. It's being collected by the Parsoid team, and they have in the recent past analyzed it and discovered bugs in both Parsoid and VE. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
On Fri, Apr 26, 2013 at 3:05 PM, Lukas Benedix bene...@zedat.fu-berlin.de wrote: I'm not a non-tech-user, but I don't like using bugzilla. here is the new bug: https://bugzilla.wikimedia.org/47755 Per my earlier post, I've closed that bug as INVALID (as feedback collection does actually work), with a reference to the bug for making it less sketchy. There are lines marked as changed in the diff that I never touched: http://lbenedix.monoceres.uberspace.de/screenshots/tlv5b64zcj_(2013-04-26_23.41.46).png http://lbenedix.monoceres.uberspace.de/screenshots/tlv5b64zcj_%282013-04-26_23.41.46%29.png Is this a (known) bug? Not that I'm aware of. Looks like a bug in reference serialization. Could you tell me which page you were editing there? Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
Le 2013-04-26 17:17, Gerard Meijssen a écrit : Hoi, Why use such an old browser and why should anybody care if it works ... Current version of Firefox is 20.0.1 Thanks, Gerard Because that's the version which is installed on one of the workstation I use and for which I have no required privileges to install anything else. We should care because we care about all potential contributors, and we don't want to make discrimination based on gender, sexual orientation nor the browser available to them. On 26 April 2013 14:52, Mathieu Stumpf psychosl...@culture-libre.orgwrote: Le 2013-04-26 14:19, Bartosz Dziewoński a écrit : It's currently disabled on IE9 and Opera. You can test it on them by using the ?vewhitelist=1 parameter (but don't expect much). I'm currently working on Opera support myself (as a volunteer). I'm using firefex 8.0.1. It works with the parameter work around. By the way, is there some roadmap somewhere for this specific extension? It looks like there's not yet feature to edit tables and I would be interested to know what's planed on this subject. 2013/4/26, Mathieu Stumpf psychosl...@culture-libre.org**: Le 2013-04-25 19:09, James Forrester a écrit : On 18 April 2013 17:32, James Forrester jforres...@wikimedia.org wrote: TL;DR: VisualEditor will be deployed on 14 new Wikipedias next week as an opt-in alpha. Your assitance is requested to inform your wikis about this and help get the software translated. This is now done (for de, nl, fr, it, ru, es, sv, pl, ja, ar, he, hi, ko, and zh). Grateful for feedback, bug reports and suggestions of how we can improve the VisualEditor for you. I opted in, but I can't see anything else than the classical edit option. I tryed on severa pages I never visited before and also to refresh my browser cache, but steal no new option. Is there a URL param I could try to see if it at least it works this way? -- Association Culture-Libre http://www.culture-libre.org/ __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Association Culture-Libre http://www.culture-libre.org/ __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Association Culture-Libre http://www.culture-libre.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSoC 2013 Proposal - jQuery.IME extensions for Firefox and Chrome
Hello, I have drafted a proposal for my GSoC Project: jQuery.IME extensions for Firefox and Chrome. I would love to hear what you think about it. I would really appreciate any kind of feedback and suggestions. Please let me know if I can improve it in any way. My proposal can be found here: http://www.mediawiki.org/wiki/User:Prageck/GSoC_2013_Application Thanks, Praveen Singh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC 2013 Proposal - jQuery.IME extensions for Firefox and Chrome
Interesting proposal. I would imagine that this does not impact most page-views since Js files are cached. It might be better to fix this bug by a tighter integration of the JavaScript with the Resource loader to lazy load the required elements as needed In such a case the solution would be less dependent on browser plugins and Would require less long term maintenance when the Js is updated On Apr 29, 2013, at 12:09, Praveen Singh prag...@gmail.com wrote: Hello, I have drafted a proposal for my GSoC Project: jQuery.IME extensions for Firefox and Chrome. I would love to hear what you think about it. I would really appreciate any kind of feedback and suggestions. Please let me know if I can improve it in any way. My proposal can be found here: http://www.mediawiki.org/wiki/User:Prageck/GSoC_2013_Application Thanks, Praveen Singh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Developing a GSoC Idea - Visual Editor
Hi, My idea of contribution to Visual Editor is in a very naive state and I don't know whether it will in full feature state before the deadline of GSoC this year. Sorry for being late. -- At the time, we are focusing at giving the users a real time, true 'visual' experience of editing on Wikipedia, It is also necessary to make sure that the editing speed and flexibility offered by the tools is maintained. If it takes too much time to perform an edit, structure the paragraph or switch between tools would eventually hamper the interest of editor especially in case of writing long article. I had previously worked on a VIM type text area which enabled users to edit text in VIM mode (the popular text) editor, and thereby increasing the speed of editing and maintaining the text. I was hoping of a similar integration with Visual Editor. I hope a major improvement to this idea can be done which can offer enhancement to regular contributors of Wikipedia. Also, if there is anything extra (and I believe there is) which can be added to this very naive idea to create something universal and better. If there exists already any extension upon which it can be build upon, please let us know. Thanks! -- Vivek Rai B.Tech First Year Undergraduate IIT Kharagpur Contact - 8013291569 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, 2013-04-29 at 03:00 +, reporter wrote: Reports marked FIXED : 908 This number is obviously wrong, and I don't know yet why. It should be around 200 instead. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
On 27 April 2013 09:25, David Gerard dger...@gmail.com wrote: On 26 April 2013 15:42, K. Peachey p858sn...@gmail.com wrote: On Fri, Apr 26, 2013 at 11:23 PM, Lukas Benedix bene...@zedat.fu-berlin.de wrote: You can share your feedback on https://www.mediawiki.org/wiki/Project:VisualEditor/Feedback but 'visual editor' - 'review and save' - 'something is wrong' - 'report problem' is not working for me. You can report it straight into Bugzilla, As mentioned at the top of that page. Here is the direct link https://bugzilla.wikimedia.org/enter_bug.cgi?product=VisualEditorcomponent=General That doesn't quite address the issue: surely it's a problem if it's claiming to take feedback but the feedback is going nowhere. (I've been trying it and flagging seriously buggy behaviour in said comment form, and would be most annoyed to find it was just being flushed.) Could someone please clarify: When you use the visual editor, and it makes weird changes in the diff, and you click there's a problem and note this in the feedback form - where does this end up? Does anyone look at it? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
Am Mo 29.04.2013 10:09, schrieb Mathieu Stumpf: We should care because we care about all potential contributors, and we don't want to make discrimination based on gender, sexual orientation nor the browser available to them. SCNR: The VisualEditor is not working in IE6, which is used by 25%* of the chinese internet user… * [http://www.ie6countdown.com/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
On 04/29/2013 03:34 PM, David Gerard wrote: On 27 April 2013 09:25, David Gerard dger...@gmail.com wrote: ... That doesn't quite address the issue: surely it's a problem if it's claiming to take feedback but the feedback is going nowhere. (I've been trying it and flagging seriously buggy behaviour in said comment form, and would be most annoyed to find it was just being flushed.) Could someone please clarify: When you use the visual editor, and it makes weird changes in the diff, and you click there's a problem and note this in the feedback form - where does this end up? Does anyone look at it? Hi David, As Roan clarified in his emails on this thread, the debugging data collected is sent to the Parsoid server and is stored there. We (the Parsoid team) do look at it and use that for debugging and fixing bugs. Thanks, Subbu. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
On 29 April 2013 12:01, Subramanya Sastry ssas...@wikimedia.org wrote: As Roan clarified in his emails on this thread, the debugging data collected is sent to the Parsoid server and is stored there. We (the Parsoid team) do look at it and use that for debugging and fixing bugs. Cool, thank you :-) Every time I've used it lately, it's messing with the ref tags. Just now I literally moved a comma and it decided messing with the ref tags would be just the thing to do ... - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC / OPW mentors README
On Sun, Apr 28, 2013 at 1:58 AM, Quim Gil q...@wikimedia.org wrote: There is more good reading at https://www.mediawiki.org/** wiki/Mentorship_programs/**Possible_mentorshttps://www.mediawiki.org/wiki/Mentorship_programs/Possible_mentors I am listed as a mentor at Outreach Program for Women[1] page, but not at Possible mentors page. Who maintains the list? Should I add myself to the list? Željko -- 1: https://www.mediawiki.org/wiki/OPW#Browser_Test_Automation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, Apr 29, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: Reports changed/set to RESOLVED : 1015 Is this one correct? It is usually 200-300. Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, Apr 29, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: MediaWiki Bugzilla Report for April 22, 2013 - April 29, 2013 Fresh charts: https://www.mediawiki.org/wiki/Bugzilla_Weekly_Report Reports changed/set to RESOLVED : 1015 Reports marked FIXED : 908 Looks like these are borken. I have included them in the graphs, of course, just for fun. :) I will update the graphs as soon as correct data is available. Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, 2013-04-29 at 14:15 +0200, Željko Filipin wrote: On Mon, Apr 29, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: Reports changed/set to RESOLVED : 1015 Is this one correct? It is usually 200-300. Same problem, should be 284: https://bugzilla.wikimedia.org/buglist.cgi?chfieldto=2013-04-29%203%3A00chfield=bug_statuschfieldfrom=2013-04-22%203%3A00chfieldvalue=RESOLVED Sigh. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, Apr 29, 2013 at 3:04 PM, Andre Klapper aklap...@wikimedia.orgwrote: Same problem, should be 284: Do you know the correct number for FIXED, so I can fix both charts? Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC / OPW mentors README
On 04/29/2013 04:55 AM, Željko Filipin wrote: On Sun, Apr 28, 2013 at 1:58 AM, Quim Gil q...@wikimedia.org wrote: There is more good reading at https://www.mediawiki.org/** wiki/Mentorship_programs/**Possible_mentorshttps://www.mediawiki.org/wiki/Mentorship_programs/Possible_mentors I am listed as a mentor at Outreach Program for Women[1] page, but not at Possible mentors page. Who maintains the list? Should I add myself to the list? Yes, sorry. This is the first time we are doing GSoC and OPW together and we still have glitches like this one. The current '''CONFIRMED''' tag has been added with GSoC mentors in mind, since they need to register to the GSoC site. OPW-only mentors like you can just add themselves to the list. It's not 100% precise but good enough for this round. We will do better in the next one. :) -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing a GSoC Idea - Visual Editor
Hi Vivek, On 04/29/2013 02:56 AM, Vivek Rai wrote: Hi, My idea of contribution to Visual Editor is in a very naive state and I don't know whether it will in full feature state before the deadline of GSoC this year. Sorry for being late. There are still several days to go before the deadline. We have already some VisualEditor related proposals at https://www.mediawiki.org/wiki/Summer_of_Code_2013#Confirmed_candidates . The VE team is small and busy, and there is just so many projects they will be able to take (regardless of the amount of slots Google gives us). If someone wants to propose a VE related project you need to aim for something better / sharper than the existing proposals. At the time, we are focusing at giving the users a real time, true 'visual' experience of editing on Wikipedia, It is also necessary to make sure that the editing speed and flexibility offered by the tools is maintained. If it takes too much time to perform an edit, structure the paragraph or switch between tools would eventually hamper the interest of editor especially in case of writing long article. I had previously worked on a VIM type text area which enabled users to edit text in VIM mode (the popular text) editor, and thereby increasing the speed of editing and maintaining the text. I was hoping of a similar integration with Visual Editor. I hope a major improvement to this idea can be done which can offer enhancement to regular contributors of Wikipedia. Also, if there is anything extra (and I believe there is) which can be added to this very naive idea to create something universal and better. If there exists already any extension upon which it can be build upon, please let us know. Well, at least my problem is that I don't get what feature(s) are you proposing. You are encouraged to draft a more specific plan in a wiki page. See http://www.mediawiki.org/wiki/Summer_of_Code_2013#Where_to_start and http://lists.wikimedia.org/pipermail/wikitech-l/2013-April/068842.html for general advice. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Countdown to SSL for all sessions?
Just curious -- what's the state of forcing HTTPS for all user sessions? It's simple common sense at this point to protect all our users from session hijacking on local networks or MITM attacks. I see some Gerrit activity on adding preferences or special groups for HTTPS, which seems a horrid practice when we could just protect everyone... -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Countdown to SSL for all sessions?
On 29 April 2013 09:12, Brion Vibber bvib...@wikimedia.org wrote: Just curious -- what's the state of forcing HTTPS for all user sessions? It's simple common sense at this point to protect all our users from session hijacking on local networks or MITM attacks. Now a bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 (how did we not have one already?). I see some Gerrit activity on adding preferences or special groups for HTTPS, which seems a horrid practice when we could just protect everyone... Agreed; this was a nice idea back in the day when SSL was expensive, but now… J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC / OPW mentors README
More about this: On 04/27/2013 04:58 PM, Quim Gil wrote: SELECTING CANDIDATES After the deadline we will meet to prioritize GSoC and OPW candidates. The first step is to tell Google before May 6 (quoting): #amazing proposals The amount of amazing proposals submitted to this organization that have a mentor assigned and the organization would _really_ like to have a slot for. #desired slots The amount of slots that this organization would like to receive if there was an unlimited amount of slots available. This is how we can define these numbers: #amazing proposals: * Must have at least 2 people wishing-to-mentor in the GSoC site. * At least one co-mentor must tell explicitly in the private comments of the GSoC that this proposal is his primary bet. * Double check this Friday with teams acting as umbrella for different proposals e.g. Language, Wikidata, VisualEditor to identify the amazing proposals within their scope. #desired slots * All of the above plus those proposals that have done all the homework well and have 1-2 free mentors. Google doesn't give much time to define these numbers: the deadline for submissions is this Friday May 3, and the numbers must be defined by Monday May 6. I hope to resolve all questions by the end of Friday, but in any case watch your mailboxes during the weekend. I will submit the numbers during Sunday, latest. We will get the answer from Google on Wednesday 8. Then we will ave more time to allocate projects to slots. OPW selection will depend on this process, so no moves are needed before May 8. * If you have more than one candidate be ready to prioritize them. One mentor can take only one project, unless there is a good justification for taking two (e.g. strong co-mentors in both). * Read also the rest of proposals and pencil your own ranking with a Wikimedia / MediaWiki wide agenda in mind. * Be ready to negotiate the place of your candidates in the general ranking. In other words, don't push blindly for your proposals. Needless to say, you must read the official GSoC manual for mentors: http://en.flossmanuals.net/GSoCMentoring/ There is more good reading at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_mentors If you are a good mentor your know that 20 minutes reading docs can save you a lot more time and energies. ;) -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Countdown to SSL for all sessions?
On Mon, Apr 29, 2013 at 9:12 AM, Brion Vibber bvib...@wikimedia.org wrote: Just curious -- what's the state of forcing HTTPS for all user sessions? It's simple common sense at this point to protect all our users from session hijacking on local networks or MITM attacks. I see some Gerrit activity on adding preferences or special groups for HTTPS, which seems a horrid practice when we could just protect everyone... A handful of people have made comments that they really want the option to not use HTTPS. And in MediaWiki, some sites may still be concerned about the performance. So I think the question is in MediaWiki, do we want to support sites that allow users to disable SSL after login (which is the current use of $wgSecureLogin)? If not, we can alter the functionality to make it force all logged in sessions to use SSL. If so, is that something the WMF wants to enable (https://bugzilla.wikimedia.org/show_bug.cgi?id=39380), or do we want another flag ($wgReallySuperSecureLogin) that forces sessions into SSL? Personally, I think giving users safe defaults, but the option to shoot themselves *often* is the most secure option, because most users will use the secure defaults, and people who want another option will go to great, ugly lengths to circumvent your feature. This is the direction I've been working towards, but if there is strong support for another option, I'm happy to adjust. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Countdown to SSL for all sessions?
On Mon, Apr 29, 2013 at 9:40 AM, Chris Steipp cste...@wikimedia.org wrote: Personally, I think giving users safe defaults, but the option to shoot themselves *often* is the most secure option, because most users will use the secure defaults, and people who want another option will go to great, ugly lengths to circumvent your feature. This is the direction I've been working towards, but if there is strong support for another option, I'm happy to adjust. I think is sane as well. You see similar patterns from products like Gmail, which have a preference to not use HTTPS all the time. In the meantime, the new login form from our team detects whether the user is on the HTTPS connection, and embeds a link at the top of the form if you're not. Hopefully this will encourage more people to use it. Steven ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Countdown to SSL for all sessions?
Some relevant info: Here's the Gerrit change implementing the user preference - https://gerrit.wikimedia.org/r/47089 Also, $wgSecureLogin was deployed once to WMF wikis, but apparently a bug occurred that was not present on my test environment. Once we figure out what the source of that issue is, at the very least we can take the first step and have secure login. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Countdown to SSL for all sessions?
On Mon, Apr 29, 2013 at 9:55 AM, Tyler Romeo tylerro...@gmail.com wrote: Some relevant info: Here's the Gerrit change implementing the user preference - https://gerrit.wikimedia.org/r/47089 Also, $wgSecureLogin was deployed once to WMF wikis, but apparently a bug occurred that was not present on my test environment. Once we figure out what the source of that issue is, at the very least we can take the first step and have secure login. Using $wgSecureLogin with CentralAuth, if a global account logged in and unchecked the box to continue using SSL, then SUL didn't correctly log them in. This has been fixed in some of the updates to SUL that we're working on right now (https://www.mediawiki.org/wiki/Auth_systems/SUL2). *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ 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] Countdown to SSL for all sessions?
On Mon, Apr 29, 2013 at 12:59 PM, Chris Steipp cste...@wikimedia.orgwrote: Using $wgSecureLogin with CentralAuth, if a global account logged in and unchecked the box to continue using SSL, then SUL didn't correctly log them in. This has been fixed in some of the updates to SUL that we're working on right now (https://www.mediawiki.org/wiki/Auth_systems/SUL2). Aha. I figured it had something to do with CentralAuth or another extension. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project Idea
On 26/04/13 22:23, Kiran Mathew Koshy wrote: Hi guys, I have an own idea for my GSoC project that I'd like to share with you. Its not a perfect one, so please forgive any mistakes. The project is related to the existing GSoC project *Incremental Data dumps * , but is in no way a replacement for it. *Offline Wikipedia* For a long time, a lot of offline solutions for Wikipedia have sprung up on the internet. All of these have been unofficial solutions, and have limitations. A major problem is the* increasing size of the data dumps*, and the problem of *updating the local content. * Consider the situation in a place where internet is costly/ unavailable.(For the purpose of discussion, lets consider a school in a 3rd world country.) Internet speeds are extremely slow, and accessing Wikipedia directly from the web is out of the question. Such a school would greatly benefit from an instance of Wikipedia on a local server. Now up to here, the school can use any of the freely available offline Wikipedia solutions to make a local instance. The problem arises when the database in the local instance becomes obsolete. The client is then required to download an entire new dump(approx. 10 GB in size) and load it into the database. Another problem that arises is that most 3rd part programs *do not allow network access*, and a new instance of the database is required(approx. 40 GB) on each installation.For instance, in a school with around 50 desktops, each desktop would require a 40 GB database. Plus, *updating* them becomes even more difficult. Well, some programs allow network access, and even if not, the school should download once, and distribute from there to the desktops, not downloading once per installation. But I agree having a copy on each computer could be problematic. So here's my *idea*: Modify the existing MediaWiki software and to add a few PHP/Python scripts which will automatically update the database and will run in the background.(Details on how the update is done is described later). Initially, the MediaWiki(modified) will take an XML dump/ SQL dump (SQL dump preferred) as input and will create the local instance of Wikipedia. Later on, the updates will be added to the database automatically by the script. Actually, you only need to add some scripts, not to modify mediawiki :) The installation process is extremely easy, it just requires a server package like XAMPP and the MediaWiki bundle. Process of updating: There will be two methods of updating the server. Both will be implemented into the MediaWiki bundle. Method 2 requires the functionality of incremental data dumps, so it can be completed only after the functionality is available. Perhaps I can collaborate with the student selected for incremental data dumps. Method 1: (online update) A list of all pages are made and published by Wikipedia. This can be in an XML format. The only information in the XML file will be the page IDs and the last-touched date. This file will be downloaded by the MediaWiki bundle, and the page IDs will be compared with the pages of the existing local database. This is available in page.sql.gz case 1: A new page ID in XML file: denotes a new page added. case 2: A page which is present in the local database is not among the page IDs- denotes a deleted page. case 3: A page in the local database has a different 'last touched' compared to the one in the local database- denotes an edited page. (here you would compare the revision id) In each case, the change is made in the local database and if the new page data is required, the data is obtained using MediaWiki API. These offline instances of Wikipedia will be only used in cases where the internet speeds are very low, so they *won't cause much load on the servers* . method 2: (offline update): (Requires the functionality of the existing project Incremental data dumps): In this case, the incremental data dumps are downloaded by the user(admin) and fed to the MediaWiki installation the same way the original dump is fed(as a normal file), and the corresponding changes are made by the bundle. Since I'm not aware of the XML format used in incremental updates, I cannot describe it now. Advantages : An offline solution can be provided for regions where internet access is a scarce resource. this would greatly benefit developing nations , and would help in making the world's information more free and openly available to everyone. All comments are welcome ! Some work on improving the import scripts would be welcome, although I wonder if what you propose would be big enough for GSoC. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC 2013 Proposal - jQuery.IME extensions for Firefox and Chrome
Hi Oren, Thanks for the feedback. If I have got your point correctly, then the browser extensions would not impact or slow down the page loading. My project scope does include on demand loading of the input methods, but I am not very sure how to go about integrating Resource Loader with the browser extensions. As far as I know, Resource Loader can only be used on MediaWiki enabled websites whereas the project aims at providing these input methods on any website. Let me know what you think of it. Regards, Praveen Singh On Mon, Apr 29, 2013 at 3:15 PM, oren bochman orenboch...@gmail.com wrote: Interesting proposal. I would imagine that this does not impact most page-views since Js files are cached. It might be better to fix this bug by a tighter integration of the JavaScript with the Resource loader to lazy load the required elements as needed In such a case the solution would be less dependent on browser plugins and Would require less long term maintenance when the Js is updated On Apr 29, 2013, at 12:09, Praveen Singh prag...@gmail.com wrote: Hello, I have drafted a proposal for my GSoC Project: jQuery.IME extensions for Firefox and Chrome. I would love to hear what you think about it. I would really appreciate any kind of feedback and suggestions. Please let me know if I can improve it in any way. My proposal can be found here: http://www.mediawiki.org/wiki/User:Prageck/GSoC_2013_Application Thanks, Praveen Singh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias
On Mon, Apr 29, 2013 at 4:36 AM, David Gerard dger...@gmail.com wrote: Cool, thank you :-) Every time I've used it lately, it's messing with the ref tags. Just now I literally moved a comma and it decided messing with the ref tags would be just the thing to do ... Yeah, sorry about that :( . There was a bug where Parsoid duplicated ref tags; Lukas's screenshot showed that too. The Parsoid team deployed a fix for this just now, so the duplication bug should be fixed now. There are rumors of other issues with ref tags, we're looking into those still. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSoC Proposal :Jquery.IME improvements
Hi Everyone, After unsuccessfully editing the proposal template wiki I have finally made a very crude draft of my proposal. http://www.mediawiki.org/wiki/User:Diadara536/GSoC Comments are welcome and appreciated Nithin Saji (diadara on freenode) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Pre-Release Announcement for MediaWiki 1.19.6 and 1.20.5
This is a notice that on Tuesday, April 30th between 20:00-21:00 UTC (1-2pm PDT) Wikimedia Foundation will release security updates for current and supported branches of the MediaWiki software. Downloads and patches will be available at that time, with the git repositories updated later that afternoon. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Special Tech Talk: Big Data Tools
This week we have a Tech Talk special edition: Big Data Tools by David Schoonover May 1, 19:30 UTC / 12:30 PDT Overview of the big data tools we have available at the Wikimedia Foundation. We'll be writing real queries to explore real data from the mobile site! More details and timezones at http://www.mediawiki.org/wiki/Meetings/2013-05-01 -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC2013/OPW Proposal: VisualEditor RTL Support
On 28 April 2013 13:04, Moriel Schottlender mor...@gmail.com wrote: Hello everyone, This is my second attempt for a proposal, but I think this is a project that is *much* better than my previous one, and has a much bigger demand. I'd love to work on this as a GSoC project! Before I submit this as an official proposal, I'd like to ask for your thoughts about this. The proposal concentrates on adding RTL support to VisualEditor, especially based on this requirements/spec page: https://www.mediawiki.org/wiki/VisualEditor/Bidirectional_text_requirements Hebrew is my maiden language, and I'm familiar with a lot of the problems that are raised when using RTL, especially when using it alongside a mix of LTR and RTL languages. A first draft of this proposal is available here: http://www.mediawiki.org/wiki/User:Mooeypoo/GSOC_2013_Proposal:_RTL_Support_in_VisualEditor I have experience with Javascript and jQuery, and I'm working on some Windows8 Metro apps as side projects, which rely heavily on javascript and html5. However, this is my first time applying for GSoC and it's my first time contributing to such a big project as MediaWiki and VisualEditor :) I'd love to hear your thoughts, ideas and feedback! Thank you again, Moriel Schottlender Moriel, Thank you for your proposal. It's a hugely-important area for us, and having someone come forward to work on it is very welcome. (As Amir puts it, getting [RTL support] done by a person who knows an RTL language is obviously preferable.) It would be really excellent to have you work on this. That said, I worry that this wouldn't be an ideal fit for Google Summer of Code. The project as a project is as stand-alone as they recommend, and would involve getting very deep into the intricacies of how the ContentEditable area of VisualEditor works. This would be a huge amount for you to learn - less a learning hill and more a cliff, and right now this area of the code is changing quite a lot so it would be difficult to work in RTL changes. Inez (copied), who's one of our ContentEditable leads, has said he'd be keen to mentor you on this, and I'd love to co-mentor. There's also the issue that this is frankly stuff we should be getting right already. :-) It would be hard for you to own the result as much, and it would be difficult to schedule the work into a timetable as Google suggests - as we added new features, we would no-doubt extend your work on indefinitely, and it would be hard to find the point where you were done. If you're worried about ownership and lack of scope, improving language support in the VisualEditor starts but does not end with the core RTL support outlined in that document. There are a number of things that you might wish to also do, like add a language inspector that would let a user tag a section of the page they're editing as in a language (for multi-lingual wikis). Just as a reminder, you should put this forward into the GSoC system (at https://google-melange.appspot.com/gsoc/dashboard/google/gsoc2013 ) as soon as possible. Happy to answer any questions you have! Yours, -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSoC Application
https://www.mediawiki.org/wiki/User:Aayush251/gsoc Please review my GSoC application. -- Aayush Sharma aayush.sha...@studentpartner.com Skype : aayush251 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki API 2.0 (was GSoC Application)
On 04/29/2013 02:18 PM, Aayush Sharma wrote: https://www.mediawiki.org/wiki/User:Aayush251/gsoc Please review my GSoC application. Hi Aayush, please write more specific emails in a mailing list. It will help getting more people looking at your proposal. You could also have pasted the summary here, so people can have a look and decide whether they want to check more or not. For instance, in your proposal you say GSoC Project Idea: MediaWiki API 2.0 I will be working and modifying MediaWiki API to solve the following problems: * Avoiding client to update every time API changes * Developers will develop extensions from the single default API (recommended). * Reduce the cost of making a change in MediaWiki. * Organize feature changes - if the client asks for ver X, API guarantees the capabilities of X and result in format X. * Avoid cluttering of parameters. * All API capabilities should return only the data requested to minimize bandwidth and improve speed. Good luck! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Offline Wikipedia (was GSoC Project)
On 04/26/2013 01:27 PM, Kiran Mathew Koshy wrote: Hi guys, I have an own idea for my GSoC project that I'd like to share with you. Its not a perfect one, so please forgive any mistakes. The project is related to the existing GSoC project *Incremental Data dumps * , but is in no way a replacement for it. *Offline Wikipedia* There is not much time left and we would still need to find mentors for this proposal. Still, you are encouraged to follow the process ad submit your proposal as described at https://www.mediawiki.org/wiki/Mentorship_programs/Application_template Good luck! PS: same advice as we have given to other students: please be more specific in the subject of your emails to mailing lists. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC2013/OPW Proposal: VisualEditor RTL Support
James Forrester jforrester at wikimedia.org writes: On 28 April 2013 13:04, Moriel Schottlender moriel at gmail.com wrote: Hello everyone, This is my second attempt for a proposal, but I think this is a project that is *much* better than my previous one, and has a much bigger demand. I'd love to work on this as a GSoC project! Before I submit this as an official proposal, I'd like to ask for your thoughts about this. The proposal concentrates on adding RTL support to VisualEditor, especially based on this requirements/spec page: https://www.mediawiki.org/wiki/VisualEditor/Bidirectional_text_requirements Hebrew is my maiden language, and I'm familiar with a lot of the problems that are raised when using RTL, especially when using it alongside a mix of LTR and RTL languages. A first draft of this proposal is available here: http://www.mediawiki.org/wiki/User:Mooeypoo/GSOC_2013_Proposal:_RTL_Support_ in_VisualEditor I have experience with Javascript and jQuery, and I'm working on some Windows8 Metro apps as side projects, which rely heavily on javascript and html5. However, this is my first time applying for GSoC and it's my first time contributing to such a big project as MediaWiki and VisualEditor :) I'd love to hear your thoughts, ideas and feedback! Thank you again, Moriel Schottlender Moriel, Thank you for your proposal. It's a hugely-important area for us, and having someone come forward to work on it is very welcome. (As Amir puts it, getting [RTL support] done by a person who knows an RTL language is obviously preferable.) It would be really excellent to have you work on this. That said, I worry that this wouldn't be an ideal fit for Google Summer of Code. The project as a project is as stand-alone as they recommend, and would involve getting very deep into the intricacies of how the ContentEditable area of VisualEditor works. This would be a huge amount for you to learn - less a learning hill and more a cliff, and right now this area of the code is changing quite a lot so it would be difficult to work in RTL changes. Inez (copied), who's one of our ContentEditable leads, has said he'd be keen to mentor you on this, and I'd love to co-mentor. There's also the issue that this is frankly stuff we should be getting right already. It would be hard for you to own the result as much, and it would be difficult to schedule the work into a timetable as Google suggests - as we added new features, we would no-doubt extend your work on indefinitely, and it would be hard to find the point where you were done. If you're worried about ownership and lack of scope, improving language support in the VisualEditor starts but does not end with the core RTL support outlined in that document. There are a number of things that you might wish to also do, like add a language inspector that would let a user tag a section of the page they're editing as in a language (for multi-lingual wikis). Just as a reminder, you should put this forward into the GSoC system (at https://google-melange.appspot.com/gsoc/dashboard/google/gsoc2013 ) as soon as possible. Happy to answer any questions you have! Yours, -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester at wikimedia.org | at jdforrester ___ Wikitech-l mailing list Wikitech-l at lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi again, James, thank you very much for your answer and thoughtful points. I have to admit, I had a feeling this may be something that's not as easy as it sounds. However, I am *more* than ready for the challenge. I am pretty confident with jQuery and general Javascript, and I consider myself a quick learner. But more than everything, I think I can get into the project if I have a bit of help pointing me in the right direction. The issue of the changing code may be a bigger problem, though; I want to make sure I contribute something beneficial -- do you think it is possible to work on a project that serves as groundwork for later improvement? If we know in advance the code is going through changes, perhaps I can work on a more flexible addition that can be adapted slightly to changes in the underlying system. It's hard for me to recommend the proper strategy at the moment, but I am wondering if this may be a good idea to add or think about when working on the project. I'd love to be able to work on this project, and I think that with a bit of planning, we may be able to find a strategy that can work despite the changing and updating code. Do you think it's realistic? Regarding ownership etc, I want to contribute and help the project regardless. GSoC is simply an awesome entry-point to help me get into the process with the help of a mentor and an organized project, so I'd like to try and see if I can join through
[Wikitech-l] project idea for wikimedia
I am a 3rd year student doing graduation on computer science and engineering in a public engineering university in Bangladesh. this year i have developed a project on constitution of Bangladesh. where i used XML parsing technique. i want to develop an application for android device which can give an user friendly environment to read, share, modify articles directly from an android handset. does this contribute any good? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project
Dear Kiran Before commenting your proposal, let me thank: * Quim for having renamed this thread... I wouldn't have got a chance to read it otherwise. * Gnosygnu and Sumana for their previous answers. Your emails points three problems: (1) The size of the offline dumps (2) Server mode of the offline solution (3) The need of incremental updates Regarding (1), I disagree. We have the ZIM format which is open, has an extremly efficient standard implementation, provides high compression rates and fast random access: http://www.openzim.org Regarding (2), Kiwix, which is a ZIM reader, already does it: you can either share Kiwix on a network disk or use Kiwix HTTP compatible daemon called kiwix-serve: http://www.kiwix.org/wiki/Kiwix-serve Regarding (3), I agree. This is an old feature request in the openZIM project. It's both on the roadmap and in the bug tracker: * http://www.openzim.org/wiki/Roadmap * https://bugzilla.wikimedia.org/show_bug.cgi?id=47406 But, I also think the solution you propose isn't adapted to the problem. Setting up a Mediawiki is not easy, it's resource intensive and you don't need all this power (of the software setup) for the usage you want to do. On the other side, with ZIM you have a format which provides all what you need, runs on devices which costs only a few dozens of USD and we will make this incremental update trivial for the final user (it's just a matter of time ;). So to fix that problem, there is my approach: we should implement two tools I call zimdiff and zimpatch: * zimdiff is a tool able to compute the difference between two ZIM files * zimpatch is a tool able to patch a ZIM file with a ZIM diff file The incrementation process would be: * Compute a ZIM diff file (done by the ZIM provider) * Download and path the old ZIM file with the ZIM diff file (done by the user) We could implement two modes for zimpatch, leasy and normal: * leasy mode: simple merge of the file and rewriting of the index (fast but need a lot of mass storage) * normal mode: recompute a new file (slow but need less mass storage) Regarding the ZIM diff file format... the discussion is open, but it looks like we could simply reuse the ZIM format and zimpatch would work like a zimmerge (does not exist, it's just for the explanation). Everything could be done IMO in only a few hundreds of smart lines of C++. I would be really surprised if this need more than 2000 lines. But, to do that, we need a pretty talentuous C++ developer, maybe you? If your or someone else is interested we would probably be able to find a tutor. Kind regards Emmanuel PS: Wikimedia has an offline centric mailing list, let me add it in CC: https://lists.wikimedia.org/mailman/listinfo/offline-l Le 26/04/2013 22:27, Kiran Mathew Koshy a écrit : Hi guys, I have an own idea for my GSoC project that I'd like to share with you. Its not a perfect one, so please forgive any mistakes. The project is related to the existing GSoC project *Incremental Data dumps * , but is in no way a replacement for it. *Offline Wikipedia* For a long time, a lot of offline solutions for Wikipedia have sprung up on the internet. All of these have been unofficial solutions, and have limitations. A major problem is the* increasing size of the data dumps*, and the problem of *updating the local content. * Consider the situation in a place where internet is costly/ unavailable.(For the purpose of discussion, lets consider a school in a 3rd world country.) Internet speeds are extremely slow, and accessing Wikipedia directly from the web is out of the question. Such a school would greatly benefit from an instance of Wikipedia on a local server. Now up to here, the school can use any of the freely available offline Wikipedia solutions to make a local instance. The problem arises when the database in the local instance becomes obsolete. The client is then required to download an entire new dump(approx. 10 GB in size) and load it into the database. Another problem that arises is that most 3rd part programs *do not allow network access*, and a new instance of the database is required(approx. 40 GB) on each installation.For instance, in a school with around 50 desktops, each desktop would require a 40 GB database. Plus, *updating* them becomes even more difficult. So here's my *idea*: Modify the existing MediaWiki software and to add a few PHP/Python scripts which will automatically update the database and will run in the background.(Details on how the update is done is described later). Initially, the MediaWiki(modified) will take an XML dump/ SQL dump (SQL dump preferred) as input and will create the local instance of Wikipedia. Later on, the updates will be added to the database automatically by the script. The installation process is extremely easy, it just requires a server package like XAMPP and the MediaWiki bundle. Process of updating: There will be two methods of updating the server. Both
[Wikitech-l] Upcoming change to section edit links
Hi all, To resolve bug 41729, patch 49364 was recently merged. This means that there's going to be a small design change for section edit links, and probably more relevant for this list, the way the HTML for them is generated will change. This is likely to break any custom gadgets, scripts or styles, etc. You can already see the change on MediaWiki.org and testwiki, if you're curious. There's pretty comprehensive documentation about this change at: https://meta.wikimedia.org/wiki/Change_to_section_edit_links Thanks, -- Steven Walling https://wikimediafoundation.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Upcoming change to section edit links
On 2013-04-29 8:01 PM, Steven Walling swall...@wikimedia.org wrote: Hi all, To resolve bug 41729, patch 49364 was recently merged. This means that there's going to be a small design change for section edit links, and probably more relevant for this list, the way the HTML for them is generated will change. This is likely to break any custom gadgets, scripts or styles, etc. You can already see the change on MediaWiki.org and testwiki, if you're curious. There's pretty comprehensive documentation about this change at: https://meta.wikimedia.org/wiki/Change_to_section_edit_links Thanks, -- Steven Walling https://wikimediafoundation.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l For future reference, if you are going to write a mail about something changing you should actually (succinctly) mention what's changing. In this case: section edit links are being moved to be right beside the headline instead of on the right of the page, and the class name is changing which may break userscripts. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] project idea for wikimedia
Hello Anurag, On 04/29/2013 03:40 PM, anurag bhattacharjee wrote: I am a 3rd year student doing graduation on computer science and engineering in a public engineering university in Bangladesh. this year i have developed a project on constitution of Bangladesh. where i used XML parsing technique. i want to develop an application for android device which can give an user friendly environment to read, share, modify articles directly from an android handset. does this contribute any good? Have you checked our Wikipedia app for Android? Our team is working already in editing features... If you are looking for GSoC ideas please check https://www.mediawiki.org/wiki/Summer_of_Code_2013 There is not much time left for submit a GSoC proposal. If you want to participate please start drafting your proposal as explained at https://www.mediawiki.org/wiki/Mentorship_programs/Application_template If you want to learn about and contribute to Wikimedia mobile projects (out of the GSoC program) check http://meta.wikimedia.org/wiki/Mobile_projects -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Countdown to SSL for all sessions?
There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically? HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1). On Mon, Apr 29, 2013 at 8:03 PM, Tyler Romeo tylerro...@gmail.com wrote: On Mon, Apr 29, 2013 at 12:59 PM, Chris Steipp cste...@wikimedia.orgwrote: Using $wgSecureLogin with CentralAuth, if a global account logged in and unchecked the box to continue using SSL, then SUL didn't correctly log them in. This has been fixed in some of the updates to SUL that we're working on right now (https://www.mediawiki.org/wiki/Auth_systems/SUL2). Aha. I figured it had something to do with CentralAuth or another extension. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ 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
[Wikitech-l] VisualEditor on wikitech.wikimedia.org
Because Faidon idly suggested that we should install VisualEditor on wikitech as a way of dogfooding, I went ahead and did it. https://wikitech.wikimedia.org/w/index.php?title=PowerDNSdiff=68284oldid=14633 is the first VE edit :) Inside baseball note: this uses the Tampa Parsoid cluster, not the one in eqiad, because the machine hosting wikitech (virt0) is in Tampa. If and when things move to eqiad we can change that. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Single User Login finalisation: some accounts will be renamed
All, The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users (like cross-wiki notifications). These changes will mean users have the same account name everywhere, will let us give you new features that will help you edit discuss better, and will allow more flexible user permissions for tools. One of the pre-conditions for this is that user accounts will now have to be unique across all 900 Wikimedia wikis.[0] Unfortunately, some accounts are currently not unique across all our wikis, but instead clash with other users who have the same account name. To make sure that all of these users can use Wikimedia's wikis in future, we will be renaming a number of accounts to have ~” and the name of their wiki added to the end of their accounts' name. This change will take place on or around 27 May. For example, a user called “Example” on the Swedish Wiktionary who will be renamed would become “Example~svwiktionary”. All accounts will still work as before, and will continue to be credited for all their edits made so far. However, users with renamed accounts (whom we will be contacting individually) will have to use the new account name when they log in. It will now only be possible for accounts to be renamed globally; the RenameUser tool will no longer work on a local basis - since all accounts must be globally unique - therefore it will be withdrawn from bureaucrats' tool sets. It will still be possible for users to ask on Meta for their account to be renamed further, if they do not like their new user name, once this takes place. A copy of this note is posted to meta [1] for translation. Please forward this to your local communities, and help get it translated. Individuals who are affected will be notified via talk page and e-mail notices nearer the time. [0] - https://meta.wikimedia.org/wiki/Help:Unified_login [1] - https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement Yours, -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Countdown to SSL for all sessions?
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selits...@gmail.comwrote: There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically? HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1). Well, with $wgSecureLogin the idea is that it is completely disallowed to log in, i.e., enter a password, over an insecure connection. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSoC 2013: UploadWizard: Book upload customization Proposal
Hi, My name is Nazmul Chowdhury, I would like to participate in the GSoC 2013, working on the UploadWizard: Book upload customization (potential mentor: MarkTraceur). My proposal can be found here: http://www.mediawiki.org/wiki/User:Rasel160. Any feedback is much appreciated. Thank You, Nazmul Chowdhury ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project
First of all, let me thank everyone who has commented on this thread. Sorry about not responding earlier. My exams are going on. You can certainly expect more response from me once they are over. On Tue, Apr 30, 2013 at 4:18 AM, Emmanuel Engelhart emman...@engelhart.orgwrote: Dear Kiran Before commenting your proposal, let me thank: * Quim for having renamed this thread... I wouldn't have got a chance to read it otherwise. * Gnosygnu and Sumana for their previous answers. Your emails points three problems: (1) The size of the offline dumps (2) Server mode of the offline solution (3) The need of incremental updates Regarding (1), I disagree. We have the ZIM format which is open, has an extremly efficient standard implementation, provides high compression rates and fast random access: http://www.openzim.org Regarding (2), Kiwix, which is a ZIM reader, already does it: you can either share Kiwix on a network disk or use Kiwix HTTP compatible daemon called kiwix-serve: http://www.kiwix.org/wiki/Kiwix-serve Regarding (3), I agree. This is an old feature request in the openZIM project. It's both on the roadmap and in the bug tracker: * http://www.openzim.org/wiki/Roadmap * https://bugzilla.wikimedia.org/show_bug.cgi?id=47406 But, I also think the solution you propose isn't adapted to the problem. Setting up a Mediawiki is not easy, it's resource intensive and you don't need all this power (of the software setup) for the usage you want to do. On the other side, with ZIM you have a format which provides all what you need, runs on devices which costs only a few dozens of USD and we will make this incremental update trivial for the final user (it's just a matter of time ;). I don't think power is much of a priority, but I agree the ZIM format would be easier, since it directly reads from the ZIM file So to fix that problem, there is my approach: we should implement two tools I call zimdiff and zimpatch: * zimdiff is a tool able to compute the difference between two ZIM files * zimpatch is a tool able to patch a ZIM file with a ZIM diff file The incrementation process would be: * Compute a ZIM diff file (done by the ZIM provider) * Download and path the old ZIM file with the ZIM diff file (done by the user) We could implement two modes for zimpatch, leasy and normal: * leasy mode: simple merge of the file and rewriting of the index (fast but need a lot of mass storage) * normal mode: recompute a new file (slow but need less mass storage) Regarding the ZIM diff file format... the discussion is open, but it looks like we could simply reuse the ZIM format and zimpatch would work like a zimmerge (does not exist, it's just for the explanation). Everything could be done IMO in only a few hundreds of smart lines of C++. I would be really surprised if this need more than 2000 lines. But, to do that, we need a pretty talentuous C++ developer, maybe you? Yes, this is a quite easy task. I can do this. I can go through the ZIM format and the zimlib library in a few days. Regarding the *zimpatch*, I think it would be better to implement both methods( although I prefer the 2nd one). The user can then select the one which he wants , depending on his configuration. Lastly, we can add the *zimdiff as an automated task in the server*. zimpatch and downloading the zim file can also be automated and added to Kiwix. If there's time left, I can port the zimlib library to python or PHP, so it becomes easier for people to hack. If you have any more suggestions, please comment. I'll submit the proposal in ~ 12 hours.(again, exams). If your or someone else is interested we would probably be able to find a tutor. Kind regards Emmanuel PS: Wikimedia has an offline centric mailing list, let me add it in CC: https://lists.wikimedia.org/mailman/listinfo/offline-l Le 26/04/2013 22:27, Kiran Mathew Koshy a écrit : Hi guys, I have an own idea for my GSoC project that I'd like to share with you. Its not a perfect one, so please forgive any mistakes. The project is related to the existing GSoC project *Incremental Data dumps * , but is in no way a replacement for it. *Offline Wikipedia* For a long time, a lot of offline solutions for Wikipedia have sprung up on the internet. All of these have been unofficial solutions, and have limitations. A major problem is the* increasing size of the data dumps*, and the problem of *updating the local content. * Consider the situation in a place where internet is costly/ unavailable.(For the purpose of discussion, lets consider a school in a 3rd world country.) Internet speeds are extremely slow, and accessing Wikipedia directly from the web is out of the question. Such a school would greatly benefit from an instance of Wikipedia on a local server. Now up to here, the school can use any of the freely available offline Wikipedia solutions to make a local instance. The problem
Re: [Wikitech-l] Countdown to SSL for all sessions?
On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo tylerro...@gmail.com wrote: On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selits...@gmail.comwrote: There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically? HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1). Well, with $wgSecureLogin the idea is that it is completely disallowed to log in, i.e., enter a password, over an insecure connection. Ah, I missed that moment. Thanks. -- З павагай, Павел Селіцкас/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] GSoC 2013 Proposal - jQuery.IME extensions for Firefox and Chrome
Hi I have implemented a small prototype Chrome extension related to this project. It is a simple browser extension (currently for Google Chrome only), that provides multilingual input support on any webpage. Source code and installation instructions can be found at: https://github.com/pravee-n/prototype.jquery.ime Currently only a few languages are supported. You can try Hindi ( हिन्दी ), Greek and a few other languages. Looking forward to some feedback and suggestions. Regards, Praveen Singh On Tue, Apr 30, 2013 at 12:10 AM, Praveen Singh prag...@gmail.com wrote: Hi Oren, Thanks for the feedback. If I have got your point correctly, then the browser extensions would not impact or slow down the page loading. My project scope does include on demand loading of the input methods, but I am not very sure how to go about integrating Resource Loader with the browser extensions. As far as I know, Resource Loader can only be used on MediaWiki enabled websites whereas the project aims at providing these input methods on any website. Let me know what you think of it. Regards, Praveen Singh On Mon, Apr 29, 2013 at 3:15 PM, oren bochman orenboch...@gmail.comwrote: Interesting proposal. I would imagine that this does not impact most page-views since Js files are cached. It might be better to fix this bug by a tighter integration of the JavaScript with the Resource loader to lazy load the required elements as needed In such a case the solution would be less dependent on browser plugins and Would require less long term maintenance when the Js is updated On Apr 29, 2013, at 12:09, Praveen Singh prag...@gmail.com wrote: Hello, I have drafted a proposal for my GSoC Project: jQuery.IME extensions for Firefox and Chrome. I would love to hear what you think about it. I would really appreciate any kind of feedback and suggestions. Please let me know if I can improve it in any way. My proposal can be found here: http://www.mediawiki.org/wiki/User:Prageck/GSoC_2013_Application Thanks, Praveen Singh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
