Hey,
Two days ago I created a tag for Diff [0]. While I'm writing this mail, the
tag has yet to appear on the GitHub mirror [1]. I made a commit after I
first noticed the tag did not appear to see if replicating that would also
sync the tags, which turned out not to be the case, as the commit made it
onto GitHub, while the tag did not show up.
We do not appear to have an appropriate component on bugzilla for this
piece of our infrastructure, so reporting the issue here.
[0] tag "0.8"
https://git.wikimedia.org/tags/mediawiki%2Fextensions%2FDiff.git
[1] https://github.com/wikimedia/mediawiki-extensions-Diff/releases
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
Sumana Harihareswara <sumanah <at> wikimedia.org> writes:
>
> I've been accepted to Hacker School <https://www.hackerschool.com>, a
> writers' retreat for programmers in New York City. I will therefore be
> taking an unpaid personal leave of absence from the Wikimedia Foundation
> via our sabbatical program. My last workday before my leave will be
> Friday, September 27. I plan to be on leave all of October, November,
> and December, returning to WMF in January.
>
> During my absence, Quim Gil will be the temporary head of the
> Engineering Community Team. Thank you, Quim! I'll spend much of
> September turning over responsibilities to him. Over the next month I'll
> be saying no to a lot of requests so I can ensure I take care of all my
> commitments by September 27th, when I'll be turning off my wikimedia.org
> email.
>
> If there's anything else I can do to minimize inconvenience, please let
> me know. And -- I have to say this -- oh my gosh I'm so excited to be
> going to Hacker School in just a month! Going from "advanced beginner"
> to confident programmer! Learning face-to-face with other coders, 30-45%
> of them women, all teaching each other! Thank you, WMF, for the
> sabbatical program, and thanks to my team for supporting me on this. I
> couldn't do this without you.
>
Congratulations, Sumana! This sounds like a great opportunity for you. It
is so great that programs like Hacker School and OPW are springing up these
days to help people that are out of school get experience becoming better
programmers. I'm looking forward to hearing about your experiences there.
--Rachel
*Gnome FOSS Outreach Program for Women Intern
Browser Test Automation, Wikimedia Foundation*
hi,
yuvi said he is not able to add account creation to the wlm mobile app
because the mw api is not usable. there is a bug filed in march, now
approaching 6 months age:
https://bugzilla.wikimedia.org/show_bug.cgi?id=46072
with priority "high", which means according to andre klapper:
https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority
"Not the next task, but should be fixed soon. Depending on teams &
manpower this can take between one and six months."
who needs to do what to get this fixed?
(sorry for crossposting to wikitech, as i understood this is not a
mobile problem ...)
rupert.
On Sun, Sep 2, 2012 at 2:57 AM, Tomasz Finc <tfinc(a)wikimedia.org> wrote:
> Sadly not for this contest. The API to create accounts never reached
> enough maturity while this app was in development.
>
> Background info here : http://www.mediawiki.org/wiki/User:Akshay.agarwal
>
> Thats why we dont require it to save images for later upload. I agree
> that this would be great to have in the future.
>
> --tomasz
>
>
> On Sat, Sep 1, 2012 at 1:41 PM, Cristian Consonni
> <kikkocristian(a)gmail.com> wrote:
>> 2012/9/1 rupert THURNER <rupert.thurner(a)gmail.com>:
>>> hi philip,
>>>
>>> would it be possible to add an account creation screen to the wlm mobile app?
>>
>> I posted the same request here:
>> http://www.mediawiki.org/wiki/Wiki_Loves_Monuments_mobile_application/Feedb…
>>
>> a couple of days ago.
>>
>> Cristian
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Fri, Aug 23, 2013 at 6:39 PM, Greg Grossmeier <greg(a)wikimedia.org> wrote:
> == Thursday ==
> * CodeEditor support will be enabled for all JS and CSS on all wikis
>
Without fixing the bug which makes it use spaces instead of tabs? Seriously?
https://bugzilla.wikimedia.org/show_bug.cgi?id=39616
Helder
Hello,
This is a reminder that the Language Engineering team will be hosting
an hour long bug triage for R-T-L bugs later today, i.e. August 28,
2013 at 1700 UTC/1000 PDT on the IRC channel #mediawiki-i18n
(Freenode).
etherpad link: https://etherpad.wikimedia.org/p/BugTriage-i18n-2013-08
Thanks
Runa
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Fri, Aug 23, 2013 at 11:56 AM
Subject: Language Engineering bug triage session for RTL language bugs
- Aug 28th 2013, Wednesday 1700 UTC/1000PDT
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Wikimedia
Mailing List <wikimedia-l(a)lists.wikimedia.org>, MediaWiki
internationalisation <mediawiki-i18n(a)lists.wikimedia.org>
Hello,
The Wikimedia Language Engineering team will be hosting a bug triage
session on Wednesday, August 28th 2013 at 17:00 UTC (10:00 PDT) for
some of the bugs that exist in languages written from Right-to-Left
(RTL). During this 1 hour session we will be using the etherpad
linked below to collaborate. We have already listed some bugs, but
please feel free to add more bugs (or file new ones!), and comments
about what you’d like to see addressed during the session. You can
send questions directly to me on email or IRC (nick: arrbee). Please
see below for the event details.
Thank you.
regards
Runa
=== Event Details ===
# What: Bug triage session for RTL language bugs
# Date: August 28, 2013 (Wednesday)
# Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130828T1700
)
# IRC Channel: #mediawiki-i18n (Freenode)
# Etherpad: https://etherpad.wikimedia.org/p/BugTriage-i18n-2013-08
Questions can be sent to: runa at wikimedia dot org
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
I know this list isn't really for linking stuff, but I found this article
earlier today:
http://zenol.fr/site/2013/08/27/an-alternative-error-handling-strategy-for-…
It's about C++, but what it describes is very relevant to our error
handling since we use the exact same pattern (via the Status class) except
in PHP.
Right now MediaWiki is a big mix of the three patterns: sometimes functions
return false on error, sometimes they throw exceptions, and sometimes they
return a Status object with error info.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com
Hi everybody,
in December I mentioned the idea of having a "PATCH_AVAILABLE" or
"PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate
the idea once we have automatic notifications from Gerrit into Bugzilla
in place [2]. This is now the case [3].
>From the Amsterdam Hackathon I know that some developers would like to
filter on bug reports that have or don't have a patch in Gerrit, and
easier finding of bug reports with a corresponding patch && lack of
recent changes might provide another entry point for new developers
(pick up the existing patch and finish it).
Hence I propose
* to remove the manually set and error-prone Bugzilla keyword
"patch-in-gerrit": Every bug on its way to get RESOLVED FIXED
has to pass this stage anyway so a status feels more
appropriate, and
* to make the "Gerrit Notification Bot" automatically change the
bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in
Bugzilla when a patch for that bug report has been committed
(not: merged) to Gerrit.
Comments?
andre
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html
[2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065226.html
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=17322
PS: Making the Gerrit notification bot automatically close bug reports
in Bugzilla after merging a patch in Gerrit, or differentiating in
Bugzilla between "RESOLVED FIXED" (fix merged) and "RELEASED" (fix
deployed on the Wikimedia wikisites) are also interesting topics to
discuss at some point, but not in this thread. One step at a time.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
By putting the following code (written by User:EnDumEn) in
user:YOURNAME/common.jsany external link gets an extra little
symbol (⎆), which leads to a link search for that link. This
is very useful for finding other articles that cite the same
source.
jQuery( "a.external" ).after( function() {
return jQuery( "<a>⎆</a>)" )
.attr( "href", "//sv.wikipedia.org/wiki/Special:Linksearch/" + this.href )
.before( " " );
});
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
We have just released Commons for iOS (version 1.0.8) and Android
(1.0beta11), with *major* UI and performance improvements on iOS and minor
bug fixes on Android.
This is our first release in a couple months on iOS -- we hoped to have one
out before Wikimania but were delayed due to problems with Apple's online
developer tools being offline for a while. There are huge UI improvements
and lots of bug fixes, thanks to our new mobile developer Monte Hurd.
Thanks Monte!
We've been releasing smaller updates on Android in the meantime, so the
updates have been more incremental there.
Both versions now include a quick 3-screen acceptable-use tutorial on first
login. iOS includes featured photos as examples as well; this will come to
Android in a future version.
Downloads and release notes:
* Apple App Store:
https://itunes.apple.com/us/app/wikimedia-commons/id630901780
* Google Play:
https://play.google.com/store/apps/details?id=org.wikimedia.commons
* Android direct download:
http://download.wikimedia.org/android/wikimedia-commons-1.0beta11.apk
-- brion vibber (brion @ pobox.com / bvibber @ wikimedia.org)
The Swedish Wikipedia now has more than 1.5 million
articles, compared to 600,000 in January 2013 and
500,000 in September 2012. This is due to the creation
by a bot of many articles on animal and plant species.
The Swedish Wikipedia community has discussed the
matter thoroughly, and there is strong consensus to
keep these articles and to keep on generating more.
(It is known that many German wikipedians think these
are bad articles that should be removed, but this is not
their decision.)
The current implementation of [[Special:Random]],
however, gives equal weight to every existing article and
this is perceived as a problem that needs to be fixed.
But it is not obvious how a bug report or feature
request should be written. A naive approach would be
to ask for a random article that wasn't created by a
bot, but this is not to the point. Users want bot
generated articles to come up, only not so often. And
some manually written article stubs are also less wanted.
Perhaps the random function should be weighted by
article length or by the number of page views? But is
it practical to implement such a weighted random
function? Are the necessary data in the database?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se