*(Cross-posting from Wikimedia-l, Wikitech-l, langdivhub-com)*
Hello everyone!
We're excited to announce that the next *Language Community Meeting* is
happening soon, *May 30th at 15:00 UTC*! If you’d like to join, simply *sign
up on the wiki page*
<https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/…>
.
This is a participant-driven meeting where we share updates on
language-related projects, discuss technical challenges in language wikis,
and collaborate on solutions. In our upcoming meeting, we plan to cover
results from a recent language onboarding experiment and hear experiences
from a Nigerian contributor who contributes to the Obolo wiki, which was
part of this experiment.
*Got a topic to share?* Whether it’s a technical update from your project,
a challenge you need help with, or a request for interpretation support,
we’d love to hear from you! Feel free to reply to this message or add
agenda items to *the document here*
<https://etherpad.wikimedia.org/p/language-community-meeting-may-2025>.
Also, we wanted to highlight that the 7th edition of the *Language &
Internationalization newsletter (April 2025)* is available here: *Wikimedia
Language and Product Localization/Newsletter/2025/April*
<https://www.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Language_and_Pr…>.
This newsletter provides updates from the January–March 2025 quarter on new
feature development, improvements in various language-related technical
projects and support efforts, details about community meetings, and ideas
for contributing to projects. To stay updated, you can subscribe to the
newsletter on its wiki page: *Wikimedia Language and Product
Localization/Newsletter*
<https://www.mediawiki.org/wiki/Special:MyLanguage/Newsletter:Language_and_I…>
.
Would you be interested in contributing to the technical workaround
language development? There is a newcomer-friendly core namespace-related
task waiting for your contribution: *T391725*
<https://phabricator.wikimedia.org/T391725>.
We look forward to your ideas and participation at the Language Community
Meeting, see you there!
Cheers,
Srishti
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
I'm going to upgrade ToolsDB from MariaDB 10.6.20 to 10.6.21
next Monday, April 28th around 13:00 UTC.
This will cause a brief downtime of ToolsDB (estimated: 10 minutes).
This work is tracked in Phabricator at https://phabricator.wikimedia.org/T392596
--
Francesco Negri (he/him) -- IRC: dhinus
Site Reliability Engineer, Cloud Services team
Wikimedia Foundation
_______________________________________________
Cloud-announce mailing list -- cloud-announce(a)lists.wikimedia.org
List information: https://lists.wikimedia.org/postorius/lists/cloud-announce.lists.wikimedia.…
Hi there,
the Cloud VPS network now supports IPv6.
We are making the final adjustments but it should be ready for general usage.
How to try yourself today:
* go to horizon.wikimedia.org
* open the panel to launch a new instance
* make sure VXLAN/IPv6-dualstack network is selected for the new instance
* the new VM will have 2 addresses, IPv4 and IPv6
See additional information, including frequently asked questions here:
https://wikitech.wikimedia.org/wiki/News/2025_Cloud_VPS_VXLAN_IPv6_migration
Please reach out for help in case you need it.
regards.
Hello, in the next coming months, these changes will happen in databases
and the infrastructure. And it might affect you if you rely on them in your
tools or queries. This list is ordered based on how soon the change will
happen.
We understand that updating your tools and systems can be time consuming,
hence we are giving an advanced notice. I truly apologize for the
inconvenience but many of these changes are needed to keep the site running
smoothly.
Image table redesign
Around fourteen years after the creation of T28741
<https://phabricator.wikimedia.org/T28741>, we are implementing the changes
described therein. Currently, every current version of an image has a row
in the image table and if there are older versions of that file, those rows
could be found in the oldimage table. These two tables (image and oldimage)
will be dropped in around two months. The replacement will be two main
tables: file and filerevision. Every file will have a row in the file table
describing the name and the type. Every version of the file (current and
old) will have a row in filerevision describing the file-specific
information such as its size or the hash of the file, similar to the
existing distinction between pages and revisions. Another improvement is
that every file and file revision will get a unique auto increment id
simplifying many operations and queries. You can check T28741
<https://phabricator.wikimedia.org/T28741> for more information. The new
tables are already accessible in wikireplicas but the data hasn’t been
fully migrated yet.
Term store split out of wikidata’s database
Wikidata’s database has been growing too fast and we need to move the term
store (tables starting with wbt_) to a dedicated cluster to allow growth
and improve wikidata’s performance by utilizing cache locality. The new
section will be called x3 and you will be able to access it in wikireplicas
but this also means you won’t be able to join these tables with the rest of
wikidata’s database (such as page table) since they will be residing in two
physically separate servers that also means most of your queries to
wikidata’s database (and term store) will become faster. We are aiming for
the switch to happen in three months’ time. You can follow the work in
T351820 <https://phabricator.wikimedia.org/T351820>.
Additionally, wb_type table will be dropped and the mapping will be
hard-coded in the code instead. See gerrit:1110810
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1110810>
for more details. This helped us simplify a lot of Wikibase code (example
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1110720>).
Categorylinks normalization
Categorylinks is the next table in the series of links tables being
normalized via the linktarget table (parent ticket
<https://phabricator.wikimedia.org/T300222>, RFC
<https://phabricator.wikimedia.org/T222224>). Similar to templatelinks and
pagelinks tables, cl_to will be dropped and instead the new field
cl_target_id will point to lt_id in the linktarget table. We will also drop
the cl_collation field and replace it with cl_collation_id which will point
to the collation_id field on the new table we are introducing called
collation. We are aiming to get this fully done by the end of the next
quarter (end of June 2025) but it depends on how fast the migration script
can operate and that’s outside of our control. You can follow the work in
T299951 <https://phabricator.wikimedia.org/T299951>.It’s worth noting that
after this migration is done, we will start working on the imagelinks table.
Thank you
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Which version of golang does the toolforge build service currently support?
Could it be upgraded to a recent version, such as go 1.23 or 1.24?
Somewhat related: Has it been considered to support building containers
from a regular Dockerfile/Containerfile? From my personal perspective, I'm
not sure if Heroku buildpacks give much value for all their complexity; if
I could, I'd rather run "podman build" from a gitlab runner. But that's
just my personal opinion as a user;. Surely this has been discussed before?
$ toolforge build start https://github.com/brawer/osmviews.git
[step-build] 2025-04-23T12:53:03.061032884Z [Reading build configuration]
[step-build] 2025-04-23T12:53:03.068120654Z Detected Go version
requirement: =1.23
[step-build] 2025-04-23T12:53:03.068814689Z
[step-build] 2025-04-23T12:53:03.068856285Z [Error: Heroku Go Buildpack
version resolution error]
[step-build] 2025-04-23T12:53:03.068870316Z Couldn't resolve go version
for: =1.23
[step-build] 2025-04-23T12:53:03.070393300Z ERROR: failed to build: exit
status 1
Many thanks,
— Sascha
Hi,
I am experiencing very slow https file transfer from the instance
mediawiki2latex in the project collection-alt-renderer to my local
computer in Germany. Transfers from upload.wikimedia.org to my local
computer still work quite fast. I already rebooted the instance but it
didn't help. Has anyone got an idea what is going wrong?
Yours Dirk
Hi,
I'm experiencing issues when trying to SSH into the CloudVPS in order to
access our project, to which I do have confirmed access.
I've carefully followed the instructions on
Help:Accessing_Cloud_VPS_instances
<https://wikitech.wikimedia.org/wiki/Help:Accessing_Cloud_VPS_instances>,
and I've verified that the correct SSH keys are associated with my account.
Despite this, I consistently receive the following error message when
attempting to connect with command:
*ssh producer.wikispeech.eqiad1.wikimedia.cloud*
Error:
*Connection closed by 185.15.56.87 port 22Connection closed by UNKNOWN port
65535*
Could you maybe help me troubleshoot what might be going wrong?
*Viktoria Hillerud*
*Developer*
Wikimedia Sverige (WMSE)