It's hipster lorem ipsum.
http://hipsteripsum.me/
- Trevor
On Thu, Mar 1, 2012 at 1:43 PM, David Gerard dger...@gmail.com wrote:
On 1 March 2012 21:38, Trevor Parscal tpars...@wikimedia.org wrote:
Screenshot of new diff styles:
https://bugzilla.wikimedia.org/attachment.cgi?id=10148
I
Me too.
- Trevor
On Thu, Feb 23, 2012 at 12:56 PM, Antoine Musso hashar+...@free.fr wrote:
Le 21/02/12 16:08, Domas Mituzas wrote:
If MediaWiki is better on newer PHP, we should use newer PHP.
I have read that:
If MediaWiki is better on JS, we should use JS.
Go figure.
I would be willing to mentor this project pending some further review so
that we could scope it correctly.
- Trevor
On Sun, Feb 19, 2012 at 10:38 AM, Ashish Dubey ashish.dube...@gmail.comwrote:
Hi Platonides
You're right on the fact that its ambitious. And this is the reason I've
started
I would also suggest you take a trick from the VE book, and rather than
wait for key events, use an interval timer to inspect the value of the
input box and if it's changed do a lookup. This is because in some
browsers, like Firefox and Opera, there are no key events during IME.
- Trevor
On Tue,
What if you need more attention and want to be harassed?
Amir: Also, SVN does kinda suck :P
Seriously though, this looks great.
I've been fortunate enough to not have been harassed at a conference much
more than being trolled on occasion, but I think that's a more borderline
case that doesn't
I spoke to some people at the Internet Archive about the ReCaptcha
situation, and learned something interesting.
Apparently, although IA provided a large dataset to ReCaptcha, they never
got any data back, and then after the Google acquisition, they got shut out
completely.
I highly recommend we
We have a lawyer that can help determine that. It's not obvious to me (or
you apparently) so I guess we should get one involved.
- Trevor
On Wed, Jan 11, 2012 at 11:07 AM, David Gerard dger...@gmail.com wrote:
On 11 January 2012 19:03, Trevor Parscal tpars...@wikimedia.org wrote:
Apparently
I was working with Victor a bit to see how close to JS we could get
WikiScripts syntax to be, and it seemed like it was possible but some
things (like objects) would either be a hack to fake in some ways or a
larger job to get working. Not sure if he's got more progress in that way
to show, but
It's important to note that technically if one were to bypass wikitext
completely, you could store serialized wikidom instead and use the visual
editor immediately. This is obviously useless for the purposes of
Wikipedia, which is why we need the parser that Gabriel is mentioning, and
the visual
I'd like to suggest something Neil has suggested before...
http://semver.org/
- Trevor
On Thu, Dec 8, 2011 at 7:31 AM, Diederik van Liere dvanli...@gmail.comwrote:
I think that the current version numbering system is confusing, incremental
version increases from 1.15 to 1.16 to 1.17 to 1.18,
The hype of 2.0 aside, is there a guideline for what should constitute a
major version number change?
It looks like we are doing something like: Major.Minor.Release
1.18 = Major: 1, Minor: 18, (alpha|beta|etc.)
I'm just curious what people think would constitue a major version. We've
certainly
Call chaining works really well for something like jQuery where you are
constantly working with a generic type of data (a selection of dom nodes in
that case) with common methods. Most of what you do in jQuery is either
modifying what is selected, or calling methods on the selection.
There are
In jQuery the benefit is less code do do the same thing, which means less
download time for the same functionality. This obviously doesn't apply to
PHP.
There may be other benefits to chaining in PHP code, but I don't really
know of them.
- Trevor
On Wed, Nov 16, 2011 at 3:01 PM, Russell Nelson
I updated the bug, but it looks like this was the issue:
http://bugs.jquery.com/ticket/9823
So, now we must upgrade or downgrade (carefully!)
- Trevor
On Fri, Oct 7, 2011 at 10:40 AM, Rob Lanphier ro...@wikimedia.org wrote:
Hi everyone,
We need your help. We have a number of reports on
+∞**
This is not going to be easy, but nothing worth doing ever is. I've been
using git for personal projects for a while, and would agree that the issues
that have come about are more to do with learning than regret.
- Trevor
On Thu, Sep 22, 2011 at 4:06 PM, Rob Lanphier ro...@wikimedia.org
I've been aware of this tool for quite a while, and shown it to some other
devs around here. I think it's awesome, but I have not had a need for it
yet. I think the visual editor may present some cases where this makes sense
- but generally it seems the most useful for writing tests that involved
The visual editor looking the same as the view is just one idea, and in some
ways we know the editor will look a little different, so it's probably not
that good of a use case for this kind of testing.
I was more thinking about interactions, such as you click on a link, some
options popup below
My main complaint with Haml and Sass are that they introduce yet another
syntax, all while trying to simplify things. On the other extreme XSLT uses
XML syntax, but can get pretty complex, usually unnecessarily so - it also
introduces XPath, which some developers may not know.
Ideally we should
I wrote a node.js module, which could easily be ported to PHP, which uses
DOM on the server to pre-process HTML, acting on some specific tags and
resulting in clean HTML output. This only works for HTML, so I don't know
about your requirements of being able to do this in inline CSS as well, but
Concurrent editing is something being researched to a small degree. The
issues you raise are well known, and there are others as well, but there may
still be ways forward. This is not something that WMF is devoting lots of
resources to, just experimenting with a bit - especially in light of how
Is popularity really the right metric to use when ordering them? Maybe
inbound link counting, or article feedback ratings could be used as well?
Using page hits to order search results seems like it would cause mire
relevant but less frequently accessed links to not be shown, and thus ensure
they
Agh, I remember this being talked about a while ago, did not know it was
working.
On Aug 27, 2011 3:30 PM, Robert Stojnic rainma...@gmail.com wrote:
It is ranked by number of links pointing to article, complete matches to
article titles are additionally boosted.
r.
On 08/27/2011 09:54 PM,
We also used this to keep track of specific preferences, some interesting
info there..
http://en.wikipedia.org/wiki/Special:PrefStats
- Trevor
On Fri, Jun 17, 2011 at 10:37 AM, Max Semenik maxsem.w...@gmail.com wrote:
On 17.06.2011, 20:20 Chad wrote:
On Fri, Jun 17, 2011 at 10:42 AM, Amir
While Vector is the default skin, the Vector extension should probably be
bundled too.
- Trevor
On Wed, Jun 8, 2011 at 9:00 AM, Jeroen De Dauw jeroended...@gmail.comwrote:
Hey,
Assuming that we are going to put *some* extensions in, we need to decide
which ones.
As some might remember, I
+1
I believe the way forward involves using pre-commit review, requiring test
coverage to pass review, and developers working in branches at all times.
SVN may be a pita when it comes to branches, but that's a solvable problem.
- Trevor
On Wed, Jun 1, 2011 at 10:52 AM, Andrew Garrett
Based on the schedule given, I would deduct that it's no longer our goal to
release as often as we may have once believed was ideal - and sometimes even
achieved.
There's been tons of discussion about what is an ideal release schedule for
us (probably literally if you printed it out at 12pt on
The obvious problem with the 72 hour time limit is that it
imposes unnecessary time limits, adding lots of to the complexity, chaos and
stress - possibly a net-negative, but it's hard to say for sure.
That said, at least it's an actionable idea.
It's pretty clear to me that the inconvenience
Moving WikiEditor into core would involve...
Straightforward changes
- Move the contents of the WikiEditor modules folder to
resources/jquery.wikiEditor/ and resources/wikiEditor (removing the ext.
from files that have it)
- Move the module registrations to resources/Resources.php
The way the WikiEditor works right now, the textbox can be replaced with
anything that can support a few methods, such as getSelection,
encapsulateSelection, etc. There are some modules that depend on specific
edit box implementations, such as the current and only alternative to the
textarea we
Dynamic linking implies we have something to dynamically link in the first
place. A parser library consisting of compiled PHP in this particular case.
Let's just cross this hypothetical bridge when we come to it, shall we?
- Trevor
On Fri, May 6, 2011 at 11:14 AM, Anthony wikim...@inbox.org
I think the idea that we might break the existing PHP parser out into a
library for general use is rather silly.
The parser is not a parser, it's a macro expander with a pile of
regular-expressions used to convert short-hand HTML into actual HTML. The
code that it outputs is highly dependent on
Some of them are already going. After talking with some of them about our
new parser and editor plans, and that we would be doing work on that in
Berlin, they said they were likely to send some people. Obviously it's up to
a variety of factors how many of Wikia's people show up, but we do know
After the question came up a few times, Ryan Kaldari and I decided to
document the official list of supported browsers and the information and
logic that surrounds this topic.
http://www.mediawiki.org/wiki/Supported_browsers
- Trevor
___
Wikitech-l
*For reading*, we aim to support any browser with 0.1%[1] use or more.
This has both culled things out, like IE 5.5, and surfaced things like NetFront
(Sony Playstation Browser).
*For security*, if it's possible to protect the site or our users, and we have
money in the bank, we should be
I will see if I can get some time dedicated to this. If/when I do, I will
probably have some more questions about the extension - are you a good person
to contact about it?
- Trevor
On Apr 8, 2011, at 4:50 AM, Niklas Laxström wrote:
On 6 April 2011 00:44, Trevor Parscal tpars
On Apr 5, 2011, at 7:49 PM, Santhosh Thottingal wrote:
Placing a select box inside a dropdown div does not look good to me(page 5
of the pdf). That adds one extra level of user interaction. Can't we
simlify this by listing available input methods with a radio button in the
dropdown div
When Roan Kattouw reviewed, and then rewrote most of the Narayam extension, I
reviewed his code, and found many things about the user interface that could
be, and need to be improved. I have both some observations and some
suggestions, expressed in the attached PDF.
The exact design I'm
OK, not an attachment...
File:Narayam-proposal.pdf
File:Narayam-proposal-annotated.pdf
- Trevor
On Apr 5, 2011, at 2:44 PM, Trevor Parscal wrote:
When Roan Kattouw reviewed, and then rewrote most of the Narayam extension, I
reviewed his code, and found many things about the user interface
And by that I meant...
http://www.mediawiki.org/wiki/File:Narayam-proposal.pdf
http://www.mediawiki.org/wiki/File:Narayam-proposal-annotated.pdf
(I need to stop clicking send so fast... waiting a minute... OK, this one looks
good.)
- Trevor
On Apr 5, 2011, at 2:55 PM, Trevor Parscal wrote
On Mar 28, 2011, at 1:31 PM, Rob Lanphier wrote:
You say that as though this were obvious and uncontroversial. The reason
why we've been dancing around this issue is because it is not.
Right now, we have a system whereby junior developers get to commit whatever
they want, whenever they
Your objections seem to be based on the assumption that you would need to have
push access to all repositories, but I think that's the point of DCVS, you can
just fork them, and then people can pull your changes in themselves (or using a
tool). Pull requests could even be generated when things
My suggestion is that all of this busy work is highly automatable, but I'm
sure he has a greater ability to assess the complexities of this work than I do.
In general I feel that we should be thinking about how would we make this
work instead of why should we not do this.
- Trevor
On Mar 22,
I can help you as well, there's an API that lets you add things after load.
Examples of this are in the test file.
- Trevor
On Feb 17, 2011, at 3:46 PM, Roan Kattouw wrote:
2011/2/18 Strainu strain...@gmail.com:
Could someone give me any pointers on how to make a new page in the
existing
This is the tests file.
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/WikiEditor/modules/ext.wikiEditor.tests.toolbar.js?view=markup
- Trevor
On Feb 17, 2011, at 3:48 PM, Trevor Parscal wrote:
I can help you as well, there's an API that lets you add things after load.
Examples
On Feb 14, 2011, at 9:42 AM, Mark A. Hershberger wrote:
This is one reason I avoided suggesting that we switch to a DVCS for
1.18: The change is too big and dramatic and would impede too many
people's workflows without offering an immediate improvement.
Mark.
I'm not sure how much worse it
I was working on fixing https://bugzilla.wikimedia.org/show_bug.cgi?id=27332
(resolved in r82155) and started messing with removing most of the gratuitous
lines in the search UI. Here's a screenshot of what we could do instead. I have
a patch for this that works in all browsers, including IE6.
There are 2 components to the JavaScriptDistiller library. One of them (the
ParseMaster class) is 100% in sync with the official distribution. The other
(the JavaScriptDistiller class) was originally based on the
JavaScriptPacker::_basicCompression function. That function had some issues
that
I was planning on emailing him a patch, probably after I wrote some tests to
ensure I wasn't submitting him something with issues.
- Trevor
On Feb 1, 2011, at 1:41 PM, Platonides wrote:
Trevor Parscal wrote:
There are 2 components to the JavaScriptDistiller library. One of them
Adding yet another discreet parsing step is the reverse of what a lot of people
hoping to clean up wikitext are heading towards.
What some of us have been kicking around would be migrating away from
pre-procesing the text at all. Instead the text should be parsed in a single
step into an
For those of you who didn't see bug 26791, our use of JSMin has been
found to conflict with our GPL license. After assessing other options (
https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
decided to try and use the minification from JavaScriptPacker, but not
its overly
Joke or not, it's in there, and it's a violation of the GPL.
- Trevor
On 1/20/11 5:44 PM, Tim Starling wrote:
On 21/01/11 09:13, Trevor Parscal wrote:
For those of you who didn't see bug 26791, our use of JSMin has been
found to conflict with our GPL license.
You're talking about the good
On 12/8/10 3:40 PM, Andrew Garrett wrote:
I think the point is that it makes bug reports that much easier to
understand when they're reported by somebody who isn't in debug mode. This
has to be traded off against the performance advantages of removing blank
lines. Is there any data on how
/10 03:11, Trevor Parscal wrote:
These blank lines should not - under any circumstances - be here. But I
do know why they are...
Tim Starling modified the standard distribution of JSMin[1] in some good
and some bad ways. These blank lines are the result of one of these
modifications which I
On 12/7/10 10:46 PM, Dmitriy Sintsov wrote:
* Ashar Voultoizhashar+...@free.fr [Tue, 07 Dec 2010 19:19:53 +0100]:
On 06/12/10 16:57, Trevor Parscal wrote:
I personally think XSL is awesome, and would defend it with
vigor.
I love XSL too. Probably the easiest way to render an XML data file
These blank lines should not - under any circumstances - be here. But I
do know why they are...
Tim Starling modified the standard distribution of JSMin[1] in some good
and some bad ways. These blank lines are the result of one of these
modifications which I find to be misguided. He's basically
Oh please no!
- Trevor
On 12/7/10 7:26 AM, Platonides wrote:
Daniel Friesen wrote:
PHP - XSL doesn't quite feel like much of an improvement in terms of
cutting down on the verbose redundant code boilerplate required to
insert something.
ie:xsl:value-of select=title/ doesn't look much
On 12/6/10 3:18 AM, Daniel Friesen wrote:
It's not part of distribution, but the new installer's ability to point
out extensions and allow you to install them from the installer was
pointed out. However generally each skin doesn't have it's own set of
configuration (vector does, but generally
in monobook, but that nice new fancy style in vector.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 10-12-03 11:10 AM, Trevor Parscal wrote:
This is a really awesome project, I'm sure we can figure out a way for
Vector and Monobook to be able to use the same arrays
(Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 10-12-06 07:57 AM, Trevor Parscal wrote:
Have you considered using something like say XSL? If a skin was a
combination of a set of CSS/JS/image files plus an XSL file which took
XML data (which would be the page content and various user
This is a really awesome project, I'm sure we can figure out a way for
Vector and Monobook to be able to use the same arrays.
Let me know if you want some help.
- Trevor
On 12/2/10 6:30 PM, Daniel Friesen wrote:
On 10-12-02 04:52 PM, Platonides wrote:
Aryeh Gregor wrote:
On Thu, Dec 2,
Agreed - branching will not prevent bugs from getting fixed, we will be
merging in a limited set of changes (fixes to bug) while ignoring new
and irrelevant development.
- Trevor
On 12/3/10 2:26 PM, Roan Kattouw wrote:
2010/12/3 Platonidesplatoni...@gmail.com:
So if we can cope with
+1
Cheap hallway testing is so incredibly useful that I dedicated my time
in Berlin last year to giving a crash course in it. I am not sure it was
effective in inspiring or educating people on how to do this, but
everyone is welcome to revisit the slides here:
Well you could use mediaWiki.loader.load in a module's script or in a
module's loader script.
Roan and I plan to change the API of mediaWiki.loader.load for external
scripts today/tomorrow, so stay tuned. The change will likely be taking
an object for non-module scripts.
I will send info to
Firs let me say, especially with this 2nd version, good work on this!
I've personally worked on revising this logo about 3 times, trashing my
work after a bit because it's such a difficult logo to get right. I
would like to see a few of the other artists in our community also take
a stab at
Well, we basically just need a template parser. Michael has one that
seems to be working for him, but it would need to be cleaned up and
integrated, as it's currently spread across multiple files and methods.
Do you like writing parsers?
- Trevor
On 11/9/10 10:25 PM, Dmitriy Sintsov wrote:
*
On 11/10/10 8:20 AM, Michael Dale wrote:
The code is not spread across many files..
I spent hours going over the code, and there were several points in the
code that called out to other libraries. This was based on the patch you
provided me.
I agree the parser is not the ideal parser, its not
On 11/10/10 1:56 AM, Roan Kattouw wrote:
I think {{PLURAL}} is an important feature for ResourceLoader, and if
no volunteer wants to implement it, I think a staff developer should.
Certainly staff members (me for instance) are already assigned this
work. I was responding to a query about what
Skin extensions exist. Look at extensions/skins.
- Trevor
On 11/10/10 12:32 AM, Daniel Friesen wrote:
On 10-11-09 03:42 PM, Platonides wrote:
Trevor Parscal wrote:
In relation to: https://bugzilla.wikimedia.org/show_bug.cgi?id=25124 - I
am considering removing $wgStyleDirectory rather than
These differences in field names aren't just to do with Vector, they are
to do with the configuration of vector. If you have
$wgVectorUseSimpleSearch = false; then the field names for search will
be the same, the point is that it's a very different control, and a
script that's hooking into it
On 11/10/10 6:52 AM, Aryeh Gregor wrote:
Whatever script makes static dumps should just get ResourceLoader to
output one CSS file that contains everything that could be needed,
probably with no JS (unless there's some JS static dumps will actually
want that I can't think of), and include that
Your problem has nothing to do with CSS. The images that are not loading
are actual img tags, and they are trying to find images in the /img/
folder, which means http://wiki.bn2vs.com/img/ in your case.
- Trevor
On 11/10/10 1:40 PM, Jeroen De Dauw wrote:
Hey,
Can you link to the actual fail
ResourceLoader uses CSSMin::remap, which *should* work with double,
single or non quoted URLs. There may be some strange syntax that it's
tripping over though...
- Trevor
On 11/9/10 12:53 AM, Maciej Jaros wrote:
@2010-11-09 05:51, Jeroen De Dauw:
Hey,
Thanks again for the quick reply.
It's in the roadmap and in process? Want to help?
- Trevor
On 11/9/10 11:00 AM, Dmitriy Sintsov wrote:
Hi!
Is it possible to add client-side support for {{PLURAL}} in
mediaWiki.msg() ? Or, that would be too complex, since different
languages can interpret plurals in different ways.
Dmitriy
On 11/9/10 11:32 AM, Emmanuel Engelhart wrote:
This is perfectly true, I have discovered that a few days ago. The
DumpHTML extension was broked by the introduction of the
resourceLoader. Consequently static pages are missing essential CSS
directives and are not correctly displayed. So we have
In relation to: https://bugzilla.wikimedia.org/show_bug.cgi?id=25124 - I
am considering removing $wgStyleDirectory rather than further depending
on it.
It seems that it's only partially used right now, and making the style
directory variable but not other directories is inconsistent as well.
Well, probably not unless the bugmeister finds most reported bugs to be
invalid or duplicates... They won't be resolving them, just helping us
organize them...
- Trevor
On 11/8/10 12:48 PM, Roan Kattouw wrote:
2010/11/8 Ashar Voultoizhashar+...@free.fr:
With Codereview backlog, manual
You are probably assuming your code is running in the global scope. It's
actually being wrapped in a closure. If you want to create a global
variable or function you need to do so by adding it to the window object.
The old way:
var myVar = 1234;
function myMethod() { alert( 1234 ); };
The new
Well, you don't have to do that, there's a work around...
ResourceLoaderFileModule objects can have more than one script per
module, just pass in an array for the scripts element. In this array you
will first have the OpenLayers script, and then the another script you
have written. Your script
Well, if OpenLayers isn't attached to window then it won't work...
You need to use the technique I told you about and add this line to the
script.
window.OpenLayers = OpenLayers;
- Trevor
On 11/8/10 3:54 PM, Jeroen De Dauw wrote:
Hey,
Using only a single resource module seems to fix the
The paths will be remapped so that relative paths in the CSS file will
still work. Look at the paths in the output CSS and you should be able
to see the issue quickly.
go to load.php?modules=ext.maps.openlayersonly=stylesdebug=true on
your wiki and you should see the CSS.
- Trevor
On 11/8/10
You can use OutputPage::addScript - who said you cant?
- Trevor
On 11/5/10 1:30 AM, Dmitriy Sintsov wrote:
Hi!
If my extension does not need jQuery and I don't like minification, why
can't I still use OutputPage::addScript() in my code? Aren't too much
number of extensions would become
MakeGlobalVariablesScript does not do what you think it does, and is not
an appropriate hook for doing anything but adding elements to the array
argument for that hook. You should be adding modules in your
SpecialPage::execute function.
As for your addScript() calls not working, I will need to
The idea of dividing deploy and enable seems strange to me. Only in the
case of a feature-flagged bit of core code or extension which has not
been deployed yet would this even work, in all other cases deployment is
enabling because you've just updated active code.
Additionally, the idea of
Please forgive my point-by-point response. You have some excellent
questions and interesting points, and I did not want to loose any context.
On 11/2/10 10:46 AM, Robert Leverington wrote:
I wasn't present in D.C. so can't comment on the arguments made there,
but it is my understanding that
On 10/21/10 3:39 PM, Maciej Jaros wrote:
What about setting a cookie to go into a debug mode? I thought you liked
the idea?
I have no problem with that, it's just not implemented yet. Want to help?
- Trevor
___
Wikitech-l mailing list
On 10/15/10 2:44 PM, Aryeh Gregor wrote:
It's not a two-way street. It would be most accurate to say that the
decision lies in the hands of just a few people.
If the problem is truly being caused by a few people's choice of action,
then volunteers should be sympathetic to staff developers,
On 10/15/10 3:19 PM, Steve Summit wrote:
Please pardon an outside comment which may be misinformed, or too
blunt; I haven't been part of this discussion or followed all of
it, and I'm not well-informed on the tensions which motivated it.
But:
well read this:
Thank you, everyone, for responding so far (not trying to stop you
here). Here's where it seems we're at.
1. Having an extension called Vector is neither descriptive or
clear, and it is anticipated to cause confusion.
2. System administrators are not enjoying things being switched
On 10/13/10 3:00 AM, Robert Leverington wrote:
On 2010-10-13, Trevor Parscal wrote:
Thank you, everyone, for responding so far (not trying to stop you
here). Here's where it seems we're at.
1. Having an extension called Vector is neither descriptive or
clear
Conversation has been taking place on CodeReview about whether people
(developer and system administrators) will find it confusing that
there's code in both extensions/Vector and skins/vector that are
related but not the same thing.
I personally find it simple to understand and don't expect
On 10/12/10 6:10 PM, Alex wrote:
On 10/12/2010 8:35 PM, Trevor Parscal wrote:
Conversation has been taking place on CodeReview about whether people
(developer and system administrators) will find it confusing that
there's code in both extensions/Vector and skins/vector that are
related
On 10/12/10 7:42 PM, MZMcBride wrote:
Trevor Parscal wrote:
Apologies in advance for the sheer triviality of this matter;
unfortunately these kinds of bike shed problems [2] tend to be
infinitely exciting, while complex matters are more often met with
general disinterest.
[1] http
On 10/12/10 8:03 PM, Chad wrote:
On Tue, Oct 12, 2010 at 10:45 PM, Trevor Parscaltpars...@wikimedia.org
wrote:
On 10/12/10 7:42 PM, MZMcBride wrote:
Trevor Parscal wrote:
Apologies in advance for the sheer triviality of this matter;
unfortunately these kinds of bike shed problems [2
On 10/12/10 10:29 PM, Ryan Lane wrote:
The only response I've gotten so far is merge into core, which is an
interesting response, but does not resolve the issue at hand, which is,
until we do so (assuming we do at some point after 1.17), what should
this extension be named?
I'm not
based on what I feel are misunderstandings.
On 9/29/10 6:28 PM, Tim Starling wrote:
On 30/09/10 08:27, Trevor Parscal wrote:
There seems to be some confusion about how ResourceLoader works, which
has been leading people to make commits like r73196 and report bugs like
#25362. I would like
On 9/30/10 10:11 AM, Roan Kattouw wrote:
2010/9/30 Trevor Parscaltpars...@wikimedia.org:
* Where it is suspected that, due to caching issues, the debug code
may not be the same as the minified code.
Shift+refresh?
Or change the URL in some way that doesn't alter the meaning of the
URL.
On 9/30/10 9:31 AM, Trevor Parscal wrote:
Tim,
First off, thank you for taking the time to respond here, I know you
have a lot on your plate right now, and I hope things are going well for
you. I did not mean to call you out as having made a mistake as much as
I wanted to point
Early on in the requirements stage of ResourceLoader development we
decided to use ISO8601 as the format for representing timestamps in
URLs. This was chosen for it's legibility, conformance to a standard and
ease of generation. However this was somewhat of an oversight since the
timestamp
Well, the MediaWiki timestamp string (19850412101530) is very
similar to the basic ISO8601 format (19850412T101530Z), the
difference being the use of T as a separator and the Z at the end to
indicate GMT.
I guess I'm a little confused why someone would find 19850412101530 to
be fairly
On 9/30/10 1:55 PM, Maciej Jaros wrote:
At 2010-09-30 20:35, Trevor Parscal wrote:
[...]
* Where end users report platform-specific JavaScript errors, it may
be useful to be able to match the line number of the error with
something meaningful.
The usefulness of this is attached
101 - 200 of 275 matches
Mail list logo
