Re: [Wikitech-l] My Phabricator account has been disabled

[David Cuenca Tudela]

On Thu, Aug 9, 2018 at 5:19 PM David Barratt  wrote:

> However, there will have to be a significant number of major changes before
> that can be a reality.
>

Which kind of changes?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[David Cuenca Tudela]

In general I would prefer to keep vulgar language out of the projects, as
it doesn't bring anything positive.
Research shows that swearing causes stress [1], and there are many ways of
showing dissatisfaction without using coarse language.

For instance, I would appreciate if there would be more interest in using
Nonviolent Communication, as it is more effective in getting the message
across than with negativity.
Introduction: https://www.youtube.com/watch?v=M-129JLTjkQ

Regards,
Micru


[1] http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0022341

On Wed, Aug 8, 2018 at 5:53 PM Bináris  wrote:

> That's what I called a very first world problem.
> This happens when American culture and behavioral standard is extended to
> an international community.
> It is not rally polite to write that F-thing (how many times has it been
> written directly or abbreviated or indirectly in this very discussion?).
> But to ban a member of the technical community from the working environment
> is really harmful.
> Although we do block people from editing Wikipedia, too, but we do it
> publicly, clearly, comparably, and by the rules of the local community, not
> by hidden rules of admin board. And not for one ugly word.
> This secret banning undermines the community, and therefore it is
> destructive.
>
> Additionally, as code of conduxt itself was discussed here, the coc file
> case was discussed here a few weeks ago, and this is the place where most
> Phabricatos users communicate,  this is a good place to discuss this case,
> too. Publicity is good.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FW: Warning on behalf of Code of conduct committee

[David Cuenca Tudela]

I do not have enough information about the events that you are talking
about, so I cannot form a complete picture with the limited information
that you offer. The nature of the job of the TCC seems to suggest that they
should operate with discretion and confidentiality, and answer questions
only to the people involved in the issues. They do not have to explain
whatever they read to any outside party, because even with all the values
of openness and transparency, the privacy of the involved parties should be
guaranteed. I mentioned the CHR because it offers a way to share
information from meetings if needed, not to say that all information should
be shared, because that is not the case.

I do not consider the operation of a common account as hiding, but rather
as a way to distribute the pressure that comes from external parties.
Considering the negative language that you use in your communication I find
it very appropriate.

Micru (also from mobile)


On Mon, Jun 25, 2018 at 4:34 PM Fæ  wrote:

> If you are going to quote Chatham House Rule, then look it up first please.
> The secretive behaviour of the TCC, along with the habit of choosing to
> suppress evidence or answer questions, to the stage where WMF employees do
> not want to explain what they read with their own eyes for fear of falling
> foul of extream interpretations of the CoC, even when originally the
> incident was a public published record, is way more paranoid than applying
> CHR.
>
> The top level stated values of our community and the WMF are explicitly to
> remain as open and transparent as possible. Recent incidents involving the
> TCC and the apparent worsening relationships between unpaid volunteers and
> WMF contractors/employees demonstrate a failure to meet those ethical and
> good governance considerations. Hiding behind an anonymous email address is
> merely the most obvious anti-transparency measure. You would think that TCC
> members are worried about putting their names against their own Committee's
> actions.
>
> "At a meeting held under the Chatham House Rule, anyone who comes to the
> meeting is free to use information from the discussion, but is not allowed
> to reveal who made any comment. It is designed to increase openness of
> discussion." See https://en.wikipedia.org/wiki/Chatham_House_Rule
>
> Fae (from a mobile phone)
>
> On Mon, 25 Jun 2018, 11:04 David Cuenca Tudela,  wrote:
>
> > @Nemo: It could be that the priority change was not seen as aggressive,
> and
> > probably it was not initially as we have the "be bold" tradition.
> However,
> > that changes as the issue heats up and becomes an edit war. In this case
> it
> > didn't get to that point (less than 3 reverts, although the reverts might
> > be perceived more strongly in Phabricator, and because the person doing
> > them had a position of power). Linguistically it is also challenging
> > because maybe the person using the word "troll" was not aware that it
> could
> > have been interpreted as "assuming bad faith". Even if an act is
> qualified
> > as "troll" there is some judgement about something that the author of the
> > action might have not intended.
> >
> > It is not fair to put all the blame on WMF employees, they might be part
> of
> > the issue, but every coin has two sides. WMF employees could improve
> their
> > openness with the frustration they get from the community, and also the
> > community should be more willing to be constructive and understanding.
> > Probably neither the WMF employees nor the community is getting the help
> > needed to collaborate better, but whose role is to provide it?
> >
> > I agree that normally the weakest suffer the most, and that somebody
> > (again, who?) should take the lead in this case to explain to the
> > contributor what happened and offer an apology.
> >
> > @Fae: indeed friendly mediation seems more appropriate in this case, but
> > again, by who? The people involved in this case didn't have anywhere to
> go,
> > so I find it understandable that they resort to their only available
> option
> > right now.
> >
> > If the TCC wants to create a friendly environment, they cannot tackle
> > unfriendliness in an unfriendly way (unless there are no other options,
> or
> > the gravity of the situation requires so).
> >
> > I am not worried about the lack of transparency of the TCC, because
> > actually it should be done that way to protect its participants (cfr.
> > Chatham House Rule), but of course they could document how they reached
> > difficult decisions. It could be useful to assess future cases.
> >
> > Micru
> >
> > O

Re: [Wikitech-l] FW: Warning on behalf of Code of conduct committee

[David Cuenca Tudela]

@Nemo: It could be that the priority change was not seen as aggressive, and
probably it was not initially as we have the "be bold" tradition. However,
that changes as the issue heats up and becomes an edit war. In this case it
didn't get to that point (less than 3 reverts, although the reverts might
be perceived more strongly in Phabricator, and because the person doing
them had a position of power). Linguistically it is also challenging
because maybe the person using the word "troll" was not aware that it could
have been interpreted as "assuming bad faith". Even if an act is qualified
as "troll" there is some judgement about something that the author of the
action might have not intended.

It is not fair to put all the blame on WMF employees, they might be part of
the issue, but every coin has two sides. WMF employees could improve their
openness with the frustration they get from the community, and also the
community should be more willing to be constructive and understanding.
Probably neither the WMF employees nor the community is getting the help
needed to collaborate better, but whose role is to provide it?

I agree that normally the weakest suffer the most, and that somebody
(again, who?) should take the lead in this case to explain to the
contributor what happened and offer an apology.

@Fae: indeed friendly mediation seems more appropriate in this case, but
again, by who? The people involved in this case didn't have anywhere to go,
so I find it understandable that they resort to their only available option
right now.

If the TCC wants to create a friendly environment, they cannot tackle
unfriendliness in an unfriendly way (unless there are no other options, or
the gravity of the situation requires so).

I am not worried about the lack of transparency of the TCC, because
actually it should be done that way to protect its participants (cfr.
Chatham House Rule), but of course they could document how they reached
difficult decisions. It could be useful to assess future cases.

Micru

On Mon, Jun 25, 2018 at 11:19 AM Fæ  wrote:

> The lack of transparency of TCC actions and assessment processes is
> troubling. TCC was supposed to be a means to handle serious misuse or
> harassment, not to use steel boots to stamp out all "non-positivity".
>
> Trivial cases like this should best be handled firstly by off project
> grown-up mediation, rather than TCC warnings for which the next step may be
> a global ban.
>
> Honestly, the TCC's actions have looked so authoritarian to my eyes, I fear
> I am adding evidence to a case for a permanent ban of my account by writing
> non-positive words here. The TCC is guilty of creating a hostile
> environment that appears unwelcoming and threatens volunteers in all
> "technical spaces".
>
> Fae
>
> On Sun, 24 Jun 2018, 22:46 MZMcBride,  wrote:
>
> > >Hello,
> > >Please refrain from name calling, the CoC has received some reports
> about
> > >users being offended by you calling them trolls. While those comments
> > >might not have been malicious they are not constructive and do not
> > >contribute to a welcoming environment for contributors.
> > >
> > >Best
> > >
> > >--
> > >This email was sent by TechConductCommittee to MZMcBride by the "Email
> > >this user" function at MediaWiki. If you reply to this email, your email
> > >will be sent directly to the original sender, revealing your email
> > >address to them.
> >
> > Wikimedia Foundation Inc. employees have blocked the ability of new users
> > to report bugs or file feature requests or even read the issue tracker.
> > But yes, please focus on me calling Andre a troll for resetting the
> > priority of . My single
> comment
> > ("andre__: Such a troll.") is clearly what contributes to an unwelcoming
> > environment for contributors, not blocking them from reading the site and
> > demanding that they be vetted first. Great work, all.
> >
> > A pseudo-focus on "civility" while you take a hard-line and skeptical
> view
> > toward outsiders. Maybe these people are auditioning for roles in the
> > Trump Administration. :-)
> >
> > I'm mostly forwarding this garbage here so that there's some better and
> > more appropriate context when, in a few months, someone says "well, the
> > code of conduct committee has dealt with dozens of incidents! Clearly
> it's
> > necessary!" The people pushing this campaign for more bureaucracy have
> > repeatedly declined to provide specifics about incidents because it's
> > pretty obvious that nobody would take them seriously (and rightfully!) if
> > there were a clearer understanding of what they're actually doing.
> >
> > Best!
> >
> > MZMcBride
> >
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> 

Re: [Wikitech-l] FW: Warning on behalf of Code of conduct committee

[David Cuenca Tudela]

On Mon, Jun 25, 2018 at 9:38 AM Stas Malyshev 
wrote:

> Wouldn't it be easy to just log out and read any task (or even use
> incognito mode/private browsing in the browser)? It is certainly a small
> inconvenience, but I am not sure how it is very important, given a very
> simple workaround.


 Sure, but you have to inform the user somehow about this.

Regards,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FW: Warning on behalf of Code of conduct committee

[David Cuenca Tudela]

On Mon, Jun 25, 2018 at 7:26 AM Federico Leva (Nemo) 
wrote:

> Pointing out trollish brehaviour is positive help for self-correction.
>

What you call "trollish behaviour" is to "provoke others (chiefly on the
Internet) for their own personal amusement or to cause disruption". Unless
there is solid evidence, when you call someone a troll you assume bad
faith, and it is not helpful. On that regard I agree with the statement by
TechConductCommittee.

On the other hand, I also agree also with MZMcBride that new users should
be able to at least see the tasks, so I don't understand why the priority
of this bug was lowered. If unapproved users cannot be treated as logged
out, then there should be another solution. Like getting more information
through OAuth to auto-approve users that meet certain criteria, or not
allowing unapproved users to log in so that they can see the tasks
(although I am not totally convinced about this).

Regards,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Planet Wikimedia using new software "rawdog"

[David Cuenca Tudela]

On Thu, May 31, 2018 at 12:08 PM, Andre Klapper 
wrote:

> The source website is linked from the date header.
>

I'm aware of that, but in my opinion that is not visible enough.


> That's a question for the blog maintainers that you could file at
> https://phabricator.wikimedia.org/maniphest/task/edit/form/
> 1/?projects=Wikimedia-Blog


 Thanks for the pointer. Done:
https://phabricator.wikimedia.org/T196069

Regards,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Planet Wikimedia using new software "rawdog"

[David Cuenca Tudela]

Hi Daniel,

I like the new design, however I am missing some information about the
source of each post. Would it be possible to add the source website to each
post?

And another more general question I have is, could the Planet be linked
from the Wikimedia blog? I feel that it is quite hidden now, so by linking
it from the blog maybe it would gain visibility.

Regards,
Micru

On Thu, May 31, 2018 at 3:33 AM, Daniel Zahn  wrote:

