I have started a page in Meta to discuss the options of either creating a
Wikisource version dedicated to musical scores or an independent project
https://meta.wikimedia.org/wiki/Requests_for_comment/Musical_score_transcri…
Micru
On Wed, Apr 24, 2013 at 4:34 AM, John Vandenberg <jayvdb(a)gmail.com> wrote:
> Yay!!
>
> John Vandenberg.
> sent from Galaxy Note
> ---------- Forwarded message ----------
> From: "MZMcBride" <z(a)mzmcbride.com>
> Date: Apr 23, 2013 12:28 PM
> Subject: [Wikitech-l] Bug 189: "Add a music wikimodule" resolved/fixed
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Cc:
>
> Hi.
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=189
>
> Congrats to all involved in getting bug 189 resolved! :-)
>
> Bug 189 was one of the oldest unresolved and one of the better known bugs
> in Bugzilla involving a request to add a music module to Wikimedia wikis.
> Quick stats about the bug:
>
> * Opened: 2004-08-22
> * Votes: 48
> * Comments: 123
>
> The bug filer is still around and left a nice note on the bug
> (<https://bugzilla.wikimedia.org/show_bug.cgi?id=189#c123>):
>
> ---
> Congratulations to all !
>
> It makes my dream comes true today !
>
> Thanks million times!
> ---
>
> <https://en.wikipedia.org/wiki/Note> seemed like an easy target for
> demoing the newly deployed Score extension
> (<https://www.mediawiki.org/wiki/Extension:Score>) on a production site,
> if anyone's interested. I tried looking around for a point and click
> lilypond or ABC code generation tool (preferably Web-based), but a lot of
> these tools quickly went over my head.
>
> MZMcBride
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikisource-l mailing list
> Wikisource-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
>
>
--
Etiamsi omnes, ego non
I agree with Erik that multi-language support on multi-language projects like Commons is very messy, complicated and inconsistent. The system has morphed into a web of java scripts and templates designed and maintained by many users that know only small section of the whole system. For example, I do a lot of template maintenance and internationalization (i18n), however have very little understanding of poorly documented java scripts[3] used (which interact with some templates) or the interactions between translatewiki (where many translations are made) and Commons (see [2]).
One of the challenges is that many issues experienced by some users in one language are not experienced by others. For example, since many templates on Commons are very close to the template expansion limit, the limit is often crossed in one language but not in the other. (Hopefully that will be solved by rewriting some of the templates in Lua.). Also there is a very different functionality for logged in and not logged in users. For example language links on the bottom of some templates, like [[Template:Delete]] [4] work for not logged in users but do not do anything if you are logged in.
Another huge challenge of current and future systems is that Erik already pointed out: that many translations are not 1:1. People are often adding corrections to text in languages they know, so slowly different language versions are drifting apart. For example, I lately noticed that some significant changes to template:PD-Polish [5] did not make it to any of the other versions, so different people see different license template. The only solution for this I can think of is some sort of marking the of the text to highlight out-of-date translations and provide also up-to-date version in other language.
Whatever system we use should allow two forms of i18n used: macro (where whole pages or large sections are translated as a whole) and micro ( where individual words, phrases or sentences are translated). Also since Commons mostly deal with images, a lot of translated content is image metadata like technique used to create an artwork or the century the creator of the artwork lived in. This type of metadata can be handled by language-independent properties like the ones used at wikidata (see [6]).
I see that there will be a scheduled talk about Extension:Translate and Commons at Wikimania 2013 [1].
[1] http://wikimania2013.wikimedia.org/wiki/Submissions/Multilingual_Wikimedia_…
[2] https://commons.wikimedia.org/wiki/User:Multichill/Template_i18n_at_Transla…
[3] https://commons.wikimedia.org/wiki/MediaWiki_talk:Multilingual_description.…
[4] https://commons.wikimedia.org/wiki/Template:Delete
[5] https://commons.wikimedia.org/w/index.php?title=Template%3APD-Polish%2Fen&d…
[6] http://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2013/03#Wikidata…
Jarek T.
User:jarekt
Date: Tue, 23 Apr 2013 20:29:49 -0700
From: Erik Moeller <erik(a)wikimedia.org>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: [Wikitech-l] Support for multiple content languages in MW
core
Message-ID:
<CAEg6ZHmcSU=M8w2314EbsLZ2ZWTYgyzSLpwBqWbyw9nauo=WLA(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi folks,
I'd like to start a broader conversation about language support in MW
core, and the potential need to re-think some pretty fundamental
design decisions in MediaWiki if we want to move past the point of
diminishing returns in some language-related improvements.
In a nutshell, is it time to make MW aware of multiple content
languages in a single wiki? If so, how would we go about it?
Hypothesis: Because support for multiple languages existing in a
single wiki is mostly handled through JS hacks, templates, and manual
markup added to the content (such as <div>s indicating language
direction), we are providing an opaque, confusing and often
inconsistent user experience in our multilingual wikis, which is a
major impediment for growth of non-English content in those wikis, and
participation by contributors who are not English speakers.
Categories have long been called out as one of the biggest factors,
and they certainly are (since Commons categories are largely in
English, they are by definition excluding folks who don't speak the
language), but I'd like to focus on the non-category parts of the
problem for the purposes of this conversation.
Support for the hypothesis (please correct misconceptions or errors):
1) There's no consistent method by which multiple language editions of
the same page are surfaced for selection by the use. Different wikis
use different templates (often multiple variants and layouts in a
single wiki), different positioning, different rules, etc., leading to
inconsistent user experience. Consistency is offered by language
headers generated by the Translate extension, but these are used for
managing translations, while multilingual content existing in the same
wiki may often not take the form of 1:1 translations.
Moreover, language headers have to be manually updated/maintained,
consider the user-friendliness of something like the +/- link in the
language header on a page like
https://commons.wikimedia.org/wiki/Commons:Kooperationen
which leads to:
https://commons.wikimedia.org/w/index.php?title=Template:Lang-Partnerships&…
Chances are that a lot of people who'd have the ability to provide a
version (not necessarily a translation) of the page in a given
language will give up even on the process of doing so correctly.
2) There's no consistent method by which page name conflicts (which
may often occur in similar languages) are resolved, and users have to
manually disambiguate.
3) There are basic UX issues in the language selection tools offered
today. For example, after changing the language on Commons to German,
I will see the page I'm on (say English) with a German user interface,
even if there's an actual German content version of the page
available. This is because these language selection tools have no
awareness of the existence of content in relevant languages.
4) In order to ensure that content is rendered correctly irrespective
of the UI language set, we require content authors to manually add
<div>s around RTL content, even if that's all the page contains.
5) It's impossible to restrict searches to a specific language. It's
impossible to restrict recent changes and similar tools to a specific
language.
I'll stop there - I'm sure you can think of other issues with the
current approach. For third party users, the effort of replicating
something like the semi-acceptable Commons or Meta user experience is
pretty significant, as well, due to the large number of templates and
local hacks employed.
This is a very tricky set of architectural issues to solve well, and
it would be easy to make the user experience worse by solving it
poorly. Still, as we grow our bench strength to take on hard problems,
I want to raise the temperature of this problem a bit again,
especially from the standpoint of future platform engineering
improvements.
Would it make sense to add a language property to pages, so it can be
used to solve a lot of the above issues, and provide appropriate and
consistent user experience built on them? (Keeping in mind that some
pages would be multilingual and would need to be identified as such.)
If so, this seems like a major architectural undertaking that should
only be taken on as a partnership between domain experts (site and
platform architecture, language engineering, Visual Editor/Parsoid,
etc.).
I'm not suggesting this should be done in the very near term, but I'd
like to at least start talking about it, hear if I'm completely off
base (and if there are simpler ways to improve on current state), and
explore where it could fit in our longer term agenda.
Relevant existing code:
* https://www.mediawiki.org/wiki/Extension:Translate - awesome for
page and message translation, but I'm not clear that it can help for
the other multilingual content scenarios and problems
* Others: https://www.mediawiki.org/wiki/Category:Internationalization_extensions
Thanks,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Wikipedia and our other projects reach more than 500 million people every
month. The world population is estimated to be >7 billion. Still a long
way to go. Support us. Join us. Share: https://wikimediafoundation.org/
Dear all,
I have started a new RFC with some proposals for the interproject links and
you can add more if you want.
https://meta.wikimedia.org/wiki/Requests_for_comment/Interproject_links_int…
It has been a long standing issue and one of the most voted enhancements in
Bugzilla
https://bugzilla.wikimedia.org/show_bug.cgi?id=708
To have the sister projects templates at the bottom of the page it is also
one of the reasons why sister projects have been also so hidden from the
eyes of the big public, and now with Wikidata also the issue of
maintainability can be addressed as well (similar problem as with
interlanguage links).
Micru
Hi Wikimedia Developers,
My name is Cheng Xing, and I'm interested in working with Wikimedia for
GSoC this summer. I sent the email below to the mailing list few days ago,
but it didn't seem like it went through, so here it is again.
Thank you for your time!
Sincerely,
Cheng
---------- Forwarded message ----------
From: "Cheng Xing" <cxing561(a)gmail.com>
Date: Apr 18, 2013 5:40 PM
Subject: [Google Summer of Code '13] Project Idea - "Inspire Me" Button
To: <wikitech-l(a)lists.wikimedia.org>
Hi Wikimedia Developers,
My name is Cheng Xing, and I am a freshman in Cornell University College of
Engineering planning to pursue a major in Computer Science and minor in
Electrical and Computer Engineering.
The gist of my idea is this: Create a magical "Inspire Me" button in the
homepage of Wikimedia sites so that it directs the user to a page that
he/she is most likely interested in. In other words, it's a page
recommender system.
For example, if a programmer clicks the "Inspire Me" button on Wikipedia,
articles such as the Whitespace programming language, Rubber Duck
Debugging, etc. would show up. Things that the user probably doesn't know
about, that would probably interest the user, will show up by clicking that
button. Very occasionally there'd be random things like Stitches, which
the user might know nothing about, but might actually be interesting.
I got this idea from three different places: Pandora, XKCD, and my own
Wikiholic-ness. Pandora, for its impressive recommender system that uses
user accounts and likes/dislikes to track recommendation data; XKCD, for
its entertainment through their "Random" button; and lastly, my own
Wikiholic-ness, for its eagerness to find random interesting things on
Wikipedia.
I think the best part of Wikimedia is its ability to inspire people from
all over the world, and it has achieved this by simply presenting
information to the masses. In my opinion, a tool that filters and
recommends information to users would be much more inspirational. Just
imagine how many people all over the world can find their dreams this way.
I realize that this could become quite a big project, so if I get the
chance to work on this, I will do a small part (possibly the basic
infrastructure of the system) for GSoC, and I am more than willing to
continue to contribute after that.
I have some ideas of how this recommender systems would work, but this
email is pretty long as it is. Please send me questions and comments! I
really appreciate it.
Sincerely,
Cheng
Hi.
https://bugzilla.wikimedia.org/show_bug.cgi?id=189
Congrats to all involved in getting bug 189 resolved! :-)
Bug 189 was one of the oldest unresolved and one of the better known bugs
in Bugzilla involving a request to add a music module to Wikimedia wikis.
Quick stats about the bug:
* Opened: 2004-08-22
* Votes: 48
* Comments: 123
The bug filer is still around and left a nice note on the bug
(<https://bugzilla.wikimedia.org/show_bug.cgi?id=189#c123>):
---
Congratulations to all !
It makes my dream comes true today !
Thanks million times!
---
<https://en.wikipedia.org/wiki/Note> seemed like an easy target for
demoing the newly deployed Score extension
(<https://www.mediawiki.org/wiki/Extension:Score>) on a production site,
if anyone's interested. I tried looking around for a point and click
lilypond or ABC code generation tool (preferably Web-based), but a lot of
these tools quickly went over my head.
MZMcBride
Hello,
This is a reminder that the Language Engineering team will be hosting
a bug triage session today, i.e. 24th of April 2013 at 1700 UTC/1000
PDT on #mediawiki-i18n (Freenode). The bug list is at
http://etherpad.wikimedia.org/BugTriage-i18n-2013-04 . Event details
can be found be in the section below.
Thanks
Runa
What: Translation User Interface bug triage
Date: April 24 2013
Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion: http://hexm.de/r0)
Channel: #mediawiki-i18n (Freenode)
Etherpad: http://etherpad.wikimedia.org/BugTriage-i18n-2013-04
Questions can be sent to: runa at wikimedia dot org
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Sat, Apr 20, 2013 at 1:02 AM
Subject: [Language Engineering] Bug triage on Wednesday, April 24 2013
at 1700 UTC/1000 PDT
To: mediawiki-i18n(a)lists.wikimedia.org, Wikimedia Mailing List
<wikimedia-l(a)lists.wikimedia.org>, wikitech-l(a)lists.wikimedia.org
What: Translation User Interface bug triage
Date: April 24 2013
Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion: http://hexm.de/r0)
Channel: #mediawiki-i18n (Freenode)
Etherpad: http://etherpad.wikimedia.org/BugTriage-i18n-2013-04
Questions can be sent to: runa at wikimedia dot org
Hello,
The Language Engineering team would like to invite everyone for the
upcoming bug triage session on Wednesday, April 24 2013 at 1700 UTC
(1000 PDT). During this 1 hour session we will be using the etherpad
listed above to collaborate. We have already listed some bugs, but
please feel free to add more bugs, comments and any other related
issues that you’d like to see addressed during the session. You can
send questions directly to me on email or IRC (nick: arrbee). Please
see above for event details.
Thank you.
regards
Runa
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
I am wishing to propose a project that needs Wikipedia and I discussed about it a little on IRC.
I wish to know that Wikimedia will not consider any Wikipedia related project as idea’s page says or if somehow I am able to demonstrate that I will be able to complete it in summer they can consider it then.
Sent from Windows Mail
Thanks for all the feedback to my proposal. I really appreciate it.
If we want to provide personalized recommendations, user data does need to
be connected for the best results, and yeah things could probably get a
little iffy with the privacy policy.
In terms of gathering data for the recommender systems, I initially had
three ideas:
1) Cookies (my least favorite)
2) Reading data saved in user accounts
Because of the privacy policy, (1) and (2) are out of the game. The third
one might get around this issue, though.
3) Facebook App
By using Facebook, not only can we use collaborative filtering techniques,
we can also use network-based techniques, and this is something unique with
Facebook. The data is gathered by Facebook (and possibly the app), not
Wikimedia, and this could be stressed with a disclaimer. This could be an
app run in the Facebook core, but it might be better if it's run separately
with a Facebook plugin.
I'm just not sure if Wikimedia content can be used in apps like that. It
could probably benefit a lot of people to have a personalized recommender,
but I could see why privacy is a concern.
I do realize that if this project is approved, it will become quite big. I
plan to take a small portion of it for GSoC to get the project, and make it
so that it can be continued in the future. Which portion I take will
depend on what the final idea is.
I looked into Special:GettingStarted. How does it gather data as it is
right now? What else could be worked on? If "Inspire Me" cannot be done,
this sounds pretty interesting as well.
And lastly, to Daniel: No I haven't talked to anyone directly about this
idea. Posting in this mailing list is the first thing I did to get some
feedback, and I did get plenty of it.
Sincerely,
Cheng
Hey,
At the risk of starting an emacs vs vim like discussion, I'd like to ask if
I ought to be using a SpecialPage or an Action in my use case. I want to
have an extra tab for a specific type of article that shows some additional
information about this article. This view is per article. It does not allow
for making modifications to the article. Registering either an action or a
special page will result in much the same behaviour for the user, with the
exception of the URL structure, which is slightly different. For me as a
developer there also is little difference, either I have some thing derive
from Action and have 3 lines of code in it or from SpecialPage and have the
lines here. Furthermore I've seen both approaches taken, and have taken
both myself. So is one approach preferred?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hi,
Just a note to say that Google Summer of Code application period is now
officially open:
http://www.google-melange.com/gsoc/events/google/gsoc2013
The deadline is May 3. In the meantime, the Outreach Program for Women
application period is also open, until May 1.
We recommend all candidates to apply soon and be ready to improve your
project proposals fast based on feedback received.
Women interested in both programs are encouraged to apply to both. If
you are unsure, apply to both as well, or just ask (the sooner, the better).
All this may create some extra traffic in this list. New project
proposals are encouraged to be announced here, pointing to their related
Bugzilla reports. Please move the technical discussions to the Bugzilla
reports as much and as soon as possible.
Thank you and good luck to all candidates!
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil