-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We don't have to do this immediately, but would there be any objection
to removing the user_id column from the user_newtalk table and using
that table only for anon IP addresses?
It just strikes me as a bizarre structure (each row contains data in
*either* user_id or user_ip), and we already load up the whole row from
the user table when dealing with a logged-in user. If we put the
user_newtalk column back into user, we can cut out a query from each
logged-in page view. Not much, sure, but it seems redundant as it is.
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+0TcfxVlOmwh1xjgRAkNVAJ9KQpiro3JfeWmZa8VNIOzlw7GhDwCePDEh
8Ml5K6CFDenN1QcHNB+jztU=
=Lx1g
-----END PGP SIGNATURE-----
When I view a page like 'Greek alphabet' on the English Wikipedia unicode characters are displayed as 'empty boxes'.
I thought Windows (I use XP) would automatically offer to download any fonts needed to display special unicode characters. It doesn't.
My suggestion: would it be useful on each page that contains unicode to automatically add a link to a help page that gives hints and tips for enabling unicode on popular browsers?
Erik Zachte
Hello all,
There have been persistent problems with file upload on the Polish
Wikipedia.
---------------cut here----------------------------------------
Wystąpił błąd składni w zapytaniu do bazy danych. Mogło to być
spowodowane przez złe sformułowanie zapytania (zobacz Przeszukiwanie
Wikipedii) albo przez błąd w oprogramowaniu. Ostatnie, nieudane zapytanie
to:
REPLACE DELAYED INTO searchindex (si_page,si_title,si_text) VALUES
(18161,'mahatma gandhi jpg',' mahatma gandhi z wp-en ')
wysłane przez funkcję "SearchUpdate::doUpdate". MySQL zgłosił błąd
"1016: Can't open file: 'searchindex.MYI'. (errno: 145)".
---------------cut here----------------------------------------
Additionally it produces invalid filenames in the system.
Developer help needed urgently.
Regards,
Kpjas.
Hi,
I done an easy SQL-Query in german Wikipedia:
select cur_title,cur_text from cur where cur_namespace=0 and
cur_is_redirect=0 and length(cur_text) < 90 order by cur_title
which returns some articles, one of them: "Film/SchauspielerinnenF" linked
to: http://de.wikipedia.org/wiki/Film/SchauspielerinnenF
Klicking the Link I got a 404 HTTP Error, Mozilla displaying:
http://de.wikipedia.org/wiki/Film%2FSchauspielerinnenF
^^^
entering http://de.wikipedia.org/wiki/Film/SchauspielerinnenF manually
everything works fine.
Any ideas?
--
Smurf
smurf(a)AdamAnt.mud.de
------------------------- Anthill inside! ---------------------------
Okay, I *think* it's fixed. In CVS, installed on test and en wikis.
I added a call to $this->loadDefaults(); if the password check fails in
User::loadFromSession(). As it was, it was clearing the user ID to
zero, but not anything else -- so user name, newtalk status, etc was
still set as for the user.
-- brion vibber (brion @ pobox.com)
Seach results in the following error:
"1016: Can't open file: 'searchindex.MYI'. (errno: 145)"
Someone at work?
--
Smurf
smurf(a)AdamAnt.mud.de
------------------------- Anthill inside! ---------------------------
At some point in the near future I'll be adding in a per-language sort
order adjustment, so that various sorted lists should turn out in more
or less correct order for a change. :)
I'd appreciate pointers to descriptions of various languages' sorting
requirements so I can try to get them right.
I don't know if we can handle Japanese and Chinese sensibly, but
alphabetic languages should generally work fairly well by making a
munged copy of the string such that, eg, if "ó" sorts as the same as
"o" we just change it to "o"; if "ó" sorts after "o" (as in Polish
IIRC), it becomes "o~", which should always sort after any "o" and
before any "p" in a binary ASCII-order string sort.
Simple replacements should generally work, though we can also do more
complicated replacements of certain sequences of characters.
-- brion vibber (brion @ pobox.com)
Ah well, I knew many of these ideas would be controversial!
Thanks for the many replies.
However, I haven't heard anyone comment about changing the
"talk" pages into a threaded discussion group:
> A related idea might be to modify the "talk" system so that it's
> more like a bulletin board, with threaded messages and
> a clear identification of who made it (click on "reply" to reply
> to that item, maybe in a threaded way). That way, any message is
> clearly
> identified with its REAL author. A side-effect would be that
> the attribution would happen automatically (no more
> forgetting ~~~~). That way, when people discuss things, they
> can't make it appear that someone else made an outrageous/nasty
> statement.
(Yes, a "diff" will show reality, but it's hard to go through
every diff to see what really happened.)
Presumably there's some acceptance of mailing lists, since
we're talking on one...! :-). Are there fewer objections to
this idea?
Erik Moeller wrote:
> Regarding the skins, I think Cologne Blue *could* become the standard with
> some design fixes, but we should stick with Standard for now.
IMO Colonge Blue is nearly as bad as Nostalgia as far as usability is
concerned. The emphasis of that design seems to be concentrated on making
things look pretty and not on making things easy to use or find.
It would probably be better to just add a bit of color to our logo and the
Standard Header.
> Underlining:
>
> Users who like their links underlined can still turn on this option, but
> extrapolating from the above, I would guess that non-underlined links are
> more popular. Note that we are a very link-heavy page, so the high amount
> of underlining on a page can get quite distracting. Links are reasonably
> easy to distinguish from normal text when non-underlined.
I agree. At one time underlining was the standard way to mark hyperlinks but
most websites don't do this anymore. One of the first settings I changed was
this one (IMO all the hyperlink underlining is really really ugly ; right
along with the even older web "standard" of having all non-bgcolor filled
backgrounds display as gray).
> Remember password:
>
> This option needs to be distinguished from underlining, as it can also be
> accessed on the login screen, not just on the preferences screen, and is
> thus likely to be noticed by more people. However, I still think this
> should be the default. There are users at places where they do not want
> their password remembered, such as cafes and changing terminals at work.
> What is the standard case and what the exception, though? My guess is that
> most people log in to Wikipedia from one or two machines, and that the
> browser on that machine is reasonably secure from access by others. Other
> users should be security aware enough to tick off the "Remember" checkbox
> during login.
Hm. Since this is more of a security issue I think the current behavior is
best. I for one often use my school's computer lab to get a quick check of my
watchlist. So the last thing I would want is for the school computer to
remember my login and allow somebody to run amok with my sysop-enabled
account (actually I always explicitly log-out, and clear the history and the
cache of any public computer after I use it - but most people don't do this).
-- Daniel Mayer (aka mav)