> Hi,
>
> this is an announcement to let you know that the service ($lang).
> planet.wikimedia.org, an RSS feed aggregator for all Wikimedia related
> blogs, has switched software.
>
> You can find the English version at  https://en.planet.wikimedia.org/
>
> Other existing languages are listed on
> https://wikitech.wikimedia.org/wiki/Planet.wikimedia.org#
> Which_languages_exist
> ?
>
> Today we moved away from planet-venus and to a newer package called
> "rawdog" that does the same thing as before, fetching a bunch of RSS feed
> and combining them into a single page and feed.
>
> The reason is that planet-venus has been dropped in Debian stable (stretch)
> because it was unmaintained, so we had to find an alternative to be able to
> upgrade the underlying servers to a current OS version.
>
> If you never heard of planet, here you can find more info:
>
> https://wikitech.wikimedia.org/wiki/Planet.wikimedia.org
>
> If you already use it but just subscribe to the "feed of feeds" then
> nothing should change for you.
>
> (Though note that we support RSS 2.0 but not a separate Atom feed anymore.
> We are redirecting the old atom.xml URL to the new (and old) URL
> rss20.xml.)
>
> If you already use it and look at the web UI, enjoy the new theme that
> Paladox imported from KDE to make it look about 150% better than before.
> (thanks to him for that theming work!)
>
> We also applied patches to make it look more like our former planet for a
> smooth transition.  A "wmf1" package has been built and uploaded at
> https://apt.wikimedia.org/wikimedia/pool/main/r/rawdog/
>
> If you want to know more about "rawdog":
>
> https://offog.org/code/rawdog/
> https://packages.debian.org/stretch/rawdog
>
> If you want to add your blog feed, feel free to upload changes or just drop
> me a mail.
>
> Bugs can be reported here:
> https://phabricator.wikimedia.org/project/view/413/
>
> Tickets are:  https://phabricator.wikimedia.org/T180498 ,
> https://phabricator.wikimedia.org/T168490
>
> Cheers,
>
> Daniel
>
> --
> Daniel Zahn 
> Operations Engineer
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Machine-utilizable Crowdsourced Lexicons

[David Cuenca Tudela]

Hi Adam,

Thanks for your well-intentioned letter. Do you know about Wikidata and the
recent developments to support machine-readable Lexicographical data? I
would like to invite you to take a look at:
https://www.wikidata.org/wiki/Wikidata:Lexicographical_data

The system is still at its early stages, but you can take a look to
examples like:
https://www.wikidata.org/wiki/Lexeme:L11
https://www.wikidata.org/wiki/Lexeme:L403

If you have any questions about this, please do ask.

Regards,
Micru


On Wed, May 30, 2018 at 3:01 AM, Adam Sobieski 
wrote:

> INTRODUCTION
>
> Machine-utilizable lexicons can enhance a great number of speech and
> natural language technologies. Scientists, engineers and technologists –
> linguists, computational linguists and artificial intelligence researchers
> – eagerly await the advancement of machine lexicons which include rich,
> structured metadata and machine-utilizable definitions.
>
> Wiktionary, a collaborative project to produce a free-content multilingual
> dictionary, aims to describe all words of all languages using definitions
> and descriptions. The Wiktionary project, brought online in 2002, includes
> 139 spoken languages and American sign language [1].
>
> This letter hopes to inspire exploration into and discussion regarding
> machine wiktionaries, machine-utilizable crowdsourced lexicons, and
> services which could exist at https://machine.wiktionary.org/ .
>
> LEXICON EDITIONING
>
> The premise of editioning is that one version of the resource can be more
> or less frozen, e.g. a 2018 edition, while wiki editors collaboratively
> work on a next version, e.g. a 2019 edition. Editioning can provide
> stability for complex software engineering scenarios utilizing an online
> resource. Some software engineering teams, however, may choose to utilize
> fresh dumps or data exports of the freshest edition.
>
> SEMANTIC WEB
>
> A machine-utilizable lexicon could include a semantic model of its
> contents and a SPARQL endpoint.
>
> MACHINE-UTILIZABLE DEFINITIONS
>
> Machine-utilizable definitions, available in a number of knowledge
> representation formats, can be granular, detailed and nuanced.
>
> There exist a large number of use cases for machine-utilizable
> definitions. One use case is providing natural language processing
> components with the capabilities to semantically interpret natural
> language, to utilize automated reasoning to disambiguate lexemes, phrases
> and sentences in contexts. Some contend that the best output after a
> natural language processing component processes a portion of natural
> language is each possible interpretation, perhaps weighted via statistics.
> In this way, (1) natural language processing components could process
> ambiguous language, (2) other components, e.g. automated reasoning
> components, could narrow sets of hypotheses utilizing dialogue contexts,
> (3) other components, e.g. automated reasoning components, could narrow
> sets of hypotheses utilizing knowledgebase content, and (4)
> mixed-initiative dialogue systems could also ask users questions to narrow
> sets of hypotheses. Such disambiguation and interpretation would utilize
> machine-utilizable definitions of senses of lexemes.
>
> CONJUGATION, DECLENSION AND THE URL-BASED SPECIFICATION OF LEXEMES AND
> LEXICAL PHRASES
>
> A grammatical category [2] is a property of items within the grammar of a
> language; it has a number of possible values, sometimes called grammemes,
> which are normally mutually exclusive within a given category. Verb
> conjugation, for example, may be affected by the grammatical categories of:
> person, number, gender, tense, aspect, mood, voice, case, possession,
> definiteness, politeness, causativity, clusivity, interrogativity,
> transitivity, valency, polarity, telicity, volition, mirativity,
> evidentiality, animacy, associativity, pluractionality, reciprocity,
> agreement, polypersonal agreement, incorporation, noun class, noun
> classifiers, and verb classifiers in some languages [3].
>
> By combining the grammatical categories from each and every language
> together, we can precisely specify a conjugation or declension. For
> example, the URL:
>
> https://machine.wiktionary.org/wiki/lookup.php?edition=
> 2018=en-US=fly=verb=first-
> person=singular=past=past_simple=indicative&…
>
> includes an edition, a language of a lemma, a lemma, a lexical category,
> and conjugates (with ellipses) the verb in a language-independent manner.
>
> We can further specify, via URL query string, the semantic sense of a
> grammatical element:
>
> https://machine.wiktionary.org/wiki/lookup.php?edition=
> 2018=en-US=fly=verb=first-
> person=singular=past=past_simple=
> indicative&...=4
>
> Specifying a grammatical item fully in a URL query string, as indicated in
> the previous examples, could result in a redirection to another URL.
>
> That is, the URL:
>
> https://machine.wiktionary.org/wiki/lookup.php?edition=
> 2018=en-US=fly=verb=first-
> 

Re: [Wikitech-l] [Wikidata] New Wikidata accounts can't edit labels?

[David Cuenca Tudela]

Hi Daniel,
The usual procedure is explained here:
https://meta.wikimedia.org/wiki/Mass_account_creation
https://www.mediawiki.org/wiki/Help:Mass_account_creation
https://meta.wikimedia.org/wiki/Grants:Learning_patterns/Six-account_limit

Normally to request a temporary lift of the IP cap, they should file a task
as explained on that page. There are some quick workarounds, like creating
accounts with smartphones.

Cheers,
Micru



On Tue, Apr 11, 2017 at 11:26 PM, Daniel Mietchen <
daniel.mietc...@googlemail.com> wrote:

> Dear all,
> I was just pinged by a Wikidata hackathon in Suriname
> (cf. https://www.spangmakandra.com/big-data-seminar-suriname )
> that they can't edit Wikidata any more - see also
> https://twitter.com/twitferry/status/851907389087502338 .
> We are musing that this may be due to an IP ban, since more than six
> new accounts were registered from the same IP (186.179.xxx.xx).
> Can anyone help sort this out quickly, so that the event can move on?
> Thanks,
> Daniel
>
> ___
> Wikidata mailing list
> wikid...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>



-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Now live: Shared structured data

[David Cuenca Tudela]

Anyway, this is great news! I hope that it gets adopted by the community.
Congratulations, Yuri!

I was going to suggest a Wikidata property, but I see that the data type
for datasets is not there yet:
https://phabricator.wikimedia.org/T151334

On Thu, Dec 22, 2016 at 8:48 PM, Yuri Astrakhan <yastrak...@wikimedia.org>
wrote:

> Micru, thanks, I think Datasets sounds like a good name too!
>
> On Thu, Dec 22, 2016 at 2:44 PM David Cuenca Tudela <dacu...@gmail.com>
> wrote:
>
> > On Thu, Dec 22, 2016 at 8:38 PM, Brad Jorsch (Anomie) <
> > bjor...@wikimedia.org
> > > wrote:
> >
> > > On Thu, Dec 22, 2016 at 2:30 PM, Yuri Astrakhan <
> > yastrak...@wikimedia.org>
> > > wrote:
> > >
> > > > Gift season! We have launched structured data on Commons, available
> > from
> > > > all wikis.
> > > >
> > >
> > > I was momentarily excited, then I read a little farther and discovered
> > this
> > > isn't about https://commons.wikimedia.org/wiki/Commons:Structured_data
> .
> > >
> >
> > Same here, I think it needs a better name...
> >
> > What about calling it datasets or structured datasets?
> >
> > Cheers,
> > Micru
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Now live: Shared structured data

[David Cuenca Tudela]

On Thu, Dec 22, 2016 at 8:38 PM, Brad Jorsch (Anomie)  wrote:

> On Thu, Dec 22, 2016 at 2:30 PM, Yuri Astrakhan 
> wrote:
>
> > Gift season! We have launched structured data on Commons, available from
> > all wikis.
> >
>
> I was momentarily excited, then I read a little farther and discovered this
> isn't about https://commons.wikimedia.org/wiki/Commons:Structured_data.
>

Same here, I think it needs a better name...

What about calling it datasets or structured datasets?

Cheers,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] T43327: Add page views graph(s) to MediaWiki's info action for Wikimedia wikis

[David Cuenca Tudela]

I also find that it is quite hidden, wouldn't it be better to show it by
default? As it is now there is no hint that the link will open the graph.

Cheers,
Micru

On Fri, Mar 11, 2016 at 2:59 AM, Yuri Astrakhan 
wrote:

> he.wiki has already enabled it by inserting Graph:PageViews template into
> the info template, but yours does look cleaner. The graph will show only if
> you did not modify your interface language in the Hebrew wiki, or if you
> are not logged in.
>
>
> https://he.wikipedia.org/w/index.php?title=%D7%A2%D7%9E%D7%95%D7%93_%D7%A8%D7%90%D7%A9%D7%99=info
>
> One thing that concerns me though - you seem to get all the Vega and d3
> code and graph data during the page load, yet you only show the graph on
> click. Seems to take a lot of extra time and very wasteful. Also, it
> doesn't work for older browsers.
>
> On Fri, Mar 11, 2016 at 4:33 AM, Legoktm 
> wrote:
>
> > Hi!
> >
> > (I meant to send this out earlier but got distracted by other things :()
> >
> > At the Wikimedia developer summit, Addshore and I started working on a
> > MediaWiki extension to resolve T43327[1], which asked for page view
> > graphs to be added to action=info. The "WikimediaPageViewInfo"[2]
> > extension has passed a security review, and should be deployed soon™.
> >
> > If you want to try it out, there's a test wiki[3] which uses the
> > pageview data for en.wp.
> >
> > And for updates on the deployment status, please follow T125917[4].
> >
> > [1] https://phabricator.wikimedia.org/T43327
> > [2] https://www.mediawiki.org/wiki/Extension:WikimediaPageViewInfo
> > [3] http://bf-wmpageview.wmflabs.org/wiki/Taylor_Swift?action=info
> > [4] https://phabricator.wikimedia.org/T125917
> >
> > -- Legoktm
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] ContentTranslation gets to 2000

[David Cuenca]

Amir,

First of all a big thank you as a speaker of Catalan and fervent advocate
of minoritary languages.

OTOH, I would like to bring awareness to the topic of translation engine.
Apertium is no longer supported as a GsoC project, I guess the project will
keep alive but it worries me that downstream we reap the benefits without
considering that the upstream projects might need support too.

I wish that the conversation thread that was started long ago to support
upstream projects also includes now open sourced translation tools because
as your number show, they seem very relevant.

Best regards,
Micru



