Wikipedia Diskussion:WikiProjekt Vorlagenauswertung/Archiv/2007

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia Diskussion:WikiProjekt Vorlagenauswertung/Archiv/2007#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_Vorlagenauswertung/Archiv/2007#Thema_1

Anzahl in der Liste

Hab gerade die alphabetische Liste aufgerufen. Da steht bei Infobox Bibliothek 37 und man denkt, das es 37 Bibliothekten gibt. Dann rufe ich die Detailtabelle auf, und es sind nur 10 Zeilen (also 10 Bibos drin) aber 37 Zellen sind gefüllt. Tim, kannst du den Zähler in der Hauptliste ändern, oder eine entsprechende Tabellenüberschrift setzen. Danke! -- sk 10:49, 16. Mär. 2007 (CET)

Wie du dir wahrscheinlich schon denkst, ist die 37 die Anzahl der eingetragenen Variablen. Ich werde die Überschrift auf der Hauptliste wohl in "Entries" oder "Values" umbenennen, denn ein Auszählen der Artikel erscheint mir aus Performance-Gründen eher nicht umsetzbar. Kolossos 11:55, 16. Mär. 2007 (CET)

Müsste doch einfacher umsetzbar sein, man muss doch nur die Feld Nr.0 der jeweiligen Vorlage zusammenzählen. Oder hab ist das schon zu Performance-lastig? -- sk 12:50, 16. Mär. 2007 (CET)

Habs so gemacht, wäre auf die Idee im Moment garnicht gekommen. Kolossos 19:08, 16. Mär. 2007 (CET)

Einbindung mal mit und mal ohne "Vorlage:"

Mir ist gerade aufgefallen, dass die "Vorlage:Alte Rechtschreibung" mal als {{Vorlage:Alte Rechtschreibung}} und mal als {{Alte Rechtschreibung}} eingebunden wird. Das sollten wir in einen Topf werden. Am besten in der Datenbank durch ersetzen vereinheitlichen. -- sk 11:07, 16. Mär. 2007 (CET)

Das beste wäre es, wenn du das bei der Erstellung deiner CSV schon wegstripen könntest. Mir war auch aufgefallen, dass "_" durch " " ersetzt werden könnte. Vorallem ist oftmals am Ende eines Vorlagennames noch eine verschiedene Anzahl an Leerzeichen unser Problem.

So liefert:

http://tools.wikimedia.de/~kolossos/templatetiger/tt-table4.php?template=Infobox%20Film%20&lang=de&where=&is= 486 Ergebnisse

http://tools.wikimedia.de/~kolossos/templatetiger/tt-table4.php?template=Infobox%20Film&lang=de&where=&is= 3491 Ergebnisse und erst

wenn man MySQL mit einer Wildcard:

http://tools.wikimedia.de/~kolossos/templatetiger/tt-table4.php?template=Infobox%20Film%&lang=de&where=&is= austrickst, bekommt man alle 3979 Ergebbnisse. Da eine Vorlage aber beliebig weiter gehen könnte, wäre das sauberste das wegnehmen dieser Leerstellen schon in der CSV. Für müssen also Aufgrund des toleranten Parsers wohl noch etwas nachbessern. Kolossos 11:55, 16. Mär. 2007 (CET)

Ok, hab die Leerstellenproblematik durch die Verwendung von RTRIM bis zur Herausgabe eines neuen Datensatzes erstmal gefixt. Aus Geschwindigeitsgründen sollten wir das dann aber wieder rausnehmen. Kolossos 12:18, 16. Mär. 2007 (CET)

Ok, ich bau das gerade mal mit ein. -- sk 14:53, 16. Mär. 2007 (CET)

Habs eingebaut, kann aber gerade nicht auf die Dumps zugreifen. Scheinbar ist funktioniert der mount gerade nicht. -- sk 15:00, 16. Mär. 2007 (CET)

Anregungen

Interessantes Tool, danke dafür - allerdings fehlt mir eine wichtige Info: mit welchem Datenbestand wird gearbeitet? Wenn ich die Beschreibung richtig lese, dann ist es vermutlich der aktuelle Dump vom 7.2. - eine kurze Infozeile wäre allerdings nicht schlecht. -- srb ^♋ 12:21, 16. Mär. 2007 (CET)

Es ist glaube ich der Dump vom 24. Januar 2007, aber ich kann es gerade nicht nachprüfen. -- sk 12:47, 16. Mär. 2007 (CET)

Habs gerade überprüft, es ist der Dump vom 24. Januar 2007. -- sk 15:02, 16. Mär. 2007 (CET)

Vorschlag: könntet ihr nicht den Abschnitt 'Sprachen' auf der Projektseite hier durch eine kleine Tabelle ersetzen, in der ihr die vorliegenden Dumps mitsamt dem Datum ihrer Erstellung listet? Das wäre für die Nutzung tatsächlich ein interessanter Hinweis.--Hk kng 16:55, 24. Apr. 2007 (CEST)

Gerne! -- sk 18:39, 24. Apr. 2007 (CEST)

...jetzt steht en zweimal drin, aber de fehlt...--Hk kng 19:00, 24. Apr. 2007 (CEST)

Fehler vom Amt! :-) Kolossos hat es gerade berichtigt. -- sk 22:00, 24. Apr. 2007 (CEST)

Andere Projekte

Was muss ich machen, damit auch der Dump der plattdeutschen Wikipedia ausgewertet wird? --::Slomox:: >< 13:32, 16. Mär. 2007 (CET)

10.000 Trillionen Euro spenden! ;-) Nein, nix musst du machen! Das Skript läuft derzeit nur bei den allergrößten Dumps durch, die für das WP:GEO interessant sind (en,de,cs,es,ru,fr,fi,pt). Ich hab das Skript aber so angepasst, dass es auch für andere Sprachen laufen kann. Ich denke wir merzen erst einmal die Kinderkrankheiten aus, und dann machen wir mit den anderen Sprachen weiter. -- sk 13:44, 16. Mär. 2007 (CET)

Dann muss ich wohl mal mein Sparschwein schlachten und zählen, ob es reicht ;-)

Ist die Aufnahme zusätzlicher Projekte denn sehr konfigurationsaufwändig? Der zusätzliche Rechenaufwand von vielleicht 0,1 Promille wird wohl kein Problem sein. --::Slomox:: >< 14:03, 16. Mär. 2007 (CET)

Ich werde es mal nds auf den Toolserver downloaden und druchrödeln lassen. Wenn Tim dann Lust hat, kann er es mit einbauen. Sehr aufwendig bei der Datenextraktion ist es sicherlich nicht. -- sk 14:41, 16. Mär. 2007 (CET)

Hmm, also ich kriegs gerade nicht auf die schnelle nicht hin, weil am Toolserver eine Verbindung zu dem Verzeichnis, in dem die Dumps gelagert werden nicht klappt (Meist kurzzeitiges Problem). -- sk 14:51, 16. Mär. 2007 (CET)

Ersten, scheint der Toolserver im Moment etwas "bugy" zu sein, so dass es wohl das beste ist, erstmal nicht zu machen. Zweitens hoffe ich, was die Unterstützung kleinerer Sprachen angeht, dass sich jemand findet, der die Funktion in den Parser des Mediawikis integriert, der Parser muß Vorlagen sowieso auswerten und die Dimensionen der Tabelle sind im Verhältnis z.B. zu den Linktabellen gering. Dann hätten wir auch nahezu Echtzeitdaten und sogar ein Editieren wie bei einer Tabellenkalkulation erschiene möglich. Sobald die anderen großen Sprachen im System drin sind, kriegen wir auf jeden Fall Plattdeutsch auch hin. Schließlich mag ich diese Sprache aufgrund ihres hohen Unterhaltungswertes, welcher für mich nur noch von Pennsilfaanisch Deitsch übertroffen wird. ;-) Kolossos 10:15, 18. Mär. 2007 (CET)

Done. http://tools.wikimedia.de/~kolossos/templatetiger/template-choice.php?lang=nds Kolossos 16:15, 9. Apr. 2007 (CEST)

Ja geil!

Kennt ihr http://dbpedia.org/ ? Los, zusammenarbeiten! :-) -- Nichtich 15:51, 16. Mär. 2007 (CET)

Kannte ich noch nicht. Scheint ebenso so ähnlich zu arbeiten. -- sk 16:10, 16. Mär. 2007 (CET)

Soweit ich das überschauen kann, haben die aber nur die englischsprachige Wikipedia genutzt. Wir wollen in Zukunft aber auch die anderen Sprachen mit einbinden. Derzeit werden schon alle beim WP:GEO unterstützten Sprachen gefilter, aber halt nur "de" hier angezeigt. --

Hallo, ich bin einer der Entwickler von dbpedia.org. dbpedia nutzt zur Template-Extraktion zurzeit nur die englische Wikipedia, das ist richtig. Eine Ausnahme bildet das PersonenDaten-Template, hier verwenden wir die deutsche Wikipedia, da hier viel mehr Daten vorhanden sind. Gerne möchten wir mit anderen an der Thematik Interessierten zusammenarbeiten. Unser Code ist Open-Source, und jeder ist herzlich eingeladen mitzuwirken. Wir haben auch eine Mailingliste (Tim kennt sie schon ;) ), auf der gerne mitdiskutiert werden kann. Der Link findet sich auf unserer Homepage http://dbpedia.org . Viele Grüße aus Berlin, Georgi Kobilarov, dbpedia.org -- Georgi Kobilarov 18:20, 27. Mär. 2007 (CET)

Daten als Download

Hallo, 1.) wo kriege ich die hier erwähnte Tabelle her? 2.) Auf der Downloadseite der Dumps ist sie nicht zu finden? 3.) Wie groß ist die denn? 4.) Habt ihr die Daten direkt aus dem Wikicode in der Tabelle 'text' extrahiert, oder wie werden die Vorlagen erfasst? Maziminke 00:08, 26. Mär. 2007 (CEST)

zu 1) Die Daten sind in der Datenbank von Kolossos. Frag ihn mal, wie man da am besten rankommt. Zu 2) Die Daten sind keine offizeller Datensatz der dort abgelegt wird, sondern sozusagen ein zusätzlicher Datensatz. Zu 3) Ziehmlich groß, wenn ich mich nicht täusche waren es 150 MB für die alle Deutschen Vorlagen. Zu 4) Die Vorlagen werdne direkt aus dem Dump ausgelesen. -- sk 01:25, 26. Mär. 2007 (CEST)

Alles klar, besten Dank für die schnelle Info. Maziminke 02:00, 26. Mär. 2007 (CEST)

Stefans CSV-Datei hab ich auf ca. 32 MB gepackt und stelle diese unter http://tools.wikimedia.de/~kolossos/templatetiger/coordinates_de_templates.txt.gz zur Verfügung. (Aktualität: 26.03.07)

CSV ist die schnellste Möglichkeit zum Einfügen in Datenbanken.

LOAD DATA LOCAL INFILE '/home/sk/data/geo/de/coordinates_de_templates.txt' IGNORE INTO TABLE `pub_tt1` 
FIELDS TERMINATED BY '\t' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\\' LINES TERMINATED BY '\n'

Die Tabelle kannst du vorher mit folgendem SQL-Kommando erzeugen:

CREATE TABLE `pub_tt1_de` (
 `lang` varchar(5) NOT NULL,
 `name` varchar(180) NOT NULL,
 `name_id` bigint(20) NOT NULL,
 `tp_nr` bigint(20) NOT NULL,
 `tp_name` varchar(100) NOT NULL,
 `entry_nr` bigint(20) NOT NULL,
 `entry_name` varchar(200) NOT NULL,
 `Value` varchar(900) NOT NULL,
 KEY `lang` (`lang`),
 KEY `name` (`name`),
 KEY `name_id` (`name_id`),
 KEY `tp_nr` (`tp_nr`),
 KEY `tp_name` (`tp_name`),
 KEY `entry_nr` (`entry_nr`),
 KEY `entry_name` (`entry_name`),
 KEY `Value` (`Value`(767)),
 KEY `tp_name_2` (`name`,`tp_name`)
) ENGINE=InnoDB;

Ich hoffe es hilft. Kolossos 20:10, 26. Mär. 2007 (CEST)

Super, danke für diesen Service. Könnt ihr noch ein bißchen was zu den Mechanismen sagen, über die ihr die Vorlagen extrahiert? Ist das einfach nur ein SQL-Statement oder was steckt da noch alles dahinter? Maziminke 20:24, 7. Apr. 2007 (CEST)

Siehe Wikipedia:WikiProjekt_Vorlagenauswertung#Erstellung! Oder was willst du genau noch wissen? -- sk 00:46, 8. Apr. 2007 (CEST)

Ein SQL-Komando hilft uns bei der Extraktion nicht, Stefan tut den Dump parsen. Um zu verstehen wie so was geht, hat mir der Artikel Kellerautomat geholfen, schließlich haben Zeichen wie "|" oder "}" in Abhängigkeit ihrer Position unterschiedliche Bedeutungen für uns. Kolossos 11:25, 8. Apr. 2007 (CEST)

