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
Are Foundation servers able to withstand Online Certificate Status
Protocol certificate revocations, such as might occur according to RFC
5280 when a government agency declares a private key compromised
because of secret evidence?
Hi,
Due to a current vandalism/spam threat, I've enabled administrator approval
of all new accounts. Hopefully this won't have to stay enabled long.
Will update when it's turned back off.
-Chad
Most of the time we assume that writing code like:
wfMessage( 'foo' )->params( $this->getRequest()->getVal( 'bar' ) )->parse();
is totally safe. However, in a wiki with $wgRawHTML = true; this code
would be an XSS. I've looked through core, and couldn't find any
examples of using unsanitized url parameters as a message parameter in
a parsed message, however it seems to me like this sort of thing is an
accident waiting to happen.
I would like to propose that $wgRawHTML only apply to actual pages.
The <html> parser tag should not be active in wfMessage() or other
parser contexts. I don't think this would break anything, but I'd like
feedback on if anyone could think of anything this could break.
For more information see https://phabricator.wikimedia.org/T156184 .
Please post any feedback about this idea on that bug.
Remember, the deadline for proposing developer wishes is TODAY, January 31
at 23:59 UTC
<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170131T235959&p…>
.
The Developer Wishlist voting phase is planned to start next Monday,
February 6.
https://www.mediawiki.org/wiki/Developer_Wishlist#Timeline
On Sat, Jan 21, 2017 at 12:00 AM, Srishti Sethi <ssethi(a)wikimedia.org>
wrote:
> That's right! At the Wikimedia Developer Summit, we decided to organize a
> Developer Wishlist Survey, and here we go:
>
> https://www.mediawiki.org/wiki/Developer_Wishlist
>
> The Wikimedia technical community seeks input from developers for
> developers, to create a high-profile list of desired improvements. The
> scope of the survey includes the MediaWiki platform (core software, APIs,
> developer environment, enablers for extensions, gadgets, templates, bots,
> dumps), the Wikimedia server infrastructure, the contribution process, and
> documentation.
>
> The best part: we want to have the results published by Wednesday,
> February 15. Yes, in a month, to have a higher chance to influence the
> Wikimedia Foundation annual plan FY 2017-18.
>
> There's no time to lose. *Propose your ideas before the end of January, *
> either by pushing existing tasks in Phabricator or by creating new ones.
> You can find instructions on the wiki page
> <https://www.mediawiki.org/wiki/Developer_Wishlist>. Questions and
> feedback are welcome especially on the related Talk page.
>
> The voting phase is expected to start on February 6 (tentative). Watch
> this space (or even better, the wiki page).
>
> Cheers,
> Srishti Sethi
> Developer Advocate, Technical Collaboration team
> Wikimedia Foundation
>
> https://www.mediawiki.org/wiki/User:SSethi_(WMF)
>
>
> _______________________________________________
> Wikitech-ambassadors mailing list
> Wikitech-ambassadors(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
>
>
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2017.01. This bundle is The bundle is compatible with MediaWiki
1.26 and 1.27 or above and requires PHP 5.5.9 or above.
Next MLEB is expected to be released in 3 months. If there are major
changes or important bug fixes, we will do intermediate release.
Please give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2017.01.tar…
* sha256sum: 89f4a029f33ea9f9225c8379367bc526fa63353845a2873290ba82560fb314c9
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Highlights and upgrade notes ==
== Babel ==
* Kunal Mehta fixed compatibility with MediaWiki 1.27 version.
* This, that and the other fixed categorization of 'pt-br' and similar
language codes.
* This, that and the other fixed Babel AutoCreate's edit summaries to
use content language instead of user's UI language.
== CLDR ==
* Reedy updated CLDR to 30.0.2
== CleanChanges ==
* Maintenance and localisation updates only.
== LocalisationUpdate ==
* Niklas Laxström added warning for deprecated PHP entry point. Use
<code>wfLoadExtensions( array( 'LocalisationUpdate' ) );</code> to
load extension in LocalSettings.php now.
== Translate ==
* Niklas Laxström made insertables more touch friendly.
* Niklas Laxström made several improvements for MessageTable.
* Niklas Laxström moved SpecialPage(Preparation|Migration) to tag, as
they are related to page translation.
* Niklas Laxström made several improvements in Special:TranslationStats.
* Niklas Laxström implemented plural aware message content comparison.
* Federico Leva added option to keep outdated page translation without
removing them. T60429
== UniversalLanguageSelector ==
* Fomafix added patch to remove jquery.i18n library which is available
in MediaWiki core since 1.26 version.
* Niklas Laxström added warning for deprecated PHP entry point. Use
<code>wfLoadExtensions( array( 'UniversalLanguageSelector' ) );</code>
to load extension in LocalSettings.php now.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Hi all,
Scap version 3.5.1-1 has been released and with it comes a few changes.
tl;dr highlights:
== MediaWiki Deploys ==
* Subcommands are the only way to scap (e.g., scap sync-file vs. sync-file) Old
stub entry points for scap (e.g., sync-file, sync-dir, mwversionsinuse, etc)
are gone. Formerly old binstubs simply exited with a non-zero exit code.
* MediaWiki canary deploys now check for both hhvm and mediawiki errors
* scap sync-file and scap sync-dir are now the same command internally. scap
sync-dir is now deprecated
== Scap3/Service Deploys ==
* Scap's rollback behavior has been greatly improved. Scap supports a global
`failure_limit` and a per-group `failure_limit` -- if a deployment exceeds the
number or percentage of failures specified by this limit a deploy will fail and
you will be prompted to rollback. Also, if you opt to *not* continue a
deployment on remaining deploy groups, you will receive the option to rollback.
(Fixes T149008)
* Scap3: This scap release has some rollback logic fixes. First, if there is
initial ssh failure for a host, scap will no longer attempt a rollback on that
host (since the same ssh failure will likely cause a rollback failure). Next,
all previously deployed groups of servers will now be rolled-back -- not just
the group of servers that had failures. (Fixes T150267, T145460)
You can see the full changelog in the repo[0].
<3 -- The Scap Folks
[0]. <https://phabricator.wikimedia.org/source/scap/browse/release/debian/changel…>
Resistance Manual <https://www.resistancemanual.org/Resistance_Manual_Home>
is a guide for organizing resistance to the policies of the Trump
administration in the United States. The site is running MediaWiki 1.28,
and its admins are looking for help maintaining the site. The main page
says to reach out to info(a)staywoke.org if interested.
Hi all,
my change for https://phabricator.wikimedia.org/T155892 was blocked by
hashar because he do not know impact that deploying will cause to our
infrastructure. May somebody have a look at it?
Thanks in advance,
Martin Urbanec
Urbanecm at phab