Changes:
* Charsets other than UTF-8 supported, Latin1 and Latin2 only now (Wikipedia uses
only Latin1 and UTF8), but it requires to edit exactly 3 lines to add another
encoding (1 line to add new type to encoding_t, another to say what is its name,
and third to say what should be LaTeX header for it). If no or unknown encoding is
passed, texvc assumes it is UTF-8. At least it is right if it's some ASCII-only
string.
* texvc_cgi.phtml now generates right HTTP Content-Type headers with encoding
* both OutputPage.php and texvc_cgi.phtml pass encoding to texvc
* (not really related to texvc, but also included) <pre> changed back to old behaviour
Now the only important unresolved things are CJK support and PNG transparency.
But I think we can live without them for now.
Oh, and texvc should allow more characters in \mbox{}, not only letters
and those with 8th bit set.
Please check this patch and comment.
> > A long term
> > redesign of the software could definitely be beneficial.
>
> We have done it twice, without much benefit.
> I'm all for evolutionary way.
Actually, we'd never have made it this far without the "revolutionary"
redesign done by Lee earlier this year. Our performance old PHP code
was breaking under far less load than we have all the time now.
While, we do need to improve our DB performance, but without better
stats, we can't say for certain that there aren't any PHP bottlenecks.
And PHP bottlenecks could eventually arise if we improve DB performance
significantly.
I'm all for the evolutionary way, but I think there's room for someone
who wants to work on a revolutionary way while others improve our
current system.
Yours
Mark Christensen
> Yes, but we were limited by MySQL each time. Have you used
> Postgres or Oracle or Sybase before? I have a hard time
> expressing briefly how great SQL92 compliance is compared to
> the subset that MySQL supports. Using MySQL for this is
> walking the long way around the bay when you could paddle the
> Postgres canoe directly across it in a fraction of the time.
>From a Project Management standpoint, I'd be very interested in knowing
what's stopping us from breaking this into two projects.
The first being a redesign of the table space, and upgrade of the DB to
the most recent version of Postgres, with modification of the current
PHP code. This could be an evolutionary process, with the one
"revolutionary" moment being the upgrade to Postgres and concurrent
update of the PHP code to remove the MySQLisms. Once we are on the new
system, the tables and queries could be updated a few at a time to
improve performance incrementally and evolutionarily.
The second stage would then be upgrading -- with the improved table
structure -- to the new ModWiki software.
I have a goal for the design. My goal is that, once a Wikilink is
exploded based on the ':' character, I can do simple database lookups,
and append the results together to get the target URL without having to
do any parsing on the data I looked up.
For instance, let us take a link Talk:foo
I can explode this into Talk and foo.
Each namespace has an "urlprefix". For Talk, the urlprefix would
be http://www.wikipedia.org/Talk
Now, let's add a (separate) language into the mix. en:Talk:foo
I can explode it into en, Talk, and foo.
Now, the urlprefix for Talk is the same. How do I say that it is an
english language page? The normal, standard way to do this would be
like so:
http://www.wikipedia.org/en/Talk/foo
That feels "right" to me. But doing that would require parsing the
urlprefix for the namespace to figure out where to put in the language.
I don't want to do that, and don't feel I should have to.
If languages are namespaces it is easy: I can make the namespace en_Talk
have an urlprefix of http://www.wikipedia.org/en/Talk
However, Brion, you've made a convincing case that we do need to know
the language. I have no problem having another field for each
namespace, giving that namespaces language to give to browsers.
Can you think of a better way to do this?
Jonathan
--
Geek House Productions, Ltd.
Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998
Phone: 604-435-1205
Email: djw(a)reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2
Yes, Jonathan. If you want to become an admired contributor around here, PLEASE OH PLEASE redesign the table schema so that queries run much faster!!
Ed Poor
On Wednesday 04 December 2002 03:38 pm, wikitech-l-request(a)wikipedia.org
wrote:
> Despite all the critics, at least for our first vandal bot on the German
> pedia the rollback function came just handy and worked fine. Thanks Brion.
>
> Sven (Ben-Zin)
Mega Dittos! I love this feature because it offers an easy way to wear-down
vandals without having to block the vandal's IP. Rolling back each edit a
vandal makes two seconds after they make it should cause most vandals to lose
interest and leave for good instead of instantly getting pissed-off by
getting blocked (therefore evoking the "I'll show you" response whose only
outlet would be circumventing the block or jumping wikis). Thus a string of
rollbacks would tend to reduce the chance that the vandal will come back
later with bigger guns (or trash a sleeping non-English wiki).
For example; as soon as I determine that an IP is a vandal, I leave that IP's
user contribs page open and periodically hit reload. And WAMMO! I click on
the rollback link each time the vandal makes an edit. So far every vandal has
gotten the hint after less than 10 rollbacks.
It would be nice, however, if clicking on rollback takes you back to the user
contribs page and not the reverted article. But I understand that there still
in the problem of possible rollback conflicts where two Admins hit rollback
in succession and Admin 2 reinstates the vandal version that Admin 1 already
reverted. So until that can be fixed I don't mind hitting the back button.
When it does get fixed I would like to propose that a limited rollback feature
be added as a logged-in user default. The limited part would be this; Regular
logged-in users would not be able to rollback edits made by other logged-in
users. But IPs would be fair game.
-- Daniel Mayer (aka mav)
Payment for this post:
http://www.wikipedia.org/w/wiki.phtml?title=Ruthenium&diff=463516&oldid=461…
PS IMO there already are way too many features available to the greenest of
newbies. It would be nice if we started off new accounts with basic features
and automatically added more features based on the number of edits that user
has made and the age of the user account (maybe have three feature-set
levels: novice, intermediate and old hand). I fear that having too many
features is intimidating to many non-technical new users. I'm also a wee bit
apprehensive that new users would abuse features we might otherwise want to
give to many users (such as the limited rollback feature described above).
However, after the Lir fiasco I'm no longer in favor of automatically granting
pure meta-level powers to users. Old hands can and should continue to ask and
be invited to ask about being Admins.
CGI interface to texvc moved to PHP (texvc_cgi.phtml).
It's much more sane now.
It now does another parsing to generate TeX.
I think that's more efficient than caching generated TeX in database.
OTOH it shouldn't have to parse it twice if both image+HTML and TeX are
requested. Well, that certainly isn't going to be performance bottleneck.
Can maintenance pages, namely misspelling seeking,
be set up to use the same mechanism as normal search
on Polish Wikipedia (and perhaps other utf8 ones)?
I put "pojedy&naccute;cze" (of course with respective letter
instead of &naccute; entity) on the Misspelling page
and I see only pages with "cze" occurences on the result page.
While the same normal search gives correct results.
TIA
Youandme
----------------------------------------------------------------------
Portal INTERIA.PL zaprasza... >>> http://link.interia.pl/f167c
Could user accounts be integrated between Wikipedias ?
(cookie would be set for whole wikipedia.com)
So that people don't have to log for every Wikipedia they modify.
It's most annoying when it's just for adding interwiki links -
often 5 or more logins would be necessary to do it right.
Oh, and why does login expire so fast ?