On Thu, Apr 30, 2015 at 8:04 PM, Steven Walling steven.wall...@gmail.com
wrote:

 -Wikimedia-l

 Amir, this is awesome. Glad to see it's taking off.

 On Thu, Apr 30, 2015 at 6:24 AM Amir E. Aharoni 
 amir.ahar...@mail.huji.ac.il wrote:
 
  * In all the Wikipedias in which ContentTranslation is deployed, it is
  currently defined as a Beta feature, which means that it is only
 available
  to logged-in users who opted into it in the preferences.
 

 Regarding Beta feature status: what would it take to enable this as a
 default? You mentioned this in plans for the coming months.

 That deletion rate (60 out of 2000 = 3%?) looks actually a lot better than
 pretty OK. According to historical stats, it's basically equivalent to
 deletion rates for article creators with more than a month of
 experience.[1]

 It seems like the only risk in taking this out of beta status as moving to
 a default is UI clutter for monolingual users who can't ever make use of
 the feature? Maybe it's unobtrusive enough that you don't need to do this,
 but perhaps you could enable as a default for only those users who have
 substantively edited more than one language edition of Wikipedia? Either
 that, or we could consider adding a languages I edit in section to
 the Internationalisation section of user preferences?

 I'm sure you've thought about this before, but I'd love to hear more about
 the rollout plan.

 1. http://meta.wikimedia.org/wiki/Research:Wikipedia_article_creation
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase

[David Cuenca]

It seems that the Visual Editor age can now be entered fully :)

Looking forward to the Wikisource adaptation of Visual Editor!

On Wed, Mar 25, 2015 at 9:34 PM, rupert THURNER rupert.thur...@gmail.com
wrote:

 Fantastic, many thanks to all involved!!
 On Mar 20, 2015 1:15 AM, Gabriel Wicke gwi...@wikimedia.org wrote:

  On Thu, Mar 19, 2015 at 4:50 PM, Jared Zimmerman 
  jared.zimmer...@wikimedia.org wrote:
 
   https://en.wikipedia.org/wiki/Barack_Obama?veaction=edit just loaded
 in
  2
   seconds.
  
 
 
  Much of this is also owed to *a lot* of optimization work in VisualEditor
  over the last months. Plenty of ingenuity and hard work by the entire
  VisualEditor team and Ori went into making this possible.
 
  Cheers!
 
  Gabriel
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Now you can submit / claim Engineering Community tasks

[David Cuenca]

Wouldn't be better to have nested projects? GsoC might need a project per
year with subprojects for each student to manage their task, is project
nesting possible on Phabricator?

And what about sister projects? Will each one have a project?

Thanks
Micru

On Wed, Oct 22, 2014 at 3:45 AM, Quim Gil q...@wikimedia.org wrote:

 Following the activity of the Engineering Community team has never been
 simple, not even for ourselves. Proposing Engineering Community tasks
 effectively was even more complex. Here is an attempt to change this:

 https://phabricator.wikimedia.org/tag/engineering-community/

 Since the beginning of this month, we are using Phabricator to organize the
 Engineering Community team work.

 https://phabricator.wikimedia.org/tag/ect-october-2014/board/

 You can watch, comment, and get involved. You can also submit and claim
 tasks. What should we be working on next month? How can we facilitate more
 tech community work done by more people?

 See you there.

 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Now you can submit / claim Engineering Community tasks

[David Cuenca]

On Wed, Oct 22, 2014 at 3:31 PM, Quim Gil q...@wikimedia.org wrote:

 Tagging describes Phabricator projects a lot better than nesting. In
 Phabricator, projects are tags and tags are projects. This means that even
 if the subproject concept is officially missing today, you can organize
 your work in a similar way.


I partially agree, but just *partially* :) Tagging is just a poor man's
version of classing, since it doesn't let you define the relationship
between tags. True that you can put any task in several projects/tags, the
problem is that the project structure is nevertheless flat:
https://phabricator.wikimedia.org/project/query/all/
Which will become cumbersome to navigate for occasional visitors as the
number of projects goes up.


Exactly. If sister projects want to have Phabricator projects, they could
 have them. But there us hundreds of them, so we better coordinate first.
 David, thank you for providing a good excuse to create this task:


Hundreds of them? :D Last time I checked there were between 1 and 12
sisters projects, depending on whom you ask. But if you meant to create
projects for each language version of each sister project, then I agree
that it would be too much. OTOH, with a proper organization it could be
innovative to manage far-reaching content projects through phabricator ;)

Cheers,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm leaving the Wikimedia Foundation

[David Cuenca]

After reading your blog post, I must agree with this:
And I'd like to [...] exclude destructive communication from my life (yes,
there's some amount of burnout on toxic people and entitlement).

I wish that in your new environment you find a better environment to grow
professionally with less attrition.Perhaps here someday we'll realize that
the problem was not the software, not the money, not the organization, and
not the lack of contributors, but the failure to understand in our
community that humanity, wisdom and virtue have to be above everything else.

All the best in you new job,
Micru


On Fri, Sep 12, 2014 at 6:09 PM, Sumana Harihareswara suma...@wikimedia.org
 wrote:

 I write this email with regret to let you know that I've decided to leave
 the Wikimedia Foundation after nearly four years working here, and that my
 last day will be 30 September.

 I go into my reasoning and plans in this personal blog post:
 http://www.harihareswara.net/sumana/2014/09/12/0

 I'm grateful for what I've learned here and will take these lessons
 wherever I go. And I've made many friends here; thank you. I'll remain
 [[User:Sumanah]] in any volunteer work I do onwiki. Quim Gil will be the
 person to contact for any loose threads I leave behind; still, if you have
 questions for me, the next two weeks would be a good time to ask them.

 best,
 Sumana Harihareswara
 ​was Volunteer Development Coordinator, then Engineering Community Manager,
 now Senior Technical Writer
 Wikimedia Foundation
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Winter, v. 0.6

[David Cuenca]

Feedback in a Spanish social news aggregator
http://www.meneame.net/story/wikimedia-pone-prueba-prototipo-diseno-wikipedia

Some relevant comments:
- Brandon is one of the most brilliant persons I ever met, and he brings
us the interface of the future Wikipedia
- thanks to this I discovered that there is not only Wikipedia, but also
{{list of sister projects}}. Reading Wikinews now
- the interface is WONDERFUL. The design is useful, clean, clear and fast.
A+.
- the discussion page should have a max-width for big screens. I hope they
manage to improve the current chaotic system
- biggest problem behind mediawiki is not the interface, but the software
- hard to admin, done by and for old-schoolers and you cannot change their
mind. Just my opinion as sysadmin.
- the typography of the Spanish wikipedia is terrible, small and hard to
read. The grammar and spelling is even worse

As a Wikisourceror I also want to thank Brandon for taking sister projects
to the light, there are so many potential readers and contributors that
after ten year don't knew about their existence! And now with Wikidata all
the content is going to be more easily integratable into Wikipedia. Many
readers (but not editors, because they already know about them) are going
to be thankful for this.

Cheers,
Micru








On Wed, Jul 16, 2014 at 3:12 PM, Quim Gil q...@wikimedia.org wrote:

 On Tuesday, July 15, 2014, Risker risker...@gmail.com wrote:

  The one thing that comes to my mind is that all the stuff at the right of
  the screen is what might be called the bottom matter from articles.
  Giving it primary place in an article, well above the majority of content
  is...well, suboptimal.


 For me it was instant love. It puts the article in its widest context,
 inviting users to discover all what the Wikimedia community is offering
 about that topic. I was even wondering why the categories are not there,
 assuming that they will be in some form in the real prototype/beta.


  It's at the bottom because it's really not all that
  important; links to other similar articles and other Wikimedia sites is
  (I'm going to be honest here) fluff, not content


 Depends on what you are looking for. Readers interested precisely in the
 article at sight and not in its context will not even look at the right
 column after the initial surprise. Just like any news readers go directly
 to the news piece ignoring whatever else is around.

 However, many (most?) users visit Wikipedia with a less precise motivation
 and a wider curiosity about some topic. These are also the users less
 likely to hit the bottom of an article, and less likely to know what  who
 is behind every Wikipedia article.



  - especially those massive
  templates that take the place of proper categorization.


 Cause and consequence, perhaps? Maybe those templates became massive as a
 way to call the attention at the bottom of the page, where proper
 categories become almost invisible to the non-trained eye. The prototype
 shows them expanded but they could be minimized by default in the beta
 version. If we go forth with this design, editors will find solutions to
 adapt oversize templates to their new privileged position.

 I'm sure Winter 1.0 can get this part right. While the previous Winter
 features were evolutionary (and that was good), this one is a real
 challenger, and this is good too.

 PS: and yes, thank you very much for prototyping.


 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Not logged in page

[David Cuenca]

Tyler, many thanks for attempting to fix this! I hope it can be merged.


On Tue, Jul 15, 2014 at 8:49 PM, Tyler Romeo tylerro...@gmail.com wrote:

 https://gerrit.wikimedia.org/r/146515
 --
 Tyler Romeo
 0x405D34A7C86B42DF

 From: Jon Robson jdlrob...@gmail.com
 Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
 Date: July 15, 2014 at 14:32:19
 To: Wikimedia developers wikitech-l@lists.wikimedia.org
 Subject:  Re: [Wikitech-l] Not logged in page

 Yes someone please submit a patch and I will help us get a fix for this
 merged.

 On Tue, Jul 15, 2014 at 6:10 AM, Bartosz Dziewoński matma@gmail.com
 wrote:
  On Tue, 15 Jul 2014 13:00:04 +0200, David Cuenca dacu...@gmail.com
 wrote:
 
  Sometimes while not logged in I try to access my Watchlist and then the
  Not logged in page appears. It is quite useless since then you have to
  click again to go to the Log in page. Wouldn't it be better to just
  redirect to the log in page instead of showing that dumb Not logged
 in
  page?
 
  Or perhaps I am missing some hidden use or reasoning behind the
 existence
  of that page...?
 
 
  There is some old discussion on
  https://bugzilla.wikimedia.org/show_bug.cgi?id=15484, which asks for
 the
  same thing.
 
 
  --
  Matma Rex
 
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l



 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Not logged in page

[David Cuenca]

Sometimes while not logged in I try to access my Watchlist and then the
Not logged in page appears. It is quite useless since then you have to
click again to go to the Log in page. Wouldn't it be better to just
redirect to the log in page instead of showing that dumb Not logged in
page?

Or perhaps I am missing some hidden use or reasoning behind the existence
of that page...?

Cheers,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Winter, v. 0.6

[David Cuenca]

I like it and I hope it gets to the point where it can be deployed as beta.

And that right panel looks a perfect place for users to place some gadgets
of their choice. That would be wonderful!


On Mon, Jul 14, 2014 at 10:06 PM, Trevor Parscal tpars...@wikimedia.org
wrote:

 I want to suggest that we give Brandon a lot of slack here, and be as
 supportive as possible.

 This is a prototype of a design, which is far better than a mockup of a
 design. It is not an actual implementation, but that is totally fine. I
 want to see more of this kind of thing, and by being more supportive and
 understanding I think we can encourage that.

 - Trevor


 On Mon, Jul 14, 2014 at 8:52 AM, Brandon Harris bhar...@wikimedia.org
 wrote:

 
  As I've said before, it doesn't work in IE. I've only just gained
  access to a Windows laptop and I'll see what I can do.
 
 
  On Jul 14, 2014, at 5:55 AM, Risker risker...@gmail.com wrote:
 
   Thanks Brandon for letting us know about this.  Since it will be many
  hours
   before I have a chance to make comments elsewhere, I'm going to let you
   know that, using a Win7 platform and IE9, the screen is illegible.  All
   writing is in a faint shade of grey (or blue where applicable); text
   overlaps images and infoboxes; and there's massive whitespace to the
  right
   of the screen.  Because of the very faint text, I can't be certain
 what's
   supposed to be above the title; however, what is there looks to all be
   crowded over to the right of the screen above the large amount of
   whitespace.
  
   I'll try to grab a screenshot and send it in.
  
   Risker/Anne
  
   On 14 July 2014 01:03, Brandon Harris bhar...@wikimedia.org wrote:
  
  
  I have uploaded a new version of the Winter
 framework/prototype,
   v. 0.6.
  
  http://unicorn.wmflabs.org/winter/
  
  This version has significant changes over 0.5.  The entire
   undercarriage has been refactored into a framework to allow for anyone
  to
   do rapid prototyping within their own copy.  The source code has been
   installed into gerrit, in the form of two depots, one of which is for
   specialized modules that change the way the prototype behaves
   (snowflakes).
  
  Links to the source depots are available at:
  
  
   https://www.mediawiki.org/wiki/Winter#The_Winter_Framework
  
  This release adds in several major changes:
  
  * Right rail functionality, designed to surface
 content
  * Search functionality
  * Watchlist functionality (for testing)
  * A revisit to the design of the edit interface.
  
  A full changelog for version 0.6 can be found here:
  
  
   https://www.mediawiki.org/wiki/Winter#Version_0.6.2C_July_13.2C_2014
  
  As usual, feedback is welcomed here:
  
  https://www.mediawiki.org/wiki/Talk:Winter
  
   ---
   Brandon Harris, Senior Designer, Wikimedia Foundation
  
   Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
  
  
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
  ---
  Brandon Harris, Senior Designer, Wikimedia Foundation
 
  Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
 
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RfC review this week: Associated namespaces

[David Cuenca]

Hi Sumana,

I hope you are well and getting ready for wikimania? :)

