Hello everybody,
I'm Namal Senarathne from Sri Lanka, I'm studying computer science &
engineering at university of Moratuwa
I'm interested in participating in GSoc 2008. I went through Wikimedia's
ideas page for soc 2007.
I found out that the idea 'upload form improvements' (
http://meta.wikimedia.org/wiki/Summer_of_Code_2007#Upload_form_improvements)
was not implemented as a project in GSoc 2007. I believe I will be a
suitable candidate to implement it
as a project in GSoc this time.
But I could not find any resource material to study the detail project
descriptions from the wikipedia
ideas page, before composing a proposal.
So I would really appreciate if some one can please direct me to some
resources
Thank you in advance
Namal
On Fri, Mar 7, 2008 at 5:35 AM, <nikerabbit(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> * Let's remove hardcoding together
>
> Modified Paths:
> --------------
> trunk/phase3/includes/SpecialUpload.php
> trunk/phase3/languages/messages/MessagesEn.php
What about other languages here?
Hi All,
So, I'm still compiler impaired (I guess I need to actually learn about
compiling and linking and stuff, and not just writing code), but I managed
to get a CLucene based (Lucene in C++) search set up which you can test
here:
http://aerik.com/cl_search.php
Uses underscores instead of spaces in a category name.
It passes the query to the CLucene executable and then displays the raw
results, as well as calculate an overall processing time. Eventually I want
to evolve this into a daemon where you send commands and queries to the
indexing daemon (I'm thinking of doing it simply in terms of POSTs and
GETs).
ANYWAY, try it out. It doesn't return the actual page, it returns the
cl_from key from the categorylinks table. I also have a fulltext MySQL
index set up and if anyone is interested in doing comparisons I'll throw up
a page for querying that too.
Just a note: it looks like the queryparser breaks up dates, but I'm
guessing it did that when it made the index too.... try a search for
'1969_Births' for example.
Best Regarsds,
Aerik
--
http://www.wikidweb.com - the Wiki Directory of the Web
http://tagthis.info - Hosted Tagging for your website!
> If there is, other than Wikitech-l, it should not be muddied with
> policy questions as well, as the page you link to is. I am not
> interested in how Wikipedia is going to categorize things.
>
> The interface I had in mind was basically a box on every category
> page, saying something to the effect of
>
> Enter a category to require: [____________________________]
> Enter a category to exclude: [____________________________]
> ( Submit )
>
> Although the wording could use improvement. Filling one or both of
> the fields and clicking Submit would jump to a special page that would
> do the intersection, have a box to add/remove another category (or
> many of them at once). It would also list all categories currently
> represented, with little (X) links next to them to remove them from
> the result set.
>
> This would be the basic functionality. Additional stuff like a
> Suggestions button (to give a partial list of categories with nonzero
> intersections with the present category, preferably the largest ones)
> would be valuable and perhaps feasible additions, but there's no gain
> in trying to do too much at once.
>
We've been hoping for something much more user-friendly, such as
check-boxes next to each category listing on a page, and a button that
says something like "find articles with checked categories". Of course
you could have a special page for the more techy users that functions as
Simetrical has laid out above, or that page could be the destination for
displaying the initial intersection results so it can be refined more.
Possible interfaces are discussed at [[Wikipedia:Category intersection]]
(or the shortcut [[WP:CI]]). I can repost here, the relevant non policy
stuff as things develop.
-- Samuel Wantman
[[en:User:Sam]]
--
(cross-posting wikitech-l and commons-l)
I created a new extension ("CategoryIntersection") that allows for
quick lookup of pages (and image) in intersecting categories. That
would enable wiki(m|p)edia sites to use categories as tags,
eliminating the need for oh-so-specialized categories.
Intersection of two categories works very fast, but intersecting more
categories is possible, and already implemented; the maximum number
can be limited.
I tried it on my (mostly empty) MediaWiki test setup, and it works
peachy. However, *I NEED HELP* with
* testing it on a large-scale installation
* integrating it with MediaWiki more tightly (database wrappers, caching, etc.)
* Brionizing the code, so it actually has a chance to be used on
Wikipedia and/or Commons
Techinical notes:
* This was recently discussed on wikitech-l
* More than two intersections are implemented by nesting subqueries
* Hash values are implemented as VARCHAR(32). Could easily switch to
INTEGER if desirable (less storage, faster lookup, but more false
positives)
* The hash values will only give good candidates (pages that *might*
intersect in these categories). The candidates have then to be checked
in a second run, which will have to be optimized; database people to
the front!
* Table to store hash values has to be created manually; SQL is in the main file
* I didn't implement code to fill the table for an existing
installation; however, since hash table updates solely hang on the
LinksUpdate hook, this should be easy
* There is no code covering page moves and deletions yet; do those
hang on LinksUpdate as well?
* SQL queries are currently "plain text" and not constructed through
the DB wrappers; I wan't sure how to do that for the subqueries
Cheers,
Magnus
Hallo WIKImaniac,
wenn Biblelover noch mit abstimmen können soll müsste der Vorschlag noch
heute eingestellt werden (falls es nicht ohnehin zu spät ist) oder erst in 1
1/2 Wochen, wenn er von der Abwesehnheit wieder zurück ist.
Beste Grüße
Hei ber
Hello, wikitech-l(a)wikipedia.org members,
From: Wikipedia user: Namazu-tron
http://en.wikipedia.org/wiki/User:Namazu-tron
This message is a solicit of further consideration of Bugzilla topic #13065
which is WONTFIX as of now.
Please read Bugzulla #13065 and this mail in detail.
https://bugzilla.wikimedia.org/show_bug.cgi?id=13065
Title changed to "13065 Pressing Enter in edit summary should not save the
page".
#13065 and this mail below all story and I still ask or solicit further
consideration for long run of
Wikimedia foundation sites.
As far as title tell every thing, improve or FIX must be taken.
Many Japanese Wikimedia sites user is facing this matter as a problem.
How this is serious problem is depends on user by user, but regardless of
weight of problem feel by each user,
it is a problem even it is small.
Some feel problem is serious.
As a nature of Japanese people, most people hesitates rise a problem for
fundamental Wikimedia sites
user interface designation logic or algorism by program, but many user feel
save page at
edit summery is very inconvenient designation.
You can understand the point I am saying by reading #13065 and all exchanged
message below.
To: wikitech-l(a)lists.wikimedia.org
CC To: Toni Despla
> think the problem is this double function of the Enter key. If you're
>selecting a word, the application shouldn't get a Enter character. How do
>you
>work with Word or Excel? Or better yet, a bare program like notepad. Do you
>need to use backspace after selecting each word? If instead of submitting
>you're previewing, things will only be marginally better. Realoading the
>page
>per word is not going to scale.
>Perhaps you're right and Wikimedia sites shouldn't do anything, and it is a
>bug of your browser. Which one are you using?
In case of Word or Excel, entry within document in value on Excel can be
corrected by back space or
delete key even on Notepad.
Even user make mistake with IME ( Input Method Editor) it is not serious
because it does not affect other party, it is a miss takes within own file
with in his computer.
In case file save into Hard disk, erroneous Enter key press may lead to
wrong file name, but this is still
error within his PC.
In case of Google search,
http://www.google.com/
When as far as "Cursor " placed in a search word entry frame or box, "
Google search" button is shaded and erroneous Enter key hit ( under IME)
goes to search for wrong topics.
Google.com is the same designation to Edit Summary and " save Page" of
Wikipedia.
However, big difference is that Google is just search and user entry DOES
NOT Change the content of Google.
Erroneous Enter key hit in Edit summary on Wikipedia DOES change database
of Wikipedia server without
Show Preview.
To talk on user DOES change or DOES NOT change is a big difference and
Wikipedia and Google is quite different site in user usage.
>From now, I will talk with wikitech-l(a)lists.wikimedia.org as you, Toni
Despla, told me.
Thank you.
Namazu-tron.
----- Original Message -----
From: "Permissions - Wikimedia Commons" <permissions-commons(a)wikimedia.org>
To: "-----" <3tx38k(a)bma.biglobe.ne.jp>
Sent: Tuesday, March 04, 2008 7:53 AM
Subject: Re: [Ticket#2007111110007993] Request or solicit
> Dear 3tx38k,
>
> Thank you for your mail.
>
> 3tx38k(a)bma.biglobe.ne.jp wrote:
>> To Toni Despla
>>
>> 1.
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=13065
>> http://en.wikipedia.org/wiki/Wikipedia_talk:Administrators#Request_layout_c…
>>
>>
>> Thank you for your response.
>> With assumption of you read precisely Bug # 13065
>> up to comment #17,
>>
>> Comment #17 From Brion Vibber 2008-02-27 18:12:12 UTC -------
>> Putting back to WONTFIX. This will not change.
>> " WONTFIX"
>> I understand it as "WILL NOT FIX".
>
> Yes, WONTFIX means that it won't change. Plase note that this action has
> been
> taken by the lead developer. There's a zero probability of the default
> action
> being changed globalwide (maybe personalized solutions could be
> developed).
>
>
>> ==Today's response-1:
>> Above is the current conditions and the subject is on the
>> Village pump as well.
>> However, I am not responding English edition above village pump and
>> Japanese
>> edition village pump, because I simply do not want let people know I am
>> discussing with Bugzilla # 13065
>> where people know my e-mail address.
>
> I am afraid Bugzilla is the proper place to deal with software issues. If
> you
> don't want your email to be shown, you can use a throw away email.
>
>
>
>> ==Today's response-2:
>> Input method editor,Keyboard layout, ATOK, List of input methods for UNIX
>> platforms,
>> CJK characters, Complex text layout,
>>
>> Above are related articles on Wikipedia. The problem is not only
>> Japanese
>> language key entry, but also relates very huge matter on many languages.
>> See also "see Also" of each article.
>>
>> >> As you read latest edition of #13065, this problem is common to all
>> language
>> >> edition.
>> >I know. But also take into account that users not using IME may want to
>> >save
>> >by pressing Enter (as i do).
>>
>> ==Today's response-3:
>> Yes, you said "(as i do)", because it is designed so then you use Enter
>> key
>> in edit summary for save page.
>>
>> Enter in edit summary force save page is designed since Wikipedia and
>> other
>> site opened, I guess.
>>
>> I believe that the point I rise "Pressing Enter in edit summary should
>> not
>> save the page" is
>>
>> may be first time for all web site designers of Wikimedia Foundation,
>> Inc.
>> #13065 , Comment #10 From Huji changed, and the title describes all the
>> thing.
>>
>> ==Today's response-4:
>> You are saying that "Of course, the proper way would be the wiki
>> detecting
>> the input method and adapting for it.".
>> This is very much miss conception.
>> As you understand with "response-2" above, many language may have
>> different
>> "input method Editor" or alike subprogram.
>>
>> With context in talk with you, Wikimedia Foundation, Inc. web site will
>> exist for ever, and world become more global communication with internet,
>> there would be highly possible that new type of "input method Editor" is
>> invented in long long range of future.
>>
>> ( By the way, Japanese [[Kanji]] etc are using two bytes, where English
>> alphabet use one byte.)
>
> It depends on the codification. On Utf-8 Kanji uses 3 octets.
>
>
>> Input Method Editor or similar subprogram is in between keyboard and
>> application program.
>>
>> Wikipedia web site is "application program" just the same to Microsoft
>> "Word" or "Excel".
>>
>> Generally, application software does not need to detect or know wheatear
>> Input Method Editor is feeding input characters after converting it from
>> Keyboard.
>
>> Japanese key board has a particular key and we are use this key to on/off
>> input Method Editor function. When it is off, keyboard works exactly the
>> same to your Keyboard, Input method Editor simply pass through letter,
>> logically.
>>
>> I now explain briefly how Japanese [[Kanji]], for example, made by
>> Keyboard.
>> We type in Kanji pronounce with [[Romaji]], or [[Hiragana]], then press
>> "space key" so, Input Method Editor show up several candidate of
>> corresponding [[Kanji]] pull down list, to advance and point candidate
>> kanji
>> list, we press space key until reach to exact Kanji, then press Enter key
>> to
>> decide matching Kanji.
>>
>> This Japanese writing and editing take place in edit summary as well as
>> article edit.
>> If our writing is mixed with Kanji and English word with alphabet,
>> Enter key decide kanji from pull down list, then particular key is
>> pressed
>> input method editor change mode from on to off, then type English word.
>>
>> In such way, pressing Enter key is two function, that is decide Kanji,
>> and
>> Line feed and delimiter of sentence. During making Japanese sentence
>> with
>> mixed English word, pressing "Enter key" and pressing "key for on/off" is
>> very much lead erroneous operation more that you imagine.
>>
>> I believe such operation and erroneous operation might happen on other
>> language user.
>
> I think the problem is this double function of the Enter key. If you're
> selecting a word, the application shouldn't get a Enter character. How do
> you
> work with Word or Excel? Or better yet, a bare program like notepad. Do
> you
> need to use backspace after selecting each word? If instead of submitting
> you're previewing, things will only be marginally better. Realoading the
> page
> per word is not going to scale.
> Perhaps you're right and Wikimedia sites shouldn't do anything, and it is
> a
> bug of your browser. Which one are you using?
>
>
>
>> From the point of view of less load or lessen storage in server(s)
>> without
>> erroneously edit content, "Show Preview" might be a recommended step
>> rather
>> than go to "save page" right after edit summary entry.
>
> Server storage is not a problem. The web site accesibility IS a problem.
>
>
>> Now, the discussing point is well summarize that as subject "Pressing
>> Enter
>> in edit summary should not save the page" .
>>
>> If web site continued forever, such inconvenience should not continue
>> forever.
>>
>> Think about millions of people will participate to edit the site
>> worldwide,
>> even English or English language like do not use Input Method Editor, the
>> such inconvenience continue forever is not attitude of Wikimedia
>> Foundation,
>> Inc who is back up by donation from world.
>
>
>> Please understand that I am talking with you on e-mail rather than
>> Bugzilla
>> nor Village pump, because the matter is very fundamental position or
>> attitude of Wikimedia Foundation, Inc itself if such condition not
>> improved.
>>
>> There is a good reason if you change NOT to save page by Enter in summary
>> by
>> some change in HTML web site designation, Web site simply mention
>>
>> newly changed that "Recommending Show Preview step, so that save page
>> will
>> not work by enter key in edit summary.
>
> Please note that -as the bottom disclaimer says- i'm am a simply
> volunteer. I
> am not a Foundation employee nor a developer. I also can't decide on this
> matters more than any other user.
> If you want to contact with the mediawiki developers, there's mailing list
> at
> wikitech-l(a)lists.wikimedia.org where you can bring this up (your email
> will be
> shown).
>
>
>> I do not accept "WONTFIX". Fix or not fix is not majority rule; it is
>> just
>> your attitude for user and IP user with various languages.
>>
>> Finally, may I ask you silly question that all above is rise up to
>> Village
>> pump?
>>
>> Thank you. Namazu-tron
>
>
>
>
> Yours sincerely,
> Toni Despla
>
> --
> Wikimedia Commons - http://commons.wikimedia.org
> ---
> Disclaimer: all mail to this address is answered by volunteers, and
> responses
> are not to be considered an official statement of the Wikimedia
> Foundation.
> For official correspondence, please contact the Wikimedia Foundation by
> certified mail at the address listed on http://www.wikimediafoundation.org
>
>
Very glad to hear there is progress on the category intersection front.
A few comments:
1) I hope there are some broad discussions about how to integrate this
into Wikipedia and other projects. Several of us (mostly admins who
focus on categorization) have been discussing this on English Wikipedia
at [[Wikipedia:Category intersection]]. You can also get there with the
shortcut [[WP:CI]]. If we could designate one place to discuss user
interface ideas and designs, that would be helpful.
2) If implementing the intersection of more than 2 categories involves
nesting, it might be fastest if you start with the smallest categories
and continue to process with progressively larger categories. The
intersections of the small categories will result in a small result, and
each pass the result is at most the same number of members and likely
much smaller, so the next intersection might be much faster. If this is
the case, then it would be possible to speed up the servers by requiring
at least one of the intersected categories to be below some set maximum
number of members. Users could get a message that all of the categories
selected were too large. The worst case seems to be the intersection of
only huge categories with very few or no members in common. If you add
a small category to the mix it should be much faster as long as you
start with the small one.
3) If the table structure of categories is going to be redesigned, could
the same or similar structure be used for links? This way we could also
implement link intersections with the same code, and use the wiki-links
that already exist on pages as tags. See [[Wikipedia:Link
intersection]] (shortcut [[WP:LI]]) for more about this.
-- Samuel Wantman
[[en:User:Sam]]
Hi,
My extension, Semantic Forms, changes the URL of certain "broken links" (AKA
red links). Up until now this has been done through a patch to the MediaWiki
code (specifically to the file "/includes/Linker.php"), but I want a real
solution. That is the new 'BrokenLink' I'm suggesting, which would involve
adding a single line to Linker.php. Around line 348, within
makeBrokenLinkObj(), under the line:
$u = $nt->escapeLocalURL( $q );
there would be added added the following:
wfRunHooks( 'BrokenLink', array( $nt, $query, &$u ));
Please let me know if you have any objections to the name of the hook, its
placement or anything else. If there are no responses or objections, I guess
I'll just feel free to add in the code myself (I've never modified MediaWiki
code before, but I suppose there's a first time for everything.)
-Yaron