Hey,
I just wanted to check in about the status of enabling JavaScript package
management usage in MediaWiki. I am basically talking about an equivalent
for JS to what we have with Composer for PHP.
Real-world example:
The "data-values/value-view" package[0] is defining
"jquery.event.special.ea
Great work!
I have noticed that the "ooui" HTMLForm format is also not supporting a
form field's "hide-if" expressions yet.
Cheers,
Daniel
On 22 July 2015 at 16:06, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:
> Yay :D
>
> Sent from my HTC
>
> - Reply message -
> From: "B
Thank you folks!
I guess I wasn't logged in when I first tried. It works fine now [0].
Anyhow, I am with Gergo and Jeroen on the issue of code hosting and I chose
to use GitHub. I also have lots of extensions on WM's facilities and won't
change that in the near future but I am switching to GitHub
Hi,
I'd like to add my extension
https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses
as "mediawiki/user-bitcoin-addresses" in packagist.
When trying to do so, packagist states I should ask someone with the proper
rights to maintain the "mediawiki" vendor.
I have read up on
https://w
-mediawiki.org/wiki/SMWCon_Fall_2013/Revolutionizing_page_naming_with_semantic_properties
The slides of the talk are already available on that page, a video
recording should follow soon.
Cheers,
Daniel Werner
2013/10/24 Élie Roux :
> Dear MediaWiki developers,
>
> I'm responsible for t
ling list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Wikimedia Deutschland - Gesellscha
2013/2/4 Brad Jorsch :
> You'd add your library object in Lua as a child of the "mw" object.
Sounds like same little mistake we are already "dealing" with in
JavaScript, see:
http://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/JavaScript#Place_for_Extensions_Objects_in_JavaScript_20654
P
There is a first implementation of this in the Wikibase extension now:
https://gerrit.wikimedia.org/r/#/c/28680/
This implements the html snippet functionality in PHP. The JS side will be next.
2012/10/18 Daniel Werner :
> Right now we are about to implement some kind of basic template Eng
ide as well.
Doesn't seem like mw.Message would be a problem.
Any thoughts on this or does anyone know about some similar
implementation in any extensions?
Cheers,
Daniel
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26
> elsewhere) to output checkboxes as fallback and an interface like "jQuery
> Chosen"
> as enhancement.
>
> -- Krinkle
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org
or a
multi-select from a JS perspective.
Anyhow, I would still appreciate if someone would merge the thing, it's
sitting around for too long already and it seems that it got stuck because
of some very minor issue once again:
https://gerrit.wikimedia.org/r/#/c/8924/
Thanks!
--
Daniel Werner
Software
imedia.org/r/#/c/20534/ which is
blocked by this problem, here I wanted to introduce the "!!config" sections
into "!!article".
" !!config" is also something new I have introduced to parser tests in case
you haven't seen it yet.
Cheers,
Daniel
2012/9/1 Platonides
a.wikimedia.org/show_bug.cgi?id=39473
I would very much appreciate if anyone could explain to me why there are
both of these files and why we maintain (more or less) a whole bunch of
redundant code for those tests.
Cheers,
Daniel
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | NE
> In that case, perhaps we should just say that all of the options are fine:
> $( '' )
> $( '' )
> $( '' )
> but emphasize not to use attributes in the tag creation.
>
+1
All three will return the same, and this is not HTML, it's JavaScript. It
really is just a matter of personal flavor in coding
experience with such
frameworks as well as dealing with the question whether it would make
sense to introduce something of this art into core in the near future
or not.
Any thoughts on this would be highly appreciated!
Cheers,
Daniel W.
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V
into wiki pages.
>>
>> > Unless you just mean that new versions of MediaWiki should keep working
>> > with
>> > old require_once based extensions until they migrate to the extension
>> > installer setup.
>> >
>>
>>
>> This.
>>
>&g
tech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
By all means, GO for it at least in extensions. Namespaces are awesome
there since they can spare you a lot of prefixing extension classes.
Have not made my mind up about core though, there might be valid
reasons why
Sounds nice, but on the long run, why not including a PHP class for
extensions into core. This would already make quite some code you need
for new extensions obsolete. I'd like to see a base class for all
extensions which offer simple information such as the extensions name,
version, file path, et
g
>>> parameter the moment you click a link.
>>> Much better than a string regex :)
>>
>> But only working if JavaScript is available.
>
> Sure, that's the limitation :)
>
> You would still cover almost everyone but jidanni ;)
>
>
>
iable in the ResourceLoaderGetConfigVars hook, but
actually, I only want to have it included when the 'wikibase' module is
loaded since it is rather big and shouldn't be loaded when not necessary.
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | NEU: Obentrautstr. 7
rs
> > Kim
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> http://palnatoke.org * @palnatoke * +4522934588
>
> Message: 8
> Date: Wed, 23 May 2012 21:49:57 +0200
> From: Platonides
> To: wikitech-l@lists.wikimedia.org
> Subject: Re: [Wikitech-l] HTMLMultiSelectField as multiple="multiple"/>
> Message-ID:
> Content-Type: text/plain; charset=ISO-8859-1
>
>
ne could "break" extensions (even though both are fully compatible and
interchangeable). So one option would be simply naming the new one
HTMLMultiSelectField2 if we don't want to stick with an additional option
here.
Cheers
Daniel
--
Daniel Werner
Software Engineer
Wikimedia Deutschlan
I am thinking about creating a very simple parser function #parse doing
nothing but returning parameter 1 with an "'noparse' => false" option.
Is there anything like this (or what could be abused for this) already
or is there any reason why this might be a bad idea?
The reason I want to have so
Hi,
Actually, I sent a mail to the maps mailing list already but there was
no feedback at all so I am taking Jeroens advice and try it again here,
there might be some users using maps and waiting for the image maps
feature. I already included some of the features suggested in my last
mail to "
25 matches
Mail list logo