There is this rfc on mediawiki that I did everything possible to promote,
to gather feedback from 3rd parties, etc. but now it is all done. From this
point on I cannot bring it any further.

What to do in this cases? Mark it as closed and unsolvable? Or ask for a
volunteer?

Thanks!
Micru



On Wed, Apr 23, 2014 at 10:43 PM, Sumana Harihareswara 
suma...@wikimedia.org wrote:

 On 04/21/2014 01:55 PM, Sumana Harihareswara wrote:
  Micru's Associated namespaces RfC is up for discussion this week.
 
 https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-23
  (We also have room for 1 more RfC to discuss.)
 
  Micru said about
 
 https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces
 :
 
  The intended outcome would be:
  1) find out if there is any objection against the Namespace registry
 and
  association handlers that Mark proposed
  2) discuss possible problems with this approach
  3) see if there would be any hands available to work on it; it is a
  delicate topic that might need someone with a deep understanding of
 MediaWiki
 
  Micru also noted that we've had a previous suggestion for a namespace
  manager https://www.mediawiki.org/wiki/Namespace_manager .
 
  AFIK, it never materialized because back then there was not such a great
  need as there is now - or at least the current use cases didn't exist
 back
  then.
  I hope this RFC moves forward because it affects important upcoming and
  already deployed projects (Commons migration, templates, Visual editor,
 WD,
  etc).
 
  Come to #wikimedia-office at 2100 UTC this Wednesday
 
 http://www.worldtimebuddy.com/?qm=1lid=2950159,2147714,5391959,100h=2950159date=2014-4-23sln=23-24
  or reply/comment with your comments/suggestions.
 
  2300 Berlin
  5pm New York
  2pm California
  7am Sydney

 This is in 15 minutes in #wikimedia-office on Freenode IRC.


 --
 Sumana Harihareswara
 Senior Technical Writer
 Wikimedia Foundation




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Output from Zurich Hackathon - yet another maps extension!

[David Cuenca]

On Thu, May 15, 2014 at 7:35 PM, Dan Andreescu dandree...@wikimedia.orgwrote:

 I like Visual:, any +1s? +2s?


I give it a +0.5 :) I also like Render but its meaning has become too
attached to 3d graphics...
Anyhow if we have a Visual and a VisualData namespace, they could be
associated to each other:
https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces


On Fri, May 16, 2014 at 12:36 AM, Erik Moeller e...@wikimedia.org wrote:

 It might be good to design it with Commons in mind from the start, so
 that a Visual:/View: can be loaded from a foreign repository as well
 as the local one. A qLabel style translation approach (using Wikidata)
 might be helpful to consider as well.


Commons looks for sure like a good place to store the datasets needed for
visualizations. I left a message on the their Village Pump to see if there
is any concern.
I like qLabel approach, and I would go even a step forward to suggest
linking the CSV headers to Wikidata properties. That way we could also
verify later on the data formatting, or importing it more easily into
Wikidata if needed.

Overall this is very exciting work with lots of potential future
 applications. I don't think it's resourced for success yet, but let's
 figure out where it should sit in our roadmap since it would address
 many shared needs if done right.


True! It would be nice to talk about it during Wikimania, from my side I
started a community consultation here:
https://meta.wikimedia.org/wiki/Requests_for_comment/How_to_deal_with_open_datasets

Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Request for comments: How to deal with open datasets?

[David Cuenca]

On Thu, May 15, 2014 at 11:53 PM, Andrew Gray andrew.g...@dunelm.org.ukwrote:

 Definitely agree that we needed something like this. There's a lot of
 confusion about what Wikidata is for, and what is and isn't appropriate for
 it - both from outsiders and from within the Wikimedia community. I've seen
 vague it's data, it'll go on Wikidata a few times, which is a bit like
 saying it's text, it'll go on Wikipedia ;-)


Actually during the Hackathon somebody said: We need a new project... a
sort of Wiki...Data...Source? :D And it is great that you make the analogy
of Wikipedia-and-Text because when you think about it, Wikipedia went
through exactly the same process until Project Sourceberg was
characterized ;-)

Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Request for comments: How to deal with open datasets?

[David Cuenca]

Hi,

During the Zürich Hackathon I met several people that looked for solutions
about how to integrate external open datasets into our projects (mainly
Wikipedia, Wikidata). Since Wikidata is not the right tool to manage them
(reasons explained in the RFC as discussed during the Wikidata session), I
have felt convenient to centralize the discussion about potential
requirements, needs, and how to approach this new changing landscape that
didn't exist a few years ago.

You will find more details here
https://meta.wikimedia.org/wiki/Requests_for_comment/How_to_deal_with_open_datasets

Your comments, thoughts and ideas are appreciated!

Cheers,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Request for comments: How to deal with open datasets?

[David Cuenca]

On Thu, May 15, 2014 at 1:42 PM, Cristian Consonni kikkocrist...@gmail.com
 wrote:

 Thanks for the pointer, How can I put this open data on Wikidata is a
 question that I have been asked many times, this page was needed.


Thanks for your comment!

On Thu, May 15, 2014 at 3:59 PM, Samuel Klein meta...@gmail.com wrote:

 Thanks Micru!  I think we should start by including datasets on
 wikisource, with descriptions about them (storing the files on commons
 where possible).   And adding more data formats to the formats
 accepted on commons.


I don't follow you... why would you put datasets on Wikisource when they
are only used in Wikipedia and have to be stored somewhere else? As it is
now, it doesn't seem a good dataset management solution.
Besides that it would conflict with its identity as repository for textual
sources..
About Commons I don't know if it is relevant to their mission as a sharing
media platform either... I hope someone from their community can share
their views.

Thanks for the input,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Question about the ContentHandler and Extension:Score

[David Cuenca]

As a continuation to the community wish expressed last year to start a
musical score transcription project [1], I'm investigating what is needed
to make it happen.

The biggest hurdle seems to be how to separate content from layout. On the
one hand users should be able to define which part to work on (a staff, a
voice, an instrument, lyrics...), otoh they should be able to select which
elements to render for different representations. For instance a single
page has all parts but just for one page, a complete score has all the
parts for all pages, a piano part has only the piano staffs for all pages,
etc.

Lilypond can handle different layout representations, but of course the
content selection has to be prepared before launching the desired layout
rendering.

Any ideas about how to deal with this situation?

Cheers,
Micru



[1]
https://meta.wikimedia.org/wiki/Requests_for_comment/Musical_score_transcription_project_proposal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Hackathon grid

[David Cuenca]

I hope that you can reserve some interesting topics for people who arrive
on Fri night/Sat morning :)

Thanks!
Micru


On Wed, May 7, 2014 at 3:59 AM, Quim Gil q...@wikimedia.org wrote:

 Wikimedia Hackathon participants, please have a look at

 https://www.mediawiki.org/wiki/Zürich_Hackathon_2014/Schedule

 It is an almost empty grid with very few exceptions. It is based on the
 idea of beginning of the day with 1h slots for planning, and then
 defaulting to 1h30 slots, following the advice of many participants in
 Amsterdam last year.

 There are some basic principles proposed, everything debatable. If you have
 especial requirements for your session (e.g. local or remote guests that
 need to know the time in advance) then you can start discussing them in the
 Talk page. The idea is to do most of the scheduling on Friday morning, then
 fine tune as we go.

 On Friday morning we will use the /Topics page to organize the scheduling,
 starting with the topics that have raised more interest:

 https://www.mediawiki.org/wiki/Zürich_Hackathon_2014/Topics

 You are welcome to create wiki subpages and/or etherpads (
 https://etherpad.wikimedia.org/ ) for your activities. We will have a
 process for session coordinators to create hangouts from the MediaWiki
 Google+ page, in order to have low-tech instant streaming and videos
 archived, all from your laptops.


 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RfC review this week: Associated namespaces

[David Cuenca]

Hi Sumana,
Thanks for moving the RFC forward! I hope some MW experts can join and
provide their very necessary advice!
Cheers,
Micru


On Mon, Apr 21, 2014 at 7:55 PM, Sumana Harihareswara suma...@wikimedia.org
 wrote:

 Micru's Associated namespaces RfC is up for discussion this week.
 https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-23
 (We also have room for 1 more RfC to discuss.)

 Micru said about
 https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces:

  The intended outcome would be:
  1) find out if there is any objection against the Namespace registry and
  association handlers that Mark proposed
  2) discuss possible problems with this approach
  3) see if there would be any hands available to work on it; it is a
  delicate topic that might need someone with a deep understanding of
 MediaWiki

 Micru also noted that we've had a previous suggestion for a namespace
 manager https://www.mediawiki.org/wiki/Namespace_manager .

  AFIK, it never materialized because back then there was not such a great
  need as there is now - or at least the current use cases didn't exist
 back
  then.
  I hope this RFC moves forward because it affects important upcoming and
  already deployed projects (Commons migration, templates, Visual editor,
 WD,
  etc).

 Come to #wikimedia-office at 2100 UTC this Wednesday

 http://www.worldtimebuddy.com/?qm=1lid=2950159,2147714,5391959,100h=2950159date=2014-4-23sln=23-24
 or reply/comment with your comments/suggestions.

 2300 Berlin
 5pm New York
 2pm California
 7am Sydney

 --
 Sumana Harihareswara
 Senior Technical Writer
 Wikimedia Foundation




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Sharing mathematical and music notations across wikis

[David Cuenca]

Hi Eugene,
you already can upload scores to Commons and transcribe them on Wikisource
as agreed on this RFC
https://meta.wikimedia.org/wiki/Requests_for_comment/Musical_score_transcription_project_proposal

Thanks,
Micru


On Thu, Mar 20, 2014 at 7:23 PM, Eugene Zelenko eugene.zele...@gmail.comwrote:

 Hi!

 I think will be good idea to introduce support for files in TeX and
 ABC/Lilypond (Score extension) formats, so such files could be hosted
 on Commons.

 This will simplify maintenance of formulas and music across projects
 as well as allow to refer to mathematical and music notations from
 Wikidata.

 Eugene.

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Sharing mathematical and music notations across wikis

[David Cuenca]

Oh, so you mean: Reasonably efficient interwiki transclusion
https://bugzilla.wikimedia.org/show_bug.cgi?id=9890

It has been 7 years open maybe some day...

Micru


On Fri, Mar 21, 2014 at 4:01 PM, Eugene Zelenko eugene.zele...@gmail.comwrote:

 Hi, Micru!

 On Fri, Mar 21, 2014 at 6:13 AM, David Cuenca dacu...@gmail.com wrote:
  Hi Eugene,
  you already can upload scores to Commons and transcribe them on
 Wikisource
  as agreed on this RFC
 
 https://meta.wikimedia.org/wiki/Requests_for_comment/Musical_score_transcription_project_proposal

 My point is to share such transcribes between projects.

 Eugene.

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bach redirecting to Bạch (notice the dot under the a)

[David Cuenca]

Hi,

When I type bach on the top right en.wp search box, I only have the
option to select Bach from the list. This option however takes me to
Bạch (with a dot under the a).
https://en.wikipedia.org/wiki/B%E1%BA%A1ch

However when I type the url I'm taken to the right article
https://en.wikipedia.org/wiki/Bach

Is this a problem with the search box? I wanted to report the bug, but I
didn't know to which component to report it.

Cheers,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bach redirecting to Bạch (notice the dot under the a)

