Hey Steffen and Andy,
Continuing what I started on Twitter here, as some more characters might be
It seems that both our projects (FLOW3 and Wikidata) are in a similar
situation. We are using Gerrit as CR tool, and TravisCI to run our tests.
And we both want to have Travis run tests for all patchsets submitted to
Gerrit, and then +1 or -1 on verified based on the build passing or
failing. To what extend have you gotten such a thing to work on your
project? Is there code available anywhere? If both projects can use the
same code for this, I'd be happy to contribute to what you already have.
Jeroen De Dauw
Don't panic. Don't be evil. ~=[,,_,,]:3
In trying to remove deprecated method usage, I've found that quite a few
tests in Wikibase.git are really complicated. Mostly this seems to be
caused by trying to stuff tests for structurally very different behaviours
in the same test method and data provider. There is no need to do this at
all. The need for a control structure in a test method is very rare, and
should be carefully considered. There is a lot of good material on the
topic, though if you cannot find the time to look into that, just keep that
simple guideline in mind: no control structures. Please keep the tests (and
production code) simple!
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Evil software architect at Wikimedia Germany
The language policy has it that any eligible language may be enabled for
Wikidata. Several of the languages in the Incubator are functional in
Wikidata already others are not.
This list shows all the requested languages and it shows an indicator when
the language can be used on Wikidata (only for eligible languages).
Please have a look and let me know when you have any comments. The idea is
that we will ask in a week for languages that are eligible to be enabled.
Discussion about Wikibase DataModel, especially the Fingerprint class (Jeroen,
* add convenience methods for setting labels, etc
* add copy() for deep cloning
* getters returning mutable objects should say whether they return a copy
* be careful to not overuse list objects
* We still need AliasGroup, but AliasGroupList can probably be replaced by a
I hope I got this all right.
Senior Software Developer
Gesellschaft zur Förderung Freien Wissens e.V.
There is a path issue with the ResourceLoader that has arisen with the use
of Composer. Additionally, the question relates to the preferred
installation method for Wikibase and Wikibase Query. This needs to be
defined for volunteers and external people who want to use the software
outside of Wikidata. If we assume that the generally preferred method
for installation is to modify the MW_INSTALL_PATH/composer.json and add the
wikibase/wikibase and wikibase/query, after running composer, the directory
structure appears like this:
Wikibase and Query are installed in extensions and the components (except
for ValueView) are now installed to the vendor directory. This
consequently creates a problem with a bit of code that is duplicated
typically in the resources.php file of several JS components.
$remoteExtPathParts = explode(
DIRECTORY_SEPARATOR . 'extensions' . DIRECTORY_SEPARATOR, __DIR__, 2
$moduleTemplate = array(
'localBasePath' => __DIR__,
'remoteExtPath' => $remoteExtPathParts,
As you can see, this is looking for the component to reside in an path that
contains "extensions". There are several questions to be answered.
1) Does this composer created directory structure work for everything
(including testing and production deployment)? (i.e. keeping things in
2) if so, should ValueView be moved to vendor?
3) How can the problem paths be fixed? Is this kind of flexible path magic
still necessary for the components resource loader? Or can it be
simplified by just statically defining the parent dir of the resource into
the $resources array? (the way that core currently does it).
4) What is the best way to load all JS resources for Wikibase?
I am looking for a great PHP developer to join the software
development department at Wikimedia Germany. We have a lot of backend
tasks to do around Wikidata especially for the support of Wikimedia
Commons. More details about the position are available at
https://wikimedia.de/wiki/PHP_Backend_Developer_(f/m) If this is you
please do apply. If you know someone who fits please send them them
the link. This is a great chance to make a difference around
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
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.