Hi, as one of WMF developers who work on MobileFrontend[1], I'd love to
know how third parties use this extension. How does your caching
works? How are you detecting mobile devices? Do you have any problems
with running it? Finally, just tell us if you tried it at all:)
----
[1] https://www.mediawiki.org/wiki/Extension:MobileFrontend
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hi,
Just a reminder that the Google Summer of Code deadline is tomorrow, May
3 at 19:00 UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130503T19
So far we have 33 students going after a total of 27 projects:
https://www.mediawiki.org/wiki/Summer_of_Code_2013#Students
Last year Wikimedia got 8 GSoC slots. We hope to get more this year, but
in any case it is clear that we can expect a tough selection process for
everybody.
Speaking of which: you can help! (yes, YOU)
Everybody is encouraged to
* Vote and contribute to the technical discussion about features at
their Bugzilla reports.
* Endorse and comment on students' proposals at their discussion wiki
pages.
We will use this feedback as one of several factors to prioritize
features and candidates.
Also, be aware of our selection process:
https://www.mediawiki.org/wiki/Mentorship_programs/Selection_process#Select…
Thank you for your help and good luck to all the students!
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello
I have finished writing my proposal for the moodle extension GSoC project.
Here is the link to the page http://www.mediawiki.org/wiki/User:Clancer. I
am currently linking to the existing bug report
https://bugzilla.wikimedia.org/show_bug.cgi?id=47381. Any feedback on the
proposal would be great!
Thank you all (especially for helping me setup my development environment
on IRC),
Rohan
Emmanuel,
Thanks for your reply!
Unfortunately -- perhaps this was not clear to you -- we really want the
application to be *the student's work*, to ensure that the student has
come up with the implementation ideas, can communicate clearly, can take
feedback, and so on. Please see
http://www.booki.cc/gsoc-mentoring/defining-a-project/ and
http://www.booki.cc/gsoc-mentoring/selecting-a-student/ especially
"starting at the beginning" at the end of "Selecting a Student".
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
On 05/02/2013 03:36 PM, Emmanuel Engelhart wrote:
> Dear Kiran, Dear Sumana
>
> I have worked on the application. I have rebased it on the WMF template
> like suggested by Sumana.
>
> @ Kiran
> I think it's really important to complete/pimpup the last paragraphs
> which are about you, your motivations, past experiences: people should
> be convinced about the project *and* about you.
>
> @Sumana
> Thank you for your valuable feedbacks. My remarks:
> * I have add portability constraints. We have a compilation farm and VM
> to tests.
> * With average Wikipedia ZIM file, the incremental update should be able
> to save ~70/80& of the bandwidth.
>
> Kind regards
> Emmanuel
>
> Le 02/05/2013 13:45, Sumana Harihareswara a écrit :
>> On 05/01/2013 07:03 PM, Kiran Mathew Koshy wrote:
>>> Hello,
>>>
>>> I have submitted my project application for GSoC '13. Please review it.
>>>
>>> Link: https://www.mediawiki.org/wiki/User:Kiran_mathew_1993
>>>
>>> Thanks,
>>
>> Hi and thanks for your interest in improving MediaWiki!
>>
>> https://www.mediawiki.org/wiki/Mentorship_programs/Application_template
>> would be a very nice thing to follow so we have the information we need
>> to evaluate your application. I especially encourage you to link to
>> your past code and open source contributions.
>>
>> Some questions you ought to answer:
>>
>> * What *kind* of documentation will you be writing? A walkthrough of
>> the code so future developers can understand it? Some kind of
>> user-facing manual? Other things?
>> * Will you be incorporating any kind of automated testing into this
>> project? To guarantee the robustness of the proposed process, it's far
>> better to have self-checks of some kind.
>> * What are your plans for testing this on Windows, Linux, and Mac OS?
>> Do you have test environments available for all those operating systems?
>> * Have you done any measuring to figure out how much bandwidth this
>> would save, given usual usage patterns?
>>
>> Thanks,
>> Sumana
>>
>
On 16 April 2013 19:13, Gaurav Chawla <grviitr(a)gmail.com> wrote:
> Hi, I am Gaurav Chawla (again :P). I will be applying for this year's
> GSOC. I have drafted a project proposal on my user page -
> http://www.mediawiki.org/wiki/User:Grv99. The project aims to develop
> jQuery.IME extensions for Firefox and Chrome (
> https://bugzilla.wikimedia.org/show_bug.cgi?id=46647)
>
> I request you to go through it and give your feedbacks and/or suggestions
> for addition of more features, or any amendments required.
>
> Hoping for a good response.
> Thankyou.
>
>
> PS: If you are thinking about my previous proposal (Wikicards -
> http://www.mediawiki.org/wiki/User:Grv99/Wikicards), I have dropped it as
> an application to this year's GSOC. But, I am glad to inform you, that I
> had already started working on it (with some less functionality), and its a
> work in progress. I will soon be uploading the source on github (blame
> classwork project submissions for the delays :P) and will provide the link
> to it here on wikitech-l. Also, I would like to work with wikidata team, if
> possible, for the same after the GSOC. Thanks for the feedback, you gave
> for wikicards. It helped me a lot.
>
>
> Regards
>
Since it had no comments (sorry for the vague subject), I am bumping this
thread up again.
I have made some amendments and additions to the proposal since its initial
version based on discussions with my mentors. Here is the link to the
proposal
- http://www.mediawiki.org/wiki/User:Grv99
May I request a last wave of feedback before the final submission :)
Thanks
Gaurav
Hi all!
I came across a general design issue when trying to make ApiQueryLangLinks more
flexible, taking into account extensions manipulating language links via the new
LanguageLinks hook. To do this, I want to introduce a LangLinkLoader class with
two implementations, one with the old behavior, and one that takes the hooks
into account (separate because it's less efficient).
The question is now whether it is a good idea to increase the number of
individual classes to improve testability. Essentially, I see two ways of doing
this:
1) The "composition" approach, using:
* LangLinksLoader interface, which defines a loadLangLinks() method.
* DBLangLinksLoader, which implements the current logic using a database query
* HookedLangLinksLoader, which uses a DBLangLinksLoader to get the base set of
links, and then applies the hooks.
* LangLinkConverter, a helper for converting between database rows and the
"$lang:$title" form of language links.
Code: https://gerrit.wikimedia.org/r/#/c/60034/
Advantages:
* All components are testable individually; in particular:
** HookedLangLinksLoader can be tested without DBLangLinksLoader, and without a
database fixture
** LangLinkConverter is testable.
* LangLinksLoader's interface isn't cluttered with the converter methods
* LangLinkConverter is reusable elsewhere
Disadvantages:
* more classes
* ???
2) The "subclassing" approach, using:
* LangLinksLoader base class, implementing the database query and protected
methods for converting language links.
* HookedLangLinksLoader subclasses LangLinksLoader and calls back to the
parent's loadLangLinks() method to get the base set of links.
Advantages:
* fewer classes
* ???
Disadvantages:
* HookedLangLinksLoader depends on the database logic in LangLinksLoader
* HookedLangLinksLoader can not be tested without DB interaction
* converter methods are not testable (or have to be public, cluttering the
interface)
* converter methods are not reusable elsewhere
Currently, MediaWiki core generally follows the subclassing approach; using
composition instead is met with some resistance. The argument seems to be that
more classes make the code less readable, harder to maintain.
I don't think that is necessarily true, though I agree that classes should not
be split up needlessly.
Basically, the question is if we want to aim for true unit tests, where each
component is testable independently of the others, and if we accept an increase
in the number of files/classes to achieve this. Or if we want to stick with the
heavy weight integrations tests we currently have, where we mainly have high
level tests for API modules etc, which require complex fixtures in the database.
I think smaller classes with a clearer interface will help not only with
testing, but also with maintainability, since changes are more isolated, and
there is less hidden interaction using internal object state.
Is there something inherently bad about increasing the number of classes? Isn't
that just a question of the tool (IDE/Editor) used? Or am I missing some other
disadvantage of the composition approach?
Finally: Shall we move the code base towards a more modular design, or should we
stick with the "traditional" approach?
-- daniel
I realized I didn't post my proposal to the list yet (I have added it to
the official GSoC site few days ago), so here it is:
http://www.mediawiki.org/wiki/User:Svick/Incremental_dumps
In short, the project aims to create new format for dumps (which allow
users to download parts of the database of Wikimedia projects). The primary
advantage of this new format will be that it should take shorter time to
create the dump, because the previous dump can be reused.
Any comments or co-mentors (as far as I know, Ariel Glenn is currently the
only potential mentor on this project) are welcome.
Petr Onderka
[[en:User:Svick]]
Greetings
My name is Yevheniy Vlasenko and I am a student of Master’s Program at
Chernihiv State Technological University(Ukraine), Department of Computer
Science. I would like to present an idea «Improvement of glossary tools»
(Semantic MediaWiki).
Currently there are two ways for handling glossaries in MediaWiki:
Lingo and Semantic Glossary. The idea aims to improve both extensions and
introduce new features. The most interesting innovations are: «support for
term multiple definition», context support», «integration of
FlaggedRevs/ApprovedRevs».
This project will significantly improve an efficiency of both
extensions. If will be useful for all wikis that use terms (science, art,
jurisprudence, etc.) as well as for third party users of MediaWiki.
Potentially it can be used in Wikidictionary and other Wikimedia projects.
The idea would be mentored by Stephan Gambke and Yury Katkov.
Full proposal can be found at my page
http://www.mediawiki.org/wiki/User:Zhenya.
Would be glad to receive any feedback either on idea or proposal.
---
Best Regards,
Yevheniy Vlasenko
Hi!
I am Siddha Ganju, a Computer Science and Engineering student from National
Institute of Technology, Hamirpur, Himachal Pradesh,India.
I have submitted a proposal[1] on jQuery.IME - the next big improvements.
All suggestions are welcome!
Thanks!
[1] https://www.mediawiki.org/wiki/User:SiddhaGanju/GSoC_2013_Application
--
Siddha Ganju
2nd Year Undergraduate Student
Computer Science and Engineering Department
National Institute of Technology, Hamirpur - 177005
E-mail Id : siddhaganju(a)gmail.com