[David Cuenca]

I was! When opting out, it works fine.

Thanks for the hint!

Micru


On Mon, Mar 17, 2014 at 2:16 PM, Nikolas Everett never...@wikimedia.orgwrote:

 Are either one of you opted into the New Search BetaFeature?

 Nik


 On Mon, Mar 17, 2014 at 9:01 AM, John phoenixoverr...@gmail.com wrote:

  It works for me.
 
  On Monday, March 17, 2014, David Cuenca dacu...@gmail.com wrote:
 
   Hi,
  
   When I type bach on the top right en.wp search box, I only have the
   option to select Bach from the list. This option however takes me to
   Bạch (with a dot under the a).
   https://en.wikipedia.org/wiki/B%E1%BA%A1ch
  
   However when I type the url I'm taken to the right article
   https://en.wikipedia.org/wiki/Bach
  
   Is this a problem with the search box? I wanted to report the bug, but
 I
   didn't know to which component to report it.
  
   Cheers,
   Micru
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org javascript:;
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New RFC: Associated namespaces (seeking comments proposals)

[David Cuenca]

Hi,

I have started drafting a RFC to associate namespaces:
https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces

Comments and proposals are very much appreciated.

Cheers,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 3d Online Geometry Viewer

[David Cuenca]

Hi Inderpreet,

Welcome and thanks for reaching out, there is definitely the need of a 3d
viewer for mediawiki and brl-cad could add some of the needed features.
Probably you could contact Bryan Davis, since he offered himself as GsoC
mentor for such a project:
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#New_media_types_supported_in_Commons

I'm also CC'ing Fabrice Florin, product manager of the multimedia team,
because I guess that the 3d viewer could be somehow related to the
Multimedia Viewer.
http://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer

I hope it helps. Cheers,
Micru



On Thu, Jan 9, 2014 at 10:50 AM, Inderpreet Singh indrp...@gmail.comwrote:

 Hi, I am Inderpreet Singh, this is my first mail and I hope I am on
 correct mailing list. I am currently working on an online geometry
 viewer that was developed under BRL-CAD (brlcad.org) as one of it's
 GSOC projects last summer. It's in it's very basic stage. It currently
 allows you to upload a CAD model (.g file) and view it 3D in the
 browser. I was planning to add a feature that would allow users to
 embed their models on websites and share it, (think of it as
 http://codepen.io/ for CAD). Also, we were planning to add a mged
 command interface so that we can edit the CAD model online using mged
 commands. We were having discussions over these when someone among us
 pointed out that there is a need of similar extension for mediawiki. I
 would really love to know more about the requirements and propose
 BRL-CAD (one of the oldest open
 source repositories in world) on a server with web-interface as a full
 open source candidate for the required tool.


 --
 Inderpreet Singh

 Ekoankar Sahai
 ishwerdas.com
 facebook.com/okayinder
 https://kippt.com/okayinder

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Quality assessment, badges and credit attribution to engage scientists

[David Cuenca]

@Mark: yes! A barnstar for major contributions to Featured/Good articles
would be perfect, but probably it would need to be a reduced group of users
the ones that are allowed to assign those kind of badges.

@Quim, I think that is a good start, tbh I didn't know about OpenBadges,
thanks for sharing. Do you think it would be worthwhile to add OAuth to the
list?

Cheers,
Micru

On Wed, Aug 21, 2013 at 12:33 PM, Quim Gil q...@wikimedia.org wrote:

 On 08/21/2013 08:35 AM, Mark wrote:

 On 8/16/13 11:48 AM, David Cuenca wrote:

 A manual system where a group of reviewers assign badges to major
 contributors of good/featured articles could be an option, since there
 are
 not that many and usually for human reviewers it is quite clear which
 users
 that have contributed the most to an article.


 Do you have in mind something along the lines of barnstars?

 -- 
 http://en.wikipedia.org/wiki/**Wikipedia:Barnstarshttp://en.wikipedia.org/wiki/Wikipedia:Barnstars


 See also 
 http://www.mediawiki.org/wiki/**OpenBadgeshttp://www.mediawiki.org/wiki/OpenBadges(just
  a stub, don't get excited yet).

 --
 Quim Gil
 Technical Contributor Coordinator @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil


 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Quality assessment, badges and credit attribution to engage scientists

[David Cuenca]

In Wikidata there is an open bug to implement badges (see email below by
Lydia), with the open question if this should be handled by the Mediawiki
software itself or in some other way. Template: Link FA and
Template:Link GA is the system currently used in all Wikipedias [1]

In addition to this, during the Wikimania Open Access project panel [2][3]
there were some suggestions about how to engage the scientific community to
contribute more content to Wikipedia. Apparently one major blocker is the
lack of credit attribution in collaborative environments. By being able to
attribute credit to major contributors of featured/good articles,
scientists could (voluntarily) link their Wikipedia profile to an external
authoring organization who would aggregate these contributions to their
standard journal-based ones.

According to Denny, once SUL is in place, it should be possible to link
Wikidata items representing authors both to their wikimedia profile and to
any external authoring organization representing their identity. However,
the information that this would provide would be of little use unless the
api could provide a list of featured contributions.

Any thoughts or ideas about these issues?

Cheers,
Micru


[1] https://www.wikidata.org/wiki/Q16467
https://www.wikidata.org/wiki/Q5462767
[2]
https://wikimania2013.wikimedia.org/wiki/Submissions/Open_Access_%26_Wikipedia:_Opening_the_world%27s_academic_research_to_improve_the_world%27s_most_popular_reference_source
[3] http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Open_Access

-- Forwarded message --
From: Lydia Pintscher lydia.pintsc...@wikimedia.de
Date: Fri, Aug 16, 2013 at 8:58 AM
Subject: [Wikidata-tech] badges support - decision needed?
To: Wikidata technical discussion wikidata-t...@lists.wikimedia.org


Hey :)

It seems that badges support is stalled on a decision about how
exactly to define the set of available badges if I read
https://bugzilla.wikimedia.org/show_bug.cgi?id=40810 correctly. Can we
make a decision and move forward? It's the most voted on bug we have.


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Technical Projects

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

___
Wikidata-tech mailing list
wikidata-t...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech



-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Quality assessment, badges and credit attribution to engage scientists

[David Cuenca]

On Fri, Aug 16, 2013 at 10:58 AM, John Erling Blad jeb...@gmail.com wrote:

 We don't use votes... ;)


I think Lydia was referring to the votes on the bugzilla bug page, 14 votes
so far :)



 If we forget about the implementation of badges and discuss the
 contributions; there are no single correct way to weight
 contributions. Assume some user A write N characters as a continuous
 string, and some user B writes the same number of characters spread
 out over a text changing N words into something else. Those two edits
 can have the same edit distance but still have a completely different
 entropy. In the last case, who owns the changed words? The original
 author or the later one? This isn't obvious at all.


I thought Wikitrust [1] and others [2] had already addressed this issues?
In any case there is no need for an exact attribution, an approximate
percentage score would be a good enough solution for practical purposes.



[1] http://www.wikitrust.net/
[2] https://www.mediawiki.org/wiki/User:Mshavlovsky/Authorship_Tracking
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Quality assessment, badges and credit attribution to engage scientists

[David Cuenca]

There is no need for a perfect system and if it is too hard to do it
automatically, then don't.
A manual system where a group of reviewers assign badges to major
contributors of good/featured articles could be an option, since there are
not that many and usually for human reviewers it is quite clear which users
that have contributed the most to an article. In a way this is how it is
already happening now, users list in their user pages their good or
featured articles. This might be also a hint for the Editor Engagement
Group, since this kind of practice reflects that it is somewhat important
for editors to list their successes in their user pages even if they have
to go through the effort of doing it manually.



On Fri, Aug 16, 2013 at 11:27 AM, John Erling Blad jeb...@gmail.com wrote:

 The approximate score will with accurate edit distance give two equal
 contributors in the first case, it will credit A with all edits if a
 limit is set on tracking of minor edits that is anything above zero
 with no edits on B, and it will credit the last of two editors if last
 contributions wins. There are no really good approximations, and t
 doesn't help to use percentages.

 Best I know of is dimension reduction and measuring path length, but
 that too fail for some combos of vandalism/reverts.

 On Fri, Aug 16, 2013 at 5:08 PM, David Cuenca dacu...@gmail.com wrote:
  On Fri, Aug 16, 2013 at 10:58 AM, John Erling Blad jeb...@gmail.com
 wrote:
 
  We don't use votes... ;)
 
 
  I think Lydia was referring to the votes on the bugzilla bug page, 14
 votes
  so far :)
 
 
 
  If we forget about the implementation of badges and discuss the
  contributions; there are no single correct way to weight
  contributions. Assume some user A write N characters as a continuous
  string, and some user B writes the same number of characters spread
  out over a text changing N words into something else. Those two edits
  can have the same edit distance but still have a completely different
  entropy. In the last case, who owns the changed words? The original
  author or the later one? This isn't obvious at all.
 
 
  I thought Wikitrust [1] and others [2] had already addressed this issues?
  In any case there is no need for an exact attribution, an approximate
  percentage score would be a good enough solution for practical purposes.
 
 
 
  [1] http://www.wikitrust.net/
  [2] https://www.mediawiki.org/wiki/User:Mshavlovsky/Authorship_Tracking
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki to Latex Converter

[David Cuenca]

Hi! Well, I was thinking that maybe both formats could coexist in the same
project/web, and as soon as somebody wants to export it, it would be
possible to convert the wikitext into latex and export both.

No idea if it would have any practical use, though.

Btw, great music! :)

Micru


On Tue, Aug 13, 2013 at 9:06 PM, Lee Worden worden@gmail.com wrote:

 Hi Micru!

 What use case do you have in mind?

 The main use of latex in WorkingWiki is simply authoring .tex files
 directly...

 Lee Worden

 p.s. I meant to post the What is WorkingWiki video here that I put on
 twitter during Wikimania: 
 http://www.youtube.com/watch?**v=D8pwr-Uizf4http://www.youtube.com/watch?v=D8pwr-Uizf4

  Date: Tue, 13 Aug 2013 16:04:44 -0400
 From: David Cuenca dacu...@gmail.com
 To: Wikimedia developers 
 wikitech-l@lists.wikimedia.**orgwikitech-l@lists.wikimedia.org
 


 I think this is going to be great news for WorkingWiki
 https://www.mediawiki.org/**wiki/Extension:WorkingWikihttps://www.mediawiki.org/wiki/Extension:WorkingWiki
 Cheers, Micru

 On Tue, Aug 13, 2013 at 3:57 PM, Greg Grossmeier g...@wikimedia.org
 wrote:

 quote name=Dirk Hünniger date=2013-08-04 time=10:05:35 +0200

 Hello,
 I made a new debian package, which resolves the security issues you
 mentioned.
 It is available here:
 http://sourceforge.net/**projects/wb2pdf/files/**mediawiki2latex/6.5/http://sourceforge.net/projects/wb2pdf/files/mediawiki2latex/6.5/
 Yours Dirk


 I had to use a mailing list archive to see the full thread here, which
 started way back in 2004(!!!):
 http://www.gossamer-threads.**com/lists/wiki/wikitech/281372http://www.gossamer-threads.com/lists/wiki/wikitech/281372

 A highlight I noticed: the wb2pdf that Dirk links above when from a
 90+meg download to only a 2.8 meg Debian package.

 Thanks for your persistence, Dirk.

 Greg

 --
 | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
 | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l


 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki to Latex Converter

[David Cuenca]

I think this is going to be great news for WorkingWiki
https://www.mediawiki.org/wiki/Extension:WorkingWiki

Cheers,
Micru

On Tue, Aug 13, 2013 at 3:57 PM, Greg Grossmeier g...@wikimedia.org wrote:

 quote name=Dirk Hünniger date=2013-08-04 time=10:05:35 +0200
  Hello,
  I made a new debian package, which resolves the security issues you
  mentioned.
  It is available here:
  http://sourceforge.net/projects/wb2pdf/files/mediawiki2latex/6.5/
  Yours Dirk

 I had to use a mailing list archive to see the full thread here, which
 started way back in 2004(!!!):
 http://www.gossamer-threads.com/lists/wiki/wikitech/281372

 A highlight I noticed: the wb2pdf that Dirk links above when from a
 90+meg download to only a 2.8 meg Debian package.

 Thanks for your persistence, Dirk.

 Greg

 --
 | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
 | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaborative machine translation for Wikipedia -- proposed strategy