Naja parsen würde ich es nicht nennen. Ich suche nach "{{" und dann nach dem entsprechenden "}}". Problem dabei sind mehrfach verschachtelte Vorlagen {{xyzs{{{{ab}}{{de}}|name=cas{12}as}}. Wenn ich Anfang und Ende gefunden habe, dann wird es aus dem Artikel ausgeschnitten und in die einzelnen Bestandteile zerlegt. -- sk 12:56, 12. Apr. 2007 (CEST)

tolle sache

allgemeines kompliment von mir an Euch, ich bin hingerissen -- W!B: 02:27, 29. Mär. 2007 (CEST)

PS "Nachteile der Verarbeitungsweise" ja, aber genau auf sowas ist Tabellen-Kalkulation spezialisiert, wozu also in das tool hineinstopfen.. ein formular suchmaske -> URL wär eine elegante lösung, müsste sich per UNO leicht in OOo einbetten lassen..

Danke für das Kompliment! Aber die zweite Bemerkung (Nachteile...) verstehe ich nicht. Was genau meinst du? Daten liegen in der Datenbank sehr zerpflückt und werden für die Ausgabe durch das Tool in Tabellenform gebracht. Bei dieser Ausgabe kann man noch ein paar Einschränkungen machen (ab Buchstabe G, alphabetisch, mit Wert XY,..) und dadurch den Toolserver entlasten. Kannst du deine Anmerkung etwas genauer formuliern? -- sk 10:59, 29. Mär. 2007 (CEST)

Das "Nachteile der Verarbeitungsweise" hat er von der Projektseite zitiert, und stammt ursprünglich von mir. Ich wollte damit zum Ausdruck bringen, dass man von unserem Tool nicht alles erwarten darf. So hätten wir z.B. Probleme Personen nach Geburtsdatum zu sortieren, was bei einer sauberen Datenbank kein Problem wäre, nun aber in einer Tabellenkalk. stattfinden muß.

Achso von UNO hab ich noch nie was gehört, wenn läuft könnte man ja mal vermerken wie man sowas macht. Würde mich interessieren. Kolossos 12:54, 29. Mär. 2007 (CEST)

hallo stimmt, war blöd gesagt: ich wollte damit sagen, dass es nicht nötig ist, das als "Nachteil" zu bezeichen, maximal als "Einschränkung", effektiver als "Performance" ("its a feature..") ;) - wozu das rad neu erfinden, es ist ja vorerst nur ein interface zwischen "Datenbank WP" und Datenbankauswertung, für die es zahlreiche spezielisierte Werkzeuge gibt

UNO, eine API-Technologie von Sun, für Makros in SO-Basic geschrieben (analogon zu VB in MS-Office), aber auch Java, Python, C++. ich spreche es aber nur rudimentär.. -- W!B: 16:16, 29. Mär. 2007 (CEST)

mittelfristig ist eine schnittstelle mit Catscan interessant - Catscan kann ja auf vorhandensein einer Vorlage testen, nicht auf deren inhalt. in kombination mit Catscan, CatTree oder CoCat lassen sich dann recht komplexe abfragen erzielen, und die informationen müssten nicht redundant in infobox und im kategoriensystem abgelegt werden, das tät die teil komplexen kategorienbäume sehr entlasten

.. kaum am laufen, schon sonderwünsche des konsumenten ;) -- W!B: 16:16, 29. Mär. 2007 (CEST)

Schon Realität

Kaum hab ich Anfang dieses Monats auf Düsentriebs CatScan Seite bemerkt, wie Toll doch nicht ein Tool zur Vorlagenauswertung wäre, schon ist dieses gemachte Sache! Fantastisch! Mittlerweile habe ich die Hoffnung zunächst aufgegeben, dass so was überhaupt mal möglich sein wird - und siehe da steht es doch schwarz auf weiß im Kurier: Geht doch! Übrigens, eine Bitte: Könntet ihr bei der Auswertung der Vorlage:Infobox Ort in Kroatien nochmal genauer nachsehen was da los ist, ich bekomme ausgerechnet da keine Treffer. Möchte gezielt nach ausständigen Angaben suchen... thx und gute Weiterentwicklung - da lohnt sich die ganze Mühe, Daten für die Wiki zusammenzustellen! :) --Capriccio 16:02, 31. Mär. 2007 (CEST)

Danke für das Lob. Das mit der nicht funktionierenden Vorlage ist uns auch schon aufgefallen, aber wir könne es derzeit noch nicht ändern. Du musst einfach hinter Kroatien im Link noch ein "%" einfügen, dann klappst. (Siehe hier; Siehe auch Diskussion weiter oben Punkt 2) Beim nächsten Update werden soll das behoben sein. Das sind halt Kinderkranheiten! ;-) Wenn dir noch mehr auffällt, einfach hier reinschreiben. -- sk 19:54, 31. Mär. 2007 (CEST)

Danke für den Tipp! Liegt wahrscheinlich auch daran, dass die Parameter in den unterschiedlichen Infoboxen oft an anderer Stelle stehen. Aber echt toll das Teil. Verbesserungsvorschläge gäbs ja en masse. Wie wärs damit, wenn ihr die oberen Tabellenspalten um die "class=sortable" Funktion (oder ähnlich erweitert), sodaß man sofort nach Parametern sortieren kann. Desweiteren wär eine manuelle Begrenzungsoption von auszuspuckenden Daten gut (nicht nur 30 Resultate, aber versteh schon, dass dies alles Kapazitäten benötigt - bestimmt wirds da eine Startseite mit Optionen geben). Zahlen evtl. sofort rechtsbündig formatieren. Schaut auch darauf, dass bei der Ausgabe zumindest die Spalten eine feste Reihenfolge pro Seite einnehmen, sonst komme ich mit Copy/Paste nicht viel weiter. Eine sofortige Export-Funktion aller Ergebnisse per Button in diverse Formate, wie etwa Excel wär da so ne Möglichkeit, die man ins Auge fassen könnte. So, ich lass jetzt aber mal das bemängeln ;). Noch viel Erfolg mit Euren internationalen Plänen - ich werd den TemplateTiger bestimmt noch oft verwenden! :) --Capriccio 18:41, 1. Apr. 2007 (CEST)

Wenn du an den Link z.B. "&limit=200" hängst, bekommst du bis zu 2000 Einträge, dass sollte für die Mehrzahl der Vorlagen erstmal reichen. Das mit der festen Reihenfolge ist schwieriger, da oft fehlerhafte oder unübliche Spaltennamen in einigen Vorlagen vorkommen. Die Datenbank weiß nicht was in einer Vorlage enthalten sein soll, sondern bastelt die Tabelle immer aus den gefundenen Resultaten zusammen. Deshalb weiß es auch nicht ob es eine Zahl oder eine Textfeld ist, woran dann die links- oder rechtsbündigkeit scheitert. Ziel von uns ist ja alle Vorlagen auszugeben und das kann ja niemand pflegen, wenn das nicht automatisiert ist. - Das mit dem Export verstehe nicht! Ist doch auf der Projektseite beschrieben, wie man das direkt in Excel öffnen kann. -- sk 19:15, 1. Apr. 2007 (CEST)

Ah, vielen Dank für die Tipps. Wusste gar nicht, dass Excel eine derartige Funktion besitzt. :) Gruss, --Capriccio 20:12, 1. Apr. 2007 (CEST)

Re Die Datenbank weiß nicht was in einer Vorlage enthalten sein soll: Soweit ich sehen kann, sind doch die Vorlage-Seiten auch im Dump vorhanden. D. h. zumindest prinzipiell sollte es doch möglich sein, durch Parsen dieser Seiten zu destilieren, welche Parameter denn wirklich ausgewertet werden. Ok, ok, das hört sich nach heftigem Programmieraufwand an, aber das potentielle Ergebnis wäre eine zusätzliche Basistabelle, die allen Vorlagen ihre Parameter-Namen zuordnet.

Wenn ich mich nicht sehr irre, und ihr eine Indizierung unterbringen könnt, hättet ihr auch deutliche Performance-Vorteile davon. (Allerdings erkauft mit dem Nachteil, entweder die in 'falschen' Parametern enthaltenen Infos auszusortieren, oder gesonderte Auswertungen dafür schaffen zu müssen.)--Hk kng 16:20, 27. Apr. 2007 (CEST)

Welche Parameter es in einer Vorlage in den verschiedenen Artikeln so gibt herauszubekommen ist nur eine einfache SQL-Abfrage und weder Kunst noch großer Aufwand. Das Sortieren funktioniert ja auch mittlerweile, zumindest alphabetisch. Schwierig ist es jedoch zu ermitteln welchen Typs die Parameterwerte sein könnten, zumal es hier auch zig Schreibweisen gibt (Tausender Punkt, Komma bzw. im engl. Punkt, Einheit( z.B: Meter),...). Somit scheitert ein performantes Sortieren z.B: von Bergen nach ihrer Höhe wohl vorerst.

Ich weiß nicht, ob ich deinen zweiten Absatz richtig verstanden habe. Alles was in Wikipedia:WikiProjekt_Vorlagenauswertung#Datenbank-Layout steht, ist auch indixiert, sonst würde das garnicht in der Geschwindigkeit gehen, schließlich hat die deutsch Version ca. 3 Mio. und die engl. 16 Mio. Datensätze. Kolossos 16:53, 27. Apr. 2007 (CEST)

Bei der Indexierung ist mir tatsächlich ein Denkfehler unterlaufen. Zur Entschuldigung kann ich nur anführen, dass ich heute nachmittag nicht experimentieren konnte, weil zeitweise das Verbindungslimit überschritten war :)

Abfragen ohne Einschränkung der Spalten sehen aber immer noch etwas seltsam aus. Auf jeder Seite erscheinen andere Spalten in einer anderen Reihenfolge. Um das zu bereinigen, wäre eine gesonderte Abrage der Art

SELECT DISTINCT `entry_name`
FROM `pub_tt1_$lang` WHERE (`tp_name` LIKE '$template')

nötig (ohne weitere Einschränkungen), aus der das $bezeichner-Array erzeugt wird und dafür sorgt, dass alle Spalten auf jeder Seite aufgeführt werden.

Die andere Variante wäre eben, nur die Spalten aufzunehmen, die in der Vorlage tatsächlich ausgewertet werden, und dafür direkt aus dem Dump die Vorlage:-Seiten zu untersuchen. Je länger ich darüber nachdenke, desto weniger kann ich allerdings selbst einen praktischen Nutzwert einer solchen Einschränkung erkennen.--Hk kng 22:48, 27. Apr. 2007 (CEST)

Schaut doch mal auf wikipedia.3ba.se

wikipedia.3ba.se ist ein Projekt das Wikipedia Dumps parst, die Vorlagenparameter auswertet, und daraus RDF-Relationen aufbaut, über die man dann Abfragen laufen lassen kann, wie z.B. Film music composer born 1965 (im Augenblick gibt es wohl nur Daten aus der Englischen Wikipedia). Das Projekt läuft an der Uni Leipzig und beteiligt sich an von dbpedia. Ich war letzte Woche mit Benutzer:Mathias Schindler bei den Leuten, klingt sehr interessant (Paper [1]) - die haben übrigens ein großes Interesse daran, Vorlagen so zu gestalten, dass sie besser zu analysieren sind. Klingelt doch mal bei Jens Lehmann an. Ich wered mit dem WikiWord-Projekt in eine ähnliche Richtung gehen, werde mich aber mehr mit Linkstrukturen befassen. -- Duesentrieb ⇌ 22:00, 31. Mär. 2007 (CEST)

Ich hatte bei dbpedia.org zumindest mal auf die Mailingliste gepostet, konkrete Zusammenarbeitsmöglichkeite sehe ich da im Moment allerdings kaum, aber wenn wir unsere Daten zum Download anbieten und die Infoboxen durch bessere Wartungs- und Weiternutzungsmöglichkeiten fördern, sollten allen geholfen sein. Größere Gemeinsamkeiten sehe ich da schon bei den auch aktiven Extension:DynamicPageList, oder wie siehst du das? Mein nächstes kleines Ziel mit Stefan zusammen, ist es erstmal den Service international in den Hauptsprachen anzubieten. Kolossos 09:44, 1. Apr. 2007 (CEST)

Ich habe gerade en:Wikipedia:WikiProject Microformats gefunden - da könntet ihr auch mal anklopfen. Die Dynamic Page List hat soweit ich weiß das Problem, dass sie zwar templates auswerten kann, aber erst, nachdem sie weiß, auf welchen Seite sie gucken soll. Das Filterkriterium kann also nicht im Template stehen. -- Duesentrieb ⇌ 02:42, 4. Apr. 2007 (CEST)

In Microformats hatte ich schonmal geschaut, erscheint mir allerdings immer auf einen Objektyp spezialisiert zu sein, somit ist das wohl eher was für WP:GEO bzw. Personendaten. Achso, du könntest mir einen Gefallen tuen und mal in meinen Sourcecode auf dem Toolserver schauen. Seitdem ich die Anzahl der Einträge in meiner tt-table4.php mittels " SQL_CALC_FOUND_ROWS" bestimme ist die Performance ganz schön runtergegangen, trotzdem möchte ich auf die Information nicht verzichten. Auch die template-choice.php ist nicht gerade die schnellste. Vielleicht hast du ja eine Idee. Kolossos 20:33, 4. Apr. 2007 (CEST)

Seitdem RTRIM aus dem Programm wieder raus ist, geht es schon wieder deutlich schneller. Kolossos 22:01, 12. Apr. 2007 (CEST)

Fehler abfangen

Das Ergebnis dieser Abfrage ist offensichtlich leer, daher wäre es schön, anstelle der PHP-Fehlermeldung einen entsprechenden Hinweis auszugeben. Grüße, --CyRoXX ^(? ±) 16:17, 22. Apr. 2007 (CEST)

