Wikitech-l

wikitech-l@lists.wikimedia.org

25 participants
23118 discussions

New diff engine from phpwiki
by Axel Boldt 12 Mar '02

12 Mar '02

I just checked in a new diff engine from phpwiki 1.3.3 (GPL). It can display diffs line by line and highlight the changed words. I also added a diff display to the edit conflict screen. I'm very impressed with the phpwiki project. They are also working on internationalization issues; I think we could do far worse than check out what they have come up with. Axel

3 2

Re: [Intlwiki-l] More translation issues, preliminary version of wikiTextPl.php
by Brion L. VIBBER 11 Mar '02

11 Mar '02

On dim, 2002-03-10 at 09:54, Jimmy Wales wrote: > pl.wikipedia.com > > How about I set this up on Monday? Do I need a new conversion script? I'll need to tweak the conversion script to convert the Latin-2 database to UTF-8, and drop in a quick fix to make searching work on non-ASCII words. Shouldn't be hard, I'll drop a note when it's checked in. The full set of encoding-related changes to the code still need to be determined and made, but if we start it off using UTF-8, the database should be ready. (Also, we may need to rebuild the search index later, as that part of the code may still change. But then this is the case if we change the mysql indexing anyway.) > I believe that this is best: > > 1. I set up pl2.wikipedia.com as the "beta test" Polish wikipedia, > and import the existing data from pl.wikipedia.com using a conversion > script. > > 2. We run this for one week, inviting as many Polish speakers as we > can find to test it, incorporating bug fixes all week as quickly as > they come in. > > 3. The following Monday, I make the conversion "for real". Sounds good to me. Can we commit to such a schedule for Esperanto as well? We've only put it off so far because we were going to change the database internals, but since we seem to have decided on UTF-8 it's not a problem to convert ASAP and make the changes later. > I'd like to follow up with Spanish and Esperanto as quickly as possible. FYI, I currently have a beta running the converted Esperanto wiki at http://leukas.dyndns.org/wiki/ . A more officialish server wouldn't hurt though, as this is limited to the reliability of my DSL line. -- brion vibber (brion @ pobox.com)

1 0

Re: whitespace in search
by Axel Boldt 11 Mar '02

11 Mar '02

>Still, what if there are legitimate >2 letter searches, like for "Ur" as someone else pointed out? The only way to make mysql index shorter words is by recompiling and setting MIN_WORD_LEN to a different number. They claim that changing this variable from the current value of 4 to 0 will enlarge the index by a factor of 20. So maybe we should go with 2. After that, the indexes have to be rebuilt. Axel

2 1

English monolinguals
by Chuck Smith 11 Mar '02

11 Mar '02

> > The English wikipedia isn't just for English > monolinguals, is it? > > Is this the new politically correct term for > Americans? :-) Sí, tienes razón. Ja, du bist richtig. Jes, vi pravas. Chuck :) ===== Come to my homepage! Venu al mia hejmpagxo! http://amuzulo.babil.komputilo.org/ ==== Venu al la senpaga, libera enciklopedio esperanta reta! http://eo.wikipedia.com/ _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com

1 0

Re: [Intlwiki-l] PHP script internationalization issues
by Tomasz Wegrzanowski 10 Mar '02

10 Mar '02

On Sun, Mar 10, 2002 at 03:11:02PM +0000, Joao M?rio Miranda wrote: > Tomasz Wegrzanowski wrote: > > 3) There are problems with interwiki links. If Polish article title contain > > non-ascii characters, I can't easily link it using [[pl:Name]]. > > I have the same problem with the portuguese wkipedia. I can't > link to [[pt:portugu?s]]. You can link by %-escapes (which you can copy from URL). This method sucks but is the only way until we all adopt UTF-8. I strongly recommend setting all non-English Wikipedias to UTF-8 on transition to PHP script, regardless of whatever encoding is currently most popular for your languages. I also think that English Wikipedia should move to UTF-8.

1 0

whitespace in search
by Lars Aronsson 10 Mar '02

10 Mar '02

If I search for "van eyck" (with the whitespace, but sans the quotes), I get an ugly error message. Searching for "eyck" actually solves my particular problem for the moment, but the error message is still ugly. Is it really such a crime to want to search for a string that includes the whitespace? Perhaps this could be explained somewhat more politely? Also, if I search for "van\ eyck", the error message comes up and the input box contains "van\\ eyck". Maybe there is a potential risk for a buffer overrun or something more exotic here? I think the input string should be quoted before being used in a regexp search. -- Lars Aronsson <lars(a)aronsson.se> tel +46-70-7891609 http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/

5 6

Re: whitespace in search
by Axel Boldt 10 Mar '02

10 Mar '02

Jimbo, the tricks that you mention (weighing titles more than text, weighing rare words more than common ones, stopwords etc.) are already used by mysql's fulltext index; I don't think it would make sense to reinvent the wheel, especially since we now have real-time searching and boolean searches, both of which are kind of nice. I am also pretty sure that the mysql index is reasonably fast, being written in C. They explain a bit about it at http://www.mysql.com/doc/F/u/Fulltext_Search.html Regarding the three letter limit: since we right now already parse the search string for AND, OR and NOT anyway, it should be pretty easy to remove short words from the search string, start the query without them, and then later report the results with a warning like The short word "the" was ignored. Axel

2 1

Feature request: Kana entities
by Tomasz Wegrzanowski 10 Mar '02

10 Mar '02

This feature should be easy to do. Unfortunately my PHP knowledge is limited, so I think it will be better if I just ask for it instead of trying to do it myself :) Using japanese characters in non-japanese wikipedias is currently hard. One have to write them as &#xHEXCODE; or &#DECIMALCODE; I think that it would be much better if parser were able to parse fake kana (at least basic kana, full kanji would be much more work) &entities; and convert them to numeric codes. So one can write &hiragana_wa; or &katakana_chi; This isn't likely to conflict with anything. Kana Unicode table (in "English") is on http://pl.wikipedia.com/wiki.cgi?Kana Entities that would be needed: * Full hiragana ぁ to ゔ * Full katakana ァ to ヺ * Prolongation mark ー Proposed names: * &hiragana_x; &hiragana_smallx; * &katakana_x; &katakana_smallx; * &kana_long; I also think that it might be good idea to extend it to other writing sytems in the future. Is it possible ?

4 15

PHP script internationalization issues
by Tomasz Wegrzanowski 10 Mar '02

10 Mar '02

I have found some problems with this script. 1) Print footer ("This article is from Wikipedia (URL), the free online encyclopedia. You can find this article at URL") is in wikiPage.php and it should be in wikiText*.php That is it should be internationalizable. 2) The same word is used for names of languages and names of non-English Wikipedias. That's wrong for Polish because "language" is masculine but "Wikipedia" is feminine, so the word should be different ("polski" and "polska"). 3) There are problems with interwiki links. If Polish article title contain non-ascii characters, I can't easily link it using [[pl:Name]]. The "right" solution is of course using UTF-8 for all wikipedias. We will have to do it some day, as not doing it is causing more problems than it saves. But that's not an urgent issue.

1 0

Short word searches
by kband＠www.llamacom.com 10 Mar '02

10 Mar '02

As someone has previously pointed out, short word searches (such as Ur and Oz) are important. There shouldn't be a letter minimum, if at all possible. We should probably use google as a good guide for usability standards. Google lets you search for single letters, for example. I understand there may be technical difficulties in reducing the minimum, but we should consider it a flaw if we have a four-letter minimum, or even a three-letter or two-letter minimum. I've cc'ed wikipedia-l because this is a policy discussion as much as a technical discussion. --tc

1 0

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