[David Cuenca]

On Fri, Jul 26, 2013 at 11:30 PM, C. Scott Ananian
canan...@wikimedia.orgwrote:

 This statement seems rather defeatist to me.  Step one of a machine
 translation effort should be to provide tools to annotate parallel texts in
 the various wikis, and to edit and maintain their parallelism.


Scott, edit and maintain parallelism sounds wonderful on paper, until you
want to implement it and then you realize that you have to freeze changes
both in the source text and in the target language for it to happen, which
is, IMHO against the very nature of wikis.
Translate:Extension already does that in a way. I see it useful only for
texts acting as a central hub for translations, like official
communication. If that were to happen for all kind of content you would
have to sacrifice the plurality of letting each wiki to do their own
version.


 Once this
 is done, you have a substantial parallel corpora, which is then suitable to
 grow the set of translated articles.  That is, minority languages ought to
 be accounted for by progressively expanding the number of translated
 articles in their encyclopedia, as we do now.  As this is done, machine
 translation incrementally improves.


The most popular statistical-based machine translation system has created
its engine using texts extracted from *the whole internet*, it requires
huge processing power, and that without mentioning the amount of resources
that went into research and development. And having all those resources
they managed to create a system that sort of works.
Wikipedia doesn't have enough amount of text nor resources to follow that
route, and the target number of languages is even higher.
Of course statistical-based approaches should also be used as well (point 8
of the proposed workflow), however more as a supporting technology rather
than the main one.


 If there is not enough of an editor
 community to translate articles, I don't see how you will succeed in the
 much more technically-demanding tasks of creating rules for a rule-based
 translation system.  The beauty of the statistical approach is that little
 special ability is needed.


One single researcher can create working transfer rules for a language pair
in 3 months or less if there is previous work (see these GsoC [1], [2],
[3]). Whichever problem the translation has, it can be understood and
corrected. With statistics, you rely on bulk numbers and on the hope that
you have enough coverage, and that makes improving its defects even harder.
It is true that writing transfer rules is technically demanding, and so it
is writing mediawiki software, which keeps being developed anyways. After
seeing how their system works, I think there is room for simplifying
transfer rules (first storing them as mediawiki templates, then as linked
data, then having a user interface). That could lower the entry barrier for
linguists and translators alike, while enabling the triangulation of rules
between pairs that have a common one.

As said before, there is no single tool that can do everything, it is the
combination of them what will bring the best results. The good thing is
that there is no need to marry a technology, several can be developed in
parallel and broght to a point of convergence where they work together for
optimal results.

I appreciate that you took time to read the proposal :)

Thanks,
David

[1]
http://www.google-melange.com/gsoc/project/google/gsoc2013/akindalki/3001
[2]
http://www.google-melange.com/gsoc/project/google/gsoc2013/jcentelles/20001
[3]
http://www.google-melange.com/gsoc/project/google/gsoc2013/jonasfromseier/5001
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaborative machine translation for Wikipedia -- proposed strategy

[David Cuenca]

On Sat, Jul 27, 2013 at 10:39 AM, C. Scott Ananian
canan...@wikimedia.orgwrote:

 My main point was just that there is a chicken-and-egg problem here.  You
 assume that machine translation can't work because we don't have enough
 parallel texts.  But, to the extent that machine-aided translation of WP is
 successful, it creates a large amount of parallel text.   I agree that
 there are challenges.  I simply disagree, as a matter of logic, with the
 blanket dismissal of the chickens because there aren't yet any eggs.


I think we both agree about the need and usefulness of having a copious
amount of parallel text. The main difficulty is how to get there from
scratch. As I see it there are several possible paths
- volunteers creating the corpus manually (some work done, however not
properly tagged)
- use a statistic approach to create the base text and volunteers would
improve that text only
- use rules and statistics to create the base text and volunteers would
improve the text and optionally the rules

The end result of all options is the creation of a parallel corpus that can
be reused for statistic translation. In my opinion, the efectivity of
giving users the option to improve/select the rules is much larger than
improving the text only. It complements statistic analysis rather than
replacing it and it provides a good starting point to solve the egg-chicken
conundrum, specially in small Wikipedias.

Currently translatewiki is relying on external tools where we don't have
much control, besides of being propietary and with the risk that they can
be disabled any time.

I think you're attributing the faults of a single implementation/UX to the
 technique as a whole.  (Which is why I felt that step 1 should be to
 create better tools for maintaining information about parallel structures
 in the wikidata.)


Good call. Now that you mention it, yes, it would be great to have a place
where to keep a parallel corpus, and it would be even more useful if it can
be annotated with wikidata-wiktionary senses. A wikibase repo might be the
way to go. No idea if Wikidata or Translatewiki are the right places to
store/display it. Maybe it will be a good time to discuss it during
Wikimania. I have added it to the elements section.



 In a world with an active Moore's law, WP *does* have the computing power
 to approximate this effort.  Again, the beauty of the statistical approach
 is that it scales.


My main concern about statistic-based machine translation is that it needs
volume to be effective, hence the proposal to use rule-based translation to
reach the critical point faster than just using statistics on existing text
alone.



 I'm sure we can agree to disagree here.  Probably our main differences are
 in answers to the question, where should we start work?  I think
 annotating parallel texts is the most interesting research question
 (research because I agree that wiki editing by volunteers makes the UX
 problem nontrivial).  I think your suggestion is to start work on the
 semantic multilingual dictionary?


It is quite possible to have multiple developments in parallel. That a
semantic dictionary is in development doesn't hinder the creation of a
parallel corpus or an interface for annotating. The same applies to
statistics/rules, they are not incompatible, in fact they complement each
other pretty well.


 ps. note that the inter-language links in the sidebar of wikipedia articles
 already comprise a very interesting corpus of noun translations.  I don't
 think this dataset is currently exploited fully.


I couldn't agree more. I would ask to take a close look to CoSyne. I'm sure
some of it can be reused:
http://www.cosyne.eu/index.php/Main_Page

Cheers,
David
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Collaborative machine translation for Wikipedia -- proposed strategy

[David Cuenca]

After Erik's email about supporting open source machine translation [1],
I've been researching options and having talks with several machine
translation researchers about what would be the best way to integrate MT
into Wikipedia. Unfortunately I couldn't find a single solution that, on
its own, would fulfill all requirements (specially being open source). On
the plus side, there is a set of technologies that if integrated, they
could provide a positive and reliable experience. It would be a hard way to
get there, and even so, it might be worth exploring.

This is the preliminary draft:
https://meta.wikimedia.org/wiki/Collaborative_Machine_Translation_for_Wikipedia

It is a shame that the talk about Supporting translation of Wikipedia
content [2] has not been accepted for WM13.
Hopefully there will be enough interest to discuss this topic there anyways.

Micru


[1] http://thread.gmane.org/gmane.org.wikimedia.foundation/65605
[2]
https://wikimania2013.wikimedia.org/wiki/Submissions/Supporting_translation_of_Wikipedia_content
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs

[David Cuenca]

On Wed, Jul 24, 2013 at 5:34 AM, John Erling Blad jeb...@gmail.com wrote:

 There are good reasons why users want to turn off VE and the most
 important reason are not what most people in the thread seems to
 think. Users that have learned to use a crappy direct editing user
 interface tend to be faster on using that interface than more modern
 WYSIWYG editors. I tried to make a few test edits whit carefully
 planned actions and I could not edit as fast with VE as with the old
 crappy edit page. I think this is quite common. When editors tries to
 edit with the new editor they experience this and gets the feeling
 that VE itself is sluggish, but the real reason is that the user
 interactions slows down. The difference in editing speed i visible
 even at ordinary text with only minor wikicode, but as the amount of
 wikicode increases the diference grows.


I would love if the Visual Editor could have also wikicode edition
capabilities with proper synthax highlighting.
There is the Dot's syntax highlighter as a gadget but it doesn't come close
to other code highlighters like Notepad++
Would that be possible?

Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] gwtoolset : architecture design help

[David Cuenca]

Dan,

Great move with the extension, I think it as good way to integrate the GWT
into Commons. I would like to make you aware of this proposal to move
Commons towards linked data:
http://commons.wikimedia.org/wiki/Commons:Wikidata_for_media_info

Obviously this move would simplify the work for you since you would know
beforehand what are the properties available and use them as you please
(unlike templates). Some other aspects would be perhaps more complicated,
like determining which Wikidata item to link for a given author.

This move in Commons is supposed to be some time next year (according to
the talk page), so in the mean time using TemplateData as Mark suggested,
seems a good idea.

David

On Wed, Jul 24, 2013 at 2:59 PM, dan entous
dan.entous.wikime...@gmail.comwrote:

 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_Comments/Technical_Architecture
 
 http://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_Comments/Technical_Architecture
 


 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
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs

[David Cuenca]

I'm glad that Tim is bringing some facts and numbers that back up what the
community is demanding.
To do otherwise will be to play tug-of-war which will lead to an even worse
outcome.

Besides of enabling the preference, a good approach would be to activate or
deactivate that preference depending on how much an user has been using (or
not) Visual Editor in their last edits and to ask new users if they want to
use VE or the plain text system. New users are not that new, since many
of them have been editing anonymously before.

When there are more compelling reasons to do the switch (like real-time
collaboration), users can have a higher incentive to do the switch.

Micru

On Mon, Jul 22, 2013 at 11:44 PM, Tim Starling tstarl...@wikimedia.orgwrote:

 On 23/07/13 11:35, James Forrester wrote:
  It would imply that this is a preference that Wikimedia will support.
  This would be a lie. We have always intended for VisualEditor to be a
  wiki-level preference, and for this user-level preference to disappear
 once
  the need for an opt-in (i.e., the beta roll-out to production wikis) is
  over.

 The feedback from established users [1] and the results from Aaron
 Halfaker's study [2] suggest that opt-in would be the most appropriate
 policy given VE's current level of maturity. That is, disable it by
 default and re-enable the preference.

 A proponent of source editing would claim that the steep learning
 curve is justified by the end results. A visual editor is easier for
 new users, but perhaps less convenient for power users. So Aaron
 Halfaker's study took its measurements at the point in the learning
 curve where you would expect the benefit of VE to be most clear: the
 first edit. Despite the question being as favourable to VE as
 possible, the result strongly favoured the use of source editing:

 Newcomers with the VisualEditor were ~43% less likely to save a
 single edit than editors with the wikitext editor (x^2=279.4,
 p0.001), meaning that Visual Editor presented nearly a 2:1 increase
 in editing difficulty.

 On the Wikipedia RFC question Wikimedia should disable this software
 by default?, there were 30 support votes and 17 opposed. But many of
 those 17 oppose votes assumed that VE is beneficial to new users. Now
 that we know that that isn't the case, the amount of support for
 enabling VE by default would surely be very small indeed. If it's not
 beneficial for either established or new users, why have it?

 It's not like the VE team are sitting around with no testing to do, no
 features to add, and no bugs to work on. So the argument that you need
 people looking at VE in order to provide feedback seems shallow.

 Round-trip bugs, and bugs which cause a given wikitext input to give
 different HTML in Parsoid compared to MW, should have been detected
 during automated testing, prior to beta deployment. I don't know why
 we need users to report them.

 Perhaps the main problem is performance. Perhaps new users are
 especially likely to quit on the first edit because they don't want to
 wait 25-30 seconds for the interface to load (the time reported in
 [3]). Performance is a very common complaint for established users also.


 [1] https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/RFC

 [2]
 
 https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_registered_editors/Results
 

 [3] https://office.wikimedia.org/wiki/VisualEditor_user_tests

 -- Tim Starling


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Suggestion for solving the disambiguation problem

[David Cuenca]

Good idea, it could also help to know which are the links more used in a
disambiguation page to sort them by importance.

Micru