Erledigt. Danke für den Hinweis, manchmal muß man mich treten. Kolossos 19:03, 26. Apr. 2007 (CEST)

GUI für Templatetiger

Hallo! Ich habe mir erlaubt, eine kleine Eingabemaske für das (tolle) Templatetigertool aufzusetzen. Diese kann gerne übernommen und adaptiert werden.

Zu finden ist diese unter http://tools.wikimedia.de/~rhodo/tigergui/

Auch bin ich bei weiteren Entwicklungsfragen gerne bereit zu helfen. Gruß, --Rhodo ^Busch 23:10, 8. Mai 2007 (CEST)

Super. Werde ich mir gleich mal anschauen. --sk 08:12, 9. Mai 2007 (CEST)

Zwei Tippfehler "Regulürer Ausdruck" und "Spaltenäberschrift" :-) -- sk 08:13, 9. Mai 2007 (CEST)

Auch von mir ein Super. Wünschenswert wäre noch ein mehrstufiges Verfahren mit Datenbankanbindung, um so die Vorlagefelder bzw. das Suchfeld bequem nur noch auswählen zu müssen. Dazu natürlich noch ein mehrsprachiges oder ggf. zumindest ein engl. Interface. Über die DB-Anbindung können wir ja nochmal sprechen, ggf. DaB. ansprechen damit du Zugriff bekommst. Kolossos 08:52, 9. Mai 2007 (CEST)

Das mit der Spaltenauswahl hatte ich mir auch schon überlegt. Ich hatte die Maske in HTML geschrieben, da ich keine Interaktionsmöglichkeiten mit der DB hatte. Wenn das für Dich/Euch OK ist, dann frage ich DaB. nach Zugriffsmöglichkeiten.

Ich habe Umlaute eingekauft und verteilt. Gruß, --Rhodo ^Busch

Na klar, lesend könnte DaB. die Datenbanktabellen sogar meinetwegen für alle freigeben, auch die Geodatentabelle "pub_CSV_test3". Kolossos 18:03, 9. Mai 2007 (CEST)

Ich habe dem User rhodo das Leserecht auf allen Tabellen des Users Kolossos wie gewünscht gegeben. --DaB. 00:15, 11. Mai 2007 (CEST)

Super, danke. Kolossos 08:35, 11. Mai 2007 (CEST)

@Rhodo: ICh könnte mir das durch aus so vorstellen, dass deine zweite Formulartabelle auch von meinem template-choice.php per Link aufgerufen würde, dann könnten DB-basiert die Auswahlmöglichkeiten des Suchfeldes und "Sortierung nach Spaltenüberschrift" ausgefühlt werden. Für die "Anzuzeigenden Spalten" hab ich mal meinen Neffen mal in die Spur geschickt, ich könnte mir das im Prinzip wie folgt vorstellen: http://tools.wikimedia.de/~kolossos/templatetiger/form1.html damit sollten Mehrfachauswahlen möglich sein. Und viel mehr wird man garnicht brauchen. Kolossos 10:42, 12. Mai 2007 (CEST)

Bug-Meldungen und Feature-Wünsche

Ein Hoch auf den Programmierer. Ich bin total hin und weg. Und ich habe auch schon die erste Frage: Ist es irgendwie hinzukriegen, dass man case-sensitive Anfragen (vgl. MySQL-Manual) formulieren kann? --TM 23:44, 4. Jul. 2007 (CEST)

Danke! Die Frage muss ich an Kolossos weiterreichen. -- sk 23:56, 6. Jul. 2007 (CEST)

Kannst du die Nutzungsmöglichkeiten etwas näher beschreiben, also welche Vorteile du dir konkret erhoffst. Ich möchte das Skript nicht unnötig verkomplizieren, kann es aber gerne versuchen, wenn ich die Nutzungsmöglichkeiten z.B. durch ein konkretes Beispiel verstehe. Ansonsten gibt es ja noch die Möglichkeit die Ergebnisse in einer Tabellenkalkulation nachzubearbeiten. Kolossos 11:28, 7. Jul. 2007 (CEST)

Ein Beispiel wäre die Suche nach ungültigen LOCODEs. Aber selbst da ist die Groß/Kleinschreibung von völlig untergeordneter Bedeutung. Also wenn du meinst, dass sich die Verkomplizierung des Skriptes nicht lohnt, muss es nicht sein.

Eine andere Frage: Wie oft werden die Daten im Augenblick aktualisiert? --TM 15:05, 8. Jul. 2007 (CEST)

Die Aktualisierung ist doch recht Rechenzeitaufwändig, so dauerte das einspielen der englischen Daten 5h 50min, also wird es die Aktualisierung wohl aller 2-4 Monate geben. Kolossos 15:54, 8. Jul. 2007 (CEST)

Und natürlich abhängig von der Verfügbarkeit eines Dumps. Für EN gibt es z.B. nur sehr selten funktionierende Dumps. Der letzte ist vom 30. Mai 2007. -- sk 15:01, 9. Jul. 2007 (CEST)

Ich denke, ich habe einen kleinen Bug gefunden. In dieser Beispielanfrage funktioniert das Weiterblättern nicht. --TM 14:26, 9. Jul. 2007 (CEST)

Der Fehler war etwas tricky , da in "&not=yes" das &not als Sondernegierungszeichen ¬ gesehen wird, ich wandle es jetzt in "&NOT=yes" um. Kolossos 21:25, 9. Jul. 2007 (CEST)

Hoppla, du hast Recht. Aber standardkonformer wäre, alle &-Zeichen innerhalb des href-Attributs als & zu schreiben. Also einfach noch ein htmlspecialchars() spendieren. --TM 11:16, 10. Jul. 2007 (CEST)

Ein weiteres kleines Problem betrifft die Handhabung von Umlauten. Dein Skript wandelt einige der übergebenen Werte noch einmal in UTF-8 um, obwohl der Browser sie schon als UTF-8 gesendet hat (Beispiel). Die beste Lösung wäre meiner Meinung nach, konsequent auf die UTF-8-Kodierung des Browsers zu setzen und die beiden utf8_encode() aus dem PHP-Quelltext zu entfernen. --TM 12:21, 10. Jul. 2007 (CEST)

Habs mal übernommen und es scheint zu laufen. Hab ichs schon gesagt, dass ich mit Sonderzeichen auf Kriegsfuß stehe? Für dein Hilfsformular, gebe ich dir das selbe Angebot wie schon unter #GUI für Templatetiger, da wir es mit DB-Anbindung und entsprechenden Auswahlfelder wohl noch Benutzerfreundlicher hingekommen könnten. Oder kann ich mir dein Skript zur Weiterentwicklung "schnappen"? Einen Toolserver-Account scheinst du ja leider noch nicht zu haben. Kolossos 19:52, 10. Jul. 2007 (CEST)

Parameter-Abfrage

Die neue Parameter-Abfrage ist großartig. Vielen Dank dafür. Ich habe gleich eine weitere Frage: Geht auch eine Negativ-Suche? Die Vorlage:Infobox Nationalpark wird 289x verwendet, davon 285 mal mit einem Aufmacher-Foto. Jetzt wüsste ich natürlich gerne welche fünf Artikel noch kein prominent plaziertes Bild haben. --h-stt !? 20:18, 19. Aug. 2007 (CEST)

Mit "order" kannst du doch eine Spalten zur Sortierung nutzen. Ich hab jetzt mal hier nach "img1_name" sortiert. --sk 13:11, 20. Aug. 2007 (CEST)

Bei Stefans Antwort lag wohl ein Mißverständiniss vor. Aber ich arbeite an einer Lösung, ganz einfach wird es aber sicher nicht. Auch wenn sich die Aufgabe nicht sonderlich kompliziert anhört, so ist mir noch nicht die optimale SQL-Abfrage eingefallen. Kolossos 20:37, 20. Aug. 2007 (CEST)

Done. Ich hoffe das Layout ist verständlich. Ich werde es auch noch etwas intensiver testen. Kolossos 22:23, 23. Aug. 2007 (CEST)

Ok, die Sonderzeichen muß ich mir nochmal anschauen. --Kolossos 09:20, 24. Aug. 2007 (CEST)

Gibt mal bitte ein Beispiel! -- sk 09:31, 24. Aug. 2007 (CEST)

Über http://tools.wikimedia.de/~kolossos/templatetiger/template-parameter.php?template=Infobox%20französischer%20Kanton&lang=de gelangt man zu den Parameter franz. Gemeinden. Von dort hat man dann die Wahl sich über den without-Link zum Parameter 'insee' den Artikel anzeigen lassen, wo dieser fehlt: http://tools.wikimedia.de/~kolossos/templatetiger/template-noparameter.php?template=Infobox%20französischer%20Kanton&lang=de&parameter=insee Umgekehrt kann man auch sich z.B. alle Artikel mit dem Parameter dates anzeigen lassen: http://tools.wikimedia.de/~kolossos/templatetiger/tt-table4.php?template=Infobox%20französischer%20Kanton&lang=de&order=dates&where=&is= Für die Sonderzeichen brauch ich im Header noch ein UTF-8 damit das vom Browser immer verstanden wird. Kolossos 10:56, 24. Aug. 2007 (CEST)

Jetzt musst du es nur noch hinbekommen, dass bei without auch noch alle anderen Felder mit angezeigt werden, ebenso wie bei with. -- sk 13:37, 24. Aug. 2007 (CEST)

Das sieht schon mal gut aus: Vier Artikel habe ich gefunden, bei zwei konnte ich sofort ein Bild ergänzen bzw anders einbauen. Aber Hohokam Pima National Monument wird nicht gefunden. Ist euer Datenbestand so alt, dass ein im April neu angelegter Artikel noch nicht drin ist? Oder erkennt dein Tool dass der Parameter in der Vorlage genannt ist, aber nicht, dass hinter dem Parameter kein Inhalt folgt? --h-stt !? 00:05, 25. Aug. 2007 (CEST)

Am Alter des Datensatzes liegt es jedenfalls nicht, eher daran, dass dem Parameter img1 als Wert ein Leerzeichen zugeordnet ist. Meine Frage an Stefan: Wie wollen wir mir Leerzeicheneinträge umgehen? Ich würde vorschlagen, genauso wie wie es der Parser macht. Und da der Parser wie in den folgenden Beispielen arbeitet sind wir eigentlich auf dem richtigen Weg, was die DB angeht.

Commons: WikiProjekt Vorlagenauswertung/Archiv/2007 – Album mit Bildern, Videos und Audiodateien

Commons: WikiProjekt Vorlagenauswertung/Archiv/2007 – Album mit Bildern, Videos und Audiodateien

Commons: dfd – Album mit Bildern, Videos und Audiodateien

Ich werde dann wohl, wenn es sinnvoll erscheint, meine SQL-Abfrage aufbohren und neben fehlenden Parameter auch nach Parametern mit leeren Einträgen schauen. Meinungen? Kolossos 11:11, 25. Aug. 2007 (CEST)

Ich fände es hilfreich, wenn das Tool leere Einträge wie fehlende Einträge behandeln würde. Denn das ist es ja, was ein Mensch sucht. Wenn ich beim Beispiel Infobox Nationalpark bleiben soll, dann verwende ich sie so, dass ich eine leere Vorlage in einen Artikel kopiere und dann nur die Felder ausfülle, die zum jeweiligen Schutzgebiet/Gedenkstätte passen. Der Rest der Felder bleibt aber stehen, denn wenn jemand zB eine Karte nachträglich auftreibt, soll er sie direkt einsetzen können, ohne sich erst mit Parameternamen beschäftigen zu müssen. Daher ist zB der Parameter | map = bei mir immer drin, auch wenn ich noch keine Karte einsetzen kann. An eine automatische Auswertung habe ich dabei natürlich bisher nicht gedacht. --h-stt !? 12:47, 25. Aug. 2007 (CEST)

Abfragezeitraum?

Ich habe die Vorlagenauswertung an Infobox:Schienenfahrzeuge ausprobiert. Einige Fehler in den Boxen konnte ich so entdecken. Nachdem ich diese in den Artikeln repariert habe, erscheinen sie aber immer noch in der Übersicht. Deshalb meine Frage: Wie oft wird abgefragt, damit ich weiß, wann ich sehen kann, ob meine Änderungen auch Erfolg hatten?

Und noch etwas: Außer den richtigen Überschriften der Infobox erscheinen auch noch einige Zahlen als Spaltenüberschrift. Wie kommen die zustande? --Köhl1 15:39, 21. Aug. 2007 (CEST)

Die Vorlagenauswertung wird aller 1-2 Monate aktualisiert. Dazu werden alle Dumps neu gefiltert und die Daten in die entsprechende Datenbank eingespielt werden. Du wirst also erst bei der nächsten Aktualisierung die Korrekturen sehen. Die Zahlen bedeuten, dass es für den gefunden Wert keinen Parameter gibt. Das Skript zerteilt die Vorlage nach den "|" und wenn dann wie z.B. bei DR Baureihe V 200 die Werte "Farbe1" und "Farbe2" auftauchen, dann gibt das Skript dem Wert eine Ziffer nach der Nummer des Auftretens. Im konkreten Fall fehlt sicherlich das "=". Aber es gibt ja auch Vorlagen die generell keine Paremeter "Name=" nutzen sondern nur durch Teiler "|" getrennte Werte haben bsp. "..20|xy|29|zy|..." und die müssen ja auch irgendwie spaltenweise aufgeschlüsselt werden. Noch Fragen? -- sk 15:50, 21. Aug. 2007 (CEST)

