Hello,
Only in vector skin, many Wikipedias are now displaying "Navigation Menu"
(different languages) at the end of the side bar after content ends.
First noticed that in Arabic Wikipedia and got it fixed by adding
#mw-navigation h2 { position: absolute; top: -9999px; }
to mediawiki:vector.css which I got by examining the pages which didn't
have this bug including my watchlist and mediawiki messages (but
not including its history)
The problem doesn't exist in some other Wikipedias, including English
and Spanish.
Any idea how did that happen and what can we do to make a global fix?
--
Mido
TL;DR: Today we are launching an alpha, opt-in version of the
VisualEditor[0] to the English Wikipedia. This will let editors create
and modify real articles visually, using a new system where the
articles they edit will look the same as when you read them, and their
changes show up as they type enter them — like writing a document in a
word processor. Please let us know what you think[1].
Why launch now?
We want our community of existing editors to get an idea of what the
VisualEditor will look like in the “real world” and start to give us
feedback about how well it integrates with how they edit right now,
and their thoughts on what aspects are the priorities in the coming
months.
The editor is at an early stage and is still missing significant
functions, which we will address in the coming months. Because of
this, we are mostly looking for feedback from experienced editors at
this point, because the editor is insufficient to really give them a
proper experience of editing. We don’t want to promise an easier
editing experience to new editors before it is ready.
As we develop improvements, they will be pushed every fortnight to the
wikis, allowing you to give us feedback[1] as we go and tell us what
next you want us to work on.
How can I try it out?
The VisualEditor is now available to all logged-in accounts on the
English Wikipedia as a new preference, switched off by default. If you
go to your “Preferences” screen and click into the “Editing” section,
it will have as an option labelled “Enable VisualEditor”).
Once enabled, for each article you can edit, you will get a second
editor tab labelled “VisualEditor” next to the “Edit” tab. If you
click this, after a little pause you will enter the VisualEditor. From
here, you can play around, edit and save real articles and get an idea
of what it will be like when complete.
At this early stage in our development, we recommend that after saving
any edits, you check whether they broke anything. All edits made with
the VisualEditor will show up in articles’ history tabs with a
“VisualEditor” tag next to them, so you can track what is happening.
Things to note
Slow to load - It will take some time for long complex pages to load
into the VisualEditor, and particularly-big ones may timeout after 60
seconds. This is because pages have to be loaded through Parsoid which
is also in its early stages, and is not yet optimised for deployment
and is currently uncached. In the future (a) Parsoid itself will be
much faster, (b) Parsoid will not depend on as many slow API calls,
and (c) it will be cached.
Odd-looking - we currently struggle with making the HTML we produce
look like you are used to seeing, so styling and so on may look a
little (or even very) odd. This hasn't been our priority to date, as
our focus has been on making sure we don't disrupt articles with the
VisualEditor by altering the wikitext (correct "round-tripping").
No editing references or templates - Blocks of content that we cannot
yet handle are uneditable; this is mostly references and templates
like infoboxes. Instead, when you mouse over them, they will be
hatched out and a tooltip will inform you that they have to be edited
via wikitext for now. You can select these items and delete them
entirely, however there is not yet a way to add ones in or edit them
currently (this will be a core piece of work post-December).
Incomplete editing - Some elements of "complex" formatting will
display and let you edit their contents, but not let users edit their
structure or add new entries - such as tables or definition lists.
This area of work will also be one of our priorities post-December.
No categories - Articles' "meta" items will not appear at all -
categories, langlinks, magic words etc.; these are preserved (so
editing won't disrupt them), but they not yet editable. Another area
for work post-December - our current plan is that they will be edited
through a "metadata flyout", with auto-suggestions and so on.
Poor browser support - Right now, we have only got VisualEditor to
work in the most modern versions of Firefox, Chrome and Safari. We
will find a way to support (at least) Internet Explorer post-December,
but it's going to be a significant piece of work and we have failed to
get it ready for now.
Articles and User pages only - The VisualEditor will only be enabled
for the article and user namespaces (so you can make changes in a
personal sandbox), and will not work with talk pages, templates,
categories, etc.. In time, we will build out the kinds of specialised
editing tools needed for non-articles, but our focus has been on
articles.
Final point
This is not the final form of the VisualEditor in lots of different
ways. We know of a number of bugs, and we expect you to find more. We
do not recommend people trying to use the VisualEditor for their
regular editing yet. We would love your feedback on what we have done
so far – whether it’s a problem you discovered, an aspect that you
find confusing, what area you think we should work on next, or
anything else, please do let us know.[1]
[0] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor
[1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback
Yours,
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Since the switch from OggHandler to TimedMediaHandler we are one step
closer to supporting video on mobile browsers.
In fact, there's one it works in now -- Firefox for Android!
We've been able to close out this Firefox evangelism bug about our broken
mobile video:
https://bugzilla.mozilla.org/show_bug.cgi?id=728486
However, every other mobile browser I've tested doesn't support Ogg Theora
or WebM formats. Mobile Safari, Chrome, the old stock Android browser,
Opera Mobile, and the IE 10 engine in our Windows 8 tablet app will show
the thumbnail, but won't play the video because they need MP4/H.264.
Looking at the bug for adding transcoding...
https://bugzilla.wikimedia.org/show_bug.cgi?id=39869https://gerrit.wikimedia.org/r/#/c/25473/
...it looks like we may have support ready to go but disabled by default,
so not yet in use.
Just thought I'd check in on what it'll take to get it going. No immediate
rush, but.... I'd really love to have videos working on smartphones and
tablets, and not everybody runs Firefox. :)
-- brion
Dear friends,
This is to inform you all about the creation of the first MediaWiki group in India. For the past several days, I’ve been speaking to Quim Gil, Sumana and Yuvi Panda. I was informed about the setting up of local groups in different countries for technical contributors. With encouragement from all of them and with help from Noopur I submitted a proposal for the formation of MediaWiki Group Ahmedabad. This proposal has been endorsed by 7 people so far.
For those who might be interested in setting up similar groups, I think a Wikitech mailing list for India is being set up and personally, I would be happy to help you write a proposal for your community. I think it’s a great idea because with the help of this technical group we intend to make good technical infrastructure and editing environment for Gujarati Wikipedia easier to contribute to.
I have already ported HotCat and Popups(on the way) on Gujarati Wikipedia. Please have a look at the areas we want to collaborate on:
Areas of collaboration:
Localize Gadgets for Gujarati Wikipedia and Wikisource
Create New Gadgets and extensions
Bug solving for Gujarati Wikipedia and WikiSource and also other MediaWiki related Bug solving for all Indian languages
Translate into Gujarati Language, i.e http://translatewiki.net/
Wikidata
You can read the proposal here: https://www.mediawiki.org/wiki/Groups/Proposals/Ahmedabad
Your endorsements, improvements and feedback are welcome at the wiki
page. Thank you!
Harsh Kothari
PS: see also http://www.mediawiki.org/wiki/Groups/Proposals
---
Harsh Kothari
Research Fellow,
Physical Research Laboratory(PRL).
Ahmedabad.
Hi,
This afternoon, I migrated one of the main production English Wikipedia
slaves, db59, to MariaDB 5.5.28. We've previously been testing 5.5.27 on
the primary research slave, and I've been testing the current build for the
last few days on a slave in eqiad. All has looked good, and I spent the
last few days adapting our monitoring and metrics collection tools to the
new version, and building binary packages that meet our needs.
A main gotcha in major version upgrades is performance regressions due to
changes in query plans. I've seen no sign of this, and my initial
assessment is that performance for our workload is on par with or slightly
improved over the 5.1 facebook patchset.
Taking the times of 100% of all queries over regular sample windows, the
average query time across all enwiki slave queries is about 8% faster with
MariaDB vs. our production build of 5.1-fb. Some queries types are 10-15%
faster, some are 3% slower, and nothing looks aberrant beyond those
bounds. Overall throughput as measured by qps has generally been improved
by 2-10%. I wouldn't draw any conclusions from this data yet, more is
needed to filter out noise, but it's positive.
MariaDB has some nice performance improvements that our workload doesn't
really hit (better query optimization and index usage during joins, much
better sub query support) but there are also some things, such as full
utilization of the primary key embedded on the right of every secondary
index that we can take advantage of (and improve our schema around) once
prod is fully upgraded, hopefully over the next 1-2 months.
The main goal of migrating to MariaDB is not performance driven. More so,
I think it's in WMF's and the open source communities interest to coalesce
around the MariaDB Foundation as the best route to ensuring a truly open
and well supported future for mysql derived database technology.
Performance gains along the way are icing on the cake.
-Asher
Well, not really now, but starting in 15 minutes. Details at
https://www.mediawiki.org/wiki/Meetings/2012-12-13 and below.
What: Wikimedia Open Tech Chat
Where: Google Hangout/#wikimedia-dev (keep an eye on IRC or [1] for the
hangout URL)
Moderator: Rob Lanphier (robla on IRC)
Presenters:
* Chris McMahon: An update on browser test automation
* Amir Aharoni: Internationalisation dos and don'ts
* Pau Giner: Multilingual user testing
Cheers!
On Wed, Dec 12, 2012 at 10:43 AM, Siebrand Mazeland (WMF) <
smazeland(a)wikimedia.org> wrote:
> Hi there!
>
> Tomorrow at 20:30 UTC (12:30 PST, 21:30 CET, 02:00 IST) there will be
> another Wikimedia Open Tech Chat[1] on Google Hangout. This time there are
> three topics. I'd love to see you there. Please come!
>
> Topics:
> * An update by the Quality Assurance department on browser test automation
> * Internationalisation dos and don'ts: Why you should not merge your
> patch set, but request i18n/L10n review (Amir Aharoni)
> * Multilingual user testing for improving the Translate extension (Pau
> Giner)
>
> The Hangout URL will be published about 5 minutes in advance and Q&A can
> go through the #wikimedia-dev IRC channel on Freenode. If you're in San
> Francisco, consider joining in the flesh on the 6th floor of the Wikimedia
> Foundation SF office's "Collab" space. The session will last between 60 and
> 90 minutes.
>
> The session will be moderated by Rob Lanphier.
>
> [1] https://www.mediawiki.org/wiki/Meetings/2012-12-13
>
--
Siebrand Mazeland
Product Manager Language Engineering
Wikimedia Foundation
M: +31 6 50 69 1239
Skype: siebrand
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hi everyone,
As a result of some configuration we had to make for
Jenkins (more on this to come), I've simplified the ACLs
in all projects. Project Owners are now granted Verified
and Code Review permissions at the All-Projects level.
This was already the case in practice, but what I'm doing
is going through all projects and removing Verified and CR
permissions when the group is the same as the owner. I'll
be finishing this off today, so you may see some ACLs
continue to change for your repositories.
Again: there should be no noticeable difference to most
people, but if you encounter issues (like you can't review
something you used to be able to), please let me know.
-Chad
I get a "Too many redirects" error when trying to open this attachement
<https://bug-attachment.wikimedia.org/attachment.cgi?id=11489>
from this bug
<https://bugzilla.wikimedia.org/show_bug.cgi?id=42955>
Anyone an idea?
Cheers,
Denny
P.S.: I just saw that Daniel poste da bug on this
<https://bugzilla.wikimedia.org/show_bug.cgi?id=43061>
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hello,
Can you help us fix the Wikipedia Logo on bcl.wikipedia.org ?
The local community is asking for assistance.
--
Roman "Butch" Bustria Jr.
Vice President (2012-2013)
Wikimedia Philippines Inc.
------------------------------
The information contained in this message is privileged and intended only
for the recipients named. If the reader is not a representative of the
intended recipient, any review, dissemination or copying of this message or
the information it contains is prohibited. If you have received this
message in error, please immediately notify the sender, and delete the
original message and attachments.
Please consider the environment before printing this email.