I added a section
http://www.mediawiki.org/wiki/Subversion#Undoing_changes
with some tips how to efficiently use "svn merge" to undo changes,
especially how to undo a specific changeset.
In addition, a hint was added how the
"svn merge ... --dry-run"
option can avoid headaches before doing something wrong.
I'm mailing you this so that everyone has a chance to improve or correct
the page - if this is needed.
Tom
Hallo.
How does SimpleSearch sort the search auto-completion? By the number
of links to the page? By some other popularity measurement?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi All,
Please join me in welcoming Jeremy Postlethwaite as a Software
Engineer in WMF’s Features Engineering team. Jeremy’s focus area will
be Fundraising. He will be joining Arthur Richards, Ryan Kaldari and
Katie Horn on the Fundraising engineering team to help make this
year’s fundraising drive successful.
Jeremy Postlethwaite has been a developer since 1996. He has been a
baker, a candy maker, a chef and a zymurgist. Fascinated with
technology, Jeremy has developed robotics, worked on nuclear energy
devices, such as the Z-machine, in conjunction with Lawrence Livermore
National Laboratory and Sandia National Laboratory. While working at
the Lawrence Livermore National Laboratory (LLNL), he developed code
to model plasmas in atomic physics. Jeremy is also interested in
artificial intelligence and is developing code in this area.
Jeremy tries to be an environmentalist and a humanitarian. And in
doing so, he tries to live by the words of the late and great sophist,
George Carlin, “If you think there is a solution, you are part of the
problem.” This helps to keep him on level ground! In times of
frustration, he tries to remember what Socrates said, “knowledge is
recollection,” meaning all the answers already exist, but it is our
duty to find them.
Jeremy also tries to remember that not all problems in the world can
be solved with a computer program. He is happiest when developing
applications on his computer, researching quantum mechanics and fusion
technology or best of all, camping in the redwoods with his wife, of
almost nine years, Christi and his three children: Marissa, Jeremiah
and Isaac.
He has contributed several thousand hours to Open Source projects,
including personal endeavors, helping others to use technology and
working on Zend Framework.
Jeremy does not own a television, but has several computers. He wishes
he had more time to read. Jeremy’s biggest problem with being human is
that he has to sleep.
Drop by and say hello to Jeremy online or in person at WMF in San Francisco.
Welcome Jeremy!
--
Alolita Sharma
Director, Features Engineering
Wikimedia Foundation
I suppose that most readers read the current versions of pages and not
the previous revisions.
Are there precise statistics about it? What percentage of readers
bother to look at the histories and the previous revisions?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
I discovered a small problem in the AJAX-Category picker as it is used
in file uploading on Commons.
In which part (product, component) of bugzilla should this bug be filed ?
Tom
Hi,
Just added 3 new committers to the bunch :)
Jeremy Postlethwaite - jpostlethwaite - WMF fundraising
Peter Gehres - pgehres - WMF fundraising
Christoph Kepper - ckepper - PediaPress developer, working on Collection
Welcome!
-Chad
Hey,
I just noticed this on line 567 of LocalizationCache.php: # Load deprecated
$wgExtensionAliasesFiles
Is this really deprecated? A lot of extensions, including several maintained
by core people, are still using it... What should be used instead?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Yesterday I ran a triage with Tomasz Finc, PediaPress (PP), and members
of the community on the Collection extension -- the tool that WMF sites
use for creating PDFs as well as ZIM (http://openzim.org/) files.
While Tomasz and I would have liked to get more MW developers to pick up
bugs, I was happy that to actually have some feedback from the
PP developers that will help us point to easier problems to
solve in the extension.
Also, due to personnel changes at PP, no one there had SVN commit
access. We were able to begin the process of resolving this and,
hopefully as a result, we'll get problems with the extension addressed
much more quickly.
You can find the lightly commented etherpad for the triage here:
http://hexm.de/6bhttps://bugzilla.wikimedia.org/28206 -- PDF generation does not support
Complex Script Wikis
We started off talking about several bugs that can all be summed up
under #28206.
Since we support several different languages with
not-very-well supported PDF creation tools and some without PDF
creation support at all, we are pushing the limits of the current
PDF creation tool.
After we discussing this, Volker Haas (a PP developer) said that the
underlying tool, ReportLab (http://www.reportlab.com/), was being
pushed to its limits and needed to be "rewritten from scratch".
PP doesn't have the resources to work on this right now, so I
updated the bug and assigned it to Tomasz so that he could begin to
figure out how we could solve it.
https://bugzilla.wikimedia.org/27462 -- <noinclude> showing in PDF
After input from PP, this bug looks like a relatively easy
to fix on the MW site. Sumana tagged it as such.
https://bugzilla.wikimedia.org/28060 -- Collection extension should not
add chapters in reverse order
https://bugzilla.wikimedia.org/28118 -- The path to images
Chris Kepper (a PP developer) said he would look at these, but also
confirmed that #28118 should be easy.
https://bugzilla.wikimedia.org/30511 -- Collection extension should
place time stamp of revision extracted into the offline file
Jessie Wild (Special Projects Manager in the Global Development at
WMF) requested this so that it would be easy to date the time a
collection was made.
The PP developers also confirmed that this one would be easy for a
MW developer to pick up -- and it doesn't involve PDF creation,
making it a particularly juicy target.
https://bugzilla.wikimedia.org/21653 -- Creating a PDF with collection
extension does not render the <pages> tag hook from proofread page
extension
At first, I didn't understand why this was needed. Luckily
helderwiki from ptwikibooks was in the triage and was able help me
understand its real need.
Ralf Schmitt (a PP developer) said he would work on this if time
permits.
https://bugzilla.wikimedia.org/22707 -- Cascading page protection for
/Print template subpages
Since this one can be solved by any MW programmer (but it involves
hooks and permissions, so I hesitate to tag it "easy"), I unassigned
it from the PP developers.
Ralf Schmitt suggested that some of the concerns about hijacking a
page could be addressed by having a "See what this page looks like
printed" mode.
https://bugzilla.wikimedia.org/28064 -- Collection extension needs some
way to credit original authors of a work
Since helderwiki (mybugs on bugzilla) was in the triage, xe took the
chance to champion this bug. There is no established established
way of tracking non-wiki authors in MW, so there wasn't anything
that the Collection extension could do here right now. helderwiki
tracked down Bug #27629 (https://bugzilla.wikimedia.org/27629
"Summary of page editors/authors") and added it as a dependency for
the bug.
http://bugzilla.wikimedia.org/27952 -- openZim export should not drop
categories
There was some confusion about this one. I gave it back to Tomasz
so he could get some clarification from ErikM for what was needed.
https://bugzilla.wikimedia.org/21504 -- Collection PDF generation
doesn't handle <ruby> elements
Can't test since URL doesn't work. Tagged "testme" and asked if
someone could attach a testcase to the bug for future reference.
https://bugzilla.wikimedia.org/28061 -- Collection extension doesn't sort
chapters when the user clicks on "Sort alphabetically"
Volker Haas said this one was really a UI bug -- something the PP
developers were currently working on.
https://bugzilla.wikimedia.org/26533 -- Collection extension should
accept lists of chapters generated by templates (e.g. expanding
templates of a collection page before loading the collection)
Resolved WONTFIX by Ralf Schmitt because of the complexity involved.
https://bugzilla.wikimedia.org/20616 -- Name of excluded-in-print
category cannot start with a namespace name
Resolved WONTFIX by Ralf Schmitt since everthing was working as
designed.
https://bugzilla.wikimedia.org/26330 -- collection contents lost when
only loading js via https
Resolved WORKSFORME
Thanks to all who participated. There are a couple more followups on
this triage, but those will wait for another email.
Mark.
> On Sat, Aug 20, 2011 at 8:35 PM, Max Semenik <maxsem.wiki(a)gmail.com> wrote:
>> On 20.08.2011, 22:23 Martijn wrote:
>>
>>> On wikimedia projects that are not Wikipedia (Wikia in specific comes
>>> to mind) I often find myself using templates that have not been
>>> defined on that installation. The English Wikipedia (which I am most
>>> familiar with) has many very usefull templates, especially the
>>> {{citeFoo}} templates, but numerous others as well. Trying to 'import'
>>> one is a bit of a pain though. Many templates depend on other
>>> templates, and it is not often very clear how (as a fun exercise for
>>> the reader, try to import the {{convert}} template to a new wiki, and
>>> see how easy it is!). I was wondering if it might be a good idea to
>>> include a standard template library to Wikimedia installations,
>>> containing a set of utility templates along with the Wikimedia
>>> distribution. I'm cross-posting foudation, for possible discussion if
>>> this is desirable, and wikitech, for possible discussion if this is
>>> feasable.
>>
>> Don't forget, English is one of 300-something languages we support.
>> And users of other languages typically don't feel comfortable with
>> using English templates, because words like "cite book", "author" and
>> "link" are meaningless to them. So we're speaking about 300+ sets of
>> templates. This is both unmaintainable and burdensome. And don't
>> forget, not every MediaWiki (that's how our software is called, not
>> Wikimedia!) will want them. I would suppport a system that downloads
>> them on-demand, however shipping zillion templates out of the box is
>> simply out of the question.
>>
>>
>> --
>> Best regards,
>> ?Max Semenik ([[User:MaxSem]])
>>
>
> eh, Derp on the MediaWiki/Wikimedia, dunno where that came from. Also
> I'm not proposing to export all the en.wiki templates, but rather
> establish a core set of templates that could be exported (and
> translated!) on demand.
>
>
> Regards,
>
> Martijn
The English Wikipedia has useful templates for an encyclopedia.
MediaWiki-software is useful for making an encyclopedia, but doesn't
have to be forced to be one. If someone wants a template from en.wp,
they will export it and import it at their own MediaWiki-install. If
that takes two hours, it says more about the total mess of the en.wp
template structure, then about the 'lack of standard templates' in a
MediaWiki-install. It will still take a considerable amount of time to
import a template with standard templates in place.
Then there will be a discussion what will be useful templates for a
new MediaWiki install. If you decide to ship a MediaWiki install with
a set of templates, the best case is that they will use all templates.
Every worse case is that they will end up with a few templates they
can use/want to use and lots and lots of junk.
Furthermore I am wondering who wants to maintain such an arbitrary
bunch of templates for 200 languages? It's not only the name of the
templates that need to be translated. The contents of every template,
including transclusions of other templates and language-specific
outcome of 'magic words' (for example in {{#ifeq: }}-statements) need
to be translated. If one wants to import a template from en.wp, he/she
has to import templates and templates where that template is depending
on like before. Now they have to translate the inclusion of standard
templates too, because on their wiki these standard templates now have
names in their custom language.
Sumurai8
I haven't been receiving any emails notifying me of user talk page changes
for quite some time now. I do have it enabled in my preferences. There
doesn't seem to have been much point enabling this for en.wiki if it's meant
shutting it down for all wikis.
-- Adrignola