Why one page_title can have different page_id? For example, the page_title
'USA' has two page_id '98937','112696'.
Thanks
vanessa
lee
___
Wikitech-l mailing list
On 28.09.2009, 16:54 ?? wrote:
Why one page_title can have different page_id? For example, the page_title
'USA' has two page_id '98937','112696'.
Because they have different page_namespace ;)
___
Wikitech-l mailing list
Hi,
On Wed, Sep 23, 2009 at 8:28 PM, Platonides platoni...@gmail.com wrote:
Aryeh Gregor wrote:
I've been meaning to investigate this, but haven't found the time yet.
Have you come up with a minimal test case, or filed a bug with
Mozilla? I'd be willing to look at this if I get the time,
My attachment did not make it into the JS2 design thread... and that
thread is in summary mode so here is a new post around the html output
question. Which of the following constructions are easier to read and
understand. Is there some tab delimitation format we should use to make
the jquery
On Mon, Sep 28, 2009 at 6:44 PM, Michael Dale md...@wikimedia.org wrote:
..
I think both are useful and I like jquery style building of html since
it gives you direct syntax errors rather than html parse errors which
are not as predictable across browsers. But sometimes performance wise
or
[snip]
what I think we have here, is that $('#cat') is expensive, and run
inside a loop in dojBuild
you can build and append in the jquery version and it only shaves 10ms.
ie the following still incurs the jquery html building function call costs:
function dojBuild(){
var o ='';
On 9/28/09 7:57 AM, Robert Ullmann wrote:
On the wiktionary (and for some things on the 'pedia), Ruby support is
useful, so I have the extension. But it also has the serious
mis-feature of trying to improve on abbr tags, and a serious bug
when there are lots of them.
Fix is to disable the
I'd like to share some exciting news with you all... After four awesome
years working for the Wikimedia Foundation full-time, next month I'm
going to be starting a new position at StatusNet, leading development on
the open-source microblogging system which powers identi.ca and other sites.
I've
Tim Starling wrote:
Michael Dale wrote:
That is part of the idea of centrally hosting reusable client-side
components so we control the jquery version and plugin set. So a
new version won't come along until its been tested and
integrated.
You can't host every client-side
On 9/27/09 4:15 AM, Aryeh Gregor wrote:
On Fri, Sep 25, 2009 at 9:55 PM, Michael Dalemd...@wikimedia.org wrote:
...right... we would want to avoid lots of live hacks. But I think we want
to avoid lots of live hacks anyway. A serious javascript bug would only
affect the pages that where
~ dough ~ Disregard previous, bad key stroke sent rather than save to draft.
Tim Starling wrote:
Michael Dale wrote:
That is part of the idea of centrally hosting reusable client-side
components so we control the jquery version and plugin set. So a
new version won't come along until its
On Mon, Sep 28, 2009 at 2:32 PM, Brion Vibber br...@wikimedia.org wrote:
I'd like to share some exciting news with you all... After four awesome
years working for the Wikimedia Foundation full-time, next month I'm
going to be starting a new position at StatusNet, leading development on
the
David Gerard wrote:
2009/9/24 Aryeh Gregor simetrical+wikil...@gmail.com:
On Thu, Sep 24, 2009 at 10:48 AM, dgerard dger...@gmail.com wrote:
WYSIWYG editing is
getting there bit by bit - FCKeditor would be fine on a fresh wiki
without the unspeakable atrocities inventive geeks
Side note. Multiple versions of jQuery can live happily on the same page.
jQuery handles isolation and noConflict so well that it can work on the
same page as incompatible versions of itself (which isn't the case for
basically any other js library, 90% of which prototype stuff in).
I like to use
I got another, not from the thread of course. I'd like addOnloadHook to
be replaced by jQuery's ready which does a much better job of handling
load events.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Tim Starling wrote:
Here's what I'm taking out of this thread:
*
Brion Vibber wrote:
...
Having this infrastructure in place further means we're in a better
position to someday make a major markup transition (say to a different
markup system or not exposing markup at all in a pure-WYSIWYG
environment)... something we're now very far from... but doesn't
Like YAML?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Aryeh Gregor wrote:
On Fri, Sep 25, 2009 at 6:48 PM, Brion Vibber br...@wikimedia.org wrote:
The field metadata can be fairly straightforwardly displayed and edited
through a nice web interface. XML as such
Hmmm... reminds me of
http://www.wikicreole.org/wiki/Placeholder
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Magnus Manske wrote:
...
* It will replace all other templates with strings like
##TEMPLATEnumber:name##, e.g., ##TEMPLATE1:Infobox VG##
...
Cheers,
On 9/28/09 12:55 PM, Aude wrote:
On Mon, Sep 28, 2009 at 2:32 PM, Brion Vibberbr...@wikimedia.org wrote:
I'd like to share some exciting news with you all... After four awesome
years working for the Wikimedia Foundation full-time, next month I'm
going to be starting a new position at
On Tue, Sep 29, 2009 at 5:55 AM, Daniel Friesen
li...@nadir-seen-fire.com wrote:
I had a user who copied an article from the html of Wikipedia (no edit
button) into Wikia's RTE.
Theoretically that use case could be supported, right? If there were
enough id's in the HTML source, then we could
we have js2AddOnloadHook that gives you jquery in no conflict as $j
variable the idea behind using a different name is to separate jquery
based code from the older non-jquery based code... but if taking a more
iterative approach we could replace the addOnloadHook function.
--michael
Daniel
That would certainly simplify the format; on the other hand, it would lead
to a lot of redundancy between the different documentation tags, which
could lead to conflicting data structures; so it's probably not a workable
solution.
-Yaron
There could be documentation lang=en, documentation
22 matches
Mail list logo