On Tue, Jul 16, 2013 at 2:03 PM, Nicolas Vervelle nverve...@gmail.comwrote:

 Interesting idea...


 On Mon, Jul 15, 2013 at 11:41 PM, Jon Robson jdlrob...@gmail.com wrote:

  I understand there is an issue that needs solving where various pages
  link to disambiguation pages. These need fixing to point at the
  appropriate thing.
 
  I had a thought on how this might be done using a variant of
  EventLogging...
 
  When a user clicks on a link that is a disambiguation page and then
  clicks on a link on that page we log an event that contains
 
  * page user was on before
  * page user is on now
 
  If we were to collect this data it would allow us to statistically
  suggest what the  correct disambiguation page might be.
 
  To take a more concrete theoretical example:
  * If I am on the Wiki page for William Blake and click on London I am
  taken to https://en.wikipedia.org/wiki/London_(disambiguation)
  * I look through and see London (poem) and click on it
  * An event is fired that links London (poem) to William Blake.
 
  Obviously this won't always be accurate but I'd expect generally this
  would work (obviously we'd need to filter out bots)
 
  Then when editing William Blake say that disambiguation links are
  surfaced. If I go to fix one it might prompt me that 80% of visitors
  go from William Blake to London (poem).
 
 
  Have we done anything like this in the past? (Collecting data from
  readers and informing editors)
 
  I can imagine applying this sort of pattern could have various other
  uses...
 
 
 
 
  --
  Jon Robson
  http://jonrobson.me.uk
  @rakugojon
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Version of the Flow Prototype Released

[David Cuenca]

Nice design! Will it work across projects?

Micru

On Sun, Jul 14, 2013 at 2:12 PM, Brandon Harris bhar...@wikimedia.orgwrote:


 Those are messages in which the reader has been mentioned.



 On Jul 14, 2013, at 1:12 AM, Aarti K. Dwivedi ellydwivedi2...@gmail.com
 wrote:

  Some usernames have a leading @ before their messages but others don't.
 Is
  it expected behavior?
 
 
  On Sun, Jul 14, 2013 at 11:21 AM, Tyler Romeo tylerro...@gmail.com
 wrote:
 
  OK. First, looks pretty good. Nice work! I have just one comment: There
 are
  quite a lot of symbols with not much explanation. What's the difference
  between the conversation having a star on it, having a dot above the
  collapse arrow, and having an @ symbol on it? Also, why are some
 usernames
  green and others gray?
 
  *-- *
  *Tyler Romeo*
  Stevens Institute of Technology, Class of 2016
  Major in Computer Science
  www.whizkidztech.com | tylerro...@gmail.com
 
 
  On Sun, Jul 14, 2013 at 12:45 AM, Chad innocentkil...@gmail.com
 wrote:
 
  Well, it's not a product (yet), so there's no place in BZ to
  file bugs (yet). I assume any bugs or feedback could be
  provided in this thread though :)
 
  -Chad
 
  On Sat, Jul 13, 2013 at 9:43 PM, Brandon Harris bhar...@wikimedia.org
  wrote:
 
 
 This isn't a product, so there isn't a place for bugs.  And I
  am
  the designer.
 
 
  On Jul 13, 2013, at 7:51 PM, Tyler Romeo tylerro...@gmail.com
 wrote:
 
  Where can we file bugs for this? Also, who came up with the design
  for
  this?
 
  *-- *
  *Tyler Romeo*
  Stevens Institute of Technology, Class of 2016
  Major in Computer Science
  www.whizkidztech.com | tylerro...@gmail.com
 
 
  On Sat, Jul 13, 2013 at 5:31 PM, Brandon Harris 
  bhar...@wikimedia.org
  wrote:
 
 
A new version of the Flow Prototype has been released.  This
  version has ''many'' changes, not the least of which is that it
  approaches
  full functionality.
 
You may play with it here:
 
http://unicorn.wmflabs.org/flow/
 
Release notes are here:
 
 
  http://www.mediawiki.org/wiki/Flow_Portal/Interactive_Prototype
 
This is a pretty heavy change.  Here are the tl;dr release
  notes:
 
* Many elements removed (author metadata, post
  counts,
  collapse all button)
* New topic dialog is single element
* Fixed header on scroll
* Many visual changes to conform to new version of
  Agora
  styling
* Posted replies should now go to correct position
  (with
  animation)
* All dates now have hover change instead of tipsy;
  clicking produces permanent link dialog
* Removed chaos modes
* Added admin toggle (turns user into admin)
* Added many moderation functions:
  edit/delete/restore
  post, delete/restore/close/supress topic, edit topic title
* Added history functionality for topics and posts
* Read posts are now open by default (experimental)
* Killed several features not in the minimum viable
  product.
* Fake-up a VisualEditor toolbar in textareas
  (non-functional)
 
  ---
  Brandon Harris, Senior Designer, Wikimedia Foundation
 
  Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
 
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
  ---
  Brandon Harris, Senior Designer, Wikimedia Foundation
 
  Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
 
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 
 
 
  --
  Aarti K. Dwivedi
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ---
 Brandon Harris, Senior Designer, Wikimedia Foundation

 Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org

Re: [Wikitech-l] Centralized Lua modules for Wikisource (OPW mentor needed)

[David Cuenca]

On Mon, Jun 3, 2013 at 9:57 AM, Mathieu Stumpf 
psychosl...@culture-libre.org wrote:
 Oh, I wasn't aware of this wikisource specificity? Is that related to a
central djvu repository?

No, it is only related to the existence of a central project. However Matt
Flaschen says that mediawiki.org could be used instead.


On Sun, Jun 2, 2013 at 2:35 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote:
 mediawiki.org is a better central location for code.

Could associated templates be stored there as well?

Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Centralized Lua modules for Wikisource (OPW mentor needed)

[David Cuenca]

On Sun, Jun 2, 2013 at 7:21 AM, Mathieu Stumpf 
psychosl...@culture-libre.org wrote:

 Interesting, but why make a central code repository only for
 Wikisource ?


 There are several reasons for this.
- trying to support all projects at once might be too much for a grantee to
do in 3 months.
- it is an experience to learn from, and it will have to be decided if it
can be applied broadly or substituted for some better method
- wikisource has a central location that can be used for this purpose,
other projects don't have it specifically. It could be meta, but that
should be discussed

Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Centralized Lua modules for Wikisource (OPW mentor needed)

[David Cuenca]

Hi all,

After a talk with Brad Jorsch during the Hackathon (thanks again Brad for
your patience), it became clear to me that Lua modules can be localized
either by using system messages or by getting the project language code
(mw.getContentLanguage().getCode()) and then switching the message. This
second option is less integrated with the translation system, but can serve
as intermediate step to get things running.

For Wikisource it would be nice to have a central repository (sitting on
wikisource.org) of localized Lua modules and associated templates. The
documentation could be translated using Extension:Translate. These modules,
templates and associated documentation would be then synchronized with all
the language wikisources that subscribe to an opt-in list. Users would be
then advised to modify the central module, thus all language versions would
benefit of the improvements. This could be the first experiment of having a
centralized repository of modules.

What do you think of this? Would be anyone available to mentor an Outreach
Program for Women project?

Thanks,
David Cuenca --Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Announcing the Flow Portal(s)

[David Cuenca]

Hi Brandon,

Thanks for the announce and also for the effort of letting the door open
for suggestions and feedback. I regard Flow as an excellent tool for
centralizing all communications in one spot and I really hope user
involvement is as high as this tool would deserve. So far the test page
looks really appealing!

I would like to make you aware of a related problem which is that of
interwiki or interproject presence. Sometimes it is wanted that a certain
set of pages is present across several wikis (like in the case of the Flow
portal), and the best approximation we had to this is interwiki
transclusion. This kind of soft transclusion is less than ideal, because
users following a transcluded page won't get notified of a change, cannot
edit the transcluded page and besides they are difficult to create.

Would be there any way to simulate a hard transclusion? What I have in
mind is:
- a set of pages in meta can be declared of interest for selected
projects/languages
- mirror pages are created on the selected wikis/projects/languages (bot
drudgery? db necromancy? flow magic?)
- changes are notified in the recent changes of all relevant projects,
subscribers are notified

What are your thoughts on this?

Cheers,
David --Micru

On Wed, May 15, 2013 at 4:47 PM, Brandon Harris bhar...@wikimedia.orgwrote:

 Hello!

 As many of you know, the Wikimedia Foundation is now actively
 engaged in designing a next-generation discussion and workflow system
 called Flow, initially slated to replace user talk pages.  Flow is an
 ambitious project (on par with the VisualEditor) and will touch nearly
 every aspect of the Wikimedia experience.

 We need ''your'' help and input.  We have started a portal for
 information and discussion.

 You can find it on the English Wikipedia here:
 http://en.wikipedia.org/wiki/Wikipedia:Flow

 And on MediaWiki here: http://www.mediawiki.org/wiki/Flow_Portal

 (We'll be creating one on meta as well).

 At the Flow portal, you can read about what we're doing and why,
 as well as play around with an interactive prototype.

 We're desperately interested in your feedback and thoughts.  There
 are things that we know, and things that we know that we don't know. But
 there are also things that we *don't* know that we don't know.  And we want
 to reduce that lack of knowledge.

 We will also be conducting additional office hours for a variety
 of timezones - as many as we need to - and will also be open to having
 conversations via Google hangouts and/or Skype as need be.  I am always
 around on irc (freenode, username jorm) and am willing to answer any
 questions you may have.

 -b.
 ---
 Brandon Harris, Senior Designer, Wikimedia Foundation

 Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate


 ___
 Wikimedia-l mailing list
 wikimedi...@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Extension:Score] Unable to create a single score from multiple pages

[David Cuenca]

Bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=48538

On Wed, May 15, 2013 at 11:33 AM, David Cuenca dacu...@gmail.com wrote:

 Hi,

 At ca-ws we have started creating musical scores and we have found out
 that when transcluding two pages into one, it is only possible to generate
 two independent audio files instead of one with the whole score.

 Example with two pages

 http://ca.wikisource.org/wiki/P%C3%A0gina%3A30_can%C3%A7ons_populars_catalanes_%281916%29.djvu/59

 http://ca.wikisource.org/wiki/P%C3%A0gina%3A30_can%C3%A7ons_populars_catalanes_%281916%29.djvu/60

 Transcluded score:
 http://ca.wikisource.org/wiki/Els_micalets_d%27Espanya

 Is there any way to combine multiple pages into a single file? I have
 tried to transclude each section independently, but I always get a wall of
 text with errors. Also interesting would be to give the user the option to
 save that lilypond file.

 Cheers,
 David --Micru




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [Extension:Score] Unable to create a single score from multiple pages

[David Cuenca]

Hi,

At ca-ws we have started creating musical scores and we have found out that
when transcluding two pages into one, it is only possible to generate two
independent audio files instead of one with the whole score.

Example with two pages
http://ca.wikisource.org/wiki/P%C3%A0gina%3A30_can%C3%A7ons_populars_catalanes_%281916%29.djvu/59
http://ca.wikisource.org/wiki/P%C3%A0gina%3A30_can%C3%A7ons_populars_catalanes_%281916%29.djvu/60

Transcluded score:
http://ca.wikisource.org/wiki/Els_micalets_d%27Espanya

Is there any way to combine multiple pages into a single file? I have tried
to transclude each section independently, but I always get a wall of text
with errors. Also interesting would be to give the user the option to save
that lilypond file.

Cheers,
David --Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSoC: next steps

[David Cuenca]

Excellent news! Congratulations to everyone involved!

Cheers,
David

On Tue, May 7, 2013 at 4:36 PM, Parth Srivastav
srivastav.pa...@gmail.comwrote:

 Hi Quim

 Great news, Congrats to the entire team


 On Wed, May 8, 2013 at 2:03 AM, Rahul Maliakkal rahul14...@gmail.com
 wrote:

  Hi Quim
 
  Great News, Youve struck Gold. Cheers to WMF :)
 
 
  On Wed, May 8, 2013 at 12:57 AM, Harsh Kothari 
 harshkothari...@gmail.com
  wrote:
 
   Hi Quim
  
   This is fantastic news. Your efforts paid off. Congrats to all. :)
  
   Cheers
   Harsh
  
  
   On Wed, May 8, 2013 at 12:51 AM, Pragun Bhutani pragu...@gmail.com
   wrote:
  
That's really good news! Thanks for sharing, Quim. I'm looking
 forward
  to
the next steps now. :)
   
