Hello all,
I would like to invite you to the upcoming localisation and
internationalisation bug triage. The bug triage preparation is
available[1]. Please feel free to add bugs / use the chat window / email me
about i18n issues that you would like to discuss in the triage.
When : August 22, 16:00 - 17:00 UTC
Where : Freenode IRC channel #mediawiki-i18n
[1] http://etherpad.wikimedia.org/BugTriage-i18n-2012-08
--
Srikanth L
Wikimedia Localisation Team
Hi everyone,
It's soft pencils down for the GSoC and I wanted to update everyone with the progress of my project.
For a reminder, my project[1] aimed at allowing uploads of images from Flickr directly from the Upload Wizard and to allow setting the geolocation through a map interface.
My work on the Flickr Integration is almost over, and I am just awaiting the final review. Once this is over, Ryan Kaldari( my mentor ) and I have been discussing the idea of putting it live on the commons for the admins, as it would help us get feedback and also allow testing of the project. You can see the work on the flickr branch on Gerrit[2].
The basic functionality of Geolocation integration has also been completed. Although still some minor changes are left, and I am sure I will get more changes to work on after it gets reviewed. Since this was a relatively small functionality of just adding a map interface for the already existing geolocation support, I would want to further add support for Altitude and direction tags for media. Hopefully by the end of this month, this would also be ready to be merged.
The work on this can be tracked on the geo branch on Gerrit[3].
You can also read all the updates of the project on my blog [4].
[1] - http://www.mediawiki.org/wiki/User:Drecodeam/GSoC_2012_Application
[2] - https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions…
[3] - https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions…
[4] - http://ankuranand.in/gsoc/wordpress/
Thanks,
drecodeam
Forwarded from FOSDEM(a)lists.fosdem.org. Subscribe at
https://lists.fosdem.org/listinfo/fosdem.
Siebrand
---------------------------- Original Message ----------------------------
Subject: [FOSDEM] FOSDEM calls for devroom organizers and main track speakers
From: "Tias Guns" <tias(a)fosdem.org>
Date: Sun, August 12, 2012 14:40
To: "Fosdem Announce" <fosdem(a)lists.fosdem.org>
--------------------------------------------------------------------------
<<< help spread the word and make FOSDEM awesome >>>
FOSDEM is a non-commercial event offering open source communities a
place to meet, share ideas and collaborate. It is renowned for being
highly developer-oriented and brings together 5000+ geeks from all over
the world. FOSDEM will take place in Brussels, Belgium on the 2nd and
3rd of February 2013.
We invite proposals for *devrooms* and *main track talks*:
*Main Track Talks*
The main tracks host high-quality seminars for a broad and technical
audience. Every track is organized around a theme (security, kernel,
collaboration, ...). They are held in the two biggest auditoria and last
50 minutes. Each of the talks is given by a speaker who gets their
travel and accommodation costs reimbursed.
To apply for a FOSDEM Main Track talk, visit
https://fosdem.org/2013/call_for_main_speakers.html
To suggest a main track speaker that we should invite, mail
program(a)fosdem.org
*Devrooms*
A devroom is a 'developer room' in which open source communities can
organize their own schedule, made of presentations, brainstorming and
hacking sessions. Our goal is to stimulate developer collaboration and
cross-pollination between projects.
Each year we receive more requests than we can host. To better achieve
our goals, preference will be given to *proposals involving multiple,
collaborating projects*. Projects with similar goals/domains that make
separate requests will be asked to co-organize a devroom under their
common theme.
To propose organizing a devroom, visit
https://fosdem.org/2013/call_for_devrooms.html
Note! Linux distributions should apply to the dedicated distribution
mini-conference:
https://fosdem.org/2013/distrominiconf.html
*Key Dates*
- 1 October: deadline for devroom proposals
- mid October: devroom announcements
- 1 November: deadline main track proposals
- mid November: main track announcements
- 2 and 3 February: FOSDEM 2013
Hey,
I'm tried fixing some issue where a "leaving page" warning is shown when it
should not, but have not been able to find how to get rid of it (as I'm not
familiar with the relevant code at all).
https://bugzilla.wikimedia.org/show_bug.cgi?id=39158
Would be awesome if someone that is familiar with this stuff can have a
look at it :)
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hey,
Not sure whether this has been discussed previously, but are there any
plans on when MediaWiki is going to upgrade to jQuery 1.8?
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com
On Aug 10, 2012, at 6:50 PM, wikitech-l-request(a)lists.wikimedia.org wrote:
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 10 Aug 2012 16:39:40 -0700
> From: Rob Lanphier <robla(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Subject: [Wikitech-l] Use cases for Sites handling change (Re:
> Wikidata blockers weekly update)
> Message-ID:
> <CAPzpXh4uXS-eNSBv_ZSfk1ijAS1_ZpZVrbgVomM70wZYhvcJ3Q(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi everyone,
>
> I'm starting a separate thread, because this is an important topic and
> I don't think it's well served as a subtopic of a "Wikidata blockers"
> thread.
>
> To recap, Jeroen submitted changeset 14295 in Gerrit
> <https://gerrit.wikimedia.org/r/#/c/14295/> with the following
> summary:
>> This commit introduces a new table to hold site data and configuration,
>> objects to represent the table, site objects and lists of sites and
>> associated tests.
>
>> The sites code is a more generalized and less contrived version of the
>> interwiki code we currently have and is meant to replace it eventually.
>> This commit does not do away with the existing interwiki code in any way yet.
>
>> The reasons for this change where outlined and discussed on wikitech here:
>> http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/060992.html
>
> Thanks Brian for summarizing an important point:
>
> On Fri, Aug 10, 2012 at 6:33 AM, bawolff <bawolff+wn(a)gmail.com> wrote:
>>
>
> First and foremost, I'm a little confused as to what the actual use
> cases here are. Could we get a short summary for those who aren't
> entirely following how wikidata will work, why the current interwiki
> situation is insufficient? I've read the I0a96e585 and
> http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/060992.html,
> but everything seems very vague "It doesn't work for our situation",
> without any detailed explanation of what that situation is. At most
> the messages kind of hint at wanting to be able to access the list of
> interwiki types of the wikidata "server" from a wikidata "client" (and
> keep them in sync, or at least have them replicated from
> server->client). But there's no explanation given to why one needs to
> do that (are we doing some form of interwiki transclusion and need to
> render foreign interwiki links correctly?
Now I can't speak for what Wikidata is doing, but there is a use case for interwikis in transclusion. I have never considered before that this would not render the the foreign interwiki links correctly. I doubt the situation has actually occurred yet, but there are two expected cases I can think of off the top of my head which might touch on this area.
Number one, people on Wikisource are expecting interwiki transclusion to be a solution to texts in duplicate languages. It inevitable that with enough such texts created there will be links made to a Wikipedia article insude one subdomain which end up being transcluded into another subdomain.
Number two is a bit different but probaly problematic all the same, Wikisource developers are searching for a solution that will allow the OCR text layer if a djvu file to replaced with the human validated text. A non-human solution. When a good solution is found the djvu files at Common can be expected to be processed this way. There will be interwiki links originally made in various Wikisource subdomains as part of the validated text that will be processed back into the Commons djvu file. Obviously the process can not leave them as wikitext, but interwikis originating from any possible language subdomain of Wikisource will have to handled by one piece of software.
I don't understand more than half of what is said on this list, although I do really try to follow along. And that is whole a lot more than I understand about how the use cases I outlined will actually work their computer magic. But if the talk of duplicate entries for different originating wikis means what I think it might mean, it strikes me as problematic.
BirgitteSB
I just wrote a very rough and quick walkthrough how to get that tool running:
https://www.mediawiki.org/wiki/Arcanist
My first impression is very good. The UI is very nice (it guides you
when it needs to, it just does the job if all is fine).
The user's guide is unfortunately poor.
I don't know yet how to avoid this warning:
This diff is for the 'E3Experiments' project but the working copy belongs to the '' project.
I see that arc can be also installed as the git pre-receive hook,
but it needs some project configuration for that. Interesting.
Anyway, I managed to download one change:
$ git branch -vv
* arcpatch-D3 be7cfd9 Merge branch 'master' of ssh://gerrit.wikimedia.org:29418/mediawiki/extensions/E3Experiments into munaf/pef2
master e40fce0 [origin/master] Rename events.js -> communityClicks.js
//Saper
> This isn't currently supported. You can see progress toward it here:
>
> https://secure.phabricator.com/T603
Except, of course, that I can't, because I (don't have a
(Facebook|Disqus|phabricator.org)|prefer not to use my (GitHub|Google))
account. I'm sure I'm not the only one who hits this wall.
> "policy.allow-public" affects future settings which will be available in the UIs built by T603.
Could you perhaps summarize what that means, time-wise? Is there
anything we (I) can do to push things forward?
--
Mark Holmquist
Contractor, Wikimedia Foundation
mtraceur(a)member.fsf.org
http://marktraceur.info