Wikipedia Diskussion:WikiProjekt Georeferenzierung/Geohack encoding 2018

moved here from Wikipedia Diskussion:WikiProjekt Georeferenzierung#Workaround für Problem mit OSM / kmlexport / bestimmten Zeichen (it's getting big - feel free to add some structure) --Herzi Pinki (Diskussion) 11:06, 15. Apr. 2018 (CEST)

Workaround für Problem mit OSM / kmlexport / bestimmten Zeichen

• Siehe Benutzer_Diskussion:Plenz/OSM_for_Wiki#Kodierungsproblem_bei_OSM_for_Wiki
• @X:: black ::X, Plenz, Dvorapa:

X:: black ::X, danke für deine Analyse. Hat mich auf folgenden Ansatz für einen Workaround gebracht: [1]

In lang: Bestimmte Zeichen, wie typographisch richtige Hochkommata und Halbgeviertstriche, aber auch Zeichen aus den slawischen Alphabeten verursachen das Problem, dass die Anzeige in der OSM Karte verschissen ist und der backlink nicht funktioniert. Man könnte das unten im kmlexport richtig machen, ..., aber niemand mag das angreifen. Und es gibt Heerscharen, die die WP mit typographisch korrekten Schreibweisen zupflastern. Mein Ansatz für einen Workaround verhindert, dass bestimmte Zeichen an den Geohack weitergereicht werden. Und verhindern damit, dass das Problem auftritt. Das typische Problem bei den diversen Listen (Naturdenkmäler, Denkmäler, etc.) sind die Zeichen im Parameter Name / name o.ä. Dieser Parameter wird für 3 unterschiedliche Dinge verwendet:

• zur Anzeige der Objektbezeichnung in der Liste (hier wäre korrekte Typographie besser)
• als name in {{Coordinate}} (hier ist korrekte Typographie schlecht)
• zur Definition eines Ankers auf die jeweilige Tabellenzeile (sollte mit dem Namen, der an Coordinate übergeben wird, übereinstimmen - sonst funktioniert der backlink nur auf Seiten-, nicht aber auf Tabellenzeilenebene)

Der Workaround oben ist nicht perfekt, weil der Anker nicht denselben Transformationen unterworfen wird (auch schon vor meinen Workaround), wie der Parameter name für Coordinate, das lässt sich aber lösen und ist nur meiner Faulheit geschuldet, ich mag nach dem Proof of Concept zuerst eine Lösung mit euch finden, die allgemeiner ist.

Ich habe daran gedacht, das Problem unten in {{Coordinate}} zentral zu lösen, aber dann bleibt das Problem der Nichtübereinstimmung mit dem Anker. Also denke ich, die Zeilenvorlage ist die richtige Stelle, Anker und Name für Coordinate sind synchron zu halten. Betrifft zwar einige Vorlagen, aber so viele sind es dann auch wieder nicht. Pech haben halt die Seiten, die Coordinate direkt aufrufen (aktuell ~730).

Meine Fragen an euch mit der Bitte um mitdenken:

• gibt es eine Zuordnungstabelle, die möglichst umfassend die problematischen Zeichen auf lesbare Ersatzdarstellungen konvertiert? Die Lesbarkeit ist wichtig, da die modifizierten Namen im Geohack auftauchen.
• meine Implementierung ist gaga, weil nicht beliebig erweiterbar (PoC), ich tendiere Richtung einer zusätzlichen Funktion in Wikipedia:Lua/Modul/WLink, die das getPlain gleich miterledigt. @PerfektesChaos:
• Alternativ / zusätzlich könnte man doch den hack auch an passender Stelle in {{Coordinate}} aufrufen (um den Preis der ev. kritischen Codeaufblähung), das würde dann auch für manuell gesetzte namen (ohne Vorlageneinschalung) funktionieren, um den Anker müsste man sich trotzdem und leider an ganz anderer Stelle kümmern.

lg --Herzi Pinki (Diskussion) 13:43, 16. Mär. 2018 (CET)

• Ich habe die Problemschilderung nur in dunklen Nebeln verstanden.
• Erster Schritt wäre eine präzise Beschreibung der Situation; tabellarisch an mehreren charakteristischen Beispielen:
  1. Was ist der Eingabetext aus dem Artikel?
  2. Was genau wird daraus für welche Nutzung benötigt?
• Es gibt schon was, das in änliche Richtung geht: Modul Sort
  • latinDIN5007m2 für Telefonbuch
  • normale Sortierung (macht schon mal aus Halbgeviertstrichen ASCII; suche nach 8211)
  • Kann ich mir für Typografisch→ASCII vorstellen, gesondert oder erweitert.
• Eine Auflistung konkreter Sorgenkinder wäre nötig.

LG --PerfektesChaos 15:22, 16. Mär. 2018 (CET)

geh, ganz oben ist das sehr konkret verlinkt. Besser könnte ich es hier nicht wiederholen, auch weil ich mir nicht die ganze Mühe gemacht habe, das wirkliche Problem im Detail zu verstehen. Und die gaga Lösung ist {{Kmlexport hack}}. Entschuldige, ich habe mitten in meinem Text den Dschinn gerufen. Ich brauche eine einfache, erweiterbare Zeichensubstitution, die auf das Ergebnis von Wikipedia:Lua/Modul/WLink#getPlain noch folgende Ersetzungen durchführt:

• s/[„“]/"/g
• s/–/-/g #halbgeviert
• und weitere (kann ich aktuell nicht abschätzen), aber etwa
• s/Č/C/g
• s/č/c/g

