Hello,
Proberly some of you will flame me, but I will take that for granted.
My idea is to combine all the European language wikipedia's (except english
and maybe spanish and portuguese) on one server and using one database,
located somewhere in Europe.
Here is why:
* We will not be depending on the US anymore.
- As this can be considered a political issue, it is mostly a technical
issue. Because when there are problems, we (Europeans) can solve this on
hours, people in the US are still at sleep. This also includes fixing
things on location.
- Also the performance will not be influenced by the English-language
wikipedia.
Problems:
* Finding a reliable server that is free and only for us.
* Finding European sysadmins for this server.
Which wikipedias:
# Basque (Euskara)
# Bosnian (Bosanski)
# Catalan (Català)
# Czech (?eský)
# Danish (Dansk)
# Dutch (Nederlands)
# Esperanto
# Estonian (Eesti)
# Finnish (Suomi)
# French (Français)
# Frisian (Frysk)
# German (Deutsch)
# Hungarian (Magyar)
# Interlingua
# Irish (Gaeilge)
# Italian (Italiano)
# Latin (Latina)
# Latvian (Latviešu)
# Lithuanian (Lietuviškai)
# Low Saxon (Nedersächsisch)
# Norwegian (Norsk)
# Polish (Polska)
(# Portuguese (Português) <<< Maybe not, because most speakers are living
outside Europe)
# Romanian (Român?)
# Romanica
# Russian (???????)
# Serbocroatian (Srpskohrvatska)
# Slovenian (Slovensko)
(# Spanish (Castellano) <<< Maybe not, because most speakers are living
outside Europe)
# Swedish (Svenska)
# Welsh (Cymraeg)
Cheers,
Jeroenvrp
nl.wikipedia.org
Today I noticed that in the new pages listing, some
titles are acompinied with the name of the first
author,
but the summary written by the last editor.
Is this a bug or an intended behaviour?
AstroNomer
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
Just a couple notes... I set up stub Arabic and Hebrew wikis:
http://ar.wikipedia.org/http://he.wikipedia.org/
When they get set up we'll need right-to-left also for other languages
using these alphabets (Persian, Urdu, Yiddish...)
I've made a few tweaks to help support this... Language::isRTL() should
return true for those requiring right-to-left support, which triggers:
* dir='RTL' attribute on the <html> element
* swap the position of the spacer cell in the topbar/bottombar so it
matches the sidebar
* swap the text alignment of the two cells in the topbar
I've only mucked about with the default skin here; I haven't tested
Cologne Blue yet for instance.
There's a lot of weirdness with punctuation; hopefully localized
interface strings should help make the screen look right. :) Various
portions may need more explicit direction indicators stuck in or other
whatnot.
-- brion vibber (brion @ pobox.com)
[This message has been crossposted from <intlwiki-L> to <wikitech-L>.
Replies should go only to <wikitech-L>.]
Timwi wrote in part:
>In addition to this, however, I would like to point out that it is
>widely considered a bad practice to serve the same content under several
>URLs. Currently I can reach the exact same article by going to any of a
>veritable plethora of URLs:
> http://www.wikipedia.org/w/wiki.phtml?title=Dextrose
> http://www.wikipedia.org/w/wiki.phtml?title=Glucose
> http://www.wikipedia.org/wiki/Dextrose
> http://www.wikipedia.org/wiki/Glucose
> http://www.wikipedia.org/w/wiki.phtml?search=dextrose&go=Go
> http://www.wikipedia.org/w/wiki.phtml?search=glucose&go=Go
>plus several different capitalisations of the latter two. Those latter
>two I find particularly disturbing. People will link to them and trigger
>the Search algorithm for every visitor, which generates an unnecessary
>impact on the database server. Plus, the searches may not return the
>same article indefinitely.
I think that we want to consider the purpose of the differences.
You've already mentioned the purpose of "Dextrose"/"Glucose";
it's to give us the redirection information. So that's OK.
I see no purpose to the "search" URIs, so I agree that they should redirect;
and in addition to your point about activating the search algorithm,
also note that the algorithm might not even give the same page next time!
(Don't confuse the two sorts of redirection here:
Wikipedia redirection and HTTP redirection.
I just mentioned both of these in that order.)
Another URI variation that you just barely missed
is capitalisation among the /non/-search URIs --
this serves no purpose under our page capitalisation scheme,
so they should probably redirect to capitalised URIs too.
Then there's the difference between "/w/wiki.phtml?title=" and "/wiki/".
AFAICT, the only purpose of this is to have robots index "/wiki/" URIs,
since "/w/" URIs are set to be unindexed in our <robots.txt> file.
(Those that understand these things will hopefully confirm if I'm right.)
Then I agree with your solution; "/w/wiki.phtml?title=..."
should redirect to "/wiki/..." if no ampersands appear in the ellipsis --
and this could conceivably even increase robots' indexing of our pages.
-- Toby
Someone found another typo, therefore I made a new update.
Brion, to get the status to a well known point, if the article count don't
go below 20000 if we change to the new one, I think we should switch. I
don't know if you can take a look, without changing it.
Than, as far as I know, we should be on the same patch level in en and de.
--
Smurf
smurf(a)AdamAnt.mud.de
------------------------- Anthill inside! ---------------------------
On the Recentchanges page, if a contributor isn't logged in, you can
click on their IP number to see what changes they have made previously.
I suggest putting a link on the IP's contributions page so you can see
the contributions from the entire Class C subnet. If someone is hopping
around from IP to IP, this should make it much easier to observe their
pattern of behavior, and revert their edits.
Just putting that out there; good luck with your Wikipedia project.
Jonathan
--
It's not true unless it makes you laugh,
but you don't understand it until it makes you weep.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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
I User:Stevertigo formally request
sysop/admin/developer level access to the Arabic
Wikipedia. Among the first issues would be to deal
with the encoding there. UTF-8 or 1256 are
canditates, but it would require some proper testing.
My Arabic is very limited, though, and hopefully some
changes ought give some life and perhaps credibility
to the Ar.Wikipedia.
I User:Stevertigo formally request sysop/admin
developer level access to the Simple Enlgish Wikpedia.
Among the first issues would be to deal with finding
a use for the simple. Wikipedia -- among my proposals
(
http://simple.wikipedia.com/wiki.cgi?SEnpl_For_Translation
)
is the possiblitly of using simple English as a base
for translating the vast catalog of English articles
to other languages. By allowing the Simple Wikipedia
to act as a kind of firewall, sandbox, embassy... any
problems arising from the perception that non-English
speakers and English
speakers have of each other, will be mitigated.
If interested, please see the recent changes made to
the Simple.wikipedia -- http://simple.wikipedia.com
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
Sofware changes for Fascile Translation on the
Wikipedia (International)
1. Wikisoftware upgrade for the Simple English
Wikipedia.
2. Means to siphon English wikipedia database to the
Simple English database.
3. Application to facilitat translation from the
English WP to the Simple English WP.
4. Download WKP format textfiles link on each article.
Comment: Some of the recent discussions among the
various mailing lists deal with the
compartmentalization factor of the Wikipedia -- that
language borders represent too much of a relative
challenge to allow for cross-language interest.
Speaking personally, I would do more translation if it
the software were set up to make it easier, so I
simply wouldnt feel alone in doing it.
In a sense, WP's strong English showing in terms of
article count (relative to non-En langa) is like a
pillar -- one that is increasingly tall, and
increasingly narrow. It's somewhat reminicent of the
saying ( from "Dune Messiah"):
"Here lies a toppled God
His fall was not a small one
We did but build his pedestal
A narrow and a tall one."
Most of us here deal with English as a common language
-- and the Goal is to increase the number of
inter-language "ambassadors" and hence, the number of
non-English speakers. By these ambassadors, and by
improving the synergy between discussion groups,
article writing, etc. -- The rules of the Wikipedia --
that its attempts to institute controls over the
processes of the Wikipedia, can then be better
disseminated and debated.
Language problems are really problems of
communication, as such can be rectified somwhat by
simplifying communication (not over-simpifying) by
allowing the Simple English WP to take the place of
the English WP as the center of international content.
Generally, it would be proper to simply stipulate that
the English Wikipedia should have a great deal of
leeway in terms of its rules, but since a great many
non-native English speakers can potentially want to
contribute and use English articles, it becomes
necessary to have a sandbox of sorts, to allow for
crude-English seeding of articles, and to port the
English WP to other languages. In the linguistic
sense, a simplified English language should serve
quite well as a "transformative grammar" -- Chomsky's
(now semi-depricated) description of an innate,
baseline natural language. In the internationalist
sense, this would be a key step toward increasing WP's
international appeal.
Reason -- to use the Simple English WP as a "pure
language" base - from which a broader range of people
can translate the populous English articles to other
languages.
A translation from say, Chinese to simple English, and
then edited, would be far easier to do than if normal
gramatical standards werent necessary. Hence, the
real purpose for a Simple Wikipedia is not to "teach
English", (as it until-recently stated) rather to
allow non-English speakers to deal with articles in
English, as well as make it possible to contribute to
them.
*Allow for a simple "port"( like "move page")
functions from the English WP to the Simple WP - (from
Simple to English only if English article doesnt
exist)
* Conversion from English to Simple English (SEmpl?)
should parse language (pw placing wrappers around
unknown terms, and if possible (as announced in some
translation attempts) to , etc.
*Problems: Redundancy/loss of information/increased
rates of poor translation.
These are all fixable. The point is to generate more
interest, and increase cross-langa communication, with
the help of a base. Simple English may not be a
theoretical ideal for this purpose, but it may be the
only practical choice.
*Requirements: Perhaps, a unified User:name system.
One name carries over all WikiMedia sites. -- This
allows at least a crossover ability to register Edits,
ports and
*Related page activity -- Since each article, though
by a new name, has some relation to activity of that
article accross lingustic lines, it should be
facilitated that each article should have a listed
cross-langa database function --( I know the DB dont
work this way now.) The current DIY langa links are an
obstacle -- for each language, be there a page or not,
there should be a link from each page, and tools to
send text to the Simple English version. It makes
sense to have this be done page by page -- not
altogether blanket automated from the English WP,
though Im sure we can all agree that the current
software doesnt help this kind of thing out at all.
Client(editing/concordancing/uploading)
The translation of an English Wikipage ideally could
be helped via a fully functional editing client, and
text highlighting could be a part --as in the VIM
Wikipedia Schema -- though Keynote might also be a
good choice client if implemented correctly. Adding
concordancing ability to this client would save yet
another step the goal of cross-pollenation of
articles.
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
Hi,
Please look into problems on the the Polish Wikipedia urgently.
Saving newly created articles results in:
Wystąpił błąd składni w zapytaniu do bazy danych. Ostatnie, nieudane
zapytanie to: "INSERT INTO cur
(cur_namespace,cur_title,cur_text,cur_comment,cur_user,cur_timestamp,c
ur_minor_edit,cur_counter,cur_restrictions,cur_user_text,cur_is_redire
ct,cur_is_new,cur_random,cur_touched,inverse_timestamp) VALUES
(0,'Antropopresja', '\'\'\'Antropopresją\'\'\' określa się ogół
planowych i nieplanowych działań człowieka, wywołujących określone
zmiany w [[przyroda|przyrodzie]]. Współcześnie określenie to akcentuje
wpływ niekorzystny, utrudniający prawidłowy rozwój ekosystemów. Zobacz
też: [[podstawowe zagadnienia związane z ekologią]].', 'Nowy art',
'4', '20030708104855', 0, 0, '', 'Kpjas', 0, 1, 0,616858519435,
'20030708104855', '79969291895144')" wywołane zostało przez funkcję
"Article::insertNewArticle". MySQL zgłosił błąd "1136: Column count
doesn't match value count at row 1".
Thanks.
Regards,
Kpjas.
Hello,
this will be usually something for Brion:
Since the update the german sysop's can't access the DB using the
AskSQL-page. All tested table-queries results in the error:
1142: select command denied to user: 'sqluser(a)localhost.localdomain' for
table 'cur' (cur is an exaample, old, user etc. don't work too.
Posible errors: AskSQL uses the wrong user, or the tables missing rights
for that user.
PS: sorry for reporting so late, but I thought after the update, the Asksql
was blocked for reducing server load.
--
Smurf
smurf(a)AdamAnt.mud.de
------------------------- Anthill inside! ---------------------------