Hi all,
(2nd attempt to post 2nd messge, sorry if this is a duplicate.)
We've started to document our thinking about page navigation, as part of a
project to use mediawiki for hosting longer structured texts (such as
books, or teacher professional development materials).
You can see an example of such navigation here:
http://oer.educ.cam.ac.uk/wiki/OER4Schools
where the red navigation box on the right lists all the pages belonging to
the resource, and there are 'previous' and 'next' buttons. This list is
automatically maintained, using the semantic extension.
It's documented here:
http://oer.educ.cam.ac.uk/wiki/EWTE#Wiki_navigation_between_pages.
with a simple example here:
http://oer.educ.cam.ac.uk/wiki/EWTE/nav
In some ways, it's quite close to what you can do with the book/collection
extension, and an example using that extension is given here:
http://oer.educ.cam.ac.uk/wiki/EWTE/booknav
Would one of the maintainers of that extension be interested in having a
look at the above links, and then be up for a chat, to see whether there is
overlap?
Thanks!
Bjoern
Please join us for the following tech talk:
*Tech Talk**:* A developer's-eye view of API client libraries: how to
choose them, how to make them, how to make them better
*Presenter:* Frances Hocutt
*Date:* January 6
*Time:* 1830 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=tech+talk%3A+API+c…>
Link to live YouTube stream <http://www.youtube.com/watch?v=hz__duVeaWY>
*IRC channel for questions/discussion:* #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/c8fnclmkeam2gbrn…>,
another
place for questions
*Talk description: *This talk will cover why developers do (and don't) use
any of the
wide variety of client libraries available to get and post data
through the MediaWiki API. We'll talk about writing tools with an eye
to developer experience, go through the "gold standard" for MediaWiki
API client libraries
(https://www.mediawiki.org/wiki/API:Client_code/Gold_standard) and the
thinking behind it, and share some of the resources available for both
library writers and library users.
If you write or maintain an API client library, you'll learn about
what you can do to help your library get out of the way and let
developers who work with it spend their mental energy on putting
together exciting projects, not on fighting with tools. If you work
with the MediaWiki API (write bots, do research, maintain wikis),
you'll learn what to consider when you're choosing a framework for
your project. Either way, you'll start to appreciate all the factors
beyond a library's code that make the difference between fun and easy
development and a frustrating slog.
It is an honor to announce that S Page[1] has moved from the Collaboration
(Flow) team to join the WMF Engineering Community team as a Technical
Writer[2]. We were really lucky to find such a great combination of English
communication skills, awareness of MediaWiki documentation pain points,
more-than-basic MediaWiki development experience, and Wikimedia community
mileage. Besides, S is self-driven, based in San Francisco, and accompanies
almost any reaction with a smile, assets of great value in his new position.
Or in his own words: "S Page, the old guy in the S.F. office in Jhane
Barnes shirts[3], feels compelled to write things down, now he'll be doing
it officially as he transfers from the Collaboration (Flow) team to the
Tech Writer position in the Engineering Community Team. He wrote
documentation for Sun's window systems and the innovative PenPoint
operating system and has a serious crush on software developers. When not
lowercasing the Invasion of Officious Pride Capitals, he lives to ski and
snowboard."
S will be responsible for leading the creation and maintenance of
documentation for third-party application developers and free software
contributors to Wikimedia projects. The three axes that define his initial
technical writing space are
1. Define the plan for a technical documentation hub[4]
2. Fix the documentation of the Architecture RfC process[5]
3. Work on T2001 (was Bug 1) blocking tasks[6]
While we expect S to write lots of docs, we actually hope that he shines in
his role coordinating technical documentation activities involving
developers and tech-curious editors with different affiliations and levels
of expertise. You’re welcome to make proposals and identify specific tasks
at mw:Talk:Documentation[7], or simply add the #Documentation tag to any
task in Phabricator that affects the documentation.[8]
As if all this would not be enough, S Page's first official assignment is
actually one that he carries from his previous position that fits perfectly
in the Engineering Community goals: deliver a Trello to Phabricator
migration script.[9]
Welcome S to your new role and to the Engineering Community team!
== References ==
[1] https://meta.wikimedia.org/wiki/User:SPage_(WMF)
[2] https://www.mediawiki.org/wiki/Engineering_Community_Team
[3] https://www.google.com/search?q=Jhane+Barnes+shirt&tbm=isch
[4] https://www.mediawiki.org/wiki/dev.wikimedia.org
[5] https://phabricator.wikimedia.org/T1107 and more
[6] https://phabricator.wikimedia.org/T2001
[7] https://www.mediawiki.org/wiki/Talk:Documentation
[8] https://phabricator.wikimedia.org/tag/documentation/
[9] https://phabricator.wikimedia.org/T821
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Changing the subject to narrow the subject:
On 22 December 2014 at 09:01, Guillaume Paumier <gpaumier(a)wikimedia.org>
wrote:
>
> - A new design for VisualEditor will come in January. You can try it
> now <https://test2.wikipedia.org/wiki/Test?veaction=edit> on test
> wikis. [4] <https://phabricator.wikimedia.org/T78054>
>
>
This is a reminder that this will roll out today (for non-Wikipedias) and
tomorrow (for Wikipedias) as part of the normal cycle.
If you find any issues, please file a ticket in Phabricator, e-mail me or
poke me on IRC.
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hello,
(2nd attempt to post, sorry if this is a duplicate.)
We're starting to use the translate extension on our wiki (
http://oer.educ.cam.ac.uk). Is this the right list to post a question on?
My question is: If you are going from one translated page (e.g. base page
in en, translated page in fr) to another page (in en) that has a
translation for the same language (fr), can you automatically stay in this
language? I.e. if you on [[A/fr]] you click on [[B]], can are you
automatically taken to [[B/fr]]? There seems to be some provisions for
this, but it's not clear to me.
Also, is it possible to add "languages" - for us it's not so much different
languages, but we're creating localised versions of a teacher education
resource for different contexts (which are mainly English-speaking), which
involves replacing things like "Zambia" with "Rwanda", but also more
complex adaptations.
Our resource is quite complex (e.g. extensive use of templates, and
semantic mediawiki) see
http://oer.educ.cam.ac.uk/wiki/OER4Schools - would somebody with MLEB
experience be happy to have a chat to see whether MLEB is the right tool?
Thanks!
Bjoern
Recently on https://developer.mozilla.org/ I noticed an easter egg
when you pop open the JavaScript console.
<snip>
"Interested in having a direct impact on hundreds of millions of users? Join
Mozilla, and become part of a global community that’s helping to build a
brighter future for the Web."
<snip>
I'm curious how successful this is but I wonder if we did the same
whether we might see some new contributors popping up?
Why don't we have a similar message linking to our mailing list /
phabricator instance / mediawiki.org homepage?
Thoughts?
This is basically a separate discussion, so I'm forking the thread.
Mark A. Hershberger wrote:
>MZMcBride <z(a)mzmcbride.com> writes:
>>><https://www.mediawiki.org/wiki/Version_check_and_opt-in_site_reporting>
>
>> Is there a reason you used the main article namespace instead of the
>> "Requests for comment/" pseudo-namespace? Your e-mail subject line says
>> "RFC" and this new page follows a previous RFC ("Opt-in site
>>registration during installation"), which makes the page title seem a
>>bit strange.
>
>This is a spec for a feature that was discussed in an RFC. Maybe I'm
>missing something about the process, but my impression was that the RFC
>was accepted and now all that is remaining is implementation.
I think some people view the RFC process much more formally than others.
By which I mean that I've always viewed RFCs as basically complements to
bug reports. I view them as fairly lightweight scratchpads that can be
used to provide context for, refine, and build ideas. This is in contrast
with a more structured approach that would typically involve an official
submission followed by approval or rejection by a small committee. While
the latter is not an unusual model, I personally don't think a strict
approach is a well-fitting model for Wikimedia development. :-)
>I didn't think it was necessary to put the specification in the RFC
>namespace since the RFC was accepted.
It's certainly not uncommon to simply throw pages in the main namespace on
mediawiki.org. We all do it occasionally. However, doing so makes it less
likely for others to find your page. Using the RFC structure (page title
prefix, infobox template, categories) makes it marginally more likely that
others might find and read your page.
One anti-pattern that I'm concerned with is that RFCs often do not have
associated discussion or related pages attached to them. We'll have
meetings about ideas or draft separate pages about ideas (on
mediawiki.org, on etherpad.wikimedia.org), but the RFC itself and its talk
page won't be updated accordingly with notes from related meetings,
transcripts of discussions, future action items, etc.
The RFC meeting index is in pretty bad shape currently:
<https://www.mediawiki.org/wiki/Architecture_meetings>. I've been thinking
that a checklist might help the meetings run more smoothly. This checklist
might include items such as announcing the time and topic of the meeting a
week in advance, informing the RFC participants of the upcoming discussion,
updating the relevant wiki indices when a meeting takes place, posting the
minutes to the wiki, and so on.
MZMcBride
Hi all,
I am all new to Mediawiki development and am working on this bug
<https://phabricator.wikimedia.org/T64305> as my first fix.
As i have understood, according to the mockup that has been have provided
in the bug description and the comments, I am first supposed to change the
text under an image which said 'Orginal File' to 'Full Resolution:' and
then provide a mean of downloading the original file in its original
uploaded format as well as in JPEG format.
So I thought of taking a top down approach by first editing the text under
the image and then implementing the download option. But i am having a
difficult time in figuring out where the HTML code for the page showing the
image lies. I was expecting a file somewhere that generates the HTML code
needed for that page to display. I ran the project in debugging mode and
looked line by line in execution as that page loaded but still could not
find any place that had the words 'Size of this preview:' or 'Other
resolutions:'. Can you please give me any clue on this?
Thanks,
Ruchiranga
Mark A. Hershberger wrote:
>I've published this at
><https://www.mediawiki.org/wiki/Version_check_and_opt-in_site_reporting>.
Hi.
Is there a reason you used the main article namespace instead of the
"Requests for comment/" pseudo-namespace? Your e-mail subject line says
"RFC" and this new page follows a previous RFC ("Opt-in site registration
during installation"), which makes the page title seem a bit strange.
MZMcBride
Hi everyone!
I've seen that Graphviz extension is being developed again! The old version
could parse the following graph:
<graphviz>
digraph W {
rankdir = LR ;
node[fontsize=10, fontcolor="blue", shape="none", style=""] ;
node [URL="/mw/index.php?title=\N"] ;
"User:MediaWiki default"
"User:MediaWiki default" [tooltip="MediaWiki default"] ;
"User:MediaWiki default" [fontcolor="#BA0000"];
"User:Us0"
"User:Us0" [tooltip="Us0"] ;
"User:Us0" [fontcolor="#BA0000"];
"User:Admin"
"User:Admin" [tooltip="Admin"] ;
"User:Admin" [fontcolor="#BA0000"];
"User:MediaWiki default" -> "Main Page" [ penwidth=2.0968239556951 label=1] ;
"User:Us0" -> "Main Page" [ penwidth=10.340079843406 label=6] ;
"User:Admin" -> "Main Page" [ penwidth=5.7720138182848 label=3] ;}</graphviz>
It seems that the new version doesn't understand any parameters except the
-> links. I'm having an error:
Error: No valid link was found at the end of line 2.
At Imagemap_body.php I see a lot of madness going on: regular expressions
and other horrible things. It seems that now Graphviz extension supports
only a little fraction of the dot language. Is that because of Imagemap?
Cheers,
-----
Yury Katkov