Es geht um alle Zeichen, die mit mehr als 2 bytes url-kodiert werden, für die es eine sinnvolle Ersatzdarstellung gibt und die mit einiger Wahrscheinlichkeit in der de:WP vorkommen. Grundsätzliche Kritik am Vorgehen ist natürlich auch willkommen. lg --Herzi Pinki (Diskussion) 16:23, 16. Mär. 2018 (CET)

Wau, ich muss sagen, dass ich keine Idee über eine Lösung gehabt habe, aber seine Lösung ist sehr klug. Es ist schwer die Lösung implementieren, weil so viele diakritische Zeichen ersetzt müssen sein. čČ sind nur zwei aus vielen anderen, die das Problem in den slawischen Wikipedias (Tschechische) bewirken. Ich glaube, dass etwa (Lua, Toolforge, andere) Unicode->ASCII Übersetzungsmodul im Vergleich zu diesem Hack ein bisschen besser wurde (haben wir solches Modul irgendwo bereit?). (entschuldigen sie bitte meine schlechte Deutschsprachkenntnisse) --Dvorapa (Diskussion) 17:43, 17. Mär. 2018 (CET)

Dvorapa, thanks for your comment, I was starting my comment in English first, but then decided to switch to the common language here. I give my answer for you in English, but will continue to write German here otherwise. čČ was just an example, yes, it will be work to get a complete translation table, and I will be happy if someone tells me where to get one. I do not believe that this will work in all cases, e.g for czech, are you confident, that there is a sound replacement for native czech people for all critical characters (as a rule of thumb: diacritical characters are critical characters)? But we can improve things in most cases. --Herzi Pinki (Diskussion) 18:00, 17. Mär. 2018 (CET)

Another possibility could be to ask for rights to abandoned kmlexport tool and find somebody, who programs in Perl and could fix the bug (but also become a maintainer of kmlexport tool for the future). I asked Czech/Slovak technicians if they know some Unicode->ASCII converter. For Czech/Slovak/Polish languages č->c and similar should be ok solution (not best, but ok). --Dvorapa (Diskussion) 18:22, 17. Mär. 2018 (CET)

as this might take longer (Nevertheless, to find someone who maintains / rewrites the tool, is the best way to go), lets head for the workaround in the meantime. I think you can keep your čČ, as they encode as 2-byte. best --Herzi Pinki (Diskussion) 19:21, 17. Mär. 2018 (CET)