(totaler Bearbeitungskonflikt,darum meine fast gleichlautende Antwort) Auf der Projektseitegibt es die Tabelle mit den Sprachen, dahinter siehst du das aktuelle Dump Datum. Das einspielen soll aller 1-2 Monate erfolgen, da wir erstens auf die Dumps angewiesen sind und es zweitens recht Rechenzeit aufwendig ist (15min bis 5h je nach Sprache). Vielleicht findet sich über den Toolserver demnächst eine bessere Möglichkeit.

Deiner Frage kannst du dank dem Parameterlink auch selbst nachgehen: Für Parameter "12" hab ich das mal gemacht, kam auf DRG 137 149 bis 152 darin stand in der Vorlage:

|LängeÜberKupplung=44.756 mm
|Höchstgeschwindigkeit || 160 km/h
|Leistungsübertragung=elektrisch
|AnzahlFahrmotoren=2

das heißt, vor den 160 km/h wurde wohl statt "=" ein "||" benutzt, was so wohl nicht richtig ist. --Kolossos 16:02, 21. Aug. 2007 (CEST)

Danke für die fixen Antworten. Genau solche Fehler lassen sich damit ja prima aufspüren. Dass die Zahlen auf Fehler hindeuten, hatte ich mir schon gedacht. Gehe ich recht in der Annahme, dass die Zahl die Fehlerzeile anzeigt? Im obigen Beispiel also Zeile 12? (inzwischen im Artikel korrigiert)--Köhl1 16:26, 21. Aug. 2007 (CEST)

Nein, das klappt nicht immer. "|Höchstgeschwindigkeit || 160 km/h" wird in drei Teile zerlegt "Höchstgeschwindigkeit " + "" + " 160 km/h". Jedes Feld bekommt eine Zahl. Es klappt also mit der Zeile nur bedingt. -- sk 16:28, 21. Aug. 2007 (CEST)

Dann also nicht die Zeile, sondern die Zahl der Teilerstriche.--Köhl1 16:50, 21. Aug. 2007 (CEST)

Vorlagen aus Namensraum, fehlerhafter Link

Ich hätte noch eine kleine Sache. Ich habe nach Benutzer in der Datenbank gesucht. War überrascht, das es Benutzerseiten im Artikelnamensraum gibt. Jetzt ist aber die Verlinkung wenn man auf "Wikipedia", also die zweite Spalte, geht fehlerhaft, da immer ein "Template" voran gestellt wird, lässt sich das bei übereinstimmung mit Namensräumen vielleicht anders machen, damit der Link korrekt ist? Lässt sich ja auf alle Namensräume anwenden, wobei ich nicht hoffe, das es noch andere in die liste schaffen, da ja nur der Artikelnamensraum dort aufgelistet wird, nehm ich an? Der Umherirrende 22:26, 15. Sep. 2007 (CEST)

Das sollte natürlich auch nicht passieren, dass Vorlagen aus dem Benutzernamensraum in Artikeln verwendet werden. Da sollte einfach mal jemand aufräumen, und da es dann keine solche Vorlagen in der Vorlagenauswertung gäben würde, müßte man auch nix mehr umprogrammieren. Die Umprogrammierung wäre einfach wenn es sich nur um eine Sprache handeln würde, da die Scripte jedoch universell in verschiedenen Sprachen laufen, wäre der Aufwand schon erheblich. Aus dem Vorlagen-Tieger einen "Babel-Tieger" zu machen, also auch Benutzerseiten zu scannen, würde ich auch schon aufgrund des Aufwandes nicht vorhaben. --Kolossos 22:56, 15. Sep. 2007 (CEST)

Ok, der aufwand würde sehr ansteigen, bei einer Datenbank mit Daten außerhalb der Artikel. Ich habe die Benutzerseiten soweit es ging entlinkt. Wenn nur Vorlagen angezeigt werden sollen, dann lohnt sich das umprogrammieren nicht, sonst könnte ja auch mit {{ns:?}} oder den Systemtexten gearbeitet werden, falls dies außerhalb von der mediasoftware verwendbar wären. Sonst aber ist die Möglichkeit der Vorlagenauswertung auch schon sehr Klasse. Der Umherirrende 23:35, 15. Sep. 2007 (CEST)

So, ich hab Benutzer:Chrislb mal wegen seiner Infobox Radikal angeschrieben, dass er die auch verschiebt. Alle anderen wurden ja von dir "Umherirrende"n schon erledigt. Jetzt bleibt nur noch Benutzer:Frnetz/Vorlage:national squad. Wobei die eine Weiterleitung auf Vorlage:National squad zu sein scheint. Was mir noch nicht klar ist: warum mein Skript die rausgefiltert hat, denn scheinbar ist die Vorlage in keinem der 6 Artikel direkt eingebunden. Ist mir ein Rätsel! Ich würde jetzt einfach diese Vorlage im Benutzernamensraum löschen und dann schauen wir mal beim nächsten Mal wie es dann aussieht. Was meint ihr dazu? -- sk 18:39, 16. Sep. 2007 (CEST)

Erscheint löschbar, schließlich verweisen nur 3 Seiten auf diese Vorlage und keiner liegt im Artikelsnamensraum. --Kolossos 21:56, 16. Sep. 2007 (CEST)

Parserfunktion

Ich wollte mal fragen, wie es mit Parserfunktion aussieht. Werden diese mit ausgewertet, das sie in geschweifden Klammern stehen, oder werden sie erkannt und nicht berücksichtig, interessant ist die Sache ja, weil es DEFAULTSORT und DISPLAYTITLE ja im Artikelnamensraum gibt. Weiter fände ich es praktisch, wenn man eine Liste bekommt mit direkt verwendeten parserfunktionen außer oben genannten, das sollte ja nicht vorkommen und lässt sich vielleicht mit einbauen, da schon die gesamten Daten durchsucht werden. Dann lässt sich soetwas vermeiden. oder auch bei defaultsort. Der Umherirrende 21:31, 14. Okt. 2007 (CEST)

Alles was in geschweiften Klammern steht wird erkannt. Aber nur die "Klammerausdrücke", die auch einen Wert enthalten, werden weiter betrachtet. Alle anderen werden links liegen gelassen. Das heißt z.B. bei der Vorlage:Lagewunsch , {{Lagewunsch}} wird nicht abgespeichert, aber {{Lagewunsch|Absturzstelle}}, da es ja einen weiteren Wert hat, wird mit gespeichert. Siehe Tabelle. Ich bin damals davon ausgegangen, dass nur die Wert interessieren. Alle Artikel mit der Vorlage:Lagewunsch erhält man ja direkt über die Verlinkung in der Vorlage. Ok, wenn ich dich richtig verstehe, dann soll ich alle in Hilfe:Variablen gelisteten Variablen mit auslesen. - Anmerkung: Die komischen Einträge oben kommen meist deshalb, weil eine Klammer fehlt und dadurch der Parser wahrscheinlich durcheinander kommt. Die Fehlerursache dafür hab ich noch nicht dingfest machen können. -- sk 23:32, 14. Okt. 2007 (CEST)

Ja, das habe ich verstanden, also würde die beiden Parserfunktionen nicht auftauchen, weil sie kein Pipe haben und somit kein wert und nicht mit ausgewertet werden. Die Variablen aus Hilfe:Variablen brauchen nicht ausgelesen werden, sie sollten im artikel ja garnicht direkt verwendet werden. Mich wunderte nur das es diese komischen einträge gibt, daher wollte ich mal nachfragen, vielen Dank. Der Umherirrende 16:16, 15. Okt. 2007 (CEST)

Insgesamt ist es ziehmlich aufwändig einen Parser für die Wikipedia-Syntax zu entwickeln. Erst schmeiß ich aus dem Artikel alle Kommentare raus, dann alle Mathematischen Formeln und Sourcecode. Was dann noch übrig bleibt, wird nach geschweiften Klammern durchsucht. Nun arbeiten hier aber tausende Menschen mit, weshalb häufig auch Tippfehler auftreten und Klammern vergessen oder zuviel gesetzt werden. Da oft das Ergebniss trotzdem gut aussieht, bleibt der Fehler häufig länger erhalten. Ich hab mir die geparsten Daten nicht selber angeschaut, da das File extrem groß ist. Kolossos liest sie immer direkt in seine Datenbank ein. Er könnte eigentlich mal die Artikel rausfiltern, bei denen diese Fehler auftreten, dann könnte man die entsprechende Version des Artikels nochmal genauer inspizieren. Leider klappt ja die Abfrage dieser Artikel mit der PHP-Maske nicht direkt. Aber man sieht dort ganz gut, dass es immer nur 1 oder 2 Artikel sind, wo der Fehler auftritt. -- sk 16:29, 15. Okt. 2007 (CEST)

Konkurrenz oder sowas

Servus, ich bin mir nicht sicher, ob ihr schon http://wiki.dbpedia.org/ kennt. Eventuell besteht da ja Synergiepotenzial ... Gruß, --Flominator 18:33, 25. Nov. 2007 (CET)

Ja ist bekannt und Stefan hatte auchmal Kontakt, siehe #Schaut doch mal auf wikipedia.3ba.se. Trotzdem vielen Dank. --Kolossos 22:07, 25. Nov. 2007 (CET)

Wikipedia:WikiProjekt_Vorlagenauswertung#Beispiele_für_Abfragen

Ich denke die Abfragen werden etwas performanter (zumindest mal theoretisch) wenn man bei der Selektierung nach String-Literalen (z.B. ... `tp_name` LIKE 'Personendaten' ... ),  =  anstatt LIKE verwendet, da bei LIKE mitttels RegEx' verglichen wird.

So der Optimizer das nicht ohnehin von sich aus macht, was ich aber weder bestätigen noch dementieren kann. Sprich: ich weiß es nicht. Genausowenig wie, ob die tatsächliche Ersparnis ohnehin nur im Mikrosekundenbereich liegen würde. Trotzdem: Nutzt's nix, schadet's nix. --Geri, 02:53, 26. Nov. 2007 (CET)

Deutlich schlechter für die Performance dürfte wohl die Tatsache sein, dass ich auch vor dem Suchausdruck ein % was wohl jeden Index versaut allerdings wohl man aber wohl kaum anders zu vollständigen Ergebnissen kommt. Die Idee, auf die du mich gebracht hast wäre allerdings, mal die Fulltext Indixierung zu testen. --Kolossos 09:02, 26. Nov. 2007 (CET)

Ja, das mit % ist leider so. fulltext klingt gut. Viel Erfolg!

Ich hab' auch gelesen, dass ihr Beta-Tester sucht. Ist das noch aktuell? Wenn du mir sagst was ich mir konkret ansehen soll, und mir vorher ein paar grundlegende Infos gibst, kann ich das machen. --Geri, 09:57, 26. Nov. 2007 (CET)

Mit den Umlaute und Sonderzeichen baue ich gerne Fehler ein, das sollte aber mittlerweile gehen. Das die Performance bei Queries in der monströsen engl. Wikipedia in die Knie geht und die Antwortzeiten unerträglich werden, ist auch bekannt und läßt sich wohl so schnell nicht ändern. Also bezieht sich das Beta testen nur auf das nennen von Bugs die bei der normalen Nutzung sowieso auffallen. --Kolossos 10:38, 26. Nov. 2007 (CET)

Integration in die Wikipediaoberfläche

Ich hab mittels der Wikipedia:Helferlein/Toolserver-Integration (kann von jedem auf Spezial:Einstellungen -> Gadgets einfach eingeschaltet werden) den Templatetiger auf Vorlagenseiten eingebunden. Mann kann also direkt von der Vorlage mitels eines Klicks zur Übersicht der Inhalte der Nutzungen dieser Vorlage springen. Was jetzt die ganze Sache wirklich gut machen würde, wäre die Suchmaske (mit teilweise bereits ausgefüllten Werten) ebenfalls auf der Ergebnisseite mit deren Hilfe man dann die Suchergebnisse weiter verfeinern kann. Ich hoffe durch diese direkte Integration werden auch mehr auf die vielfältigen Möglichkeiten der Vorlagenauswertung aufmerksam. Arnomane 19:49, 26. Nov. 2007 (CET)

Klingt sehr gut. Derzeit arbeiten ich erstmal an der stabilen Versorgung des Templatetigers mit Daten. -- sk 16:07, 27. Nov. 2007 (CET)

Hej, ist das cool. Danke. Aber könntest du bitte noch das "...&order=article" aus der URL rausnehmen? Das ist eine tierische Performancebremse wenn wie bei den Personnendaten erst 163.000 Einträge sortiert werden müssen. Danke. --Kolossos 13:07, 28. Nov. 2007 (CET)

Danke für den Hinweis. Ich hab es eben mal schnell rausgetan: [2]. Arnomane 13:22, 28. Nov. 2007 (CET)

Anmerkung: Wenn das nächste Einlesen der Daten eh nicht mehr über die Dumps, sondern über die auf dem Toolserver vorhandenen Daten erfolgt, könnten wir die Artikel auch alphabetisch sotiert einlesen, das reicht dann ggf. bis in die Anzeige durch. --Kolossos 15:07, 28. Nov. 2007 (CET)

