As multilingual content grows, interlanguage links become longer on
Wikipedia articles. Articles such as "Barak Obama" or "Sun" have more than
200 links, and that becomes a problem for users that often switch among
several languages.
As part of the future plans for the Universal Language Selector, we were
considering to:
- Show only a short list of the relevant languages for the user based on
geo-IP, previous choices and browser settings of the current user. The
language the users are looking for will be there most of the times.
- Include a "more" option to access the rest of the languages for which
the content exists with an indicator of the number of languages.
- Provide a list of the rest of the languages that users can easily scan
(grouped by script and region ao that alphabetical ordering is possible),
and search (allowing users to search a language name in another language,
using ISO codes or even making typos).
I have created a prototype <http://pauginer.github.io/prototype-uls/#lisa> to
illustrate the idea. Since this is not connected to the MediaWiki backend,
it lacks the advanced capabilities commented above but you can get the idea.
If you are interested in the missing parts, you can check the flexible
search and the list of likely languages ("common languages" section) on the
language selector used at http://translatewiki.net/ which is connected to
MediaWiki backend.
As part of the testing process for the ULS language settings, I included a
task to test also the compact interlanguage designs. Users seem to
understand their use (view
recording<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>),
but I wanted to get some feedback for changes affecting such an important
element.
Please let me know if you see any possible concern with this approach.
Thanks
--
Pau Giner
Interaction Designer
Wikimedia Foundation
context
-------
i’m working on a mediawiki extension,
http://www.mediawiki.org/wiki/Extension:GWToolset, which has as one of its
goals, the ability to upload media files to a wiki. the extension, among
other tasks, will process an XML file that has a list of urls to media
files and upload those media files to the wiki along with metadata
contained within the XML file. our ideal goal is to have this extension run
on http://commons.wikimedia.org/ <onhttp://commons.wikimedia.org/>.
background
----------
h
ttp://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_Co…<http://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_C…>
Metadata Set Repo
-----------------
one of the goals of the project is to store Metadata Sets, such as XML
under some type of version control. those Metadata Sets need to be
accessible so that the extension can grab the content from it and process
it. processing involves iterating over the entire Metadata Set and creating
Jobs for the Job Queue which will upload each individual media file and
metadata into a media file page using a Mediawiki template format, such as
Artwork.
some initial requirements
• File sizes
• can range from a few kilobytes to several megabytes.
• max file-size is 100mb.
• XML Schema - not required.
• XML DTD - not required.
• When metadata is in XML format, each record must consist of a single
parent with many child
• XML attribute lang= is the only one currently used and without user
interaction
• There is no need to display the Metadata sets in the wiki.
• There is no need to edit the Metadata sets in the wiki.
we initially developed the extension to store the files in the File:
namespace, but we were told by the Foundation that we should use
ContentHandler instead. unfortunately there is an issue with storing
content > 1mb in the db so we need to find another solution.
1. any suggestions?
Mapping
-------
a mapping is a json that maps a metadata set to a mediawiki template. we’re
currently storing those as Content in the namespace GWToolset. an entry
might be in GWToolset:Metadata_Mappings/Dan-nl/Rijkmuseum.
1. does that namespace make sense?
a. if not, what namespace would you recommend?
2. does this concept make sense?
a. if not, what would you recommend?
Maintaining Original Metadata Snippet & Mapping
-----------------------------------------------
another goal is to link or somehow connect the original metadata used to
create the mediafile:
• metadata set
• metadata snippet
• metadata mapping
the current thought is to insert these items as comments within the wiki
text of the media file page
1. does that make sense?
a. if not, what would you recommend doing?
2. is there a better way to do this?
mediawiki template parameters
-----------------------------
the application needs to know what mediawiki template parameters exist and
are available to use for mapping media file metadata to the mediawiki
templates. for the moment we are hard-coding these parameters in a db table
and sometimes in the code. this is not ideal. i have briefly seen
TemplateData, but haven’t had enough time to see if it would address our
needs.
1. is there a way to programatically discover the available parameters for
a mediawiki template?
thanks in advance for your help!
dan
Hi everybody,
in December I mentioned the idea of having a "PATCH_AVAILABLE" or
"PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate
the idea once we have automatic notifications from Gerrit into Bugzilla
in place [2]. This is now the case [3].
>From the Amsterdam Hackathon I know that some developers would like to
filter on bug reports that have or don't have a patch in Gerrit, and
easier finding of bug reports with a corresponding patch && lack of
recent changes might provide another entry point for new developers
(pick up the existing patch and finish it).
Hence I propose
* to remove the manually set and error-prone Bugzilla keyword
"patch-in-gerrit": Every bug on its way to get RESOLVED FIXED
has to pass this stage anyway so a status feels more
appropriate, and
* to make the "Gerrit Notification Bot" automatically change the
bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in
Bugzilla when a patch for that bug report has been committed
(not: merged) to Gerrit.
Comments?
andre
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html
[2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065226.html
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=17322
PS: Making the Gerrit notification bot automatically close bug reports
in Bugzilla after merging a patch in Gerrit, or differentiating in
Bugzilla between "RESOLVED FIXED" (fix merged) and "RELEASED" (fix
deployed on the Wikimedia wikisites) are also interesting topics to
discuss at some point, but not in this thread. One step at a time.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
The extension OpenID loads a CSS file via RL:
$myResourceTemplate = array(
'localBasePath' => $path . '/skin',
'remoteExtPath' => 'OpenID/skin',
'group' => 'ext.openid',
);
...
$wgResourceModules['ext.openid.icons'] = $myResourceTemplate + array(
'styles' => 'openid.css',
'dependencies' => array(
'ext.openid'
)
);
openid.css comprises lines such as
#openid_provider_OpenID_icon { /*@embed*/background-image:
url(icons/OpenID_large.png); }
Question:
=========
How to contruct the background-image filename from a value in one of the
OpenID PHP modules ?
Hi.
As <https://bugzilla.wikimedia.org/show_bug.cgi?id=50552#c0> explains,
MediaWiki's current README file isn't as strong as it could be. Following
discussion on that bug report, there's now a wiki page that can be used to
freely edit MediaWiki's README: <https://www.mediawiki.org/wiki/README>.
In the past few days, I think significant progress has been made in
cleaning up the README. If anyone has thoughts about what it should or
shouldn't include, please feel free to reply on this mailing list, on the
bug report, or be bold and contribute directly to the wiki page. :-)
MZMcBride
Hi everyone,
There have been a couple of conversations recently and I am hoping to
combine them into a discussion towards a long term strategy for math on
Wikipedia.
To get things rolling, I've added a few topics below which a strategy could
address.
Perhaps a disclaimer: I manage the MathJax project. Also, I've tried to be
brief but I may have compressed too much.
Peter.
(1) math output
Currently, low resolution PNGs are the default and registered users have an
option for MathJax (except on mobile). MathML3 is the web standard for math
and part of HTML5 and epub3.
Does Wikipedia want to adopt MathML output in the long term?
MathML is still facing a chicken-and-egg problem: little browser support
means little content means little browser support etc. While it's been in
use for over a decade, most MathML is hidden on intranets (technical
documentation) and behind paywalls (publishing). But there's clearly demand
-- e.g. MathJax CDN gets 65 million unique visitors per month.
Wikipedia's long term adoption of MathML would help this crucial web
standard for education and research since browser vendors will see the
content on the open web.
But a web standard is not a value in itself -- luckily MathML has real
advantages.
* accessibility
The few existing math accessibility tools (MathPlayer, ChromeVox, FireVox)
only work with MathML. Modern accessibility features like synchronized
highlighting (for learning disabled readers) is basically impossible with
image rendering.
* rendering quality
Image renderings are not only inaccessible, they lack quality and
flexibility. Reflow, CSS, alignments are the classic problems. Static
images could be improved via SVG but even these would not be accessible or
participate in line breaking. MathML integrates naturally into HTML.
* dynamic content
Math and science are becoming native on the web -- data and markup is not
forced into image renderings anymore, instead dynamic and interactive
content is finally showing up.
These don't fit into the current authoring and rendering solution on
Wikipedia. MathML would be a critical first step towards richer scientific
content.
* editing
Editing math is an obstacle for Wikipedia users. The GSoC project for math
in VE has a lot of potential to lower the barrier. But a live preview is
not very feasible with server side image generation.
(2) math input
wikitext is human readable and serialized so MathML does not seem to fit.
But TeX-syntax is robust and powerful to create any MathML construct. Texvc
has limitations (unicode support, graphical and dynamic content), but the
syntax could be extended to overcome these and to produce dynamic content
(mathapedia is a nice example).
An extended TeX-like syntax might serve as a safe abstraction for tools
like d3.js, processing.js, ensuring that Wikipedia content is not dependent
on specific rendering solutions. The same holds for physical, chemical and
biological markup. Such TeX extensions do make backwards compatibility to
real TeX/LaTeX more difficult.
(3) First steps towards a transition.
Client-side, only Firefox has decent support, so a polyfill like MathJax
would be needed for a while. Performance, especially on mobile, would need
a thorough investigation.
Server side, there are a number of tools for converting TeX to MathML, in
particular the recent work by Martin Schubotz towards integrating LaTeXML
(a fully featured LaTeX to XML converter); there's also BlahTeX and MathJax
via js-runners.
The question regarding new forms of content and wikitext might be important
for both client and server side solutions.
To pull in the entire community, something like bug 48036 (easier MathJax
opt-in) would be great. It would allow people to vote with their feet and
tell us continually if the benefits of MathML are worth the cost.
All,
The developer team at Wikimedia is making some changes to how accounts
work, as part of our on-going efforts to provide new and better tools
for our users (like cross-wiki notifications). These changes will mean
users have the same account name everywhere, will let us give you new
features that will help you edit & discuss better, and will allow more
flexible user permissions for tools. One of the pre-conditions for
this is that user accounts will now have to be unique across all 900
Wikimedia wikis.[0]
Unfortunately, some accounts are currently not unique across all our
wikis, but instead clash with other users who have the same account
name. To make sure that all of these users can use Wikimedia's wikis
in future, we will be renaming a number of accounts to have "~” and
the name of their wiki added to the end of their accounts' name. This
change will take place on or around 27 May. For example, a user called
“Example” on the Swedish Wiktionary who will be renamed would become
“Example~svwiktionary”.
All accounts will still work as before, and will continue to be
credited for all their edits made so far. However, users with renamed
accounts (whom we will be contacting individually) will have to use
the new account name when they log in.
It will now only be possible for accounts to be renamed globally; the
RenameUser tool will no longer work on a local basis - since all
accounts must be globally unique - therefore it will be withdrawn from
bureaucrats' tool sets. It will still be possible for users to ask on
Meta for their account to be renamed further, if they do not like
their new user name, once this takes place.
A copy of this note is posted to meta [1] for translation. Please
forward this to your local communities, and help get it translated.
Individuals who are affected will be notified via talk page and e-mail
notices nearer the time.
[0] - https://meta.wikimedia.org/wiki/Help:Unified_login
[1] - https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement
Yours,
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Jimmy just tweeted this:
https://twitter.com/jimmy_wales/status/362626509648834560
I think that's the first time I've seen him say "fuck" in a public
communication ...
Anyway, I expect people will ask us how the move to all-SSL is
progressing. So, how is it going?
(I've been telling people it's slowly moving along, we totally want
this, it's just technical resources. But more details would be most
useful!)
- d.
GSoC mentors: read this email through and submit your mid-term
evaluation between 29 July - 2 August in Google Melange. One per project
is enough. If the primary mentor can't make it then the secondary mentor
needs to step in.
VERY IMPORTANT
Missing this deadline means the cancellation of your student's GSoC
project. It also means "damage points" for Wikimedia in the current and
future GSoC editions.
You have the questions of the evaluation below, and you can start
preparing it now. Please add "Mid-term evaluation: WIP" in the table at
https://www.mediawiki.org/wiki/Summer_of_Code_2013 now (so your student
and the org admins know that you are on it). After submitting it change
that line with "Mid-term evaluation: OK".
Students: do not hesitate pinging your mentors about this evaluation if
you don't hear from them. Also remember that your monthly reports are
expected during next week.
https://www.mediawiki.org/wiki/Summer_of_Code_2013#Reporting
Thank you to everybody!
PS: fwiw I'm starting a week of holidays tomorrow and then I will be
flying to Hong Kong for Wikimania on Aug 1-2. If you need and org admin
Lydia Pintscher will be able to help you.
-------- Original Message --------
Subject: [GSoC Mentors Announce] 2013 Google Summer of Code Mentor
Midterm Evaluations 29 July - 2 August
Date: Sun, 21 Jul 2013 13:49:11 -0700
From: Carol Smith <carols(a)google.com>
Reply-To: gsoc-mentors-announce+owners(a)googlegroups.com
To: GSoC Mentors Announce <gsoc-mentors-announce(a)googlegroups.com>
Hi GSoC 2013 Mentors and Org Admins,
Per the program timeline [0], starting on Monday, 29 July you will will
be able to submit an evaluation of your student(s)' progress on their
projects thus far. Here's some important info on midterm evaluations for
those not familiar:
Midterm evaluations are done via Melange [1]. Starting at 19:00 UTC on
29 July you will be able to submit an evaluation for your student(s).You
can find the evaluation links on your dashboard under 'Evaluations', one
for each student you are a mentor (or co-mentor) for. If you are curious
about who can see evaluations after they are submitted, please check out
the FAQ on Evaluations [2]. I have also pre-published the evaluation
questions below in this email so you can prepare. The deadline is 19:00
UTC on Friday, 2 August.
You may not submit your evaluation before or after the evaluation
window. Please ask your org admin to submit your evaluation for you if
you absolutely cannot submit yours during the time allotted. Primary
mentors, co-mentors, and org admins may all submit evaluations of their
students.**Students must have an evaluation on file from both themselves
*and* their mentors in order to receive their midterm payments.** There
is no excuse for missing the submission of a student's evaluation.
You must submit an evaluation for every student you are the primary
mentor for this year. You must fill out the entire survey in one session
as there's no auto-save in Melange. You may submit, modify, and resubmit
an evaluation as many times as you choose up until the deadline.
Please note that failing a student at the midterm evaluation means *this
student is immediately removed from the program.* There is no way to
fail a student at the midterm and have the student continue with the
program to try to "make it up" at the final. If your student fails, your
student is out.
You might find the FLOSS manual on GSoC evaluations [3] helpful as well.
There's some excellent wisdom in there from your fellow mentors and org
admins on the evaluation process.
Finally, a reminder: This year we will not allow any mentor who misses
an evaluation deadline to attend the mentor summit (assuming no one else
submits the evaluation on the mentor's behalf before the deadline
either). Also, any org that misses 2 or more evaluation deadlines (for
the midterm, final, or midterm and final combined) will not be invited
to attend the mentor summit this year.
Please let me know directly if you have questions or concerns.
[0] - http://www.google-melange.com/gsoc/events/google/gsoc2013
[1] - http://google-melange.com <http://google-melange.com/>
[2] -
http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc20…
[3] - http://www.booki.cc/gsoc-mentoring/evaluations/
Cheers,
Carol
------
1.
How many years have you been a mentor for Google Summer of Code
(Total - this doesn’t have to be consecutive)?
1.
This is my first year
2.
2-3 years
3.
More than 3 years
2.
If you answered 2-3 years or more than 3 years, what years did you
participate?
3.
How many years have you been a student in Google Summer of Code?
1.
I have never been a student
2.
1 year
3.
2 years
4.
3+ years
4.
If you answered 2 years or 3+ years, what years did you participate?
5.
At what point did you first make contact with your student?
1.
Before the program was announced
2.
After my organization was selected to participate in Google
Summer of Code
3.
During the student application/acceptance phase of the program
4.
During the community bonding period
5.
After the start of coding
6.
How often do you and your student interact?
1.
Daily
2.
Every few days
3.
Weekly
4.
Every few weeks
5.
Monthly
6.
Less than once a month
7.
How do you communicate with your student? (Check all that apply)
1.
Google+ Hangout
2.
Voice (phone, Skype, etc.)
3.
IM/IRC
4.
Private emails
5.
Mailing Lists
6.
Student blog updates
7.
In-person meeting(s)
8.
Other
8.
Of the communication methods listed above, which do you use most
frequently?
9.
How much time do you spend on Google Summer of Code per week (take
into consideration your interactions with your student as well as
time working with your org and on your own)?
1.
1-5 hours
2.
5-10 hours
3.
10-15 hours
4.
15-20 hours
5.
More than 20 hours per week
10.
How many time zones apart from your student are you?
1.
Less than 3
2.
3-6
3.
More than 6
11.
How often do you require status updates from your student?
1.
Daily
2.
Every few days
3.
Weekly
4.
Only when explicitly asked for by me
12.
Please rate the quality of your interactions and communications with
the student (consider his/her communication with you as well as your
responses).
1.
Very Good (Student is regularly responsive and the quality of
communication is high)
2.
Good (Student is somewhat responsive and the quality of
communication is okay)
3.
Bad (Student is only somewhat or not at all responsive and the
quality of communication is low)
13.
Please rate the quality of the student’s interactions with your
organization and community.
1.
Very Good (Student is regularly responsive and the quality of
communication is high)
2.
Good (Student is somewhat responsive and the quality of
communication is ok)
3.
Bad (Student is only somewhat or not at all responsive and the
quality of communication is low)
14.
Is your student on track to complete his/her project?
1.
The student has already completed his/her project
2.
He/she is ahead of schedule
3.
He/she is on schedule
4.
He/she is behind schedule
15.
Please rate the quality of code/work the student has produced thus far.
1.
Amongst the best people I’ve ever worked with
2.
Solid-quality performance
3.
Good performance
4.
Mediocre performance
5.
Disappointing or not performing at all
16.
How do you feel about the new Google Summer of Code timeline?
1.
Less accommodating to my school/work schedule
2.
Equally accommodating to my school/work schedule
3.
More accomodating to my school/work schedule
17.
If you answered “less accommodating” above, what would be a better
schedule for you?
18.
Give an example of a very good or very bad interaction you had with
your student.
19.
Anything else you’d like to tell us or suggestions on how we could
improve the program?
20.
For the midterm evaluation, should this student pass or fail?
1.
Pass
2.
Fail
--
You received this message because you are subscribed to the Google
Groups "Google Summer of Code Mentors Announce List" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to gsoc-mentors-announce+unsubscribe(a)googlegroups.com.
Visit this group at http://groups.google.com/group/gsoc-mentors-announce.
For more options, visit https://groups.google.com/groups/opt_out.
Below you can find the condensed version of changes made to the WMF
Engineering Roadmap made over the last week. For the full roadmap, see:
http://www.mediawiki.org/wiki/Roadmap
For the diff used to create the below summary, see:
http://www.mediawiki.org/w/index.php?title=Roadmap&diff=748215&oldid=731898
Any questions/clarifications, please don't hesitate to ask!
Greg
== AFT ==
* July: remove from dewiki, support frwiki pilot, start winding down
development
* August: support frwiki and other wikis
== Echo ==
* July: HTML email notifications, release on meta & frwiki
* Aug: relase on more wikis, team transitions to work on Flow
== Mobile ==
* June: Mobile GettingStarted in beta, and EventLogging on betalabs
* July: notification styling changes in beta
* August: Editor dashboards, notifications in stable
== Ops ==
* July: DNS upgrades rolled out, OpenStreetMap (OSM) design work
* Aug: OSM deployment
== Platform ==
* July: Search prototype in Labs, Release Engineering (RelEng) (first)
Quarterly review prep
* Aug: OAuth deployment to all wikis, Search deploy to test2, RelEng
Quarterly review
* Sept: RelEng sprints begin
== QA ==
* Aug: Continue training sessions: failure analysis; ongoing newbie
training
== Wikidata ==
* July: URL datatype, Wikivoyage interwikis
* Aug: Monolingual text
* Sept: Simple queries (one property with one value), Quantity datatype,
arbitrary item access
* Oct: Range queries, statements with ranks, Merge/redirect of entities
* Nov: Visualisations of results, Merge/redirect of entities
* Dec: Conjunctive queries, Defining queries per UI
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |