Hello Wikitext-l,
-----------------------------------
TL;DR: The Wikidata team is considering to use a MVVM/Single-State solution
for Wikidata’s UI. What are requirements and concerns would be important to
consider?
-----------------------------------
Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
out, we are looking at possible future frameworks or paradigms to build our
UI on. Our needs are:
- Having a sustainable foundation
- Being able to handle complex state dependencies (simplest are like: "if
element x is in edit mode, set element y to saving mode")
- A solution that is easy to learn for beginners and easy to read and
reason about for our engineers.
State management and data/event propagation goes beyond of what OOUI can
provide, as far as I (Jan) know. So an obvious candidate was looking into
MVVM solutions of which the most well known is the React library.
We had a deeper look at Vue.js which is known for having a large community,
too, but being easier to understand and not using an additional patent
clause in its licensing.
We see the following possible advantages:
- Better modularization
- understandability of our code, in particular reasoning about event- and
data-flow
- better separation of concerns and testability for:
-- HTML templates
-- Component interactivity
-- Data manipulation
-- connection to backend-API
- If we use a well documented framework, learning to contribute is much
easier compared to software for which there is only auto-generated
code-level-docs
Here are some answers to obvious questions:
1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
too) normal HTML templates are used
2) Does that mean that people coming from Object oriented languages will
need to learn a whole new paradigm – reactive, pure-functional programming?
-> While there are some elements of functional programming used in
react-like-frameworks, I would (subjectively) say that few additional,
totally new knowledge is needed and most can be covered by "take
parameters, work with them, return values; don't manipulate non-local
values"
3) How does DOM access work? Does this mean no jQuery?
-> DOM can be still be directly accessed. Libraries like jQuery can still
be reused (even if they might not be necessary in many points any more).
However, to change data or dom persistently, you need to tell the library
(which is not unusual, afaic)
There are also some other concerns:
- Should we introduce a new dependency like a framework as Vue?
- What would be the process of introducing such a dependency (if we agree
on one)?
- Can we agree on this (or another?) paradigm for managing complex UIs, so
that it is not a Wikidata-only solution, but could be used by other
Wikimedia projects in the future, too?
- How will this work with OOUIjs? OOUI seems to be mainly responsible for
creating DOM elements and this actions are usually owned by the MVVM
framework. One can use hooks to use libraries like OOUI and such, but it
feels like having the same functionality twice. A possible solution would
be using OOUI styles and markup but leaving DOM creation to the framework.
Do you think using Vue (or a similar framework) is an option for us? What
are requirements and concerns which would be important?
Kind Regards,
Jan
--
Jan Dittrich
UX Design/ User Research
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hi,
The Architecture Committee plans to make a decision in two weeks on the RFC
about the schema change for image and oldimage tables. [1] [2]
Please review the updated RFC page [2] and send any final comments here on
Wikitech-l or Phabricator [1] by 2017-02-01. If no new and significant
concerns are raised within this time the committee will most likely approve
the RFC on Wednesday, February 1st.
-- Timo
[1] https://phabricator.wikimedia.org/T589
[2] https://www.mediawiki.org/wiki/Requests_for_comment/
image_and_oldimage_tables
Hello!
Registration and scholarship applications for the WIkimedia Hackathon 2017
are open!
The hackathon will be taking place in Vienna, Austria between 19 - 21 May,
2017.
Scholarship applications are open until February 26, 2017.
- Register here:
https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2017/Register_and_Attend
- Event details here:
https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2017
- If you have any questions, please email: hackathonwikimedia.at
Please forward this announcement along to any relevant mailing lists!
We hope to see you in Vienna!
Hello,
Almost two weeks ago, the Technical Collaboration team invited proposals
for the first edition of the Developer Wishlist survey!
We collected around 77 proposals that were marked as suitable for the
developer wishlist and met the defined scope and criteria
<https://www.mediawiki.org/wiki/Developer_Wishlist#Scope>. These proposals
fall into the following nine categories: Frontend, Backend, Code
Contribution (Process, Guidelines), Extensions, Technical Debt, Developer
Environment, Documentation, Tools (Phabricator, Gerrit) and Community
Engagement.
Voting phase starts now and will run until *February 14th, 23:59 UTC*. Click
here on a category and show support for the proposals you care for most
<https://www.mediawiki.org/wiki/Developer_Wishlist>. Use the 'Vote' and
'Endorse' buttons next to a proposal to do so.
*What happens next?*Proposals that will gather most votes will be included
in the final results which will be published on *Wednesday, February 15th*.
These proposals will also be considered in the Wikimedia Foundation’s
annual plan FY 2017-18.
Cheers,
Srishti
--
Srishti Sethi
Developer Advocate
Technical Collaboration team
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:SSethi_(WMF)
I'm working on to run the Citation Hunt to enable it for Japanese
Wikipedia, on my home Mac mini (not on the Tools Lab). Sorry if
this is not the right channel to communicate with. In that case I
would appreciate if you guide me to more appropriate one.
After reading
https://github.com/eggpi/citationhunt/blob/master/CONTRIBUTING.md ,
I have succeeded to run it at least for enwp locally, with provided
en.sql.gz
from https://tools.wmflabs.org/citationhunt/static/exports/en.sql.gz
That's a good kickstart, I assume.
---
Currently I'm stuck in preparing jawp's database to run.
After importing categorylinks.sql and page.sql, downloaded from
https://dumps.wikimedia.org/jawiki/latest/jawiki-latest-category.sql.gzhttps://dumps.wikimedia.org/jawiki/latest/jawiki-latest-page.sql.gz
on to local MySQL database "jawiki_p", with the instructions shown at:
https://github.com/eggpi/citationhunt/blob/master/scripts/README.md .
(I have done it like;
$ mysql -u root
mysql> create database jawiki_p;
mysql> use jawiki_p;
mysql> source jawiki-latest-category.sql;
mysql> source jawiki-latest-page.sql; )
When you run scripts/print_unsourced_pageids_from_wikipedia.py
after setting CH_LANG, it dumped an error shown below:
(ch-venv) Mac-mini:scripts takot$ export CH_LANG=en
(ch-venv) Mac-mini:scripts takot$ echo $CH_LANG
ja
(ch-venv) Mac-mini:scripts takot$
./print_unsourced_pageids_from_wikipedia.py > unsourced
Traceback (most recent call last):
File "./print_unsourced_pageids_from_wikipedia.py", line 40, in <module>
print_unsourced_ids_from_wikipedia()
File "./print_unsourced_pageids_from_wikipedia.py", line 21, in
print_unsourced_ids_from_wikipedia
' OR '.join(['cl_to = %s'] * len(categories)) + ')', categories)
File
"/Users/takot/ch-venv/lib/python2.7/site-packages/MySQLdb/cursors.py", line
205, in execute
self.errorhandler(self, exc, value)
File
"/Users/takot/ch-venv/lib/python2.7/site-packages/MySQLdb/connections.py",
line 36, in defaulterrorhandler
raise errorclass, errorvalue
_mysql_exceptions.ProgrammingError: (1146, "Table 'jawiki_p.categorylinks'
doesn't exist")
---
Apparently the database on MySQL seems not prepared well.
My current config.py can be seen at:
https://github.com/takot/citationhunt/blob/master/config.py
Current database tables in jawiki_p on my local MySQL database is like this:
$ mysql -u root
mysql> show databases;
+-----------------------+
| Database |
+-----------------------+
| information_schema |
| jawiki_p |
| mysql |
| performance_schema |
| root__citationhunt_en |
| root__citationhunt_ja |
| root__stats_global |
| sys |
+-----------------------+
8 rows in set (0.02 sec)
mysql> use jawiki_p;
mysql> show tables;
+--------------------+
| Tables_in_jawiki_p |
+--------------------+
| category |
| page |
+--------------------+
2 rows in set (0.01 sec)
---
Hopes you provide some tip or hack to proceed.
Thanks in advance,
--Takashi [[User:Takot]]
Hello volunteer developers & technical contributors!
The Wikimedia Foundation is asking for your feedback in a survey. We want
to know how well we are supporting your contributions on and off wiki, and
how we can change or improve things in the future.[1] The opinions you
share will
directly affect the current and future work of the Wikimedia Foundation.
*** The survey will close on February 15, 2017. ***
To say thank you for your time, we are giving away 10 Wikimedia T-shirts to
randomly selected people who take the survey.[2] The survey is available in
various languages and will take between 20 and 40 minutes.
Use this link to take the survey now:
https://wikimedia.qualtrics.com/SE/?SID=SV_6mTVlPf6O06r3mt&Aud=DEV&Src=DEV
You can find more information about this project here[3]. This survey is
hosted by a third-party service and governed by this privacy statement[4].
Please visit our frequently asked questions page to find more information
about this survey[5]. If you need additional help or have questions about
this survey, send an email to surveys(a)wikimedia.org.
Thank you!
Edward Galvez
Community Engagement
Wikimedia Foundation
[1] This survey is primarily meant to get feedback on the Wikimedia
Foundation's current work, not long-term strategy.
[2]Legal information we have to share: No purchase necessary. Must be the
age of majority to participate. Sponsored by the Wikimedia Foundation
located at 149 New Montgomery, San Francisco, CA, USA, 94105. Ends February
16, 2017. Void where prohibited. Follow this link for the contest rules:
https://meta.wikimedia.org/wiki/Community_Engagement_Insights/2017_second_c…
[3] About this survey:
https://meta.wikimedia.org/wiki/Community_Engagement_Insight
s/About_CE_Insights
[4] Privacy statement: https://wikimediafoundation.or
g/wiki/Community_Engagement_Insights_2016_Survey_Privacy_Statement
[5] FAQ:
https://meta.wikimedia.org/wiki/Community_Engagement_Insight
s/Frequently_asked_questions
--
Edward Galvez
Evaluation Strategist (Survey Specialist), and
Affiliations Committee Liaison
Learning & Evaluation
Community Engagement
Wikimedia Foundation
Hi all!
Here are the minutes from this week's ArchCom meeting. You can also find the
minutes at <https://www.mediawiki.org/wiki/Architecture_committee/2017-02-01>.
See also the ArchCom status page at
<https://www.mediawiki.org/wiki/Architecture_committee/Status> and the RFC board
<https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>.
Here are the minutes, for your convenience:
* New MW core team is taking shape. Relationship to ArchCom to be worked out.
* IRC office hour on Feb 1st didn’t happen. The office hour about DB schema
changes may happen on Feb 8th, pending confirmation from Brion.
RFC Activity:
* [[phab:T589]]: "image and oldimage table refactoring": '''Approved after last
call'''.
* [[phab:T66214]]: "Define an official thumb API": Converging on a solution.
Proceeding to concrete planning & last call period soon. Please review and
comment now.
* [[phab:T122942]]: "Support language variants in the REST API": Marko and Corey
driving the discussion forward. Both hope to find a solution that is consistent
across APIs, but this requires coordination.
* [[phab:T155813]]: "Decide on storage and delivery method for TemplateStyles
CSS": The Reading team is working towards device-specific styling for templates.
They are looking for feedback on whether to store these styles on a separate
page, and how to deliver these styles to the user. After brief discussion,
ArchCom tentatively favors inline delivery; similarity to template-data would be
good for consistency.
* Daniel is working on [[phab:T152425]]: "make use of varnish xkey" and
[[phab:T154674]]: "HookRunner"; these are soon to become RFCs.
--
Daniel Kinzler
Principal Platform Engineer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.