Vorlagendaten aus Text herausfiltern

Hallo Stefan,

Hallo Kolossus,

wir sind uns hier ja schon öfter über den Weg gelaufen (hier und hier und auf anderen Seiten). Ich bräuchte mal ein wenig Hilfe von euch. Zum einen kann ich mir die hier erwähnte CSV-Datei nicht runterladen, da funktioniert der Link wohl nicht mehr.

Zum anderen hätte ich ein paar Fragen. Erstmal zum Hintergrund: Im Rahmen meiner Dissertation beschäftige ich mich mit der Wikipedia und muss dabei häufig Daten nach bestimmten Kriterien filtern. Aktuell stehe ich vor dem Problem, dass ich aus dem Text eines Artikel (in der DB in der Tabelle text.old_text) die eingebundenen Vorlagen herausfiltern möchte, so dass möglichst nur noch der Text ohne die Daten aus den Vorlagen vorhanden ist. Die Vorlagendaten befinden sich ja stets am Anfang des Textes und müssten doch irgenwie zu extrahieren sein, ihr macht das doch auch so!?

Zusammengefasst:

1. Stehen die Vorlagendaten immer am Anfang der Artikel?

2. Kann man die Vorlagen direkt per SQL-Statement (Regex, lösche alles was zwischen zwei geschweiften Klammern steht "{{ ... Vorlagendaten ... }}") filtern?

3a) Wie extrahiert ihr die Vorlagendaten aus dem Artikeltext. Funktioniert das über das abgewandelte Perlskript der Geoauswertung?

3b) Gibt es evtl. auch eine PHP-Version, die die Filtermechanismen enthält?

3c) Sind a) oder b) irgendwo als Download verfügbar?

4. Habt ihr evtl eine Grafik, die verdeutlicht, wie viel Prozent der Artikel mit Vorlagen durch die 10/50/100 am häufigsten genutzten Vorlagen abgedeckt werden? Das müsste ja nach eurer Übersicht recht exponentiell verlaufen. Hintergrund: Wenn ich mit 10% der Vorlagen schon 90% der Artikel bereinigen könnte, würde mir das evtl. schon genügen und ich könnte einfach bestimmte Charakteristika aus den 10 Vorlagen hardcodiert filtern (quick and dirty halt ;-) ).

---

NEU (Einschub):

So, ich habe mir mal die Mühe gemacht und anhand eurer Daten die Verteilung berechnet. Siehe Grafik.

Anbei noch die genaue daten der Verteilung in der Relation "Anzahl Vorlagen / Abdeckung in Prozent":

• 5 - 41%
• 10 - 54%
• 15 - 61%
• 25 - 69%
• 40 - 75%
• 65 - 81%
• 105 - 88%
• 170 - 92%
• 285 - 95%
• 455 - 98%
• 740 - 99%

Fazit: Um 75% der Vorlagen auf die quick-and-dirty-Weise zu filtern, müssten die zu extrahierenden Texte mit 40 teilweise recht langen Suchmustern abgeglichen werden. Bei über 100.000 Datensätze, die ich auf diese Weise bearbeiten wollte, wohl ein ziemlicher Performance-Killer?!?.

5. Wäre es evtl. möglich, zunächst nur auf den Namen der Vorlage zu filtern und dann die zu filternden Elemente dynmisch in das Filterskript einzubinden? Sprich ich entdecke in einem Artikel als erste zwei Zeichen "{{" und weiß, dass dieser eine Vorlage besitzt. Nun extrahiere ich aus dem Text den Namen der Vorlage und vergleiche ihn mit einer zu erstellenden Auflistung, die auch die einzelnen Vorlagenelemente (Attribute wie z. B. Geburtstdatum, Sterbedatum, Geburtsort, ...) enthält. Die eigentlichen Wertzuweisungen (z. B. "01.11.1900", "20.12.1999", "Berlin") möchte ich gar nicht filtern, nur die Attributnamen. Haltet ihr diese Vorgehensweise für realisierbar?

ENDE Einschub

---

Ihr habt auf dem Gebiet ja schon einige Erfahrung angehäuft. Es wäre echt super, wenn ihr mir ein wenig unter die Arme greifen könntet. Falls ihr bei irgendwelchen PHP/MySQL-Problemen Hilfe braucht, würde ich im Gegenzug versuchen, euch dabei zu unterstützen, sofern möglich.

Besten Dank nochmal auch im Namen der anderne Wikipedianer für dieses tolle Projekt. Maziminke 13:26, 2. Dez. 2007 (CET)

So viele Fragen! :-) Also 1.) Nein. Personendaten stehen zum Beispiel am Ende des Artikels. 2.) Hmm, kann man versuchen, aber es gibt zu viele Außnahmen. z.B. wenn in einer Vorlage eine neue Vorlage aufgemacht wird. Oft fehlt auch eine Klammer oder eine ist zuviel. 3a.) Ja das ist das abgewandelte Geoskript. Zuerst werden aus dem Artikeltext alle Mathe-Formeln und Kommentare gelöscht, weil die bei der Weiterverarbeitung sonst probleme bereiten. Dann wird alles zwischen den geschweiften Klammern rausgefiltert, so das ich alle Vorlagen eines Artikels einzeln habe. Diese werden dann zerlegt in ihre Bestandteile, wobei das nicht trivial ist, da ja wieder anderer Vorlagen enthalten sein können (z.B. Infobox Ort in Deutschland könnte eine Geokoordinate enthalten). Wenn die Vorlage in seine Parameter zerlegt ist, wird diese dann in eine riesige Tabelle gesteckt, die Kolossos in die Datenbank einlädt. Alles andere ist dann nur SQL und PHP Abfragen. Der erste Teil ist halt Perl, weil man da viele Fehlerquellen ausschalten kann. Die Artikeltexte enthalten ja immer Syntaxfehler. 3b) Nein. 3c) Die Perl-Skripte gibt es hier. 4) Hast du ja fix selber gemacht. - Noch Fragen? -- sk 21:16, 2. Dez. 2007 (CET)

Heute nur mal eine kurze Antwort, für das was nicht schon von Stefan beantwortet wurde. Du könntest einen Toolserver-Account beantragen dann hättest du auf meine Datenbanktabellen und alle Wikipedias Lesezugriff. Wenn du das nicht willst, sag nochmal bescheidt dann muß ich dir einen Dump erzeugen. Zu Frage 3b , PHP hat da sicher Funktionen da es der Media-wiki Parser ja auch kann, nur kenne ich diese nicht. Anmerkungen: ungetestester Tip dazu http://pear.php.net/package/Text_Wiki_Mediawiki , desweiteren empfehle ich den Artikel "Kellerautomat".

Deine Vorlagennutzungsstatistik erscheint ohne Textscan möglich, da die Verwendung der Vorlagen in der Extra-DB-Tabelle Templatelinks gespeichert werden, damit dürfte ein SQL Kommando und wenige Sekunde zur Auswertung reichen. Ich verstehe deine berechnete "Abdeckung Vorlagen" nicht, da Artikel auch mehrere Vorlagen enthalten kann. --Kolossos 23:10, 2. Dez. 2007 (CET)

• zu 1.) Das wär ja auch zu einfach, wenn man lediglich die ersten Zeichen übeprüfen bräuchte. Stehen die Vorlagendaten nur entweder am Anfang oder am Ende oder können die auch mitten im Text versteckt sein?
• zu 2.) Wär ja auch zu einfach... :-(
• zu 3a) Besten Dank für diese ausführliche Erklärung
• zu 3b) Ebenfalls schade, mit Perl kenne ich mich leider kaum aus. Ich nutze schon einen PHP-Parser, den ich auf der PEAR-Seite gefunden habe, aber der macht seine Arbeit nur sehr schlampig und ist daher nur in geringem Maße hilfreich. Der Artikel Kellerautomat ist sehr aufschlussreich, aber ich wollte das Rad auch nicht neu erfinden und die Filterfunktion nicht komplett selbst nochmals in PHP umsetzen.
• zu 3c) Danke für den Link
• zu 4.) @Kolossos: Der Tipp mit der Templatelinks-Tabelle könnte eine gute Hilfe sein. Ich bräuchte nur eure Daten zu Vorlagen und Parametern, sprich am besten einen SQL-Dump. Könntest du mir den irgendwo zur Verfügung stellen? Dann kann ich selbst damit rumspielen und mache nicht den Toolserver kaputt ;-) Zur Grafik: Die Übersicht habe ich mir auf die schnelle aus euren Daten generiert. Natürlich sind da Effekte wie mehrere Vorlagen in einem Artikel nicht mit drin. Ich wollte nur eine grobe Orientierung haben, wie die Verteilung aussieht.
• zu 5.) Zum Text unter der Grafik habt ihr euch noch nicht geäußert. Es würde mich sehr interessieren, was ihr davon haltet. Theoretisch müssten die Vorlagenelemente zu einer Vorlage doch in euren Daten vorhanden sein, oder?

Vielen Dank für die Hilfe und die Anregungen! Maziminke 17:02, 4. Dez. 2007 (CET)

• zu 1.) Schau dir doch einfach ein paar Artikel an, dann siehst du, dass es wohl auch Vorlagen in der Mitte gibt. Wenn du nur Infoboxen suchst dann gibt es trotzdem Ausnahmen wie Ford Mustang
• zu 2.) Schau dir doch einfach ein paar Artikel an, dann siehst du, dass es wohl auch Vorlagen in der Mitte gibt. Wenn du nur Infoboxen suchst dann gibt es trotzdem Ausnahmen wie Ford Mustang
• zu 4.) Dump: http://tools.wikimedia.de/~kolossos/tt-datas/pub_tt1_de.sql.gz
• zu 5.) Ich verstehe wahrscheinlich nicht was du damit meinst, aber du hast ja jetzt die Daten (siehe 4.) womit es ein leichtes sein sollte nur die Vorlagenparameter zu analysieren. Wie fit bist du in MySQL? --Kolossos 19:27, 4. Dez. 2007 (CET)

• zu 4.) Super, besten Dank dafür.
• zu 5.) Mit MySQL kenne ich mich einigermaßen gut aus, bin aber kein Profi. Maziminke 11:03, 5. Dez. 2007 (CET)

Automatisches Update

Ich zittier dich jetzt einfach mal:

Ich hab es ja schon oft erwähnt, dass wir noch jemanden suchen der in der Lage ist, eine Extension zu schreiben, welche bei jedem Edit die Datenbanktabelle aktualisiert, so wie das bei Links, Vorlagen, Bilder .... schon jetzt der Fall ist. Wir können es leider nicht. Kolossos 11:52, 12. Apr. 2007 (CEST)

Ist daraus was geworden? Wenn nein, würde ich mich dazu bereit erklären. Ich bräuchte halt nur igendwo Webspace wo man nen Mediawiki aufsetzen kann, um dort zu entwickeln und jemanden der das dann in den Hauptmediawikizweig übernehmen würde, vor allem weil das wohl eher nen Hack als ne Extension ist. --Saerdnaer 21:38, 3. Dez. 2007 (CET)

Ein Hack hat wohl im Mediawiki Produktiveinsatz der Wikipedia keine Chance, das muß schon etwas sauberes sein. Zum Entwickeln solltest du wohl deinen lokalen Rechner nutzen, z.B. mit einem Xampp, da du dort ersten alles hast, selbst auf dem Toolserver eine Mediawiki Installation ungern gesehen wird und ich dir jetzt auch keinen freien Webspace anbieten könnte. Die Veröffentlichung könnte dann über http://www.mediawiki.org/wiki/Category:Extensions erfolgen. Oder gibt es einen Grund, warum das nicht als Extension laufen könnte? Ich könnte mir schon vorstellen, das die Erweiterung auch bei kleineren Wikis auf Interesse stößt. --Kolossos 22:00, 3. Dez. 2007 (CET)

Naja, wenn jemand in die Originalsoftware entsprechende Hooks zum einhängen der Extension einbaut, kann man auch ne Extension bauen. Interessant wäre das sicher für jedes Wiki. Wie man unter PHP Entwickelt weiß ich, mach das ja schon ein paar Jahre. Ich muss dann wohl doch meinen eigenen Server dafür her nehmen. Naja, mal schauen. Soll man da gleich allgemein so nen Art Event System bauen, das dann irgendwelche andere Tools per HTTP benachrichtigt, das an der Seite in dem Bereich etwas geändert wurde, oder nur fix auf das Auswerten von Templates fokusieren? --Saerdnaer 22:28, 3. Dez. 2007 (CET)

Schön wenn du dich in Richtung Mediawiki auskennst, ich bin da nie richtig rein gekommen und hab auch noch nie mit OOP gearbeitet, darum sind mir da auch die Hände gebunden und deshalb würde es mich umso mehr freuen wenn es einer übernimmt, der sich das zutraut. Im Moment greifen die Tools einfach auf die Daten zu, eine Anwendung in Richtung: "Zeige mir alle Änderungen an der Infobox PKW der letzten Zeit" war bis jetzt noch nicht vorgesehen, könnte aber interessant sein. Ebenso etwas Richtung RSS. Wobei man dafür glaube ich weniger einen Event als einfach ein Datumsfeld in der DB braucht. Eine Eventanwendung sehe ich z.B. Richtung Datawarehouse, da in bestimmten Abständen auch die Tabelle "pub_tt1_de_sum" aktualisiert werden muss ,siehe meinen neuen Eintrag in Wikipedia:WikiProjekt_Vorlagenauswertung#Datenbank-Layout. Eine ähnliche Tabelle könnte man neben den Vorlagen auch für die Parameter haben, die Daten sind zwar redundant, aber sonst dauert es echt ewig bis was kommt.

