Dear all,
I thank you for your efforts. I am working on a research project to ameliorate linked data quality of Wikidata. I am looking for a develop who can create Gadget tools like Merge that can be implemented on Wikidata to adjust common deficiencies. I have several ideas on how to develop the Gadget tools. But, I lack the skills needed to do that. I ask if someone can join our research project and create the tools for our work. I will attend Wikimania from 16 to 18 August 2019 and I will be honoured to meet him during the conference.
Yours Sincerely,
Houcemeddine Turki (he/him)
Medical Student, Faculty of Medicine of Sfax, University of Sfax, Tunisia
Undergraduate Researcher, UR12SP36
GLAM and Education Coordinator, Wikimedia TN User Group
Member, WikiResearch Tunisia
Member, Wiki Project Med
Member, WikiIndaba Steering Committee
Member, Wikimedia and Library User Group Steering Committee
Co-Founder, WikiLingua Maghreb
Founder, TunSci
____________________
+21629499418
Dear all,
I thank you for your efforts. I am working on a research project to ameliorate linked data quality of Wikidata. I am looking for a develop who can create Gadget tools like Merge that can be implemented on Wikidata to adjust common deficiencies. I have several ideas on how to develop the Gadget tools. But, I lack the skills needed to do that. I ask if someone can join our research project and create the tools for our work. I will attend Wikimania from 16 to 18 August 2019 and I will be honoured to meet him during the conference.
Yours Sincerely,
Houcemeddine Turki (he/him)
Medical Student, Faculty of Medicine of Sfax, University of Sfax, Tunisia
Undergraduate Researcher, UR12SP36
GLAM and Education Coordinator, Wikimedia TN User Group
Member, WikiResearch Tunisia
Member, Wiki Project Med
Member, WikiIndaba Steering Committee
Member, Wikimedia and Library User Group Steering Committee
Co-Founder, WikiLingua Maghreb
Founder, TunSci
____________________
+21629499418
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2019.07. This bundle is The bundle is compatible with MediaWiki
1.32 or above and requires PHP 7.0.0 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-2019.07.tar…
* sha256sum: 84cb6de241f62c7e5e9853d74390c4ffbf55cf35aab930c36f9ec5733a351130
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2019.07.tar…
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, CleanChanges and LocalisationUpdate ==
* Maintenance and localization updates only.
== cldr ==
* Update to cldr 35.1 ([https://phabricator.wikimedia.org/T220906 T220906]).
* Maintenance and localization updates.
== Translate ==
* Translate now requires MediaWiki >= 1.32.0. Please upgrade!
=== Noteworthy changes ===
* Reduced the size of the cache used by the Translate extension
([https://phabricator.wikimedia.org/T213802 T213802]).
* Fixed incorrect link to the message on the translate editor
([https://phabricator.wikimedia.org/T222588 T222588]).
* Fixed the tabs on the message table on Special:Translate with the
new Timeless theme.
* Added a new MessageValidator framework to improve translation
validation. ([https://phabricator.wikimedia.org/T204568 T204568])
([[Help:Extension:Translate/Validators|See documentation]]).
* Fixed invalid more warnings label shown during message translation
([https://phabricator.wikimedia.org/T220789 T220789])
* Moved Translate special pages to a specific Translation section in
Special:SpecialPages ([https://phabricator.wikimedia.org/T227393
T227393])
* Fixed issue with base page not getting removed when removing translatable page
* Removed unused global variable <code>$wgTranslateCC</code>
([https://phabricator.wikimedia.org/T214356 T214356])
== UniversalLanguageSelector ==
* UniversalLanguageSelector now requires MediaWiki >= 1.32.0. Please upgrade!
==== Input Methods ====
* Added Afrikaans, N'Ko and Vai syllabary keyboards.
* Added new input methods for languages of Africa without the need for
replacement or key combinations: Akan (ak, tw), Bambara (bm), Dagbani
(dag), Dinka (din), Fula (ff), Ga (gaa) and Wolof (wo).
* Fixed the combining character in Yoruba Alt method.
* Minor fixes in existing layouts with replacements and key
combinations for Akan, Dagbani, Dinka, Fula, and Ga.
Hi All,
Reminder there is a TechCom RFC on the RFC "Merge Extension: Theme
into core": <https://phabricator.wikimedia.org/T122924> in
#wikimedia-office on July 24th at 21:00 UTC/23:00 CEST/14:00 PDT
The RFC is a proposal to merge the Extension:Theme into core because
of the limitations it has being an extension.
Thanks,
-Kate
--
Kate Chapman
Senior Program Manager, Core Platform
Wikimedia Foundation
kchapman(a)wikimedia.org
Hello,
I use parsoid to publish email messages into wiki and have a little
issue.
Sometimes generated article has "preformatted" fragments that do not
have any special formatting in source text.
After investigation I discovered that it is caused by spaces that start
new line in HTML text.
When source HTML of email is viewed in browser these spaces do not have
any effect, but after converting to wikitext they became part of markup.
Next, trying to discover they way parsoid works I have seen that
normally these spaces became surronded with <nowiki> tag, but in some
circumtances it does not happen.
So I made test HTML file to see different results of converting:
<html>
<head>
</head>
<body>
<p>test2<span>
test3
</span></p>
<p><span>test2
test3
</span></p>
<p>textx<span>test2
test3
</span></p>
</body>
</html>
The result of conversion is:
test2<span>
test3
</span>
<span>test2
<nowiki> </nowiki>test3
</span>
textx<span>test2
<nowiki> </nowiki>test3
</span>
It seems that if new line is just at end of <span> tag, <nowiki> is not
inserted.
How do you get patches merged when you don't actually know anyone to
review it?
Sometimes you just get lucky, but sometimes you add a bunch of people, a
few others even wander in and +1 it, you ask a few people with core +2
to take a look, and then you're still waiting on a product owner to
maybe even comment at all and you can't get anyone to actually merge it
months later.
The patch I'm referring to right now is this:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Interwiki/+/501820
It adds another global inheritance feature, this time for interlanguage
links, where they can just be set once on a single wiki and other wikis
in the farm can likewise just use those instead of local ones. Separate
setting from the global interwikis because ones that would share this
will be a smaller subset than would share general interwikis.
Normally we'd just merge each other's patches in-team or go get an
actual product owner to review it, but there are a couple of problems
with this:
* The patch was co-authored by Jack Phoenix and me (and I defined the
design in the first place), so neither of us can meaningfully review
it any further than we already have. No one else has +2 here.
* We don't know any product owners (in fact we're not even sure if
there are any product owners), so we can't get them to review it.
Given the total lack of comment, normally we might just declare this
as 'nobody cares' after awhile and charge ahead regardless, but:
* Nobody else we know with general +2 is willing to merge it without
weigh-in from the product owners/actually has any time to review it
in the first place, either.
Basically, uh, can anyone else help us with this? Any of this? Given the
nature of the patch we really do kind of need it merged so it can get
translations.
-I
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
I (with Reedy's help) recently started work on librarizing MediaWiki's
IP class into a separate composer package (wikimedia/ip-utils[1]). The
main motivation was so that the Parsoid PHP port could use it[2].
However, I ran into an unexpected hitch[3], as it seems we're using
the IP class before the composer autoloader is even intialized. Here's
the basic initialization in Setup.php:
- - AutoLoader.php (MediaWiki's)
- - Defines.php
- - DefaultSettings.php
- $wgServer = WebRequest::detectServer()
- Calls IP::splitHostAndPort()
- - GlobalFunctions.php
- - vendor/autoload.php (composer's)
My understanding is that composer's autoloader runs late so extensions
registering themselves using it can add their stuff to the necessary
globals.
And we call WebRequest::detectServer() in DefaultSettings.php so that
in LocalSettings.php people can use the value of $wgServer for other
stuff.
I see 3 main ways to move forward:
1. Move vendor/autoload.php earlier in Setup.php, potentially breaking
extensions that still rely on composer autoloading for initialization.
2. Set $wgServer = false or something in DefaultSettings.php, and then
fill it in later in Setup.php *after* the composer autoloader has been
loaded, potentially breaking anyone relying on the value of $wgServer
in LocalSettings.php.
3. (status quo) not librarize code that runs before composer
autoloader initialization. :(
Advice/input welcome.
[1] https://packagist.org/packages/wikimedia/ip-utils
[2]
https://gerrit.wikimedia.org/g/mediawiki/services/parsoid/+/77064cfff717
6493a2828bb4f95f397dfce7d659/src/Utils/Title.php#46
[3] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/519089/
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl0S1oQACgkQ8QX4EBsF
Jpufrg/+J9RUUxRAtgJLEkyACE6GREis0eyEIZnWmMr3s9YpFPoqtWocFrUk6Wsn
W7d9Oda/8CW0/d894gGMn8LWIj9oWq2gMPWzCVFpg8uu3r4967qxBp+ba29uMOJw
Qpw6DhXtPvVAeUCy8P38Y5vM7TGmV+J1T5jDY21zimT1dRrJsI1KD+u/Ue3nYy/y
B1ic3i7vJfhYErdhHgN98ETXfXOaDx4rgd2N7PLjVNx3IYCC8LNiR8wSLuydfdbk
PLTT1bA2qi0h2wgcEr7Qtq9YstVotq8899rgKLtGDBwQi3qGNcdOgQGEMFDVfjfO
CsiWocj6s4oc3ScVj+Eb9xtvIqhNx+oRbWE1vKd4TmtSdyzpv6xadV60tq5qNFEY
I0cBDOWU5UFNHbvbyjK4dqIDEVhJ6LiEgLVBOj81U27s8mR4Dv/yFB3eac0ROk7p
gaEeOjfhtVU558XfpEsmu1H05VJT3kXNxK8y0UQOjy11SErzsXv6vDzyzLDJM/W7
WF0I4nyjeqVsBjLBN9li+5AnU3cAKVOCfZ+/aRYyg89Du//nJRjm+4lxnuPrGlaG
ES/nVUnkDZ9Yc/xA1yacm3Ytx9hpoY1mIZgxxxveyeU1KsNXAZ2BOGA2T7kU4yUw
Uyg+byYwI+1uVOjAVd3BInGV2R2/GmeIn9FOpthBaw8wcz0Y/8c=
=tU4+
-----END PGP SIGNATURE-----