Wikitech-l December 2002

wikitech-l@lists.wikimedia.org

41 participants
139 discussions

TeX, release candidate 1
by Tomasz Wegrzanowski 10 Dec '02

10 Dec '02

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.

1 0

RE: [Wikitech-l] Languages & namespaces
by Mark Christensen 10 Dec '02

10 Dec '02

> > 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

2 1

RE: [Wikitech-l] Languages & namespaces
by Mark Christensen 10 Dec '02

10 Dec '02

> 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.

2 1

the problem with languages being separate from namespaces
by Jonathan Walther 09 Dec '02

09 Dec '02

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

7 11

Speeding up the database (was: Languages & namespaces)
by Poor, Edmund W 09 Dec '02

09 Dec '02

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

2 1

RE: [Wikitech-l] the problem with languages being separate from namespaces
by Poor, Edmund W 09 Dec '02

09 Dec '02

We can't abolish the colon, because then [[Magic: the Gathering]] couldn't have a properly name article. Ed Poor

2 1

Rollbacks: SoftSecurity on Steroids
by Daniel Mayer 07 Dec '02

07 Dec '02

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.

1 0

TeX, version 14
by Tomasz Wegrzanowski 07 Dec '02

07 Dec '02

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.

1 0

bug in utf8 misspelling searching
by youandme＠poczta.fm 06 Dec '02

06 Dec '02

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

2 1

User accounts
by Tomasz Wegrzanowski 06 Dec '02

06 Dec '02

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 ?

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l December 2002