Deine Fähigkeiten könnten wir auch dahingehend gebrauchen, dass ein auf dem Mediawiki-Parser basierender Vorlagenextraierer besser arbeiten könnte, als unser Perl-Skript, so haben wir z.B: momentan keine Vorlagen in Vorlagen extraiert, also wenn sich z.B. in der Vorlage:Infobox Berg eine Geokoordinate befindet. Andere Probleme waren auskommentierte Stellen und meines Wissens Vorlagenprogrammierung bzw. Variablen, da wäre es schön, möglichst nah am Mediawiki zu bleiben. Es wäre also gut, wenn sich dein Programm auch leicht so modifizieren lassen könnte, dass man es auf einen Dump eine DB oder ähnliches ansetzen könnte. --Kolossos 20:22, 4. Dez. 2007 (CET)

Es sollten auf jedenfall IDs eingeführt werden, dadurch sollte die ganze Anwendung um einiges schneller Laufen. Beispiel:

pub_tt1_de {[name_id, name, tp_id, entry_name, value]}
pub_tt1_de_sum {[tp_id, tp_name, sum]}

wobei ich sum evtl. noch umbenennten würde.

Wenn man das noch weiter durchziehen möche, und mehrere Tabellen verwendet (ich verwende jetzt mal andere Tabellenamen):

de_names{[name_id, name_name]}
de_templates {[tp_id, tp_name, sum]}
de_template_entries {[entry_id, entry_name]}
de_template_data {[tp_id, entry_id, name_id, value]}

So wäre das Datenbank-technisch eigendlich richtig umgesetzt und man hätte keine Redundanzen mehr. Die Queries brauchen halt nur ein paar Joins mehr. Aber da könnte man evtl. die Queries automatsich umbauen lassen, so dass man z.B. eine Query der Art

SELECT name, geburtsdatum 
FROM Personen 
WHERE name LIKE "And%" 

in

SELECT d1.value AS name, d2.value AS geburtsdatum 
FROM de_templates t, de_names n
  LEFT JOIN de_template_entries e1 ON e1.entry_name = "name"
  LEFT JOIN de_template_entries e2 ON e2.entry_name = "geburtsdatum"
  LEFT JOIN de_template_data d1 ON d1.tp_id = t.tp_id AND d1.entry_id = e1.entry_id AND d1.name_id = n.name_id
  LEFT JOIN de_template_data d2 ON d2.tp_id = t.tp_id AND d2.entry_id = e2.entry_id AND d2.name_id = n.name_id
WHERE t.tp_name = "Personen"
 AND d1.value LIKE "And%"

umbaut

Noch besser währe natürlich, wie unten angesprochen, man würde für jedes Template eine extra Tabelle erstellen:

de_names{[name_id, name_name]}
de_templates {[tp_id, tp_name, sum]}
de_template_entries {[entry_id, entry_name, entry_type]}
de_tp_Personen {[name_id, name, geburtsdatum, geburtsort, ...]}
de_tp_Orte {[name_id, ortsname, gründungsdatum, einwohner, ...]}

Man müsste dann halt aus dem Templates automatisch ein CREATE TABLE Statement generien, müsste halt mal jeman den Code dazu schreiben. Bei der Gelegenheit könnte man gleich die Daten des Vorlagenmeisters (also welcher entry ist welcher Typ) mit einfließen lassen und den Vorlagenmeister auch gleich fest ins Mediawiki mit einbauen, um nicht das ganze Javascript Zeug machen zu müssen.

Soweit meine Ideen für heute. --Saerdnaer 16:12, 9. Dez. 2007 (CET)

Datenformat

Seh ich das richtig das ihr momentan folgende Tabelle für die Daten verwendet?

CREATE TABLE `pub_tt1_de` (
 `lang` varchar(5) NOT NULL,
 `name` varchar(180) NOT NULL,
 `name_id` bigint(20) NOT NULL,
 `tp_nr` bigint(20) NOT NULL,
 `tp_name` varchar(100) NOT NULL,
 `entry_nr` bigint(20) NOT NULL,
 `entry_name` varchar(200) NOT NULL,
 `Value` varchar(900) NOT NULL,
);

? --Saerdnaer 21:45, 3. Dez. 2007 (CET)

Ja, hab mal eine 1:1 Auszug mit den Keys erstellt.

CREATE TABLE `pub_tt1_de` (
 `lang` varchar(5) NOT NULL,
 `name` varchar(180) NOT NULL,
 `name_id` bigint(20) NOT NULL,
 `tp_nr` bigint(20) NOT NULL,
 `tp_name` varchar(100) NOT NULL,
 `entry_nr` bigint(20) NOT NULL,
 `entry_name` varchar(200) NOT NULL,
 `Value` varchar(900) NOT NULL,
 KEY `lang` (`lang`),
 KEY `name` (`name`),
 KEY `name_id` (`name_id`),
 KEY `tp_nr` (`tp_nr`),
 KEY `tp_name` (`tp_name`),
 KEY `entry_nr` (`entry_nr`),
 KEY `entry_name` (`entry_name`),
 KEY `Value` (`Value`(767))
) ENGINE=InnoDB DEFAULT CHARSET=latin1;   --Kolossos 22:00, 3. Dez. 2007 (CET)

Schon mal daran gedacht da mehrere Tabellen draus zu machen um Redundanz zu vermeiden? Für was ist z.B. das lang nochmal in der Tabelle, das steht doch schon im Tabellenname? --Saerdnaer 22:29, 3. Dez. 2007 (CET) und woher stammt denn eigendlich die name_id? --Saerdnaer 01:06, 4. Dez. 2007 (CET)

Hupp, es gibt mehrere Tabellen und die "lang" ist eigentlich unnötig, könnte aber für die vielen kleinen WPs ggf. mal interessant werden. Ich glaube `tp_nr` und `entry_nr` werden momentan auch nicht genutzt. --Kolossos 08:28, 4. Dez. 2007 (CET)

Da schließe ich mich mit meinen Fragen gleich mal an:

• 1. Wieso ist auf jede Tabellenspalte ein Index gelegt? Für lang scheint dies wirklich nicht notwendig zu sein und auch bei einigen anderen Spalten könnte man wohl zugunsten einer geringeren Datenbankgröße darauf verzichten.
• 2. Wieso ist der Index von Value als "KEY `Value` (`Value`(767))" definiert? Diese Notation kenne ich nicht, deshalb die Frage.
• 3. Ich denke auch, dass die Tabelle eine Menge Redundanz enthält. Wieso wird beispeilsweise einmal name und dazu noch name_id benötigt? Unter Redundanz und Performancegesichtspunkten würde sich eine Aufspaltung in drei Tabellen anbieten a) artikel mit den Artikeldaten, b) vorlage mit den Vorlagedaten und c) eine Tabelle für die Relation zwischen a) und b), z. B. r_artikel_vorlagen.

Sind nur so ein paar Ideen. Ich arbeite natürlich auch gerne nach dem Motto Never change a running Database, aber bei zunehmender Datenmenge könntet ihr da noch mehr aus eurem System rausholen. Maziminke 15:13, 7. Dez. 2007 (CET)

zu 1. Da lang unnötig ist ist natürlich auch der Index abartig. name_id könnte als ID das Verbindungsglied zu den Kategorien oder ähnlichen Mediawiki-Tabelle dienen, wobei das mittlerweile schwierig ist, da ja einige Sprachen auf dem zweiten SQL-Server laufen. name_id wird auch wirklich genutzt da es aufgrund eines MySQL-Bugs nötig ist bei den "where .... is ...." Abfragen erstmal die Artikel zu finden und in einer zweiten SQL-Abfrage diese Artikel dann anzuzeigen.

zu 2. Keine Ahnung, das System hat das glaube ich automatisch gemacht, da varchar(900) auch deutlich länger ist.

zu 3. Könnte man sich überlegen, muß man aber glaube ich nicht. So können die Daten einfacher aus dem Dump eingelesen und einfach ausgegeben werden. Würden sich die Daten auch Stückweise ändern wäre eine solche Redundanz natürlich tödlich. --Kolossos 16:35, 7. Dez. 2007 (CET)

Ich denke da könnte man einiges am Datenmodell optimieren, in dem man die ganzen Redundanzen behebt und mehr einzelne Tabellen erstellt. Ich wäre außerdem schon fast dafür für jede Vorlage eine eigene Tabelle zu machen, die dann eben die entsprechenden Spalten hat, die das Template selbst auch anbietet. --Saerdnaer 14:11, 9. Dez. 2007 (CET)

Na eigentlich bin ich ganz froh, nicht 3000 oder mehr Datenbanktabellen pflegen zu müssen, lieber erstelle ich mit einer einfachen SQL-Abfrage wie:

INSERT INTO `u_kolossos`.`pub_personendaten_de`
SELECT DISTINCT `name` a, 
(SELECT `Value` FROM `pub_tt1_de` WHERE `entry_name` LIKE 'ALTERNATIVNAMEN' AND `tp_name` LIKE 'Personendaten' AND `name` = a LIMIT 1	) ALTERNATIVNAMEN,
(SELECT `Value` FROM `pub_tt1_de` WHERE `entry_name` LIKE 'KURZBESCHREIBUNG' AND `tp_name` LIKE 'Personendaten' AND `name` = a LIMIT 1) KURZBESCHREIBUNG,
(SELECT `Value` FROM `pub_tt1_de` WHERE `entry_name` LIKE 'GEBURTSDATUM' AND `tp_name` LIKE 'Personendaten' AND `name` = a LIMIT 1) GEBURTSDATUM,
(SELECT `Value` FROM `pub_tt1_de` WHERE `entry_name` LIKE 'GEBURTSORT' AND `tp_name` LIKE 'Personendaten' AND `name` = a LIMIT 1	) GEBURTSORT,
(SELECT `Value`FROM `pub_tt1_de` WHERE `entry_name` LIKE 'STERBEDATUM' AND `tp_name` LIKE 'Personendaten' AND `name` = a LIMIT 1) STERBEDATUM,
(SELECT `Value` FROM `pub_tt1_de` WHERE `entry_name` LIKE 'STERBEORT' AND `tp_name` LIKE 'Personendaten'	AND `name` = a LIMIT 1) STERBEORT,
(SELECT `Value` FROM `pub_tt1_de` WHERE `tp_name` LIKE 'PND'	AND `name` = a LIMIT 1) PND
FROM `pub_tt1_de` WHERE `tp_name` LIKE 'Personendaten'

für spezielle Vorlagen eigene Tabellen. Die Einträge wie das Geburtsdatum müssen dann eh nochmal umgewandelt werden, um verwertbar zu sein. Die vielen Tabellen waren, glaube ich, auch der Tod des alten Wikidatas. Ein Exporttool könnte natürlich nix schaden. Auch könnte man mal die Vorlagen mit auslesen, um zu sehen welche Parameter dort verarbeitet werden und welche nicht. --Kolossos 21:11, 9. Dez. 2007 (CET)

Vorlage:Infobox Nationalpark

Hi, würde jemand von euch bitte mal in die oa Box reinschauen? Ich mache mir Sorgen, ob sie von der 100-If-Statements-Regel erfasst werden könnte. Ich bin reiner Anwender der Box, kann sie nur benutzen, kenne aber den Code nicht. Der Ersteller hat die Wikipedia verlassen, deshalb wende ich mich an euch. --h-stt !? 20:47, 9. Dez. 2007 (CET)

Da bist du hier wohl falsch, schau mal bei Hilfe:Vorlagen bzw. Wikipedia:Vorlagenprogrammierung. Ich hab mal rein geschaut und fand die Komplexität nicht überdurchschnittlich. --Kolossos 21:13, 9. Dez. 2007 (CET)

Oups - sorry, falsche Seite erwischt. --h-stt !? 22:01, 9. Dez. 2007 (CET)

Neues Datenformat

Okay, ich für die zwei Diskussionsstränge mal wieder zusammen: Ich schlage jetzt einfach mal folgendes Vorgehen vor: Wir nutzen als neues Datenformat folgende Tabellenaufteilung:

de_names {[name_id, name_name]}
de_templates {[tp_id, tp_name, sum]}
de_template_entries {[entry_id, entry_name, entry_type]}
de_template_data {[tp_id, entry_id, name_id, value]}

(Wenn man kann man names noch in articles umbennen) Falls nötig erstellt man daraus dann per SQL INSERT INTO ... SELECT ... Statement neue Tabellen. Die jetzt anfallenden Aufgaben wären folgende:

• Extraktion der in Tempate:XXX enthaltenen Vorlagenvarablen zur Befüllung der Tabelle de_templates und de_template_entries evtl. mit zuhilfenahme der Daten für den Vorlagenmeister (oder wie das Ding hieß) um den Typ zu definieren
• Funktion die aus einem Text der Templates enthält, die entsprechenden Daten extrahiert und in einem Array ausgiebt.
  • Funktion die aus diesem Feld ein SQL Insert oder Update Statement für Tabellen de_names und de_tables_data macht
• Event System das obrige Funktionen bei Änderungen an einem Bereich einer Seite der ein Template enthält, die Ausführung der obrigen Funktionen veranlasst.

