Hi all,
Firstly, thank you very much for enabling DPL on all Wikisources! [1] It is
IMO a pity that this request was fulfilled based only in a direct request,
but at least it is now enabled.
I'm no longer involved on Wikimedia projects like in the past years, but I'm
still looking their development, for research pursposes. A lot of things
have changed on this time, but the issue of simply shell requests generating
a backlog don't seems to be one of those.
Please help us to develop Wikimedia contents in foreign languages simply
giving 30 minutes each week to check those requests!
Examples of backlogs:
25609 <https://bugzilla.wikimedia.org/show_bug.cgi?id=25609> Enable
liquidthreads for the Wikimedia Brasil wiki (waiting since 2010-10-21)
28290 <https://bugzilla.wikimedia.org/show_bug.cgi?id=28290> Create
namespaces Page and Index for Esperanto Wikisource (waiting since
2011-03-28)
28686 <https://bugzilla.wikimedia.org/show_bug.cgi?id=28686> Enable
namespace "Mutirões:" for WIkimedia Brasil (wainting since 2011-04-24)
Best,
--[[:m:User:555]]
[1] - http://lists.wikimedia.org/pipermail/wikisource-l/2011-May/000973.html
Yesterday, since Amir E. Aharoni, an RTL developer who has been
actively helping out by testing and filing RTL bugs, was at the
Berlin Hackathon along with Siebrand from TranslateWiki, it was the
perfect time to hold an RTL triage.
During the triage a developer made the point that screenshots help a
lot in RTL bugs. Often the person filing the bug does not use English
regularly so their bug report isn't clear. A screenshot that
demonstrates the problem, along with the URL that produced it, helps a
great deal.
Of course, this doesn't apply only to RTL bugs as even native English
speakers could often clarify their bug report with a screenshot.
During the triage, we looked at the list of RTL blockers on tracking
bug #745
Bug 6100 — Allow different directionality (rtl/ltr) for user interface
and wiki content
http://bugzilla.wikimedia.org/6100
This is a particularly important bug for multilingual sites like
Commons and Incubator. Amir has said he will be willing to test
this as soon as anything is committed and deployed on
TranslateWiki.
Of course, if this is fixed, then we'll need a way specify the
directionality for a page. Amir opened Bug 28970 to request this
functionality.
A number of other RTL bugs (e.g, 4236 “BiDi support for the
personal toolbar,” 13477 “Tabs collapsed on LTR wikis for RTL
users”, and 4236 “Bidi support for the personal toolbar”) would be
solved by fixing this bug.
Bug 28994 — Special pages such as watchlist and recent changes should be
tabular
http://bugzilla.wikimedia.org/28994
A few bugs mentioned RTL formatting problems on Special Pages.
Amir pointed out that much of this was tabular data that would be
better suited to table layout than list layout. Using table
layout each cell of the table could specify the textual direction
and the problems could be solved.
Amir opened this request after the triage.
Bug 13285 — Background incorrectly extended in RTL wikis when using IE
http://bugzilla.wikimedia.org/13285
This one actually looks like it was mis-titled. We're not
positive yet (and have asked Trevor to have a look), but it looks
like the problem was the background image for arwiki's monobook skin.
Bug 24204 — Problem with external link arrow in rtl languages
http://bugzilla.wikimedia.org/24204
The problem described here is actually a browser bug that we
pushed upstream last year. We decided to close this bug since it
isn't one that we can fix and the problem is already reported, and
claimed to be fixed, upstream
(https://bugs.webkit.org/show_bug.cgi?id=9272).
Bug 4039 — BiDI: please preserve dir="ltr" and dir="rtl" in TOC
http://bugzilla.wikimedia.org/4039
As Amir explained, this is not a MediaWiki bug, but a part of a
family of feature requests to make true BiDi editing
easier. Currently it can be solved by inserting LRMs in the right
places.
Bug 9316 — checkbox alignment in protection form
http://bugzilla.wikimedia.org/9316
Apparently this has been fixed … maybe in Vector, but maybe no one
has checked since Brion last looked in 2007.
Bug 12242 — directionality is not present in action=render
http://bugzilla.wikimedia.org/12242
If you're fetching content using action=render, it is your
responsibility to make sure it is rendered correctly. Usually,
people should be using the API for getting doing wikitext->html.
Bug 12151 — Bidi problem at Special:RenameUser
http://bugzilla.wikimedia.org/12151
This can't happen any more because of SUL, but even if it could,
bug 6100 (above) would probably take care of the fix.
The remaining three we discussed, we tested and found fixed:
Bug 3621 — BiDi: evaluate LRM, RLM, followed by "*", "#", ":", ";" …
http://bugzilla.wikimedia.org/3621
Bug 12079 — BiDi problem at History/Diffs
http://bugzilla.wikimedia.org/12079
Bug 12225 — influencing the BiDi algorithm to clearly distinguish
between the signature
http://bugzilla.wikimedia.org/12225
Till next week, happy hacking!
Mark.
It looks to me like this code is a trope:
if ( $repo->isVirtualUrl( $path ) ) {
$path = $repo->resolveVirtualUrl( $path );
}
Or in this form:
if ( self::isVirtualUrl( $file ) ) {
// This is a virtual url, resolve it
$path = $this->resolveVirtualUrl( $file );
} else {
// This is a full file name
$path = $file;
}
Can we replace it by a resolveVirtualUrl which simply returns what it was given if there is no mwrepo:// at its beginning?
And ... there are only two calls to isVirtualUrl which are not part of this trope, and one of them is labelled with FIXME. :) The other one is used as a front-end to splitVirtualUrl, which does its own check to see if the url is virtual, and it's only called in one place.
Simplify, simplify!
Anybody object to me refactoring this code?
So here at the Wikimedia main office in San Francisco we've got a spiffy
printer upstairs that can churn out large posters, banners, etc (24" / circa
60cm wide). I've been thinking that the walls in Engineering could use some
decoration, and am looking around for some nicely thematic things.
An obvious candidate is the database layout diagram:
http://www.mediawiki.org/wiki/File:MediaWiki_database_schema_1-17_%28r82044…http://www.mediawiki.org/wiki/Manual:Database_layout
Any other nice poster-size visualizations hiding around?
-- brion
A few people (including myself) have expressed some concerns about the way
in which the mobile site is being rewritten. I don't really think Bugzilla
or MediaWiki.org are the appropriate forums for this, but this list probably
is. (I assume Patrick Reilly is subscribed to this list. CC'ing him in any
case.)
The previous mobile site was written in Ruby and does some of its own
parsing. The rewrite is written in PHP and many people seem to agree that it
should be some sort of "skin" system so that it's adaptable to other
MediaWiki installations and doesn't try to do anything too crazy (like
re-implement the parser). There are concerns that the current rewrite
approach (in SVN in an extension called "PatchOutputMobile" for those
curious) isn't the best, but it's completely possible there are reasons for
the way it's being re-implemented.
Patrick or Tomasz: can you give an overview of what the current
re-implementation strategy is?
* Relevant bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=25558
* Relevant MediaWiki page: http://www.mediawiki.org/wiki/Mobile_site_rewrite
MZMcBride
(I apologise for breaking the thread)
>The reason that I went the route of creating an extension vs a skin was that
>I wanted the most flexibility in adapting the content for mobile device
>rendering. There are a number of sections that need to be removed from the
>final output in order to render the content effectively on mobile devices.
>So, being able to use a PHP output buffer handling is a nice feature. I also
>wanted the ability to use many of the features that are available when
>writing an extension to hook into core functionality.
>
>-- Patrick
Sorry, but this is a poor excuse.
Categories were introduced in 2003 and are celebrating
their 8th anniversary this year.
One thing that I would like to do in Wikipedia is:
A category that spans a scale, e.g. people by date
of birth. Today we use [[Category:1823 births]] to
group people born in that year, where the category
page has links to the previous and next year, and
possibly to supercategories by decade or century.
I would like to index people by birth *date* along a
timeline, from where any subsection could be listed.
Some kind of {{#select: ...}} could be used to find
a subsection from this index. Instead of category
pages, some continuously scrolling page should be
used. Just like Google Maps, when you scroll one
way, new content should be retrieved by API, and
presented in the same Javascript scrolling page.
Maybe "category" is the wrong word to describe
this function, but today we use categories because
we have no better way. A possible extension is
2-dimensional ranges, for geographic coordinates.
Does any extension like this already exist?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
.png){kind=link}