Hi Parsoid & VisualEditor crew,
Google Code-In (GCI) will soon take place again - a contest for 13-17
year old students to contribute to free software projects.
Wikimedia wants to take part again.
Last year's GCI results were surprisingly good - see
https://www.mediawiki.org/wiki/Google_Code-in_2013
We need your help:
1) Go to
https://www.mediawiki.org/wiki/Google_Code-in_2014#Mentors.27_corner and
read the information there. If something is unclear, ask!
2) Add yourself to the table of mentors on
https://www.mediawiki.org/wiki/Google_Code-in_2014#Contacting_Wikimedia_men…
- the more mentors are listed the better our chances are that Google
accepts us.
3) Please take ten minutes and go through open recent tickets in
https://bugzilla.wikimedia.org in your area of interest. If you see
self-contained, non-controversial issues with a clear approach which you
can recommend to new developers and would mentor: Add the task to
https://www.mediawiki.org/wiki/Google_Code-in_2014#Proposed_tasks
Until Sunday November 12th, we need at least five tasks from each of
these categories (plus some less technical beginner tasks as well):
* Code: Tasks related to writing or refactoring code
* Documentation/Training: Tasks related to creating/editing documents
and helping others learn more - no translation tasks
* Outreach/research: Tasks related to community management,
outreach/marketing, or studying problems and recommending solutions
* Quality Assurance: Tasks related to testing and ensuring code is of
high quality
* User Interface: Tasks related to user experience research or user
interface design and interaction
Google wants every organization to have 100+ tasks available on December
1st. Last year, we had 273 tasks in the end.
Note that you could also create rather generic tasks, for example fixing
two interface messages from the list of dependencies of
https://bugzilla.wikimedia.org/show_bug.cgi?id=38638
Helpful Bugzilla links:
* Reports that were proposed for GCI last year and are still open:
https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=ALL%20whiteboard%3Ag…
* Open Parsoid tickets created in the last six months (if I got your
products and components right):
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
* 8 existing Parsoid "easy" tickets (are they still valid? Are they
really self-contained, non-controversial issues with a clear approach?
Could some of them be GCI tasks that you would mentor? If so, please tag
them as described above!):
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
* Open VisualEditor tickets created in the last six months (if I got
your products and components right):
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
* Zero existing VisualEditor "easy" tickets (are they still valid? Are
they really self-contained, non-controversial issues with a clear
approach? Could some of them be GCI tasks that you would mentor? If so,
please tag them as described above!):
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
Could you imagine mentoring some of these tasks?
Thank you for your help in reaching out to new contributors and making
GCI a success again! Please ask if you have questions.
Cheers,
andre
PS: And in a future Phabricator world, Bugzilla tickets with the 'easy'
keyword will become Phabricator tasks with the 'easy' project.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Lists in wikitext are a pain. Proof: number of duplicates of
<https://bugzilla.wikimedia.org/1581>.
Aryeh Gregor proposed in 2007 an amendment that would IMHO solve many
problems and find no opposers in principle, "Have multiline tags not
terminate the list item until the tag is terminated":
<https://bugzilla.wikimedia.org/show_bug.cgi?id=9996#c5>
Does someone disagree? How hard is it to implement? (Probably rather or
very hard, but who knows.)
For more general context of how I was brought to this problem, and to
discuss alternative solutions for my specific issue, please refer to
<https://meta.wikimedia.org/wiki/Help_talk:List#List-agnostic_markup_inserti…>
instead.
Nemo
Hi
I maintain the server running the wiki at
https://wiki.transitionnetwork.org/ and 3 month ago it was upgraded to
MediaWiki 1.22.x and the VisualEditor was installed from source and that
was quite straight forward, details here:
- https://trac.transitionnetwork.org/trac/ticket/706
Yesterday I upgraded to MediaWiki 1.23.0 and switched to using the
Debian repo for parsoid as per:
- https://www.mediawiki.org/wiki/Parsoid/Setup#Ubuntu_.2F_Debian
And since then I have been unable to get the VisualEditor working, when
you click on 'Edit' nothing happens, looking at the HTTP requests there
is a GET to load.php and a 304 in response but nothing actually happens
in the web browser, I have tried with Firefox 30 and the Debian Wheezy
Chromium.
There is nothing of note in the webserver logs or the parsoid.log.
It appears to be working correctly on the command line:
curl http://localhost:8142/localhost/Sandbox -d wt="Hello ''world''" -d body=1
<body data-parsoid='{"dsr":[0,15,0,0]}'><p data-parsoid='{"dsr":[0,15,0,0]}'>Hello <i data-parsoid='{"dsr":[6,15,2,2]}'>world</i></p></body>
I'm not sure what to try next.
More details including the Nginx config can be found on the comments I
have posted to this ticket:
- https://trac.transitionnetwork.org/trac/ticket/736
Any pointers would be greatly appreciated, I fear I have made a simple
mistake somewhere...
All the best
Chris
--
Webarchitects Co-operative
http://webarchitects.coop/
+44 114 276 9709
@webarchcoop
Hi,
I am working on the mass migration tools project
<https://www.mediawiki.org/wiki/Extension:Translate/Mass_migration_tools>
as a part of Google Summer of Code. One of the parts of project is to
import old translations into the Translate Extension.
We are done with a basic import by splitting the old pages on double
newlines (\n\n) and some more alignment based on h2 headers. We are now
thinking of improving the alignment.
Is there some work done on the subject mentioned? For each of the unit,
what I would like to do is clear all the linguistic elements and have the
bare markup left. Then, I could compare the markup of the source and target
units and align accordingly.
Are there any API's available which already do this? Please guide me to
accomplish this task.
--
Warm Regards,
*Pratik Lahoti*
GSoC Intern | Wikimedia
User:BPositive <http://www.mediawiki.org/wiki/User:BPositive>
Hi,
I put an internal wiki under HTTPS to prevent clear password
transmissions and modified the ad hoc parsoidConfig.setInterwiki entry
to https.
Parsoid seems to refuse the self-signed certificate presented by the
wiki :
_ERROR in wikie7ar:Accueil with oldid: 10928_
_Stack trace: DoesNotExistError: Page Fetch failure for null : Error:
DEPTH_ZERO_SELF_SIGNED_CERT_
_worker 8536 died (1), restarting._
How can I tell Parsoid to accept such certificates ?
Cheers,
--
Fraifrai
http://www.fraifrai.net [1]
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org [2]
Links:
------
[1] http://www.fraifrai.net
[2] http://www.april.org/
Dear all,
I impemented node.js / parsoid and nginx and are able to access the mediawiki via https 443.
But when I use the button edit which appeared after I implemented visual editor I got the following error message:
Error loading data from server: parsoidserver-http-curl-error: Peer certificate cannot be authenticated with known CA certificates. Would you like to retry?
This is an "self-made" certificate and not signed by an official company. Can you help me to allow this communication.
Kind regards
Andreas Brill
________________________________
Utimaco Safeware AG
Seat: Aachen - Registergericht Aachen HRB 17938
WEEE-Reg.No.: DE39805015
Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO
Supervisory Board: Katrin Wehr-Seiter (Chairman)
________________________________
Utimaco Safeware AG
Seat: Aachen - Registergericht Aachen HRB 17938
WEEE-Reg.No.: DE39805015
Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO
Supervisory Board: Katrin Wehr-Seiter (Chairman)
Hi,
I'd like to ask you for your input on a change to the DOM spec [1] we
are considering. The idea is to simplify links by removing the explicit
mw:WikiLink or mw:ExtLink typeof attributes:
<a rel="mw:WikiLink" href="./Main_Page">Main Page</a>
<a rel="mw:ExtLink" href="http://example.com">http://example.com</a>
would become just
<a href="Main_Page">Main Page</a>
<a href="http://example.com">http://example.com</a>
Reasons for this change are:
- The external vs. internal link distinction is pretty simple to do
with a prefix match on the href.
- When editing, an internal link can turn into an external one and
vice-versa. Editors should not have to deal with updating the typeof
to reflect the information already available in the href attribute.
- The page source will be slightly cleaner and smaller.
Potential disadvantages we see are
- For ISBN links [2], we will continue to link to Special:BookSources,
which looks internal. Matching on that to identify ISBN links should
however not be harder than it is right now.
Are you currently relying on these typeofs? Do you see other issues with
this proposed change?
Thanks for your input,
Gabriel
[1]: https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Wiki_links
Hi,
I do not understand how I could install Parsoid on the web server so I could use the new visual editor. I would really appreciate help with this.
Regards,Thomas Gulli
Hi
I noticeced that Parsoid API cannot support language variant (e.g.
simplified Chinese in mainland China (zh-cn) v.s. traditional Chinese in
Taiwan (zh-tw) ) - they both hosted under zhwiki.
Do you have any plan to support them? and what's the rough timeline?
Thanks
--
Jiang BIAN
This email may be confidential or privileged. If you received this
communication by mistake, please don't forward it to anyone else, please
erase all copies and attachments, and please let me know that it went to
the wrong person. Thanks.