Da Mediawiki in PHP geschrieben ist, wäre das auch die bevorzugte Sprache dafür. Für die Vorlagenextraktion aus Texten habe ich bereites mal irgendwann eine Funktion geschrieben; werde sie nacher suchen und dann hier Online stellen. --Saerdnaer 19:27, 15. Dez. 2007 (CET)

An der Datei hätte ich auch Interesse dran. Ist das denn ein wenig kommentiert, damit man da auch durchsteigt? Maziminke 14:57, 16. Dez. 2007 (CET)

Das Ding sollte eingendlich relativ einfach zu Verstehen sein. /ExportXML--Saerdnaer 17:25, 19. Dez. 2007 (CET)

Ich komme erst jetzt dazu auf die vorgeschlagene Tabellenstruktur zu antworten: Bezüglich Redundanz halte ich die ersten beiden Tabellen "de_names" und "de_templates" für entbehrlich, wenn es sich um eine direkte Mediawiki-Erweiterung handelt, da die Daten in der Tabelle "page" in den jeweiligen namespaces stecken dürften. Natürlich gibt es noch die "sum" wofür diese Tabellen performancetechnisch sinnvoll sein könnten und auch auf dem Toolserver, wo die DB über 2 Rechner verteilt sind, sind die Tabellen sicher nicht verkehrt.

Den "entry Type" zu bestimmen halte ich im internationalen Umfeld für schwierig, oder gibt es den Vorlagenmeister z.B. auch auf spanisch? Also würde ich empfehlen das zum Schluss anzugehen. Prinzipiell sollen auch in einer Vorlage nichtdefinierte Parameter mit ausgelesen werden, da so Fehler in einzelnen Artikeln leichter zu finden sind. Performance ist echt noch so eine Sache wo ich Probleme sehe. --Kolossos 18:24, 19. Dez. 2007 (CET)

Skripte bekommen?

Workflow der Datenextrahierung aus eine Wikipedia-Dump durch sk

Servus, besteht die Möglichkeit, eure Tools auch in anderen MediaWikis jenseits der Wikimedia-Stiftung zu installieren bzw. zu nutzen? --Flominator 11:39, 24. Mär. 2007 (CET)

Generell ja, aber es sind mehrere Perl-Skript, ie eigentlich für einen ganz anderen Zweck geschrieben wurde. Ich habs versucht so weit wie möglich zu kommentieren, aber ich weiß nicht ob da überhaupt jemand durchsieht. ;-) Wenn du die Skripte trotzdem haben möchtest, dann schick mir eine Mail und ich sende es dir per Anhang. -- sk 18:48, 24. Mär. 2007 (CET)

Meine Skripte kannst du auch gerne bekommen, womit du dann die von Stefans Skript extrahierten Daten auswerten kannst. Den Code für das Hauptskript findest du unter [3]. Eine Mediawiki-Extension für die Extraktion wäre natürlich besser. Kolossos 21:28, 24. Mär. 2007 (CET)

Nach welchen Änderungen muss das Skript laufen? Was genau macht es? Vorlagen auswerten und Datensätze dafür schaffen? --Flominator 17:25, 9. Apr. 2007 (CEST)

Anbei hab ich mal ein Workflow-Diagramm eingebaut. Für das WP:GEO hab ich einige Auswerteskripte geschaffen. Die laufen ohne Mediawiki. Man braucht den Dump der Datenbank in XML-Format und dann die entsprechenden Perl-Skripte. Das Skript schaut sich jeden Artikel an, löscht Komentare und sucht im Rest nach Geodaten und Vorlagen. Danach bekommt man zwei CSV-txt-Dateien mit eben den Geodaten und den Templates. In der Zeichnung ist es das oberste Skript. -- sk 18:18, 9. Apr. 2007 (CEST)

Vielen Dank für die Infos. Das heißt aber, dass die Skripte die Artikel permanent abgrasen müssen? --Flominator 19:45, 10. Apr. 2007 (CEST)

Nicht permanent, nur einmal im Monat wenn es einen neuen Dump gibt, anschließend wird nur noch die recht kompakte DB abgefragt. Dem entsprechend ist allerdings auch unser Aktualitätsstand. Kolossos 20:14, 10. Apr. 2007 (CEST)

Für permanente Aktualität im privaten Wiki also immer! --Flominator 11:19, 12. Apr. 2007 (CEST)

Ich hab es ja schon oft erwähnt, dass wir noch jemanden suchen der in der Lage ist, eine Extension zu schreiben, welche bei jedem Edit die Datenbanktabelle aktualisiert, so wie das bei Links, Vorlagen, Bilder .... schon jetzt der Fall ist. Wir können es leider nicht. Kolossos 11:52, 12. Apr. 2007 (CEST)

Ist kein Problem, ist nur gut zu wissen! --Flominator 21:47, 13. Apr. 2007 (CEST)

Ich vermute, daß das nicht allzu schwierig ist - der Ansatz muß doch ungefähr sein: Unmittelbar vor oder nach dem Abspeichern muß der Wikitext des Artikels noch an ein perl script gepiped werden, das es schon gibt. Ist das richtig? Wenn ja, schreib mir mal einen Hinweis op ming Klaafsigk, ich guck dann mal, ob ich so eine Extension hinkriege. Wie sollte die denn heißen? mw:Extension:ExternalNotifyOnArticleUpdate z.B.? --Purodha Blissenbach 23:33, 26. Dez. 2007 (CET)

Listen

ich hab mir mal den code durchgelesen, eh ein recht einfaches programm, muss eine heidenarbeit gewesen sein.. ;)

(heisst, die wirklich guten programme schaun immer einfach aus, wenn sie fertig sind)

je länger ich über Euer projekt nachdenke: ich seh als ideales einsatzgebiet die automatische generierung von listenartikel. wir haben da beispielsweise gerade die löschdisk Liste der Erstbesteigungen, die als redundant zu den infoboxen bemängelt wurde (ich hab mit erlaubt, dort auf Euer projekt zu verweisen - wenn Ihr angst habt, dass sich vorbehalte der listenfreude aufbauen, lass ich sowas lieber..), oder die endlosen Liste der Deutschen LA, Liste der Franzosen† (hier wird argumentiert, sie würde zusatzinformation bieten, die die kats nicht haben, dier Infobox macht genau das, etwa wenn man in der Namensbox eine kurzbeschreibung miteinbaut) - jedenfalls, die sammelwut, die zu den zahllosen listenartikel führt, ist halt einfach ein bedürfnis, an dem man nicht vorbeikommt - die sammelleidenschaft ist auch ein starker motor für viele unserer fleissigen mitarbeiter, überhaupt hier mitzumachen, sie zu bekämpfen halte ich für falsch. die listenartiekl haben halt den entsetzlichen nachteil, dass sie extrem wartungsintensiv sind, und wenn die mitarbeiter, die sie aufbauen, abspringen, bleibt nur eine informationsmülldeponie zurück. jetzt haben wir den Vorlagen-Generator, der zukünftig wohl auch das ausfüllen von vorhandenen Infoboxen dem laien erleichtert, fehlen die listen, die der Template-Tiger generiern könnte. dazu braucht es imho zweierlei:

1. er müsste statt HTML halt Wikicode produzieren, der dann wieder durch den Parser geschickt wird. ich versteh leider nichts davon, aber ich denke, die kategorien und specialpages funktionieren genauso
2. er müsst die eintäge der infobox filtern können, also nur gewisse spalten der tabelle anzeigen (etwa bei den Erstbesteigungen zB. nach gebirge filtern, und nur berg, datum, erstbesteiger und aufstiegsroute anzeigen)

   dazu müsste man etwa einfach diejenigen einträge als liste mitübergeben können, die angezeigt werden sollen. wenn ich das programm recht verstanden hab (ich spreche nicht PHP, zum lesen reicht der saubere code) ist das in der foreach($namen as $name), wo man „if $valuename in anzeige-wunsch“ filtern täte. oder geht das schon bei SQL-abfrage, indem sie je $row[i] nur $column[j₁], [j₄], … ausliest? wär schneller, dann bräuchte man auch nur die spalten-indizes übergeben. jedenfalls könnte man dann, statt listenartikel zu erstellen, einfach die datenbankabfrage fix als link im oberartikel verdrahten (Anden - siehe auch: Erstbesteigungen..). bei der GUI ist das sicher aufwändiger, weil dann ja zuerst der infobox-code geöffnet werden müsste oder eine metadatenbank über infoboxen abgefragt, um auszulesen, welche einträge verfügbar sind, dann könnte man aber per radiobutton anwählen. fragt sich, ob das nötig ist.

3. seitenweise anzeigen wie die whatlinks (oder das {TOC} miteinbauen, oder sortable, aber das kommt später..)

seht ihr da chancen in diese richtung? -- W!B: 17:23, 20. Apr. 2007 (CEST)

PS den code kommentieren wär vielleicht ganz hilfreich, den sinn der if ($ausgabe [$row[0]][$row[1]]=="") hab ich nicht ganz gecheckt

zu erstens: Einen Listengenerator widerspräche der Informationstechnischen Divise jede Information nur einmal zu speichern, um so einfache Änderungen zu ermöglichen. Das heißt nicht, dass ich der Idee komplett abgeneigt wäre, z.B: da wo sich Listen schon bewährt haben, aber da man mit dem Tool eine beliebige Menge von Listen erzeugen könnte und damit die Wiki-Server-DB wiederum belasten würde, bin ich zumindestens skeptisch. Statt Wikicode zu produzieren, wäre es wohl sinvoller z.B. die enthaltenen Links nutzbar zu machen. Wie auf der Projektseite geschrieben sehe ich den Templatetiger als ein Anregung für unsere echten Programmierer die Möglichkeiten der fetten Datenbank (auf der das Mediawiki sitzt) endlich voll zu nutzen. Wenn du dir folgendes ansiehst, wirst du sehen was alles möglich wäre: http://ontoworld.org/wiki/Help:Inline_queries

zu zweitens: Spaltenfilterung hatte ich von Anfang an vor, nur weiß ich noch nicht so recht wie ich die anzuzeigenden Spalten dem Programm übergebe ohne die URL zu sprengen und dabei nach Möglichkeit ein Benutzerfreundliches Formular einsetzen zu können. Erste Variante wäre hätte folgende URL: "&Spalten[Spalte1,Spalte2,...]" ein HTML-Formular mit Häckchen wirft eher sowas aus &Spalte1=yes&Spalte2=yes...., dafür habe ich noch keinen Plan zur Auswertung.

zu dritten: An serverbasiertem Sorttable arbeite ich gerade, das andere wird wohl eher nicht kommen,schließlich komm ich mit der Programmierweise des Mediawikis überhaupt nicht klar. Be der Kommentierung/Strukturierung lob ich Besserung, schon um selber überhaupt noch durchzusehen. Kolossos 19:56, 20. Apr. 2007 (CEST)

hm, bin nicht sicher ob wir uns richtig verstehen, ich glaub, wir sind eh einer meinung: ich will ja nicht wikicode produzieren um artikel zu erstellen, sondern die listenartikel ersetzen: die information steht eh je berg oder person in der infobox, wozu nochmal als liste(nartikel)? ich weiß nicht genau, wie die technologie der kategorien oder whatlinks funktioniert, aber thumbnails und TeX werden meines wissens auch "on the fly" erstellt, und dann gecached - drum bauen sich oftbesuchte seiten viel schneller auf als seltene, weil deren bilder schon lang wieder rausgeflogen sind, wenn der nächste leser kommt - mit den listen stell ich mir das genauso vor: die listen werden on the fly beim anklicken erstellt, oft besuchte listen liegen noch im cache und kommen schnell, selten genutztes dauert länger - aber hardcodierten wikicode als artikel (mit versionsverwaltung usw) gibts dann nicht mehr dafür (die last verlagert sich halt vom Websever zum Toolserver.. )

Du liest doch exakt den wikicode aus, der in der vorlage steht, also [[link]], genau das, was der WikiParser zu link macht - und dann ist er genutzt, Du liest auch [[bild.png]] aus, und das wird zu einem thumbnail konvertiert - und ist genutzt - dann brauchst Du auch nicht sortable oder sonstwas implementieren, das hat die MediaWiki schon.. (oder möchtest Du die WikiMedia in PHP nochmal implementieren?) : die frage ist, wie man die ausgabe des TemplateTiger in form eines "virtuellen artikels" als eingabe für den WikiParser nutzbar macht

Semantic MediaWiki ist mir bekannt, ich hab mich aber nicht sonderlich damit beschäftigt, und insbesondere nicht begriffen, ob es das überhaupt schon gibt.. aber ehrlich gesagt glaube ich, Euer tool ist schon das SemanticWeb (zumindest ein teil davon): ich glaub, gerade darin liegt die zukunft der Werkzeuge wie Deinem, oder CatScan, oder CoCat: schau Dir mal die abfrage an: (Liste) aller Sechtausender der Anden - und jetzt sollte CatScan eine "virtuelle Kategorie" draus bauen, und die wird dann in den TemplateTiger gepiped als auswertungsgrundlage, und dann hab ich Liste aller Sechstausender der Anden, die im 19. Jahrhundert erstbestiegen wurden, inklusive ihren Besteigern. und wenn ich jetzt statt einer liste vom TTiger eine virtuelle kategorie aus der spalte erstbesteiger bekommen, und die mit CatScan drauf teste, wer davon in der Kategorie:Franzose steht, dann hab ich eine Liste aller Sechstausender der Anden, die im 19. Jahrhundert von einem Franzosen erstbestiegen wurde, oder wenn ich sie nochmal durch den TTiger schicke, hab ich eine Liste aller Franzosen, die im 19. Jahrhundert einen Sechstausender der Alpen bestiegen haben, mit foto, lebensdaten usw: das ist doch das SemanticWeb, und DataMining vom feinsten, oder? die frage ist also, wie erstell ich "virtuelle kategorien", sodass die sql-abfrage darauf zugreifen kann..

