I use another method to know the number of pages.
i do:
http://es.wikipedia.com/wiki.cgi?action=index
(for example, with the spanish version)
By the way, i truly need help with the catalan wikipedia... see
meta.wikipedia.com. Now i have trolls too writing stupid jokes instead
of articles :(.
--
tuxisuau. tuxisuau(a)7a69ezine.org
http://tuxisuau.7a69ezine.org
"How I need a drink, alcoholic of course, after the heavy chapters involving quantum mechanics"
George Polya
"Esto son 31338 hax0rs y se cae el del medio"
Tahum
Wikipedia, la enciclopedia libre. http://es.wikipedia.com
> I like [Tim's] proposal because it is both useful and
> technically sound - a rare combination these days ;)
It's not clear to me from Tim's description exactly what
he's proposing, so let me paraphrase what I think he means:
1) No meta tags (#base, #context, #parent, #alias, or all
the variants we've discussed over the months), no new name
spaces or runtime-features of any kind.
2) As purely a typing convenience like ~~~, links typed
as [[/baz]] on page "Foo (Bar)" are rewritten when saved
as [[Baz (Bar)|baz]]; links in the form [[/baz]] on page
"Foo" are rewritten as [[Baz (Foo)|baz]]. If the link
already specifies a display form (the part after the
vertical bar), that display form is used as is.
3) Links with non-initial slashes are not modified at all.
0
>> That's it (as I understood it). The problem at [[Middle Earth]]
>> does seem to be thy typing inconvenience. The proposal should
>> solve it nicely and simple, without subpages.
> I think Tims proposal is an excellent one, but if I'm honest it
> looks very much like subpages with a slightly different (better)
> notation.
But there are critical differences: most importantly, the article
namespace remains semantically flat; "Foo (Bar)" is still a top-
level article just like "Bar", and they have no pre-defined
relationship of any kind, and no runtime features that link them
in any way. People won't be tempted to use them to "categorize"
pages into hierachies.
Secondly, since the easy-to-type form is replaced by the full
form at save time, newbies won't even know about the shortcut and
won't be tempted to use it, the way they were tempted to use
subpages because they were /too/ easy. Only when one is
experienced enough to recognize that this feature would be
useful will you make the effort to discover it and use it.
Also, cutting and pasting from an article in one context into
another won't change the links, which is a good thing.
0
Michel Clasquin <clasqm(a)mweb.co.za> writes:
> You mean, just like [[Batman]]? The people working on Tolkien seem to be
> the only ones in a huff and a hurry about this.
Well, thats different.
Primarily, because Batman is a *the* main character in the franchise, and the
name of that franchise. If I use the proper noun "Batman", people know what
I'm talking about. There is no ambiguity. The question is not where do you
put [[Batman]], but where do you put [[Robin]]. Or [[Alfred]] (do you really
want the [[Alfred]] page to be an article about an English king with poor
culinary skills and and an article about Bruce Wayne's butler?
A link to both? What would you call the latter?
Similarly, whilst [[Bilbo Baggins]] is unproblematic, [[The Ring]] should
probably be an article about Wagner's operatic cycle.
Whereas [[Middle Earth/The Ring]] can tell us about its forging in Mount Doom,
its loss in Gladden Fields yadda, yadda, yadda.
The fact remains, that (modulo the auto-wikifying of GNU/Linux, which was a
bug not a feature), and when used for *disambiguation* rather than in any
hierarchical sense, SUBPAGES WORKED.
It continues to baffle me that some people seem to think
[[Alfred (Batman)]] is in somehow sense different from [[Batman/Alfred]]
(rather than just more difficult to type).
--
Gareth Owen
"Wikipedia does rock. By the count on the "brilliant prose" page, there
are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)
Sorry, Magnus, but your counter-proposal changes the
runtime behavior of the system and is /far/ too complicated.
Let's not shoot the golden goose here: Wikipedia works
because it is SIMPLE. Article title space should be
flat (whether or not we add typing conveniences).
Also, disambiguation isn't the problem we're trying to
solve here. That can be done easily enough manually.
There are already great disambiguating pages like "Java",
and we should allow the software to do those automatically
because we want human judgment and creativity to apply to
making them.
The issue really is just one of typing convenience. When
I write about Texas Hold'em strategy, I might say something
like "A raise from late position on the flop will often
cause an opponent to check to you on the turn, giving you
the chance to check behind him and take a free card." In that
sentence, I might want to link words like "raise", "position",
"flop", "free card" and such, and typing "[[Raise (Poker}|raise]]"
for every one of them is a pain. But I /want/ to do the right
thing semantically and make sure that the link actually does go
to the "Raise (Poker)" page, and not just to a disambiguating
"Raise" page that will interrupt and confuse the reader.
Of course, when I /want/ links to be ambiguous to encourage
"accidental" discovery, I can still do that too. In my
"See also" lines, for example, I'll probably just link to
simple titles, hoping that accidental links do interesting
things. So there /will/ be an "Elves" page with pointers to
other contexts, as well as "Elves (Tolkein)", or whatever.
The author should have the choice, and the power. The software
should support what theauthor wants to do, not enforce its
ideas or structure upon the author.
0
> I noticed that the software (see how I avoid saying "my software" in this
> context? ;) sometimes creates subpages that are named wiki.phtml.
>
> Trying to figure out the cause of that, I'd like anyone who accidentially
> created such a page tell me what *exactly* he/she was doing when this
> happened. Were there any other strange side effects? Did you do a preview?
> Create another new page? Got an edit conflict?
I created one today by trying to edit
[[Stephen_Gilbert/Contributions]]. Several days ago I got into a
perpetual edit conflict with myself, so I left it. Today, I went back to
it, and came up at the edit page automatically. I was still in that
edit conflict, so I hit the Random Page link in the header. That's
when the software created [[Stephen_Gilbert/wiki.phtml]].
- Stephen
>> There are already great disambiguating pages like "Java",
>> and we should allow the software to do those automatically
>> because we want human judgment and creativity to apply to
>> making them.
>
>I am almost certain that Lee meant to write:
>"...we should NOT allow the software to do those automatically"
Yep. The brain is faster than the fingers.
0
Sorry, Magnus, but your counter-proposal changes the
runtime behavior of the system and is /far/ too complicated.
Let's not shoot the golden goose here: Wikipedia works
because it is SIMPLE. Article title space should be
flat (whether or not we add typing conveniences).
Also, disambiguation isn't the problem we're trying to
solve here. That can be done easily enough manually.
There are already great disambiguating pages like "Java",
and we should allow the software to do those automatically
because we want human judgment and creativity to apply to
making them.
The issue really is just one of typing convenience. When
I write about Texas Hold'em strategy, I might say something
like "A raise from late position on the flop will often
cause an opponent to check to you on the turn, giving you
the chance to check behind him and take a free card." In that
sentence, I might want to link words like "raise", "position",
"flop", "free card" and such, and typing "[[Raise (Poker}|raise]]"
for every one of them is a pain. But I /want/ to do the right
thing semantically and make sure that the link actually does go
to the "Raise (Poker)" page, and not just to a disambiguating
"Raise" page that will interrupt and confuse the reader.
Of course, when I /want/ links to be ambiguous to encourage
"accidental" discovery, I can still do that too. In my
"See also" lines, for example, I'll probably just link to
simple titles, hoping that accidental links do interesting
things. So there /will/ be an "Elves" page with pointers to
other contexts, as well as "Elves (Tolkein)", or whatever.
The author should have the choice, and the power. The software
should support what theauthor wants to do, not enforce its
ideas or structure upon the author.
0
Sorry, Magnus, but your counter-proposal changes the
runtime behavior of the system and is /far/ too complicated.
Let's not shoot the golden goose here: Wikipedia works
because it is SIMPLE. Article title space should be
flat (whether or not we add typing conveniences).
Also, disambiguation isn't the problem we're trying to
solve here. That can be done easily enough manually.
There are already great disambiguating pages like "Java",
and we should allow the software to do those automatically
because we want human judgment and creativity to apply to
making them.
The issue really is just one of typing convenience. When
I write about Texas Hold'em strategy, I might say something
like "A raise from late position on the flop will often
cause an opponent to check to you on the turn, giving you
the chance to check behind him and take a free card." In that
sentence, I might want to link words like "raise", "position",
"flop", "free card" and such, and typing "[[Raise (Poker}|raise]]"
for every one of them is a pain. But I /want/ to do the right
thing semantically and make sure that the link actually does go
to the "Raise (Poker)" page, and not just to a disambiguating
"Raise" page that will interrupt and confuse the reader.
Of course, when I /want/ links to be ambiguous to encourage
"accidental" discovery, I can still do that too. In my
"See also" lines, for example, I'll probably just link to
simple titles, hoping that accidental links do interesting
things. So there /will/ be an "Elves" page with pointers to
other contexts, as well as "Elves (Tolkein)", or whatever.
The author should have the choice, and the power. The software
should support what theauthor wants to do, not enforce its
ideas or structure upon the author.
0
Two points before I make my proposal:
1. I prefer the Frodo (Middle Earth) naming convention. It's more
encyclopedia-like.
2. I stand against subpages. Having said that, I stand in support of a
software solution that will translate links so people don't have to type so
much.
So here's yet another proposal. (Although I haven't done anything yet, I am
a registered SourceForce developer. So I'm willing to code up what I
propose.)
It's a blend of ideas already presented by Uri, Magnus, and Mark.
Mine is different because I think the system should merely translate what an
author has typed into what the author is presumed to have meant. This
completely simplifies the wiki syntax to what we have now, but it makes it
easier to create content. An acceptable balance, IMHO. Magnus has set a
precedent for this with the ~~~ signature feature (however, it would be much
more useful if it would expand in the preview screen). So I'm assuming that
the section of the system that translates ~~~ would do these new
translations.
So the elements of the changes are:
1. If the title has a parenthetical phrase, then that phrase is presumed to
be the parent article. So on the Frodo (Middle Earth) page, a link typed
[[/elves]] will be expanded to [[elves (Middle Earth)|elves]] when the page
is saved.
2. If the Title doesn't have a parenthetical phrase, e.g. Middle Earth, then
links of the form [[/elves]] are translated to [[elves (Middle
Earth)|elves]] when the article is saved.
3. To make it easier to use random parethesized article names, the system
could translate any link of the form
[[/name (parenthetical)]]
to
[[name (parenthetical)|name]]
It doesn't save much typing, it has a nice symmetry to the previous two
translation patterns.
4. If we want to get fancy, then we can borrow from the way Perl programmers
change namespaces. I'm simplifying, but basically, in Perl, typing
package "FantasyFiction";
will cause subsequent symbol lookups to happen in the FantasyFiction::
namespace.
So we could use Uri's idea of the #base pragma to cause something like this:
#base [[Fantasy Fiction]]
[[/elves]]
to be translated into this:
See also: [[Fantasy Fiction]].
[[elves (Fantasy Fiction)|elves]]
The system could remove the #base line completely instead of translating it,
but I think it's useful to reflect by default that there's a relationship
between the content of a give page and some other related page. After all,
if the author doesn't like that behavior, he or she can simply type the
links manually instead of using #base. Or the author can edit twice: the
first is a major edit, and the second is a minor edit to remove the See
also: line.