[Wikitech-l] [Language Engineering] Reminder: Office hour on 10th April 2013 at 1700 UTC/1000 PDT
* Hello, * * * * This is a reminder that the Language Engineering team will be hosting an IRC office hour today, i.e. 10th of April 2013 at 1700 UTC/1000 PDT on #wikimedia-office (Freenode). The agenda can be found in the section below. * * * * Thanks * * Runa * * * * Agenda: * * 1. Introductions 2. Translate UX - Deployment and other news 3. Language Mavens - an outreach initiative with the Wikimedia language communities 4. MediaWiki Language Extension Bundle (MLEB) Release 5. Q/A - We shall be taking questions during the session. Questions can also be sent to runa at wikimedia dot org r...@wikimedia.org before the event and can be addressed during the office-hour. * -- Forwarded message -- From: Runa Bhattacharjee rbhattachar...@wikimedia.org Date: Fri, Apr 5, 2013 at 3:07 PM Subject: [Language Engineering] Office hour on 10th April 2013 at 1700 UTC/1000 PDT To: mediawiki-i...@lists.wikimedia.org, Wikimedia Mailing List wikimedi...@lists.wikimedia.org, wikitech-l@lists.wikimedia.org * Hello, The Wikimedia Language Engineering team [1] invites everyone to join the team’s monthly office hour on April 10, 2013. We have some exciting updates about our ongoing projects, some of which have also been shared in our recent blog posts[2]. During this session we would like to walk through some of them. The team would also like to introduce a new outreach program which was mentioned in the last office hour held on 13th March 2013 [3]. Event details and the general agenda is mentioned below. See you all at the IRC office hour! regards Runa Event Details: == Date: 2013-04-10 (Wednesday) Time: 1700 UTC, 1000 PDT IRC channel: #wikimedia-office on irc.freenode.net Agenda: 1. Introductions 2. Translate UX - Deployment and other news 3. Language Mavens - an outreach initiative with the Wikimedia language communities 4. MediaWiki Language Extension Bundle (MLEB) Release 5. Q/A - We shall be taking questions during the session. Questions can also be sent to runa at wikimedia dot org r...@wikimedia.org before the event and can be addressed during the office-hour. [1] http://wikimediafoundation.org/wiki/Language_Engineering_team [2] http://blog.wikimedia.org/c/technology/features/internationalization-and-localization/ [3] http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2013-03-13 * -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deployment highlights - week of April 8th
Thank you, also for the explanation. I am glad we could defuse this. On Apr 10, 2013 7:07 AM, Risker risker...@gmail.com wrote: On 9 April 2013 12:15, Denny Vrandečić denny.vrande...@wikimedia.de wrote: Risker, I find myself unconvinced by your argumentation as I perceive it as inconsistent. On the one hand, you suggest that before we enable the option to access data from Wikidata using either Lua or a parser function should be discussed and decided by the community beforehand - the same community, that has been informed since mid 2011 that this change is coming. You suppose that the community can actually come together and decide this globally. On the other hand, you are not trusting the community with the use of the same feature. You say they would weaponize the feature, that the community will be unable to adapt to the new feature, and that it needs to discuss first how to use it, and for deployment to wait a few months (I do not fully understand why you assume that a few months will be enough to sort things out). You seem to assume that a wiki as large and active as the English Wikipedia is not resilient enough to absorb the rather minor technical change we are introducing. It is, technically, a minor change. Socially it can lead to bigger changes -- but I found it hard to believe that anyone can predict the actual effect on the English Wikipedia community. This has to be seen and experienced, and I, for one, trust the English Wikipedia community to be as awesome as always, and to absorb and use this new features in ways no one has even imagined yet. I'll just quickly point out the dichotomy in what you're saying here: first you say that you doubt the project can come together and make a global decision, and then you say that it is resilient enough to ... make a global decision. This is, from the technical perspective, a small change. It is a major philosophical change: actively preventing editors from making content changes on the home project. It's also a contradictory change: it makes it more complex to edit content, but at the same time major investment of developer time and talent is being invested into making the editing process simpler and more intuitive through Visual Editor (and ultimately projects like Flow and Echo). Infoboxes (and ultimately lists) are an integral part of the content of Wikipedias; making text easier to edit and other integral content more difficult to edit suggests that, at minimum, there are some fairly significant philosophical and practical conflicts within the overall platform development. From the community perspective, a simpler editing interface has been a community priority for almost as long as Wikipedia has been in existence. It is good to see the WMF putting its (much improved) financial resources into a project that has been near the top of the editorial wish list for so long, and that investment has very good prospects of paying off with both editor retention and editor recruitment. Unless I've missed something, that's still a key metric for measuring success. I agree that Wikidata is cool (to use others' expressions), but I've not seen anything indicating it is attracting new editors; instead it seems to be drawing in editors from other WMF projects, who are now doing less editing in their home projects. I'd hope that is a short-term change as Wikidata develops as a project. I suppose what I am saying here is that Wikidata doesn't seem to be working within the articulated master vision of the platform (which focuses on simplifying the editorial process), and absent the ability to edit the wikidata on the project where it appears, I don't see how it's going to get there. It doesn't make Wikidata any less of a great idea, and I still think it has potential for new projects to build content. I'm just having a hard time seeing where it's fitting with everything else that is going on, if data can't be changed by using real words directly on the wikipedia project. What I am looking for is a good, plain-English explanation of how these two different directions in software development are not divergent, and how they are intended to co-exist without one adversely affecting the effectiveness of the other. Since you are saying that our communication has not been sufficient, I would be very glad to hear which channels we have missed so that we can add them in the future. Since Wikidata phase 2 is actually a less intrusive change than phase 1, and based on the effectiveness of the discussion about phase 2 on the English Wikipedia so far, I think that a post-deployment discussion is the right way to go. In what way is this less intrusive? Phase 1 changed the links to other projects beside articles, a task that was almost completely done by bots, and did not in any way affect the ability to edit or to modify
Re: [Wikitech-l] Ideating on GSoC project : Mobilize Wikidata
Based on a discussion I had with YuviPanda and MaxSem on #wikimedia-mobile, I've got a few things to add: - It might be a good idea to let Wikidata detect when it's being accessed through a mobile device and then have it adjust the widths and such of the box-structures accordingly and then pass them to MobileFrontend. Maybe we can set up a Wikilabs instance with MobileFrontend like Quim Gil suggested and then we can see how much work there is involved with trying to make WIkidata mobile-friendly. If we can get it to work with MobileFrontend, that'll be excellent but if it turns out to be too complex or too dirty a solution, it would make more sense to make a completely new extension for it. Although the scope of the project is not very clear at the moment, I think that a feasible implementation plan could be worked out with respect to the GSoC timeline and if it's required, I can continue to work on the project after GSoC ends. On Tue, Apr 9, 2013 at 6:49 PM, Quim Gil q...@wikimedia.org wrote: On 04/09/2013 02:39 AM, Denny Vrandečić wrote: I would hope It would also be extremely good to look I would assume I don't think Can the Wikidata and Mobile teams please answer with the best of your knowledge to the questions at Bug 43065 - WikibaseRepo to be mobile friendly (tracking) https://bugzilla.wikimedia.**org/show_bug.cgi?id=43065https://bugzilla.wikimedia.org/show_bug.cgi?id=43065 Beyond hope and believe, the fact is that I couldn't get any answer more precise than Interesting when asking about this project to people in those teams. And as for today I'm not confident to tell to a candidate like Pragun whether this project is too complex or too simple, and where the complexity/simplicity relies. In case of doubt I'd prefer to play safe and actually not encourage GSOC / OPW to apply for a project like this, before we regret around August. Is it possible to have a Wikidata / WikidataRepo test instance somewhere with MobileFrontend enabled, so we can all have a look and know more about the gap this project should fill? -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Pragun Bhutani http://pragunbhutani.in Skype : pragun.bhutani ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deployment highlights - week of April 8th
2013/4/10 Risker risker...@gmail.com On 9 April 2013 12:15, Denny Vrandečić denny.vrande...@wikimedia.de wrote: Risker, I find myself unconvinced by your argumentation as I perceive it as inconsistent. On the one hand, you suggest that before we enable the option to access data from Wikidata using either Lua or a parser function should be discussed and decided by the community beforehand - the same community, that has been informed since mid 2011 that this change is coming. You suppose that the community can actually come together and decide this globally. On the other hand, you are not trusting the community with the use of the same feature. You say they would weaponize the feature, that the community will be unable to adapt to the new feature, and that it needs to discuss first how to use it, and for deployment to wait a few months (I do not fully understand why you assume that a few months will be enough to sort things out). You seem to assume that a wiki as large and active as the English Wikipedia is not resilient enough to absorb the rather minor technical change we are introducing. It is, technically, a minor change. Socially it can lead to bigger changes -- but I found it hard to believe that anyone can predict the actual effect on the English Wikipedia community. This has to be seen and experienced, and I, for one, trust the English Wikipedia community to be as awesome as always, and to absorb and use this new features in ways no one has even imagined yet. I'll just quickly point out the dichotomy in what you're saying here: first you say that you doubt the project can come together and make a global decision, and then you say that it is resilient enough to ... make a global decision. No, this is not what I am saying. I am saying that the English Wikipedia is resilient enough to absorb such a change after it happened. I would actually be a bit disappointed if that would happen through a global and absolute decision on whether to replace all template parameters through Wikidata, or to not use Wikidata at all. I see a lot of middle ground there, which can be decided case by case, Wikiproject per Wikiproject, template per template, article per article, and even per single parameter in a template call. I even hold the notion of a single English Wikipedia community to be misleading. There are many overlapping communities working on the different parts of the project. I expect that some of them might embrace the new features that Wikidata offers, and others might less so. And that is OK. If editors of classical composer articles don't want infoboxes for them, so be it. Wikidata does not require them. It won't take long for these editors to figure out that they can use Wikidata as an argument *against* having Infoboxes: after all, if you want an Infobox just go to Wikidata. If the editor community of Egyptian cities prefers to keep their mayors up to date through Wikidata though, because they are more comfortable in Egyptian Arabic, French, or Arabic, but still edit a bit on English - as so many do - why deny them? There are many different ways Wikidata will interact with existing workflows. I can envision some, but I expect the creativity of Wikipedians to go well beyond that, and amaze me again. But this can only happen if we let Wikidata and Wikipedia grow together and co-evolve. If we wait a few months to let Wikidata mature, there is a serious threat of the two projects to grow too much apart. I suppose what I am saying here is that Wikidata doesn't seem to be working within the articulated master vision of the platform (which focuses on simplifying the editorial process) Simplifying editing and reducing maintenance costs for the Wikipedias are explicit goals of Wikidata. Obviously the simplest edit is the one you don't have to do. Furthermore, simplifying template calls makes the job of the Visual Editor team easier. Also Wikidata provides an API that makes inline editing possible. James and I are talking with each other, and we are making sure that the vision does not diverge. And yes, from the perspective of editors, infoboxes are part of the content of the article. The technology change may be minor, but its use means changing the core anyone can edit philosophy that has created, and constantly renewed and developed, the wikipedia projects. In that matter, we are currently failing. The often screen-filling Infobox invocation code at the top of an article, that is displayed when you click on edit, has scared off many potential contributors. Wikidata is going to provide the means to improve the situation considerably. I apologize to Denny for my being too much of a word wonk, and perhaps spending too much time reading political history. Thank you for the explanation. As a non-native speaker I did not have the same connotation and was thus confused by the strong reaction. Cheers, Denny
Re: [Wikitech-l] Bugs in 1.21rc2
On Tue, Apr 9, 2013 at 10:37 PM, Greg Grossmeier g...@wikimedia.org wrote: Then, if those numbers change much, graphs from Zeljko ;) Give me numbers and there will be graphs. :) Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] OpenID: Mozilla bridges their PERSONA with OpenID and OAuth
For those being interested: Mozilla Persona is an open authentication system that lets you implement sign-in on your site in an afternoon. Today, Persona Beta 2 was released, including a feature called Identity Bridging that lets hundreds of millions of users sign into sites supporting Persona with no new username and no new password. The announcement video gives you a good overview of the Beta 2 release.. See https://hacks.mozilla.org/2013/04/persona-beta-2-launch/ and our https://bugzilla.wikimedia.org/show_bug.cgi?id=34565 and our https://www.mediawiki.org/wiki/Extension:OpenID ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OpenID: Mozilla bridges their PERSONA with OpenID and OAuth
You may have forgotten a link there ;) http://www.mediawiki.org/wiki/Extension:Persona *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Apr 10, 2013 at 10:27 AM, Thomas Gries m...@tgries.de wrote: For those being interested: Mozilla Persona is an open authentication system that lets you implement sign-in on your site in an afternoon. Today, Persona Beta 2 was released, including a feature called Identity Bridging that lets hundreds of millions of users sign into sites supporting Persona with no new username and no new password. The announcement video gives you a good overview of the Beta 2 release.. See https://hacks.mozilla.org/2013/04/persona-beta-2-launch/ and our https://bugzilla.wikimedia.org/show_bug.cgi?id=34565 and our https://www.mediawiki.org/wiki/Extension:OpenID ___ 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] WMF Engineering Roadmap updates 4/10
Here are the highlights of the WMF Engineering roadmap updates for today focusing on major activities in April: Mobile * iOS upload app delayed due to appstore snafu * Community testing around Mobile this month Ops * build out for ULSFO datacenter, RFP for hardware in progress Platform * Redis JobQueue * (finish) review/fixing of Score and Vipscaler extensions Language * TranslateUX improvements are out * IE fixes will be rolled out today (4/10) Full details at: https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Aoizbfxc5g6KdEkza0xkQnJlM0o0TXlwQXhDOUFvYnc#gid=0 (shorturl: http://goo.gl/7611Q ) Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Engineering Roadmap updates 4/10
Small correction: quote name=Greg Grossmeier date=2013-04-10 time=10:56:01 -0700 Language * IE fixes will be rolled out today (4/10) These actually are going out tomorrow (4/11) at 08:00 UTC, see the deployments calendar: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_April_8th Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A new project - Wikicards
Sorry, I was unable to repond for last two days, I had some academic work to be done. Thankyou for the discussion and the much needed feedback. As from the various discussions (bugzilla, my talk page and this thread), it turns out that this project is not as feasible or worthy enough to be applying with. I understand that improving the existing projects is much more important for our awesome wiki to grow better. Hence, I am thinking to drop (Can we apply for multiple projects?) this as an application for GSOC 2013, because without its (wikicards') edit-ability, it will be nearly re-inventing the wheel(or rather Navigation popups, to be precise). I had already started making it though, and now it would probably complete in a couple of days or by this weekend. But, these new wikicards will not be editable :( , no subject-specific subtitles any sooner and loading the links will probably make it slow (will have to search almost 7 times to fetch 1 card, for the time being, until I research more about all the available APIs). In short, these cards = Navigation popups + links + universally accessible. and for the GSOC, I am on the hunt for projects again :) Thankyou again for this great help. Regards, Gaurav Chawla On 9 April 2013 09:13, Matthew Flaschen mflasc...@wikimedia.org wrote: On 04/07/2013 03:24 PM, Gaurav Chawla wrote: - I introduced voting to include the users view into the information/definition that wikIcards will show. That will give a more accepted defn. I agree with Quim (on the bug). Consensus is a better approach for content (voting on such things is vulnerable to gamesmanship and mob rule). I am also skeptical of this as a WMF project. Slightly rethought, though, it could certainly be a cool use of the Wikipedia and Wikidata APIs and/or dumps. Matt Flaschen ___ 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] JobQueue on Redis initial test deploy today
Sending this out because I know many of your are wondering about the status of the Redis JobQueue work. This happened today: 18:24 logmsgbot: aaron synchronized wmf-config/jobqueue-eqiad.php 'Enabled use of redis for null test jobs' What that means is that null test jobs will be sent to the new Redis-based JobQueue. Aaron will also begin sending some real jobs to the Redis-based queue later today and monitor them. If all goes well with the testing, we should be able to switch over fully by this coming Monday. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Temporarily disabling l10n update
Hi folks, We've had at least a couple of site outages which we believe are due to l10nupdate. The root cause is identified in a fairly old ResourceLoader bug that seems to be biting us a little harder than it normally does: https://bugzilla.wikimedia.org/show_bug.cgi?id=27320 Disabling l10nupdate means that changes from Translatewiki.net will not propagate to our websites as quickly as they normally do. Depending on how long it takes us to fix this, it could be multiple days. Brad Jorsch is going to take a closer look at this issue today/tomorrow, and hopefully identify the root cause. If he's able to find the cause quickly, we may not need to disrupt the service, but we're going to plan for the worst here. Thanks (in advance) for your patience! Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A new project - Wikicards
On 04/10/2013 12:33 PM, Gaurav Chawla wrote: (Can we apply for multiple projects?) Yes. http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page#6._Can_a_student_submit_more_than_one You can technically submit many projects to many organizations. In practice we'd rather help you submitting a good one with us. :) and for the GSOC, I am on the hunt for projects again :) I know you know it, but there are many project ideas with mentors available at https://www.mediawiki.org/wiki/Summer_of_Code_2013 Thank you again for this great help. Thank you for your willingness to experiment and contribute regardless of GSOC and whatever we say. It is essential to believe in you and your ideas. That's the spirit! :) -- 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] Temporarily disabling l10n update
Does that mean that scap is also prohibited? On 11.04.2013, 0:01 Rob wrote: Hi folks, We've had at least a couple of site outages which we believe are due to l10nupdate. The root cause is identified in a fairly old ResourceLoader bug that seems to be biting us a little harder than it normally does: https://bugzilla.wikimedia.org/show_bug.cgi?id=27320 Disabling l10nupdate means that changes from Translatewiki.net will not propagate to our websites as quickly as they normally do. Depending on how long it takes us to fix this, it could be multiple days. Brad Jorsch is going to take a closer look at this issue today/tomorrow, and hopefully identify the root cause. If he's able to find the cause quickly, we may not need to disrupt the service, but we're going to plan for the worst here. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporarily disabling l10n update
On Wed, Apr 10, 2013 at 1:14 PM, Max Semenik maxsem.w...@gmail.com wrote: Does that mean that scap is also prohibited? Scap runs the same script to clear blobs. We can sabotage that script, but that will cause all i18n updates to JS to propagate more slowly, regardless of whether they came from a code deployment or l10nupdate. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporarily disabling l10n update
On Wed, Apr 10, 2013 at 4:25 PM, Roan Kattouw roan.katt...@gmail.com wrote: On Wed, Apr 10, 2013 at 1:14 PM, Max Semenik maxsem.w...@gmail.com wrote: Does that mean that scap is also prohibited? Scap runs the same script to clear blobs. Actually, it doesn't look like it does. -- Brad Jorsch Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Proposing topics for Tech Talks and meetups
Hi, We have sorted out the calendar of Tech Talks and Wikipedia Engineering meetups, dancing to the rhythm marked by the WMF Metrics and Activities meeting: 1st Thursday of the month: Metrics meeting. 2nd Thursday: Wikipedia Engineering meetup. 3rd Thursday: Tech Talk. This is now reflected at https://www.mediawiki.org/wiki/Project:Calendar Please propose topics you are missing or would like to see discussed in more detail. We will do our best finding speakers and slots. Proposing topics via email is fine, but it's even better if you do it at http://www.mediawiki.org/wiki/Talk:Meetings -- 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] Gerrit slow to the point of being unusable today
Is anyone able to look into this? It's extremely slow and I can't find someone to fix it. It's making me a very sad and unproductive panda :( -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: Commons App v1.0 beta6 released
Spamming wikitech-l, which might possibly care more than mobile-l.
-- Forwarded message --
From: Yuvi Panda yuvipa...@gmail.com
Date: Thu, Apr 11, 2013 at 3:43 AM
Subject: Commons App v1.0 beta6 released
To: mobile-l mobil...@lists.wikimedia.org
Hello! New beta release of commons app went out today!
Features of v1.0 beta 7 include:
- Added opt out from EventLogging
- Remove {{Uncategorized}} template after adding categories
- Be more consistent and proactive in syncing modifications (adding categories)
- Add a minimal About page
- Add option to send feedback via email from within the app
- i18n updates
There is no major new feature, just a bunch of bug fixes and minor features.
Bug reports welcome at
https://bugzilla.wikimedia.org/enter_bug.cgi?product=Commons%20App
(pick the Android component). The apps team uses Trello to organize
our work, you can look at the board for our current iteration at
https://trello.com/board/sprint-6/5162461b43476994540002ba
Pull requests welcome at https://github.com/wikimedia/android-commons
Thank you!
This mail brought to you by the vague feeling that this list feels
lonely and has abandonment issues.
--
Yuvi Panda T
http://yuvi.in/blog
--
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] [Wiktionary-l] [Commons-l] Advice Needed
The whole idea is project specific,we are not converting to wav, but since its the only format that browsers can easily upload in for the time being. Thanks On Thu, Apr 11, 2013 at 3:26 AM, Sebastian Hellmann hellm...@informatik.uni-leipzig.de wrote: You didn't include the list in your reply. What about: http://firefogg.org/ ? -- Sebastain Am 10.04.2013 23:41, schrieb Rahul Maliakkal: The point is not about efficiency rather the only format that browsers can presently capture into. As browsers add support for AAC converting / uploads, then we will prefer that. Thanks On Thu, Apr 11, 2013 at 2:52 AM, Sebastian Hellmann hellm...@informatik.uni-leipzig.de wrote: Well, I guess this should be researched quite well, before investing time in this feature: WAV WAVEform audio format http://en.wikipedia.org/wiki/WAV (WAV) is a Microsoft http://en.wikipedia.org/wiki/Microsoft and IBMhttp://en.wikipedia.org/wiki/IBM audio file format http://en.wikipedia.org/wiki/Audio_format for storing audio on PCs. It is the main format used on Microsoft Windowshttp://en.wikipedia.org/wiki/Microsoft_Windowssystems for raw audio storage. The WAV format is most commonly used with an uncompressed, lossless storage method (pulse-code modulation) resulting in comparatively large audio files. Today, the WAV audio format is no longer popular being superseded by other more efficient means of audio storage. [19]http://en.wikibooks.org/wiki/FOSS_Open_Standards/Comparison_of_File_Formats#cite_note-19 from http://en.wikibooks.org/wiki/FOSS_Open_Standards/Comparison_of_File_Formats#WAV So who wants wav files actually, they are normally very large as well. The legal status is not so obvious. Maybe you even need a lawyer to judge this correctly. Again, is .wav really so popular, that it justifies the effort? All the best, Sebastian Am 10.04.2013 19:40, schrieb Federico Leva (Nemo): Rahul Maliakkal, 10/04/2013 19:27: As we all know right now uploading an audio file is only possible in .ogg format. In my GSOC project , i plan on adding *.wav support* to commons ,since its not patent encumbered i think it should be fine Context: Pronunciation Recording Extension https://www.mediawiki.org/wiki/User:Rahul21/Gsoc I would like to get the communities feedback on this. Is the reason that the dependencies you found all require this format? Nemo ___ Wiktionary-l mailing list wiktionar...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiktionary-l -- Dipl. Inf. Sebastian Hellmann Department of Computer Science, University of Leipzig Projects: http://nlp2rdf.org , http://linguistics.okfn.org , http://dbpedia.org/Wiktionary , http://dbpedia.org Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann Research Group: http://aksw.org -- Dipl. Inf. Sebastian Hellmann Department of Computer Science, University of Leipzig Projects: http://nlp2rdf.org , http://linguistics.okfn.org , http://dbpedia.org/Wiktionary , http://dbpedia.org Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann Research Group: http://aksw.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Commons App v1.0 beta6 released
Install link from Google Play: https://play.google.com/store/apps/details?id=org.wikimedia.commons -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] test gossip
A few things I learned recently by gossiping with WMF quality assurance people: We're deploying fresh code to the beta cluster ~50 times a day, or maybe even more often! https://gerrit.wikimedia.org/r/#/q/status:merged+project:%255Emediawiki.*+-owner:l10n-bot,n,z shows merged code to MediaWiki core extensions -- on every merge or every few minutes, we update the code on http://commons.wikimedia.beta.wmflabs.org/ and all the other beta cluster sites. So right now, beta is the best target for automated browser tests, but because of some configuration issues, http://test2.wikipedia.org/ is the best target for manual/exploratory testing. When you're writing automated browser tests (good setup instructions: https://github.com/wikimedia/qa-browsertests ), feature files are a plain-English communication tool; step definitions are where the magic happens. So, in features/ , there's step_definitions/ with .rb files, each corresponding to a feature file. Look through those for some idea of the neat stuff we can do these days. If you want ideas for useful automated browser tests to write, try looking at recently fixed bugs. That way we'll catch regressions. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] wav support to Commons (was Re:Advice Needed)
On 04/10/2013 03:16 PM, Rahul Maliakkal wrote: In my GSOC project , i plan on adding *.wav support* to commons As of today this falls in the category of NO to projects depending on unconvinced maintainers. In this case the Commons maintainers. http://commons.wikimedia.org/wiki/Commons:Project_scope/Allowable_file_types If the Commons community is happy to take this format, fine. But we need to know before the deadline for accepting projects. Or you need to change your strategy. Another question is of course how feasible is to include adding *.wav support* to commons in the scope of your project. Relevant: WAV audio support via TimedMediaHandler https://bugzilla.wikimedia.org/show_bug.cgi?id=32135 Good to see that mdale is already involved there. -- 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] wav support to Commons (was Re:Advice Needed)
On 04/10/2013 07:29 PM, Quim Gil wrote: If the Commons community is happy to take this format, fine. But we need to know before the deadline for accepting projects. Or you need to change your strategy. An alternative approach is server-side conversion to a Commons-approved format such as Ogg, before uploading to Commons. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] test gossip
Very helpful, Sumana. I'd happily encourage more gossip of this type. On Thu, Apr 11, 2013 at 12:40 AM, Sumana Harihareswara suma...@wikimedia.org wrote: A few things I learned recently by gossiping with WMF quality assurance people: We're deploying fresh code to the beta cluster ~50 times a day, or maybe even more often! https://gerrit.wikimedia.org/r/#/q/status:merged+project:%255Emediawiki.*+-owner:l10n-bot,n,z shows merged code to MediaWiki core extensions -- on every merge or every few minutes, we update the code on http://commons.wikimedia.beta.wmflabs.org/ and all the other beta cluster sites. So right now, beta is the best target for automated browser tests, but because of some configuration issues, http://test2.wikipedia.org/ is the best target for manual/exploratory testing. When you're writing automated browser tests (good setup instructions: https://github.com/wikimedia/qa-browsertests ), feature files are a plain-English communication tool; step definitions are where the magic happens. So, in features/ , there's step_definitions/ with .rb files, each corresponding to a feature file. Look through those for some idea of the neat stuff we can do these days. If you want ideas for useful automated browser tests to write, try looking at recently fixed bugs. That way we'll catch regressions. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wav support to Commons (was Re:Advice Needed)
On 4/10/13 4:29 PM, Quim Gil wrote: On 04/10/2013 03:16 PM, Rahul Maliakkal wrote: In my GSOC project , i plan on adding *.wav support* to commons I don't see any email on this list that includes that quote, nor does Ruhul's GSoC proposal mention anything about WAV. Could you provide some context by either quoting the entire message or pointing to where this discussion is actually taking place? Thanks! Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wav support to Commons (was Re:Advice Needed)
On Thu, Apr 11, 2013 at 12:16 AM, Ryan Kaldari rkald...@wikimedia.org wrote: I don't see any email on this list that includes that quote, nor does Ruhul's GSoC proposal mention anything about WAV. Could you provide some context by either quoting the entire message or pointing to where this discussion is actually taking place? Thanks! Looks like it was on commons-l today. -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sort on category
Hello, Are there any plans to have a tool that would allow to dynamically sort content based on category? Single category views, especially for large categories, aren't particularly helpful. Something similar to what Microsoft's pivot demo had? An HTML5 example at: http://pivot.lobsterpot.com.au/pass2012.htm -Small ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sort on category
On 2013-04-10 10:25 PM, Small M smallma...@yahoo.com wrote: Hello, Are there any plans to have a tool that would allow to dynamically sort content based on category? Single category views, especially for large categories, aren't particularly helpful. Something similar to what Microsoft's pivot demo had? An HTML5 example at: http://pivot.lobsterpot.com.au/pass2012.htm -Small ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l No, there are no current plans for doing this. Interesting idea though. If I understand you correctly you want a category page where things are grouped by what other categories a page is a member of. I don't think such a thing can be done in an efficient manner for big categories given the way category membership is currently stored. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