denn imho ist genau dieser "virtuelle artikel/kategorienraum" die schnittstelle, die aus diesen werkzeugen ein web macht: sie müssten das ausgeben, was sie als eingabe erwarten -- W!B: 22:19, 20. Apr. 2007 (CEST)

Zum ersten Absatz: Ja da haben wir uns wohl mißverstanden. Nur vom Parsen des Wikicodes hab ich auch keine Ahnung und leider auch keine Zeit, das müßten andere machen. Der Toolserver ist zur Zeit eh manchmal schon ein Engpass.

Zu den virtuellen Kategorien muß ich mal eine Nacht drüber schlafen, vielleicht fällt mir dazu was ein. Kolossos 01:50, 21. Apr. 2007 (CEST)

gut geschlafen? ;) spaltenauswahl ist perfekt.. -- W!B: 23:59, 21. Apr. 2007 (CEST)

Ich habe jetzt nur den Anfang dieses Abschnitts gelesen. Bezüglich der Listen, schaut Euch mal die Extension:Semantic MediaWiki an, die kann genau das dynamisch und in den Wikicode integriert, was man auch mit einem Auswertungstool statisch erzeugen könnte, also immer wieder von neuem machen muß. --Purodha Blissenbach 23:50, 26. Dez. 2007 (CET)

Das SemanticMediaWiki ist bekannt und von mir auch in einem anderen Projekt im Einsatz, es gilt aber auch als Resourcen-hungrig und wird deshalb nicht in den großen Wikimedia-Projekten eingesetzt. Zudem ist deren Semantic etwas komplexer als unsere und hat mir schon leichtes Kopfzerbrechen gemacht ehe es lief. --Kolossos 15:50, 27. Dez. 2007 (CET)

Aktualisierung

Entweder ich hab es überlesen, oder es steht nichts drin... wie oft bzw. wann werden die Abfragen aktualisiert (interessiert mich im speziellen hier). Danke --тнояsтеn ⇔ 17:09, 27. Apr. 2007 (CEST)

Wir sind auf die Dumps angewiesen und benötigen auch etwas freie Zeit. Somit wird die Aktualisierung aller 1-2 Monate hinauslaufen, wie bei den Geo-Koordinaten auch. Für deine Fehlerhafte_Koordinaten sollte man also ein System sich erarbeiten wo man reinschreibt, "abgearbeitet" bzw. "abgearbeitet bis Fehler 123". Kolossos 17:15, 27. Apr. 2007 (CEST)

Sobald ich selber feststelle, dass ein neuer Dump da ist, oder mir jemand den Tipp gibt, und ich ein paar Minuten Zeit habe, dann aktualisiere ich die Geodaten. Meiner Meinung lohnt es sich aber auch nicht wirklich wenn ich jeden Sonntag eine Änderung machen könnte, denn die Gesamtzahl der Änderung ist sehr minimal in dieser kurzen Zeit, deshalb mache ich alle 3-5 Wochen einen Update, wenn ein Dump da ist. @Kolossos: Bring doch nochmal den ErrorChecker richtig zum laufen. Da müssten alle Koordinaten mit fehler drin sein. -- sk 17:38, 27. Apr. 2007 (CEST)

OK. Es geht mir eben darum, dass es sinnlos ist, alle Artikel zu öffnen und dann festzustellen, dass jemand anderes schon alles korrigiert hat. --тнояsтеn ⇔ 17:55, 27. Apr. 2007 (CEST)

Ich kenn das Kreuz mit der Aktualisierung. Hilfreich wäre allerdings wenn auf jeder HTML-Ergebnisseite immer der Stand der Datenbasis (Aktualisierungsdatum) steht, damit klar ist, auf welchem Stand die Auswertung ist. -- Nichtich 17:49, 2. Mai 2007 (CEST)

Ich müsste noch mal nachschauen, aber ich denke generell sollte bei jeder Vorlage der Permalink mit ausgelesen worden sein. Dann sollte dass für Kolossos kein Problem sein. Aber ich bin mir nicht sicher. Generell gute Idee! -- sk 19:32, 2. Mai 2007 (CEST)

Wenn das Tool ohnehin auf dem Toolserver läuft, warum liest es die XML Dumps und nicht die replizierten Datenbanken? Ok, der Algorithmus dafür ist ein ganz anderer und benötigt ArtikelWikiCode, der auf dem Toolserver noch nicht lange überhaupt verfügbar ist.

Aber allein der Ansatz: Suche die Artikel, die ein bestimmtes Template verwenden aus der replizierten DB, dann lade die aktuellen Daten über die Export-Schnittstelle in Happen zu N Artikeln, und zwar so selten, daß für den Toolserver pi-mal-Daumen eine Datentransferrate bei herauskommt, die in der kleiner oder gleich dem Downloaden eines Dumps ist (nur so ins Unreine gedacht) wäre doch auch ei Weg? --Purodha Blissenbach 00:01, 27. Dez. 2007 (CET)

Das ist das richtige Thema für den CCC, da es auch mein Ziel ist. Wir hatten dabei auch schon etwas mit Duesentriebs Wikiproxy herumgespielt, Stefan kam auf eine Dauer von zwei 2 Sekunden pro Artikel, womit wir bei 600.000 Artikel unmööglich langsam waren, ich kam irgendwie auch 0.2 sek, was sich aber auch schon zu 33 Stunden alleine für de aufsummiert. Mal sehen, was da möglich ist. --Kolossos 15:32, 27. Dez. 2007 (CET)

Super Sache

Ich wollte euch einfach mal ein Lob aussprechen, für das, was ihr hier auf die Beine gestellt habt. Nicht nur für das Projekt an sich, sondern auch für die ausführliche Dokumentation und Erklärung der Abläufe. Da lässt sich sicherlich noch mehr daraus machen, insbesondere in Kombination mit ähnlichen Projekten.

Weiter so!

Maziminke 03:42, 1. Jun. 2007 (CEST)

Besten Dank für das Lob! -- sk 10:11, 1. Jun. 2007 (CEST)

Dieses Lob möchte ich auch nochmal unterstreichen und unterschreiben --Diwas 01:44, 2. Jun. 2007 (CEST)

Dann auch noch mal Danke an dich. Es freut uns, wenn die Mühe sich gelohnt hat und einige Benutzer damit was anfangen können. :-) -- sk 09:08, 2. Jun. 2007 (CEST)

Ich möchte auch danke sagen. Mit dem Templatetiger war es ganz einfach, falsch eingetragene ISINs aus den Infoboxen "Unternehmen" zu fischen. --Echoray 18:36, 2. Jan. 2008 (CET)

Übersetzungstool

Kann bitte jemand das neue, kleine Übersetzungstool von mir mal testen. Beim Template-choice auf "Translate" gehen, dann die Sprache auswählen in die man übersetzen will. Nun erscheint eine Tabelle wo links die Ausgangsparameter stehen, rechts steht der neue Vorlagenname und die neuen Parameternamen. Die in der Ausgangsvorlage benutzte Variablennamen können über "Parameter" nachgeladen werden. Nun müssen diese Variablennamen so übersetzt werden, dass sie mit der Zielvorlage übereinstimmen. Anschließend auf SAVE gehen und danach sich die neuen Vorlagen unter TRANSLATION anschauen. Da es sich dabei um den normalen Template-tiger (nur ergänzt um die "trans=..." und "format=template") handelt, stehen alle anderen bekannten Parameter und Möglichkeiten zur Verfügung. Wenn das Ergebnisse geprüft ist, sollte es Stück für Stück in die Wikipedia der Zielsprache kopierbar sein, wo es dann hoffentlich nur minimal modifiziert werden muß.

Für die Nutzung der Interwikilinks sehe ich im Moment leider keinen Weg da man dazu in eine andere Datenbank wechseln müßte, wo ich noch nicht weiß wie/ob das geht. Zusätzlich könnten auch die einzelnen Werte übersetzen. Den Quelltext stelle ich auch zur Verfügung. Mich würde auch interessieren ob diese Vorgehensweise für Transferaufgaben anwendbar erscheint und wenn ja für welche Vorlagen. Natürlich müssen Ausgangs- und Zielvorlage sehr ähnlich sein. Vorteilhaft ist es zudem wenn es sich bei den Werten um viele Zahlen handelt, so wie es bei PKW's und Galaxien der Fall ist. Auch wäre es interessant zu erfahren, ob die Arbeitsweise verständlich ist und wo es noch Verbesserungbedarf gibt? --Kolossos 22:13, 3. Sep. 2007 (CEST)

Beispiel: Ich hab mal eine Übersetzung der engl. Film-Infoboxen ins deutsche unter folgender Seite angelegt:

• http://tools.wikimedia.de/~kolossos/templatetiger/template-trans.php?tolang=de&fromlang=en&fromtemplate=Infobox+Film

Das Ergebnis ist damit unter folgender Seite einsehbar:

• http://tools.wikimedia.de/~kolossos/templatetiger/tt-table4.php?template=Infobox%20Film&lang=en&format=template&trans=de

Nun müßte man nur noch den Links in die englische Wikipedia folgen und und über die Interwikilinks nachschauen ob in der deutschen Wikipedia noch eine Infobox fehlt und dann die angezeigten Ergebnisse reinkopieren, prüfen und leicht anpassen. Auch wenn das Verhältniss von engl. zu deutschen Filminfoboxen bei 23.000 zu 7.000 liegt, erscheinen die deutschen Artikel gut ausgestattet zu sein, zumindestens hab ich keine fehlenden Infoboxen gefunden, aber es sollte ja auch nur ein Beispiel sein. In einem solchen Fall kann es sinnvoll sein, die Auswahl über Catscan oder anderweitig einzugrenzen, allerdings ist die engl. Wikipedia Datenbank mit 23 Mio. Einträgen so monströs, das das ewig dauert, also kann man es in einem solchen Fall die Übersetzung gleich manuell vornehmen, naja.

Ein besseres Beispiel ist wohl die Übersetzung der PKW-Infoboxen:
http://tools.wikimedia.de/~kolossos/templatetiger/tt-table4.php?template=Infobox%20Automobile&lang=en&format=template&trans=de Das das Tool jedoch in jede beliebige Sprache übersetzt sollte es genügend Anwendungsmöglichkeiten gäben. Wobei "Übersetzen" zuviel gesagt ist, es werden nur Strings ausgetauscht. --Kolossos 19:41, 4. Sep. 2007 (CEST)

Typo im Tool: seperated be "|" should be separated by "|" --Purodha Blissenbach 01:06, 27. Dez. 2007 (CET)

Erledigt. Danke. --Kolossos 15:25, 27. Dez. 2007 (CET)

Neue Daten und Speed

Die Sprachen de,cs,es,fi,fr,nds,pt und ru sind jetzt eingespielt. Da ich einmalig die Nutzungsanzahl der einzelnen Vorlagen in jeweils eine eigene zusätzlich Tabelle schreibe und diese dann wiederholt nutze dürfte das Programm geschwindigkeitsmäßig kaum wiederzuerkennen sein (Es ist jetzt schnell). Jetzt könnten wir Leute für eine internationale Zusammenarbeit gebrauchen. Oder wer kann das Programm bekannt machen? Kolossos 23:08, 18. Apr. 2007 (CEST)

Interessante Erkenntnisse / Trivia

Ich wollte mal hier eine Liste beginnen, um zu sammeln was es so zu entdecken gibt, ohne die Projektseite aufzuweichen, die Liste kann gerne ergänzt werden (Kolossos 17:02, 27. Apr. 2007 (CEST)) :

• 880 Waffen-Infoboxen in en Braucht das ein internationales Projekt, welches die Welt verbessern will wirklich?

• 46069 Musikalben in en Ist zwar auch wahnsinnig viel, tuen aber zumindestens keinem weh.

• Spanische Taxoboxen, die Spanier sind meines Wissens die einzigsten mit vernüftigen Taxoboxen für Lebewesen. Ok, habs entdeckt, es gibt wesentlich mehr englische Taxoboxen, namlich 33444. Dazu kommen dann noch 493 Pokémon species.

• Die Russen scheinen sich besonders für Galaxien zu interessieren.

• ...

betrifft Vorlage_Diskussion:Infobox_Flughafen#Parameter_Logo

Beteiligt euch an der dortigen Diskussion, wenn ihr ohne große Mühen Vorlage:Infobox Flughafen auslesen wollt. --BLueFiSH ✉ (Langeweile?) 16:24, 16. Jul. 2007 (CEST)

en wiki dump

Great project! BTW in case you are interested, an new dump is available at http://download.wikimedia.org/enwiki/20070716/ -- User:Docu

Thanks for this info. Yesterday I download the new dump. And tomorrow I will start the new script run. Maybe next week User:Kolossos has time to update the database. -- sk 13:28, 22. Jul. 2007 (CEST)

Thank you for updating it. Great! -- User:Docu