> On Apr 8, 2024, at 10:42 PM, James Forrester wrote:
>
> This is now done. This is the first step in the release process for
> MediaWiki 1.42.0, which should be out in May 2024, approximately six
> months after MediaWiki 1.42.0.
six months after MediaWiki 1.41.0
__
Hello all,
We have [written previously][0] about upcoming changes to how media is
structured in the HTML output of MediaWiki's wikitext parser. You can read
more about it in [the FAQ][1].
Over the past many months, we have been [gradually rolling out these
changes][2], first to test wikis, th
Hello all,
We'd like to inform you of a change coming in how media is structured in the
parser's HTML output. It has been [in the works for quite some time][1]. The
new structure was prototyped in Parsoid's output since its inception and
outlined in [its specification][2].
The proposed chang
> On Jul 22, 2019, at 5:11 AM, Sergey F wrote:
>
> test2
> test3
>
>
> The result of conversion is:
>
> test2
> test3
>
Yes, this looks like a bug
See https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/524811
Thanks
___
Wikitech-l
> On Aug 8, 2018, at 1:43 PM, Saint Johann wrote:
>
> Code of conduct is important to be enforced, but, in my opinion, there should
> be a difference in how it’s enforced. To volunteers that help the movement,
> there should be no unacceptable language, as it is a way (and a purpose of
> som
> On Aug 8, 2018, at 9:42 AM, Saint Johann wrote:
>
> especially when said to Wikimedia employees as opposed to volunteers.)
Can you elaborate on that?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/l
> On Jul 13, 2017, at 10:35 AM, Subramanya Sastry wrote:
>
> (2) There is a Parsoid bug in detection of self-closing tags where presence
> of a "/>" in an HTML attribute triggers a false positive. This has been
> reported previously ... so I suppose it is not as uncommon as I thought.
> We'll
> On Jul 11, 2017, at 6:13 AM, Nicolas Vervelle wrote:
>
> - Where is it possible to change the description displayed in each page
> dedicated to a category ?
https://phabricator.wikimedia.org/source/mediawiki-extensions-Linter/browse/master/i18n/fr.json;6fc72c808136676da0302d98601bd4662a6b
> On Feb 15, 2017, at 8:01 PM, Pine W wrote:
>
> I'm happy to see "Starting to work on audio/video support in Parsoid (VE
> will follow)". Any ETA on this? Links to Phab tickets would be appreciated
> as well.
Please see, https://phabricator.wikimedia.org/T64270#2981630
__
https://www.mediawiki.org/wiki/Specs/wikitext/1.0.0
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> Can you think of anything specific in your setup that
>> might be preventing that?
> In that case I think there could be something. I cannot start the parsoid
> server with "service parsoid start",
What happens when you try to do that?
> so I must do it manuelly with nodejs and maybe thats
> On Jul 29, 2016, at 12:24 PM, Julian Loferer wrote:
>
> Yeah here is my localsettings.js file:
>
> https://phabricator.wikimedia.org/P3603
Thanks!
> And i have installed it as an ubuntu package so with apt-get install parsoid .
I'm assuming you have v0.5.1 then. Correct me if I'm wrong.
> On Jul 29, 2016, at 10:07 AM, Julian Loferer wrote:
>
> Yeah it looks similar. The link direct me to the right page.
Can you paste your localsettings.js file somewhere for us to
take a look?
https://phabricator.wikimedia.org/paste/edit/form/14/
Also, in case I missed it, how did you install
> On Jul 28, 2016, at 9:03 AM, Julian Loferer wrote:
>
> I looked into my localsettings.js and didnt found a line called setInterwiki
> I only found setMwApi? Is it the same or should i add setInterwiki for my own?
setMwApi is the newer name for that function
and should be fine.
Can you first
> And there is a consensus for English being bad choice for RTL languages as
> it cause mixed directional content which should be avoided. So if we go
> with 1 choice, RTL languages should be exception.
See https://gerrit.wikimedia.org/r/#/c/280792/
_
> Parsoid and VisualEditor are working great with this setup for everything
> except images. When I first add an image (VE --> Insert --> Media) it works
> as expected. The image displays and is configurable. When I save the page
> everything functions properly. However, when I click edit again th
מִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> “We're living in pieces,
> I want to live in peace.” – T. Moore
>
> 2015-06-20 19:45 GMT+03:00 Arlo Breault (mailto:abrea...@wikimedia.org)>:
>
> > On Friday, June 19, 2015 at 1:38 AM, Amir E. Ahar
On Friday, June 19, 2015 at 1:38 AM, Amir E. Aharoni wrote:
> There may be more - I'm still looking for these.
If you find any, please propose them on the Parsoid’s normalization talk page
[0].
I’ve added the ones you’ve mentioned so far.
We’ve documented [1] what’s currently been implemented.
I share Risker’s concerns here and limiting the anonymity
set to the intersection of Tor users and established wiki
contributors seems problematic. Also, the bootstrapping
issue needs working out and relegating Tor users to second
class citizens that need to edit through a proxy seems less
than ide
On Tuesday, February 3, 2015 at 10:24 AM, Brion Vibber wrote:
> Special page inclusions shouldn't be able to do anything privileged;
> they're meant for public data. If that's not being enforced right now I'd
> recommend reworking or killing the special page inclusion system...
Ok, although Brion'
> On Thu, Jan 29, 2015 at 5:38 PM, Brad Jorsch (Anomie) <
> > > bjor...@wikimedia.org (mailto:bjor...@wikimedia.org)
> > > > wrote:
> > >
> > >
> > >
> > > > On Thu, Jan 29, 2015 at 2:47 PM, Arlo Breault
Currently, while {{urlencod}}ing, content in strip markers is skipped.
I believe this violates the expectation that the entire output
will be properly escaped to be placed in a sensitive context.
An example is in the infobox book caption on,
https://en.wikipedia.org/wiki/%22F%22_Is_for_Fugitive
On Sunday, October 12, 2014 at 4:45 PM, Marc A. Pelletier wrote:
> On 10/12/2014 12:50 PM, Arlo Breault wrote:
> > The people on this list can best answer that.
>
>
> What the people on this list cannot answer is /whether/ and under what
> conditions it would desirable t
> Unless there is further discussion to be had on a new *technical* solution
> to Tor users, this is the wrong mailing list to be making these proposals.
> At the very least take it to the main wikimedia list, or on-wiki, where
> this is a lot more relevant.
Thanks Tyler. I kept the discussion goi
Thanks for initiating the conversation Derric. I've tried to put together a
proposal addressing the general problem of allowing edits from a proxy.
Feedback is appreciated.
Proposal:
* Require an account to edit via proxy.
* Allow creating accounts from proxies but globally rate limit account cr
11:39 AM, "Terry Chay" wrote:
>
> > Hello everyone,
> >
> > It’s with great pleasure that I’m announcing that Arlo Breault joined the
> > Wikimedia Foundation as a Features Engineer. Note the past tense. :-D
> >
> > Before joining us, Arlo worked as
I can help a bit with review. I maintain the check[0] service for the Tor
project.
[0] https://check.torproject.org/
On Wed, Jul 23, 2014 at 10:16 PM, Legoktm
wrote:
> On 7/23/14, 4:56 AM, Quim Gil wrote:
> > According to our algorithm (*), TorBlock currently has the worse track
> > reviewing
Is this happening for all pages on the wiki,
or just for this “TestPage”?
On Monday, August 11, 2014 at 4:48 PM, Bjoern Kahl wrote:
>
> Dear Scott
> dear All,
>
> Am 11.08.14 um 11:54 schrieb C. Scott Ananian:
> > > What could cause this behavior and how should I configure my system to
> >
On Monday, August 11, 2014 at 5:18 AM, svetlana wrote:
> On Mon, 11 Aug 2014, at 21:42, Chris Keating wrote:
> > >
> > > I think the most helpful thing would be to not attempt to start wars, and
> > > particularly not on behalf of anyone or against individuals. We are all on
> > > the same side h
Maybe you're looking for,
document.querySelectorAll("[lang]")
On Sun, Mar 16, 2014 at 1:35 PM, Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> wrote:
> Hello,
>
> Is there an easy known way to find all HTML elements with an attribute that
> appear in the text of a given wiki after it's parsed?
30 matches
Mail list logo