Cheers everybody!
   
On Wed, May 8, 2013 at 12:14 AM, Siebrand Mazeland (WMF) 
smazel...@wikimedia.org wrote:
   
 That's awesome, Quim. Thanks for all your efforts, support,
   encouragement
 and guidance so far.

 The best is yet to come! May you enjoy many more alcohol-free
 drinks
  in
 celebration of future milestones passed.

 Cheers!

 Siebrand


 On Tue, May 7, 2013 at 8:40 PM, Quim Gil q...@wikimedia.org
 wrote:

  Google just allocated slots and...
 
 
  On 05/05/2013 09:23 PM, Quim Gil wrote:
 
  Based on the feedback received from the mentors we are
 requesting
 
  11 min
  21 max
 
 
  ... WE HAVE GOT 21 SLOTS ALLOWED
 
  First: congratulations to everybody involved: mentors AND
 students.
This
  number reflects succinctly how much someone like Google trusts
 you.
 
  Second: this relaxes a lot our selection process. Between this
 and
   OPW
we
  can accommodate many good proposals.
 
  Third: still, we will keep standards high as we have done so far.
Having
  21 slots doesn't mean that we will take them blindly. We will
   continue
  asking questions to mentors and students about the feasibility of
   each
  proposal and we will consider accepted only those that have all
 the
  foundations in place.
 
  Last but not least: remember the important point about
   confidentiality.
  Now several projects might look pretty obvious candidates but
 this
 doesn't
  authorize anybody to leak / pre-announce our decisions made.
 Google
   is
  still the one that must announce all accepted GSoC projects
 first.
 
  PS: and now, if you don't mind, I'll go get some sophisticated
  alcohol-free drink to celebrate. Salut!
 
 
  --
  Quim Gil
  Technical Contributor Coordinator @ Wikimedia Foundation
  http://www.mediawiki.org/wiki/**User:Qgil
 http://www.mediawiki.org/wiki/User:Qgil
 
  __**_
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 



 --
 Siebrand Mazeland
 Product Manager Language Engineering
 Wikimedia Foundation

 M: +31 6 50 69 1239
 Skype: siebrand

 Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

   
   
   
--
Pragun Bhutani
http://pragunbhutani.in
Skype : pragun.bhutani
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
   
  
  
  
   --
   Harsh Kothari
   Engineering Trainee,
   Physical Research Laboratory.
   Follow Me : harshkothari410 https://twitter.com/harshkothari410/
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 



 --
 Regards
 Parth Srivastav
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Prototyping Wiki Inline Comments

[David Cuenca]

Hi Anthony,

Your proposal seems quite suitable to annotate texts in Wikisource, since
the text is constant and you will not have problems using the highlighted
text as anchor.
Another participant has suggested storing the annotation as JSON in a new
namespace Annotation:, I think there is a plugin for the OKFN annotator
that can handle this, but I don't know how well Mediawiki could handle it,
maybe a support extension is needed.

David  --User:Micru

On Sat, May 4, 2013 at 12:49 PM, Daniel Mietchen 
daniel.mietc...@googlemail.com wrote:

 Hi Anthony,

 sorry for not having expressed myself clearly enough.

 What I had in mind was mainly that the text of the page might change
 after the initial highlighting of parts of that text, but yes,
 sometimes an inline comment might actually fit better at a different
 place within the text, so moving the comment's location around would
 also be interesting.

 Daniel


 --
 http://www.google.com/profiles/daniel.mietchen


 On Sat, May 4, 2013 at 6:36 PM, Anthony cs3245...@gmail.com wrote:
  Hi Daniel,
 
  I hope to clarify the question you asked. Let's say userA highlighted the
  text sunflower stalk and wrote an inline starting comment.
 
  Now userB decides to give an inline reply to the inline comment.
 
  Are you asking about how the system would handle a case in which userA
  shifts the highlighting from sunflower stalk to green leaves at the
  same time when userB is adding the inline reply?
  (and you have userB who thinks his inline reply would be appearing next
 to
  the sunflower stalk text.)
 
 
  On Sat, May 4, 2013 at 4:15 AM, Daniel Mietchen 
  daniel.mietc...@googlemail.com wrote:
 
  Hi Anthony,
 
  interesting feature. How would the system handle cases in which the
  content originally pointed at when making the initial inline comment
  has been changed?
 
  Daniel
 
 
  On Fri, May 3, 2013 at 10:09 PM, Anthony cs3245...@gmail.com wrote:
   Dear all,
  
   I have applied for the Prototyping Inline Comments for the Google
 Summer
  of
   Code.
  
   Essentially, the project is an extension that allows any wiki user to
   select text and then make an inline comment or a reply to an existing
   inline comment. Imagine: a user lands in a Wikipedia article, selects
 one
   sentence and leaves an inline comment that others can optionally read
 and
   reply to.
  
   Users can make useful comments regarding specific part of articles,
 which
   will be a part of collaborative work. The key benefit is to users to
   collaborate easily - because this actually allows you to point to
  something
   and comment in direct reference to it. It's like pointing your finger
 to
  a
   piece of paper and telling your friend sitting next to you, which can
  only
   be done in person and is currently impossible over the Internet. So
 it's
  a
   really powerful feature for collaborations since it makes one of the
   Internet-impossibles into a possible action.
  
   That was for the insertion of a new comment. For the replying part, it
  will
   be a format will likely be similar to how threads are like in a forum,
  for
   the prototype.
  
   As I go along the project, I will be posting more technical details
 and
   updates. From now til the end of the project, I do hope to get
 everyone's
   feedback along the way :)
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] High-resolution Score images for printing, hi-dpi displays: two possible ways?

[David Cuenca]

Brion,
Have you checked if Vexflow renders svg properly on you Macbook/Ubuntu?
Maybe you can get some ideas from its code.
http://vexflow.com/

Thanks for working on this,
David --Micru

On Sat, May 4, 2013 at 7:09 PM, Brion Vibber bvib...@wikimedia.org wrote:

 I've done a little weekend hacking experimenting with adding
 higher-resolution output support for the Score extension -- the current PNG
 images look pixelated or fuzzy when printed or viewed on high-DPI (eg
 'Retina') displays.


 There's two avenues I'm exploring:
 * https://gerrit.wikimedia.org/r/#/c/62243/ - outputs SVG instead of PNG

 In theory, SVGs will scale cleanly to any screen or print resolution; but
 some older browsers (IE  9 and Android  3) won't display them.

 Unfortunately I'm getting totally corrupted SVG output on my MacBook with
 Lilypond 2.16.2. On my Ubuntu 12.04 machine with 2.14.something I get
 complete-looking SVGs, but they're missing the XML namespace and so won't
 render.

 So far there's no PNG fallback made, which would be needed (either by
 converting the SVGs or by running lilypond twice with different backends).
 Also don't know if the SVGs are full-page or trimmed, since they don't
 display.


 * https://gerrit.wikimedia.org/r/#/c/62313/ - allows for producing
 higher-resolution PNGs

 This adds a $wgScoreScale setting, which can be cranked up from the 1.0
 default to say 2.0 to render PNGs twice as big as normal and scale them
 down in the browser.

 This looks great in a PDF or on a Retina screen, but the scale-down might
 not be ideal on traditional screens with some browsers.

 Could be improved by outputting to multiple resolutions (1.0, 1.5, and 2.0
 scale) and using 'srcset' to specify which image goes to which resolution.

 (In this version, I'm storing the images' width/height in a .json file.)

 Any ideas or preferences on which is the better way to go?

 -- brion
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Works on annotations

[David Cuenca]

Hi Mathieu, hi James,

There is this GsoC proposal that plans to explore the integration of an
annotation system in Mediawiki:
https://www.mediawiki.org/wiki/User:Rjain/Proposal-Prototyping-inline-comments

The idea is to see how well and in which ways the OKFN Annotator could be
deployed:
http://okfnlabs.org/annotator/

If successful, it would be very useful for cases like the one you are
suggesting. It could be used to cite texts in Wikisource in a easier way
than now.

David ---Micru

On Sun, Apr 28, 2013 at 12:59 AM, James Forrester
jforres...@wikimedia.orgwrote:

 On 19 April 2013 03:28, Mathieu Stumpf psychosl...@culture-libre.org
 wrote:
  I think I red some things on annotations in the Visual Editor, but I
 can't
  find it again. Do you have relevant informations on the subject? I like
 to
  use template like {{why|blabla}} and {{according to who|blabla}}, but in
 the
  same time I can see that while making a contribution call to
 knowledgeable
  people, it can quickly clutter the text with a lot of underlined
 sentances.
  So it may be interesting to have an option to hide/show this kind of
 query.

 Sorry, just saw this; we have some vague plans to add an out-of-page
 commenting tool to VisualEditor in the longer term, along the lines of
 how Google Docs handles things, possibly using the Flow system if
 that's appropriate, but these are not solid and certainly are not
 planned for us to work on them in the near future. :-)

 There's also the question of how to handle HTML comments (which are
 sometimes used for editor-facing annotations) and whether this
 replaces them or would sit alongside them.

 Such a tool would also interact with the real-time collaboration and
 chat work that we're planning to do next fiscal year (so, from July
 2013 onwards), so it's worth properly discussing with interested
 parties.

 J.
 --
 James D. Forrester
 Product Manager, VisualEditor
 Wikimedia Foundation, Inc.

 jforres...@wikimedia.org | @jdforrester

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikisource-l] Fwd: Bug 189: Add a music wikimodule resolved/fixed

[David Cuenca]

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_transcription_project_proposal

Micru

On Wed, Apr 24, 2013 at 4:34 AM, John Vandenberg jay...@gmail.com wrote:

 Yay!!

 John Vandenberg.
 sent from Galaxy Note
 -- Forwarded message --
 From: MZMcBride z...@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@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@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ___
 Wikisource-l mailing list
 wikisourc...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikisource-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bug 189: Add a music wikimodule resolved/fixed

[David Cuenca]

This is really amazing! Specially for Wikisource :-)

Is multi-page score transclusion with Extension:Proofread page able to
generate a global midi/score file or each page has to be treated as an
independent entity?

Micru

On Tue, Apr 23, 2013 at 4:11 AM, Antoine Musso hashar+...@free.fr wrote:

 Le 23/04/13 04:27, MZMcBride a écrit :
   Add a music wikimodule
  https://bugzilla.wikimedia.org/show_bug.cgi?id=189
 
  Congrats to all involved in getting bug 189 resolved! :-)

 I think that deserves an official press release by the WMF :-D

 Congratulations to everyone involved!

 --
 Antoine hashar Musso


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC on possible interproject link interfaces

[David Cuenca]

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_interface

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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Google Summer of Code '13] Project Idea - Inspire Me Button

[David Cuenca]

Hi Cheng,

As you say there are many recommendation systems, some of them already work
or used to work with wikipedia (like StumbleThru) or just to find
interesting articles (like reddit.com/r/wikipedia ).
In my opinion those systems are better developed externally because if not
done right, they can get easily annoying... for instance, if you use
previous contribution or watchlist data, I might have edited or be watching
articles about themes I am not longer interested in. And if done right,
then you need to put many more hours than a Gsoc would allow you.
Anyway, maybe a mentor is interested, if not take a look to the proposed
projects with mentor. There are some cool ideas there too :)

Micru


On Mon, Apr 22, 2013 at 12:54 PM, Cheng Xing cxing...@gmail.com wrote:

 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 cxing...@gmail.com
 Date: Apr 18, 2013 5:40 PM
 Subject: [Google Summer of Code '13] Project Idea - Inspire Me Button
 To: wikitech-l@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
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Special:ActiveUsers, where did it go?

[David Cuenca]

Hi there,

I'm trying to find the Special:ActiveUsers page that used to show activity
statistics.

Where did it go? Has it been replaced by something better?

Thanks,
Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Looking for a GsoC mentor (Wikisource, Djvu)

[David Cuenca]

Hi!

I'm looking for a co-mentor for this project:
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Merge_proofread_text_back_into_Djvu_files

There is already someone that would be giving guidance on Tesseract OCR,
now I'm looking for a second mentor to advise on Mediawiki issues.
A student has shown interest in this project already.

Anyone up to mentoring? :-)

David --User.Micru
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l