Hi All,
Is there any documentation or Gadget I can have a quick look at yo be able
to learn how to enable translation in gadgets?
Thanks in advance.
—
Eugene233
Hello all,
This message is important to everyone running an instance of Wikibase
including the Query Service GUI.
We just released a new version of the Wikidata Query Service GUI. This
release is primarily to fix several security issues described in T238822
<https://phabricator.wikimedia.org/T238822> and T238824
<https://phabricator.wikimedia.org/T238824> (these tasks will be made
public soon). These are different from the previous fix we deployed on
November 7th. The fix has been successfully deployed for the Wikidata Query
Service.
In order to keep your instance safe, please make sure to update your Query
Service GUI!
Git repositories, releases and currently active version docker images also
include the latest fixed code (see links below). If you have a local test
setup using the docker-compose example then see:
https://gist.github.com/addshore/36f8d6fe2331d28ca8f70df5abda20fd
Gerrit repositories:
-
https://gerrit.wikimedia.org/r/#/c/wikidata/query/gui/+/553311/
-
https://gerrit.wikimedia.org/r/#/c/wikidata/query/gui-deploy/+/553313/
Docker images:
-
latest: digest:
sha256:6570acb916b429f10ccb3bf3479b66aa6697b3fb3982166a09aba87eeaba7c90
-
legacy: digest:
sha256:4503257bbe1744ce389f07f6dcbaf53db7569cc3e570e30dd5a85c8d0073a39d
If you have any questions or issues updating your code, please let us know
(you can write me an email, or ask in the Wikibase Telegram group
<https://t.me/joinchat/HGjGexZ9NE7BwpXzMsoDLA>)
Thanks for your understanding,
Cheers,
--
Léa Lacroix
Project Manager Community Communication for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
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/029/42207.
Hey,
Since it's still Tuesday in some parts of the Pacific ocean, I want to
start the thread of Thank you Tuesday for this week [1] by thanking James
Forrester for working on improving production mediawiki configs that
reached an important milestone yesterday [2] This work is extremely
important not just because of migration to containers but also because it
makes our systems less prone to breakage. Thank you James.
[1] We haven't done thank you Tuesdays for a long time now, we should do it
more often.
[2]
https://lists.wikimedia.org/pipermail/wikitech-l/2019-November/092816.html
Best
--
Amir Sarabadani (he/him)
Software engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
Unsere Vision ist eine Welt, in der alle Menschen am Wissen der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
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 all,
Further to my email from Nov 19 [1], here is the next update about
Parsoid/PHP deployment on the Wikimedia cluster.
As of today,
* Parsoid/PHP is serving Visual Editor (VE), Content Translation (CX),
and Mobile Content Service (MCS, used by the Android app) on group 0 and
group 1 wikis [2].
* Parsoid/PHP is serving Flow on group 0 wikis [2]. It will be deployed
to group 1 wikis on Monday, Dec 2.
* During the week of Dec 2, we plan to enable Parsoid/PHP on all group 2
wikis for VE, CX, MCS, and Flow.
* Linter output on all wikis is currently served by Parsoid/JS and will
be the last product to be switched over to Parsoid/PHP.
If you notice any problems, please flag it on T238928 [3] or file a phab
task and tag Parsoid-PHP.
You can follow the deployment schedule on T229015 [4].
Subbu (on behalf of the Parsing team).
[1]
https://lists.wikimedia.org/pipermail/wikitech-l/2019-November/092777.html
[2] https://wikitech.wikimedia.org/wiki/Deployments/One_week (info about
what wikis are in groups 0, 1, 2)
[3] https://phabricator.wikimedia.org/T238928
[4] https://phabricator.wikimedia.org/T229015
Hey all,
[Unless you're writing Wikimedia production MediaWiki-land configuration
changes, you can ignore this note.]
As part of my work on moving variant configuration in static files[0], I've
just merged and deployed a change to how dblists work. They are now
auto-generated at merge time[1] (except for the very few lists which are
live-computed in production, which remain). The lists are calculated from
the per-wiki YAML files in wmf-config/config (and if you try to change the
dblist files manually, CI will error at you).
Changes to dblist memberships are quite rare, and this will enforce that we
don't make mistakes. (As part of this deployment, I removed three duplicate
entries and noted several irregularities we probably didn't intend.)
This means that if you're writing a change that previously would have meant
manually editing the dblist files, you now have to touch the YAML file
instead (and run composer build locally, or use CI to tell you what to
change).
This mostly affects the creation of new wikis (which should now be slightly
simpler), plus a few major features currently enabled through dblists. For
an example, if you were to remove FlaggedRevisions from Chechen Wikipedia,
you'd now need to edit cewiki.yaml[2] to remove the " - flaggedrevs" line,
as well as changes to InitialiseSettings.php.
This work unblocks some of the future re-architecting of config, which I've
mentioned before, as part of the long-term plan to move Wikimedia
production into containers. Configuration traits related to FR will inherit
from flaggedrevs.yaml, and static-like code in CommonSettings.php (and in
this case, flaggedrevs.php) can be significantly shrunk.
If anything has broken or has become, if you have any questions, or want to
talk about things, I'd be happy to discuss, here, on IRC, or on Phabricator.
Thanks!
[0] - https://phabricator.wikimedia.org/T223602
[1] - https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/545411
[2] -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/…
Yours,
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello,
We have requested a 30 minutes read-only window for s7 (T238046) for the
26th November from 06:00-06:30 AM UTC to switchover that section primary
database master (T238044)
db1062 is an old host and out of warranty that will be decommissioned
(T217396). The new master will be db1086
We are going to do this on Tuesday 26th Nov from 06:00 to 06:30 AM UTC (we
do not expect to use the 30 minutes window, if everything goes as expected).
Impact: Writes will be blocked on the following wikis:
arwiki
cawiki
eswiki
fawiki
frwiktionary
hewiki
huwiki
kowiki
metawiki
rowiki
ukwiki
viwiki
Reads will remain unaffected.
This also includes centralauth database, which means some operations might
fail during the read-only period, such as: GlobalRenames,
Changing/Confirming emails, logging into new wikis, password changes...
Communication will happen at #wikimedia-operations
If you are around at that time and want to help with the monitoring, please
join us!
Thanks
Hi all,
A high volume of error messages in production logs can make
it hard to glance at error logs after a deployment and
reason about the deployment's impact.[0] This recurring mail
is part of an ongoing effort to reduce log noise.
At present I'm aware of three unresolved-but-tracked issues
which are causing a fair amount of noise:
* https://phabricator.wikimedia.org/T143756
** UnresolvedRedirectException in EntityAccessor::getEntity
(scribunto)
** ~8000 occurrences today
* https://phabricator.wikimedia.org/T226751
** PHP error "non well formed numeric value encountered" from
FormatMetadata->formatCoords
** ~600 occurrences today
* https://phabricator.wikimedia.org/T239165
** PHP Warning: count(): Parameter must be an array or an
object that implements Countable in WikibaseMediaInfo
** ~120 occurrences today
As ever, help in eliminating these errors from production
logs is greatly appreciated.
As a procedural note, I'm sending this early in the week due
to the Thanksgiving holiday. We'll be releasing 1.35.0-wmf.8 to
group 0 tomorrow (Tuesday) and then pausing there until
2019-12-04.
[0].
https://wikitech.wikimedia.org/wiki/Deployments/Holding_the_train#Logspam
--
Brennen Bearnes (he/him)
Release Engineering
Wikimedia Foundation
Every year or so the Cloud Services team tries to identify and clean up
unused projects and VMs. We do this via an opt-in process: anyone can
mark a project as 'in use,' and that project will be preserved for
another year.
I've created a wiki page the lists all existing projects, here:
https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2019_Purge
If you are a VPS user, please visit that page and mark any projects that
you use as {{Used}}. Note that it's not necessary for you to be a
project admin to mark something -- if you know that you're currently
using a resource and want to keep using it, go ahead and mark it
accordingly. If you /are/ a project admin, please take a moment to mark
which VMs are or aren't used in your projects.
When December arrives, I will shut down and begin the process of
reclaiming resources from unused projects.
If you think you use a VPS project but aren't sure which, I encourage
you to poke around on https://tools.wmflabs.org/openstack-browser/ to
see what looks familiar. Worst case, just email
cloud(a)lists.wikimedia.org with a description of your use case and we'll
sort it out there.
Exclusive toolforge users are free to ignore this task.
Thank you!
-Andrew and WMCS team