{{#invoke: Sort|Tlatin|1=„č–ČÄß“}}: "c-CAss" ist zuviel. čČ sollte keine Probleme bereiten, da die Utf-8 Kodierung mit 2 Bytes auskommt. @PerfektesChaos: wir brauchen eine Funktion, die ausgehend von Sort Tlatin und Modul:Sort/latin alle 3 Byte Character wie gehabt behandelt, die anderen aber unverändert lässt. Soweit ich das begreife, sind das die Zeichen mit einem Code > 2048 (dezimal). Aus der Konversionstabelle Modul:Sort/latin wären also alle 2 Byte character zu streichen und der verbleibende Rest sollte wie folgt aussehen:

return {
-- 2 byte characters omitted
[  5760] = " ",  -- OGHAM SPACE MARK
-- 2 byte characters omitted
[  8192] = " ",  -- EN QUAD
…
[  8722] = "-",  -- MINUS sign
-- 2 byte characters omitted
[  7838] = "SS", -- CAPITAL SHARP S
…
[  7935] = "y",  -- y with loop
-- 2 byte characters omitted
[  6158] = "",   -- MONGOLIAN VOWEL SEPARATOR
…
failsafe = Serial
};

Einen sinnvollen Namen dafür überlasse ich dir. Sieht doch schon fast nach einer Spezifikation aus. Könntest du bitte sowas bereitstellen, wenn nicht, kann ich auch selber hingreifen, weiß allerdings nicht, wie der Mechanismus mit der Mutterversion funktioniert. lg --Herzi Pinki (Diskussion) 19:21, 17. Mär. 2018 (CET)

• Actually the issue is not to remove characters.
• The question is: Which characters do you want to keep? And being translated into which others?
• The following code is removing all the three byte UTF-8 things you are complaining about:

p.removeHighChars = function ( frame )
    local pattern = mw.ustring.char( 93, 0x0800, 45, 0x1FFFF, 95 )
    return mw.ustring.gsub( frame.args[ 1 ], pattern, "" )
end

• You might put that into some Module:Benutzer:Herzi Pinki and play around a bit (never tested, but should work).
• Within the two byte UTF-8 limitation all latin, greek, cyrillic, arabic, hebrew and armenian letters are maintained.
• The remaining issue would be to preserve some typographic punctuation (dash and quotation mark) by ASCII simplification? Next week more.

Greetings --PerfektesChaos 12:09, 18. Mär. 2018 (CET)

I got a response, that some translation module is already used on Wiktionary. --Dvorapa (Diskussion) 14:44, 18. Mär. 2018 (CET)

Das Kodierungsproblem im Tool kmlexport ist leider nicht ganz eindeutig entschlüsselt. Bei Tests auf der Wikipedia:Spielwiese (die inzwischen teilweise auch in der Versionsgeschichte gelöscht sind) mit dem Tool osm4wiki (OSM for Wikipedia) habe ich herausgefunden, dass in der de-Wikipedia die im Unicode in mehr als einem Byte kodierten Schriftzeichen – ’ „ “ — € ‚ … † ‡ ‰ ‹ › ‘ • ™ č ć š ě ů Ā α ؠ (Anmerkung: das erste der aufgelisteten Schriftzeichen ist ein Halbgeviertstrich (–), das fünfte ein Geviertstrich (—), das siebte U+201A (‚)) defintiv das Problem auslösen können; übergibt man osm4wiki jedoch den Titel einer Kategorie als Parameter article, in der der betreffende Artikel eingeordnet ist, so tritt das Problem nicht auf und die Schriftzeichen werden korrekt dargestellt (siehe https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&l=0&article=Kategorie%3ASchiffswrack in der sich in den Zeilen Wrack der „Admiral Nachimow (1885)“, Wrack der „City of Rio de Janeiro“, Wrack der „HMS Swordfish (61S)“, Wrack der „HMS Umpire (N82)“, Wrack der „HMS Vandal (P64)“, Wrackposition der „Ostmark“ jeweils die Zeichen „ und “ befinden und hier auch korrekt dargestellt werden, im Gegensatz zu z. B. https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=City%20of%20Rio%20de%20Janeiro). (Im übrigen wird beim Auslesen über eine Kategorie die jeweils aktuellste Artikelversion ausgelesen, auch wenn sie ungesichtet ist, beim Auslesen über den Artikeltitel wird die aktuellste gesichtete Version ausgelesen.)
Nach meinem derzeitigen Erkenntnisstand können alle Schriftzeichen, die im Unicode in mehr als einem Byte kodiert sind (also alle Zeichen ab U+0100 aufwärts), in der de-Wikipedia das Problem auslösen, wenn sie im Wert des Parameters title des URL des Links zum GeoHack stehen. Sie lösen das Problem (oft, vermutlich immer) aus, wenn man per osm4wiki direkt den Wikipedia-Artikel ausliest, sie tun es (vermutlich) nicht (oder nur selten), wenn man per osm4wiki einen Wikipedia-Artikel über eine seiner Kategorien ausliest. Warum das Problem in der cs- und in der ja-Wikipedia mal auftritt und mal nicht ist unklar, die Auslöser sind hier aber höchstwahrscheilich andere, möglicherweise verwendet kmlexport für die de-Wikipedia ISO-8859-1 oder Windows-1252 und für andere Wikipedias entsprechende andere Standards zur Zeichenkodierung. Wenn ein Zeichen das Problem auslöst, erstreckt sich das Problem auf den Wert des Parameters title eines jeden Links zum GeoHack auf dieser Wikipedia-Seite (also nicht nur des Links, in dem das problemauslösende Schriftzeichen steht, sondern auch andere GeoHack-Links mit anderen Koordinaten, sofern sie sich in der gleichen Wikipedia-Seite befinden). Schriftzeichen, die sowohl im Unicode, als auch in der UTF-8 basierten URL-Encoding in nur einem Byte kodiert sind (ASCII-Zeichen) können das Problem weder auslösen, noch sind sie selbst von dem Problem betroffen, wenn ein anderes Zeichen es auslöst. Schriftzeichen, die im Unicode in einem Byte, in der UTF-8 basierten URL-Encoding aber in mehr als einem Byte kodiert sind (z. B. ä ö ü ß á é í ó ú ý à è ù ÿ, können das Problem nicht selbst auslösen, sind aber von dem Problem betroffen, wenn ein anderes, im Unicode in mehr als einem Byte kodiertes Schriftzeichen im Wert des title-Parameters eines Links zum GeoHack auf der gleichen Seite das Problem auslöst. Nach diesem Erkenntnisstand können in der de-Wikipedia die Schriftzeichen des Unicodeblockes Basis-Lateinisch (U+0000–U+007F) sowie jene des Unicodeblockes Lateinisch-1, Ergänzung (U+0080–U+00FF) kein Problem auslösen, alle anderen potentiell schon.
Bei von mir kürzlich, auf der Spielwiese der cs-Wikipedia cs:Wikipedie:Pískoviště, durchgeführten Test haben im Unicode in mehr als einem Byte kodierten Schriftzeichen dann das Problem verursacht, wenn sie in der Überschrift eines Abschnittes (einschließlich Unterabschnitt, Unter-Unterabschnitt usw., wobei jeweis nur der niedrigste relevant ist) stehen, in dem die Vorlage cs:Šablona:Souřadnice (das cs-Wikipedia-Pendant zur Vorlage:Coordinate) eingebunden ist. Stehen die Zeichen im Parameter název von cs:Šablona:Souřadnice (dem Äquivalent zum Paramter name der Vorlage:Coordinate), verursachen die Zeichen das Problem nicht (sind aber bei anderweitiger Verursachung davon betroffen, wenn sie in der UTF-8 basierten URL-Encoding in mehr als einem Byte kodiert sind). Sichtbar wird das Problem z. B. bem Artikel cs:Středověké památky v Kosovu, in dem der Buchstabe ř in der Abschnittsüberschrift, und beim Artikel cs:Seznam kostelů v Brně, in dem der Buchstabe Ř in der Unterabschnittsüberschrift das Problem auslösen. Da im Artikel cs:Seznam chráněných území v okrese Havlíčkův Brod die cs:Šablona:Souřadnice nur außerhalb von Abschnitten eingebunden ist, tritt das Problem hier nicht auf. Unklar ist, was das Auftreten des Problems im Artikel cs:Azory verhindert (näheres siehe hier). Auch in der ja-Wikipedia tritt das Problem manchmal auf und manchmal nicht.
Für das Problem existiert phabricator:T187625.
Der GeoHack (auf den der von der Vorlage:Coordinate erzeugte Link zeigt) stellt alle Schriftzeichen korrekt dar, funktioniert mithin mit dem Satus Quo gut (dies gilt ebenso für osm4wiki und wp-world/googlmaps-proxy.php, wenn diese auf Kategorien angesetzt werden); da kmlexport aber genau diese Links auf den GeoHack ausliest, dürfte ein Workaround ohne Änderungen in kmlexport nur durch Veränderung des Wertes im title-Parameter des Links zum GeoHack (der mit dem Wert im name-Parameter der Vorlage:Coordinate gefüllt wird) möglich sein. Das bedeutet, dass man, bei Implementierung eines solchen Workarounds, auf die mögliche und derzeit erfolgende, typographisch korrekte Darstellung im GeoHack zukünftig – zugunsten der Vermeidung von Zeichenkodierungsproblemen in kmlexport – verzichten würde. --X:: black ::X (Diskussion) 02:28, 19. Mär. 2018 (CET), korrigiert 03:33, 19. Mär. 2018 (CET), präzisiert 09:38, 19. Mär. 2018 (CET), ergänzt 10:59, 19. Mär. 2018 (CET) und 11:31, 19. Mär. 2018 (CET), überarbeitet 13:31, 20. Mär. 2018 (CET), korrigiert 16:49, 20. Mär. 2018 (CET), erweitert 00:42, 21. Mär. 2018 (CET), korrigiert 11:51, 6. Apr. 2018 (CEST)

nochmals danke, zum letzten Absatz: ich denke, dass primitiv falsche Typographie das geringere Problem gegenüber nicht funktionierenden Links ist. Aber auch deshalb natürlich will ich das breiter diskutieren.

Ich habe mal geschaut, was in der Datenbank drinnen steht (https://quarry.wmflabs.org/query/25680) und es steht im Fehlerfall wie im OK-Fall strukturell derselbe Text drinnen.

Liste	OSM link	geohack link in der DB (strukturell ident)	backlink aus OSM	Fehler
Graz/Andritz	https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=Liste_der_Kunstwerke_im_%25C3%25B6ffentlichen_Raum_in_Graz%2FAndritz	https://tools.wmflabs.org/geohack/geohack.php?pagename=Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Andritz&language=de&params=47.099194_N_15.42_E_region:AT-6_type:landmark&title=Trink-Brunnen,+Grazer+Stra%C3%9Fe+34e	https://de.wikipedia.org/wiki/Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Andritz#Trink-Brunnen,_Grazer_Stra%EF%BF%BDe_34e	richtige Seite, falscher Anker
Graz/Gries	https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=Liste_der_Kunstwerke_im_%25C3%25B6ffentlichen_Raum_in_Graz%2FGries	https://tools.wmflabs.org/geohack/geohack.php?pagename=Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Gries&language=de&params=47.068333_N_15.42_E_region:AT-6_type:landmark&title=Fr%C3%BCchte+des+Feldes,+Eggenberger+G%C3%BCrtel+36	https://de.wikipedia.org/wiki/Liste_der_Kunstwerke_im_%C3%83%C2%B6ffentlichen_Raum_in_Graz/Gries#Fr%C3%BCchte_des_Feldes,_Eggenberger_G%C3%BCrtel_36	falsche Seite, richtiger Anker (nützt nix)

Was noch auffällt:

• in der zweiten Liste treten relevante typographische Zeichen auf, allerdings nicht im konkreten Eintrag.
• Die Information gibt es an (mindestens?) zwei Stellen, Tabelle externallinks & geo_tags. kmlexport ist alt und holt die Daten ziemlich sicher aus externallinks, geo_tags ist jüngeren Datums.
• In externallinks stehen die Daten doppelt drinnen. Keine Ahnung warum.

Kategorien wie Kategorie:Schiffswrack würde ich momentan außen vor lassen, ist ein anderer Fall und vermutlich auch anders implementiert. Außerdem funzt es. Detto japanisch und Konsorten. lg --Herzi Pinki (Diskussion) 23:25, 19. Mär. 2018 (CET)

Hallo Herzi Pinki, die Liste der Kunstwerke im öffentlichen Raum in Graz/Andritz enthält keine potentiell problemauslösenden Zeichen (siehe meine überarbeitet, jetzt hoffentlich klarere Beschreibung oben), ä und ü können das Problem nicht auslösen, das sie im Unicode in einem Byte kodiert sind (U+00E4 und U+00FC). Die Liste der Kunstwerke im öffentlichen Raum in Graz/Gries enthält mit den Anführungszeichen „ und “ sowie dem Halbgeviertstrich – im Unicode in mehr als einem Byte kodierte Zeichen (U+201E, U+201C und U+2013), die das Problem auslösen, wovon dann alle in der URL-Encoding in mehr als einem Byte kodierten Schriftzeichen betroffen sind (also auch ü, ä, ß und ö [%C3%BC, %C3%A4 , %C3%9F und %C3%B6]); daher ist für mich nachvollziehbar, dass in diesem Fall in der Datenbank strukturell derselbe Text drin steht.
Was meinst Du mit „allerdings nicht in konkreten Eintrag“? (In der Spalte el_to steht die entprechende URL-Kodierung [%E2%80%9E für „, %E2%80%9C für “ und %E2%80%93 für –].)
Außerdem ist mir aufgefallen, dass in https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Andritz , wo das Problem ja nicht auftritt, der Backlink zum Eintrag „Trink-Brunnen, Grazer Straße 34e“ nur auf Seitenebene, aber nicht auf der Ankerebene funktioniert, da als URL fälschlicherweise https://de.wikipedia.org/wiki/Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Andritz#Trink-Brunnen,_Grazer_Stra%EF%BF%BDe_34e statt https://de.wikipedia.org/wiki/Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Andritz#Trink-Brunnen,_Grazer_Stra%C3%9Fe_34e verlinkt ist (also %EF%BF%BD statt dem korrekten %C3%9F zur URL-Kodierung des ß im Wort Straße). Es kann durchaus sein, dass dieser Fehler im Tool osm4wiki (OSM for Wikipedia) verursacht wird, siehe hier. --X:: black ::X (Diskussion) 16:49, 20. Mär. 2018 (CET), korrigiert 16:57, 20. Mär. 2018 (CET), ergänzt 00:42, 21. Mär. 2018 (CET)

nicht im konkreten Eintrag heißt, dass ein falsches Zeichen irgendwo in der Liste alle backlinks unbrauchbar macht. Das entspricht deiner Beobachtung (ich habe es nur dazugeschrieben, weil an dem einen Eintrag nicht zu erkennen). Ansonsten beschreibst du in Worten, was ich oben mit meiner Tabelle sagen wollte. Dass strukturell derselbe Text drinnen steht, beweist, dass der Fehler nicht beim Schreiben der geohack-Links in die DB passiert (was ja hätte sein können). Auch der Anker ist in der DB mE richtig kodiert (in beiden Fällen). Die letzte Spalte meiner Tabelle beschreibt, dass in beiden Fällen der url falsch ist, einmal der Seitenteil (fällt klarerweise eher auf), das andere Mal der Ankerteil. Ich hätte auch dafür den kmlexport verantwortlich gemacht, aber noch nicht genauer drüber nachgedacht. War nur so als Hinweis gemeint, dass es da zwei Probleme gibt, ev. mit gleicher oder ev. mit unterschiedlicher Ursache - sowas kann ja bei der Analyse nützlich sein. Ich kämpfe gerade mit der Zeichenersetzung in lua, Bytegepfriemel. lg --Herzi Pinki (Diskussion) 18:50, 20. Mär. 2018 (CET)

so, es gibt einen verbesserten Hack: Modul:Benutzer:Herzi Pinki/kmlhack und Benutzer:Herzi Pinki/kmlhack. Feedback willkommen. @PerfektesChaos: wohin damit? @X:: black ::X, Dvorapa:. Eingebaut in {{WLPA-AT-Zeile}}, wirksam in Graz/Andritz und Graz/Gries. lg --Herzi Pinki (Diskussion) 22:11, 20. Mär. 2018 (CET)

• I presume the function p.kmlhack() is supposed to become active in the productive pages.
• Functionality in a nutshell: Replace listed characters by ASCII surrogates, then remove everything from 0x0800 up.
• The prototype module contains two bugs and one serious inefficiency.
• The next few days I will find a internationalizable robust efficient global solution, implement that and document it.

Greetings --PerfektesChaos 15:19, 21. Mär. 2018 (CET)

Hallo Herzi Pinki, in Modul:Benutzer:Herzi Pinki/kmlhack stehen als codeReplacements
[ 160] = " ", -- nbsp
[ 171] = "\"", -- laquo
[ 187] = "\"", -- raquo.
Die Zeichen von 0 bis einschließlich 255, also auch die Zeichen 160, 171 und 187 lösen das Problem nicht aus und sollten daher auch nicht ersetzt werden. --X:: black ::X (Diskussion) 15:41, 21. Mär. 2018 (CET)

habs geändert. --Herzi Pinki (Diskussion) 23:50, 21. Mär. 2018 (CET)

re

• I have established Module:Coordinates/kml (WP:BETA).
• Please feel free to test whether that matches your needs.
• Greetings --PerfektesChaos 15:34, 22. Mär. 2018 (CET)

um was zu lernen: was waren die zwei bugs und die serious inefficiency? lg -Herzi Pinki (Diskussion) 16:05, 22. Mär. 2018 (CET)

1. s = mw.text.decode(frame.args[ 1 ], decodeNamedEntities );
s = mw.text.decode(frame.args[ 1 ], true );
decodeNamedEntities ist etwas, das du mit nicht-nil nicht-false belegen müsstest, sonst sinnfrei.
2. local res, n = mw.ustring.gsub( s, pattern, charReplacements )
local res, n = mw.ustring.gsub( res, pattern, "" )
   Das zweite local res überschreibt die erste Definition als neue Variable, weshalb die erste wirkungslos bleiben und die zweite mit undefinierter Eingabe arbeiten könnte; zumindest schwer vorherzusagen. Falls es trotzdem funktioniert hatte, dann nur, weil auf der rechten Seite die zuvor angelegte Variable noch ausgewertet wurde. Jedes local verdeckt alle bisherigen local, was zumindest bei einer Verschachtelung zur Unsichtbarkeit der äußeren führt. Jeder name darf in einem Kontext nur ein einziges Mal ein local erhalten, sonst völlig undurchschaubar.

• if mw.ustring.find( r, pattern ) then
  Wenn es überhaupt nix am tun gibt, dann auch keinen Aufriss veranstalten.

LG --PerfektesChaos 16:35, 22. Mär. 2018 (CET)

I have tested & copied your script to Module:Coordinates/kml. It does what I think is needed. I will now replace my script with yours. thanks --Herzi Pinki (Diskussion) 00:54, 26. Mär. 2018 (CEST)

ich war mutig und habe den hack zentral eingebaut. Es verbleiben die folgenden Probleme:

• Umlaute im Anker ([2]: Fundstelle (Latènezeit) und Grabhügel beim Aichberger, Aichberg)
• Abschneiden des Ankers bei " ([3]: Kruzifix/Kreuz, "Kreuzigungsgruppe", bei Hörmsdorf 23)

lg --Herzi Pinki (Diskussion) 12:30, 26. Mär. 2018 (CEST)

• @Dvorapa: Please find further instructions at Wikipedia:Lua/Modul/Coordinates/en.
• @Herzi Pinki
  1. Etwas Hausmeisterei:
     • Seitenschutz Modul:Coordinates/kml + Modul:Sort/utf8max2bytes – edit=Dreiviertel, move=sysop
     • SLA WL
     • A/A, wenn du schon grad dabei bist: Bitte BETA über MediaWiki:Editnotice-10 drüberkopieren (kleine Optik).
  2. Warst du dieser hier?

Greetings --PerfektesChaos 17:50, 26. Mär. 2018 (CEST)

done, ich war dieser dort, danke für die erweiterten Rechte. lg -- 18:36, 26. Mär. 2018 (CEST)

Die „erweiterten Rechte“ hast du erst durch diese Rückmeldung bekommen; das davor war nur die Grundausstattung für bekannte Nicks.

Von meiner BD zuständigkeitshalber zur Erledigung hierher:

Ich denke deine Bearbeitung hat dazu geführt das Sprachvergleich anhand des Vaterunsers in der Kategorie:Wikipedia:Koordinaten-Parameterfehler steht. Die Namen mehrerer Koordinaten werden nicht mehr angezeigt. --2003:DE:71D:6E6E:7D29:7B45:C8F6:6B1F 20:16, 26. Mär. 2018 (CEST)

LG --PerfektesChaos 21:11, 26. Mär. 2018 (CEST)

ist ja gar nicht so viel, kümmer mich drum. lg --Herzi Pinki (Diskussion) 22:20, 26. Mär. 2018 (CEST)

Ad Herzi Pinki: Von den beiden, von Dir erwähnten, verbleibenden Problemen ist ersteres (falsche URL-Kodierung von Sonderzechen) aller Wahrscheinlichkeit nach eines von osm4wiki, letzteres (Abschneiden des Ankers bei ") vermutlich eines von kmlexport (siehe hier).
Ad PerfektesChaos: Concerning internationalization, every interested wikipedia community first has to find out, where exactly the problem is caused in its language version of wikipedia. E. g. as in the cs-wikipedia, the problem is caused by the headings of the sections, subsections or sub-subsections (in each case only the lowest one is relevant) a cs:Šablona:Souřadnice is in (see above and here), this workaround would not solve the problem in the cs-wikipedia, if adopted there.
Ad Herzi Pinki und PerfektesChaos: Das Problem wird von Schriftzeichen ab Unicode 0x0100 (hexadezimal) aufwärts verursacht (siehe oben) (nicht nur von Schriftzeichen ab Unicode 0x0800 [hexadezimal] aufwärts, wie ursprüglich mal vermutet). Die derzeit realisierte Version des Workarounds reduziert das Auftreten des Problems in der de-wikipedia erheblich, schließt es aber nicht völlig aus. Im Falle einer entprechenden Umstellung würde sich für den Bereich 0x0100 bis 0x07FF (hexadezimal) (= 256 bis 2047 dezimal) die Frage nach adäquaten Ersetzungen durch andere Schriftzeichen aus dem Bereich 0x0000 bis 0x00FF (hexadezimal) stellen; diesbezüglich sind am ehesten die Unicodeblöcke Lateinisch, erweitert-A und Lateinisch, erweitert-B, eventuell auch Spacing Modifier Letters relevant, ich kann aber nicht sagen, ob es in jedem Fall sinnvoll ist, das jeweilige Zeichen durch den oder die in der offiziellen Bezeichnung angegebenen Basis-Buchstaben zu ersetzten. Bei anderen Alphabeten (0x0370 bis 0x07FF, z. B. griechisch oder kyrillisch) könnte sich allerdings ebenfalls die Frage stellen, ob es sinnvoll ist, einzelne Buchstaben ins deutsche Alphabet zu transkribieren (nebenbei würde man damit von „utf8max2bytes“ (wie in Modul:Sort/utf8max2bytes konstatiert) auf sowas wie „unicodemax1byte“ umstellen). Unabhängig davon stellt sich auch die Frage, was in jenen Fällen geschehen soll, in denen nach der Zeichenentfernung (außer gegebenennfalls Leerzeichen) keine Schriftzeichen übrig bleiben? --X:: black ::X (Diskussion) 15:09, 6. Apr. 2018 (CEST)

First response:

• A (mandatory?) parameter would be introduced. Currently 2 for max2bytes, maybe 1 for max1.
• I did not understand yet why the 0x0100 issue is still a kmlTitle issue.
• Reducing to 1 byte may be done by one of the Sort subsets, like /latin, but yields ISO 8859-1 and that contains just one greek μ and some faked MOCKBA.
• If 1 byte is required, neither greek nor cyrillic nor arabic or hebrew would be possible.
• An osm4wikiTitle interface might be created.
• The cs: stuff needs further explanation.

Greetings --PerfektesChaos 15:21, 6. Apr. 2018 (CEST)

Hi X:: black ::X, I intended a workaround mainly for dewiki (it will for sure not work for Kanji and other far east languages.). It does not work in all cases, but in most (do you know a case where it doesn't?). It is a workaround and I could not reproduce the cases with 0x0100 to 0x00FF characters. The workaround now acts a central place where to tweak around. The main focus of the workaround is to avoid the side-effect where failing with one name will mean failing with all. There is a drawback of removing too many characters, as this might cause other problems (reading, annoyed users, etc.). When nothing is left, we fail with the original string now (better than the stripped-all empty string). --Herzi Pinki (Diskussion) 17:07, 6. Apr. 2018 (CEST)

It's completely O. K. that the workaround is mainly for dewiki, I only wanted to say that one must not advertise it as a solution, any other wiki can adopt, as the causation of the problem in the different wikipedias is slightly different; so for each wikipedia one first has to check, if the problem is caused by characters in a template (where the workaround might be used, as in dewiki) or outside a template.
Regarding the characters 0x0100 to 0x07FF, compare https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&oldid=175831694, that only contains characters of the range 0x000 to 0x00FF, to https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&oldid=175831653, that contains the character Ā, which is 0x0100. You have to klick on edit and save the old version as new and then klick on the OSM-link or the Google-link. When I tested it Ā, and all other tested characters form the range 0x0100 to 0x07FF (including greek and arabic) caused the problem (which of course only becomes relevant for a normal user, if in this page the Vorlage:All Coordinates or the Vorlage:Linked Coordinates is used; Kategorie-pages are not affected by the problem anyway, see here). For the characters, see the relevant Unicode blocks, linked in this list.
For the cswiki-“stuff”, see here. --X:: black ::X (Diskussion) 01:08, 7. Apr. 2018 (CEST), corrected 18:02, 8. Apr. 2018 (CEST)

sorry, got it. While Ā does cause the problem of unreadable escape sequences in the OSM map navigation and this is still a problem, it does not cause the malfunction of backlinks from OSM maps. So we are just halfway done. I'll think about. Reducing to ASCII only seems to be too brutal. --Herzi Pinki (Diskussion) 10:20, 7. Apr. 2018 (CEST)

At least on the the page level, the backlinks work (and when using data from Kategorie-pages they work only on page level anyway). If the workaround makes the value of the parameter type contain only characters of the Unicode range 0x000 to 0x00FF and you use the tool wp-world/googlmaps-proxy (the “Google”-link in Vorlage:All Coordinates or Vorlage:Linked Coordinates), as far as I know, only the character " causes a problem because the anchor is cut off. Non-ASCII characters of the Unicode range 0x000 to 0x00FF (Umlaute, è etc.) cause the breaking of the backlinks on the anchor-level only in osm4wiki, not in wp-world/googlmaps-proxy, and the maintainer of osm4wiki Benutzer:Plenz wrote here, that he is planing to debug osm4wiki (until tested, on a seperate server or file), but needs some time, so this problem might be solved there. This backlink-on-anchor-level-problem-in-osm4wiki is rather increased by the workaround, as the apperance of the kmlexport-encoding-problem heals those backlinks in osm4wiki, that are not working because of non-ASCII characters of the Unicode range 0x000 to 0x00FF, as long as it does not affect the name of the page the backlink goes to.
I was wondering, if HTML-entities could help, but this would have to be tested precisely, as different entities are processed differently: While " appears transformed in GeoHack and osm4wiki and „ apperars as ", probably because it's also transformed and afterwards replaced with " by the workaround, “ apperars not transformed in GeoHack, but written as plain text, whereas in osm4wiki it apperas transformed and causing the kmlexport-encoding-problem. :-/ --X:: black ::X (Diskussion) 19:01, 7. Apr. 2018 (CEST), erweitert 20:09, 7. Apr. 2018 (CEST), corrected 18:02, 8. Apr. 2018 (CEST), extended 13:29, 9. Apr. 2018 (CEST) and 14:04, 9. Apr. 2018 (CEST)

I was thinking about how to reduce the negative effects of the workaround. As a normal user only accesses osm4wiki and wp-world/googlmaps-proxy via the links generated by the Vorlage:All Coordinates or the Vorlage:Linked Coordinates, the workaround is only needed to be active in those usages of the Vorlage:Coordinate, wich are embedded in pages in which also, either the Vorlage:All Coordinates, or the Vorlage:Linked Coordinates (or both) are embedded. Thus, I was wondering, if it would be possible to add a parameter to the Vorlage:Coordinate, by whiches value one could activate or deactivate the workaround. By such a switch, an editor would be able to switch on the workaround, if in the page, this Vorlage:Coordinate is embedded, also the Vorlage:All Coordinates or the Vorlage:Linked Coordinates is embedded, while in all other cases, the workaround would be inactive and the full ability of the GeoHack to display Unicode characters could be used without—in this situation unnecessary—replacements or removals of characters. This would be useful, as the Vorlage:Coordinate is (either directly or via an other Vorlage) used in much more pages than Vorlage:All Coordinates and Vorlage:Linked Coordinates. --X:: black ::X (Diskussion) 18:02, 8. Apr. 2018 (CEST)

Ad PerfektesChaos: What do you mean by “A (mandatory?) parameter would be introduced. Currently 2 for max2bytes, maybe 1 for max1.” and “An osm4wikiTitle interface might be created.”? --X:: black ::X (Diskussion) 13:29, 9. Apr. 2018 (CEST)

I would offer to the public a kmlTitle interface (which is a sufficient solution rignt now) and perhaps a new osm4wikiTitle.

Internally they would call one and only one generic functionality, perhaps genericDowncode(0x0800) for kml and genericDowncode(0x0100) for osm4wiki. The unique procedure might select appropriate mapping tables depending on the figures.

@Herzi Pinki: It is not ASCII, it is at least ISO 8859-1.

Greetings --PerfektesChaos 15:29, 9. Apr. 2018 (CEST)

Ad PerfektesChaos: Having separate interfaces for kmlexport and osm4wiki (and GeoHack [and if necessary, also wikipedia]) is a good idea. I just wonder, how to make kmlexport employing its new one (a long as, de facto, it has no maintainer)? As osm4wiki relies on kmlexport, I also ask myself, if you want to transfer the data, that is meant for osm4wiki, to it via kmlexport or if osm4wiki shall fetch it directly from wikipedia? --X:: black ::X (Diskussion) 14:06, 10. Apr. 2018 (CEST), corrected 14:25, 10. Apr. 2018 (CEST)

Such Lua functions can only offer to change the title text into a less challenging encoding.

Which template then converts which parameter for which tool call is not their business.

Greetings --PerfektesChaos 17:09, 10. Apr. 2018 (CEST)

caused by anchor only

Yesterday I could find out, that all three problems are caused by the anchor, not the value of the parameter title in the URL of the link to the GeoHack. Vorlage:Coordinate creates an anchor for itself (that's why the problem appears in a different way in the de-wikipedia) that is named by the value of the parameter name of the Vorlage:Coordinate. The en-, cs- and ja-wikipedia versions of this template do not create their own anchors, so kmlexport just uses the last anchor of the wikitext, that is placed before the template. No matter if this anchor is created by a heading of a section, subsection or sub-subsection, a reference-tag, the Vorlage:Anker (respectively it's equivalents in the other wikipedias), an other template that creates anchors, or anything else. While in the en-, cs- and ja-wikipedia versions, the problem can be solved by placing an additional anchor in front of the Vorlage:Coordinate-equivalent, using only ASCII characters, but without the character " (if this character could be escaped by ", %22, " or " would have to be tested), for the name of the anchor, in de-wikipedia an other way would have to be used (because of the anchor created by the Vorlage:Coordinate):
Ad Herzi Pinki: Is it possible to alter the Vorlage:Coordinate in that way, that the value of the parameter name of the Vorlage:Coordinate ist transmitted to the parameter title of the URL to the GeoHack without changes, and to use the workaround only to change the name of the anchor in wikipedia-HTML-code created by the Vorlage:Coordinate? Then the GeoHack could display the typorgraphicly correct name of the object and osm4wiki and wp-world/googlmaps-proxy.php would work without problem, if the name of the anchor would be created of ASCII characters, but without the character " (if this character could be escaped by ", %22, " or " would have to be tested) only. The replacement of non-ASCII characters by ASCII characters should further be used, to avoid ending up with empty output values after processing through the workaround or same values that were differing before processing through the workaround.
The emerging difference between the name of the referenced object and the name of the anchor should not be a problem to the tools using kmlexport. But we should be aware, that tools relying on wp-world-database-dumps—which for the de-wikipedia aren't updated since 2015—, that have anchors in their output which they go from that database dump, are affected by the workaround, as the workaround changes the names of the anchors. This can be seen by Liste der Seen in Bayern#Lechstaustufe 2 - Prem. The anchor is created by the Vorlage:Coordinate and the workaround changed it from „Lechstaustufe 2 – Prem“ to „Lechstaustufe 2 - Prem“. The wp-world overlay in WIWOSM uses the old database dump and thus still links to https://de.wikipedia.org/wiki/Liste_der_Seen_in_Bayern#Lechstaustufe_2_–_Prem, see here. It's the same for wp-world/umkreis.php, which on top has the problem, that it doesn't escape the spaces in the anchor when creating the URLs to wikipedia, see here. I don't know if this problem would disappear, if the data would be updated, but anyway, nobody knows when this will happen again (see here). --X:: black ::X (Diskussion) 16:57, 13. Apr. 2018 (CEST)

• Regarding the anchor question, it is possible to create more anchors than one in order to support a traditional one and a modified one.
  • The method of anchor encoding in MediaWiki changed end of 2017 for non-ASCII targets and those with special characters. In order to support older (as of 2015) fragments generated by anchor template, one might consume this talk and have a look at that draft which can be fed multiple times with the same ID (which is actually an HTML error).
  • The latter is able to solve a lot of anchor issues and will support pre-2018 anchors stored in a database.
• This discussion became very, very long. It deserves a subpage on its own, /Encoding 2018, with sub-headlines for various steps and solutions and comprehensive summaries.

Greetings --PerfektesChaos 17:31, 13. Apr. 2018 (CEST)

The idea to create more than one anchors is good. I dont know if it's possible but I suppose it should be. If it's possible, probably the anchor with ASCII characters (without ") only would have to be the last one in front of the GeoHack-URL, as kmlexport uses the last anchor in front of the coordinate. --X:: black ::X (Diskussion) 11:53, 14. Apr. 2018 (CEST)

Thanks you Benutzer:X:: black ::X, need some quiet hours to think about. As Coordinate is used extensively in large lists, duplicating the anchors will bloat the post include expand size. --Herzi Pinki (Diskussion) 11:37, 15. Apr. 2018 (CEST)

Concerns about resulting page size:

No problem.

Until November 2017 always two span Elements were produced. Your large pages did not crash before, did they?

My suggestion would add again one span only where an encoding problem occurs and old and new fragments differ. And this is needed anyway since old URL to anchor templates with non-ASCII fragments fail today.

Have a nice week with a lot of quiet hours --PerfektesChaos 12:40, 16. Apr. 2018 (CEST)

kmlexport-cswiki

@X:: black ::X, Plenz: Hello, I think I solved the issue. Please see https://phabricator.wikimedia.org/T198073. You can test my patch on https://tools.wmflabs.org/kmlexport-cswiki/ until my patch will be applied (if ever). --Dvorapa (Diskussion) 12:16, 25. Jun. 2018 (CEST)

PS: Patch applied and I've also become a maintainer of kmlexport. Feel free to contact me with any issue. --Dvorapa (Diskussion) 17:00, 19. Jan. 2019 (CET)