mizusumashi schreef:
By the way, I sent some mails to ML wikitech-l. But they are not in the
Archive. Why?
Mails don't always show up immediately. Also, the archives are grouped
per month, so you may have been trying to find e-mails sent in late
November in the December archives.
Roan
We had a pretty lengthy discussion about this before the summer, and the
consensus seemed to be that a fulltext-based approach looked most
viable. I actually wrote an extension that does that, and promised to
release it soon; that was quite a few months ago, and I never got around
to it. I'll
We had a pretty lengthy discussion about this before the summer, and the
consensus seemed to be that a fulltext-based approach looked most
viable.
So how does this take care of deep indexing non-atomic categories?
=How will this extension be even remotely useful for let's say commons?
This
2008/12/3 Daniel Schwen [EMAIL PROTECTED]:
I'm sure this thread will die out soon.
Half of the participants will again be soothed by the promise of some easy
solution just barely beyond the horizon, while the half that realizes that
said solution _cannot possibly work_ without a radical
Daniel Schwen schreef:
We had a pretty lengthy discussion about this before the summer, and the
consensus seemed to be that a fulltext-based approach looked most
viable.
So how does this take care of deep indexing non-atomic categories?
Err.. what? Please explain what you mean by
On Wed, Dec 3, 2008 at 10:59 AM, Daniel Schwen [EMAIL PROTECTED] wrote:
So how does this take care of deep indexing non-atomic categories?
=How will this extension be even remotely useful for let's say commons?
That's a social problem, and so of secondary importance. Once a
technical mechanism
the other useful technical innovations that get introduced. All it
would take is running some bots for a while to switch to the better
system, not a big cost for a large wiki like Commons with plenty of
bot operators.
I'd like for you to be right. But switching from the present category
Aryeh Gregor [EMAIL PROTECTED] writes:
On Tue, Dec 2, 2008 at 11:01 AM, Daniel Schwen [EMAIL PROTECTED] wrote:
So we have shown multiple times now that cat intersection is technically
feasible. What we nee now is massive lobbying for atomic categorisation.
THAT is the hurdle right now
2008/12/3 Aerik [EMAIL PROTECTED]:
I'm with you - we've shown feasibility in large datasets with a lucene based
approach, and I think we need to roll it out and test it with real users on
real data. We need a new lucene index and a user interface (needs to be
defined) suitable for average
On Wed, Dec 3, 2008 at 12:37 PM, Aerik Sylvan [EMAIL PROTECTED] wrote:
[snip]
But it sounds like maybe those of us who'd like to see this happen should
discuss a UI (or several) for it. I was thinking the most intuitive
interface was a sort of browse type function, where for any given group
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
mizusumashi wrote:
I see that some (maybe all) Japanese names are correctly displayed. I
am very glad thanks to your work.
Yay!
But I have a very few dissatisfaction. Surname are displayed after
personal name. As you know, in east Asia we
As per Michael's earlier e-mail:
http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_user-friendly_for_new_volunteer_writers
We're very grateful to the Stanton Foundation for this important
investment in Wikipedia's user-friendliness. We're aware of the UNICEF
research as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brion Vibber wrote:
mizusumashi wrote:
I see that some (maybe all) Japanese names are correctly displayed. I
am very glad thanks to your work.
Yay!
But I have a very few dissatisfaction. Surname are displayed after
personal name. As you
Bence Damokos schreef:
Thank you for considering Hungarian. You could detect Hungarians by simply
looking for donations in Hungarian Forints (HUF).
Note that not all people who live in Hungary have Hungarian names, and
not all Hungarians live in Hungary.
Roan Kattouw (Catrope)
On Wed, Dec 3, 2008 at 10:01 PM, Roan Kattouw [EMAIL PROTECTED] wrote:
Bence Damokos schreef:
Thank you for considering Hungarian. You could detect Hungarians by
simply
looking for donations in Hungarian Forints (HUF).
Note that not all people who live in Hungary have Hungarian names,
Unfortunately we get the name already divided up from PayPal and are
stuck either guessing or making an unattractive 'Surname, Given' display
which looks bad for everyone. :(
There is something to be said for annoying everyone equally. Being an
international organisation is very important for
(long, complex solutions to guess the right display)
Why not have a Show Name, Surname / Show Surname, Name option on the
donation display?
Easy, consistent, and everybody should be happy with it.
___
Wikitech-l mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Platonides wrote:
(long, complex solutions to guess the right display)
Why not have a Show Name, Surname / Show Surname, Name option on the
donation display?
Easy, consistent, and everybody should be happy with it.
Because it would show
On Wed, Dec 3, 2008 at 11:43 AM, Daniel Schwen [EMAIL PROTECTED] wrote:
I'd like for you to be right. But switching from the present category system
to atomic categories is not as straight forward as having a few bots run over
all existing cats.
Of course, humans would have to manually specify
how things are categorized. As long as category intersections remain
vaporware, there's no incentive to change. A technical fait accompli
will bring about change.
Uhm, yeah.. except that intersection of atomic categories are not vaporware.
We had proofs of concept for that and the interest
From CNET interview to Brion
http://news.cnet.com/8301-17939_109-10103177-2.html
The text alone is less 500 MB compressed.
That statement struck me, as I wouldn't think that big wikis could fit
on that, much less all wikis.
So I went and spent some CPU on calculations:
I first looked at
Brion Vibber wrote:
Platonides wrote:
(long, complex solutions to guess the right display)
Why not have a Show Name, Surname / Show Surname, Name option on the
donation display?
Easy, consistent, and everybody should be happy with it.
Because it would show everything wrong? :)
--
On Wed, Dec 3, 2008 at 8:12 PM, David Gerard [EMAIL PROTECTED] wrote:
The last time will be when there's a feature end-users can use without
going off to the toolserver.
With a JS hack I had my tool integrated to the site. The AJAX calls
went to the toolserver, but as far as the users could see
Gregory Maxwell wrote:
With a JS hack I had my tool integrated to the site. The AJAX calls
went to the toolserver, but as far as the users could see it was
running on the site. No one cared: It didn't produce useful results
because of how categories are used, and when I suggested changing
Gregory Maxwell wrote:
So an interface I had that was really pleasing was that I asked the
database to find a random subset of the results, which it could do
quickly, (or I used the whole results if the initial query contained
them) and I found the set of categories which maximally bisected
Aerik Sylvan wrote:
But it sounds like maybe those of us who'd like to see this happen should
discuss a UI (or several) for it. I was thinking the most intuitive
interface was a sort of browse type function, where for any given group
of categories (could just be one category), you have two
26 matches
Mail list logo
