Benutzer Diskussion:RolandUnger/Archiv/2022/1.Quartal

Dieser Artikel ist Teil unseres Archivs. Den aktuellen Artikel findest Du unter Benutzer Diskussion:RolandUnger.

---

it:Modulo:Marker

Thanks for your corrections. Now I'm going to study your changes. However, if you don't mind, could you answer my previous questions to help me to better understand the LUA logic? Let me wrap them up here below:

1. the commented code in line 84 is exactly mapTagOutput = map.tag( mapTagArgs ) but it doesn't work and I don't understand why. As you noticed, I've structured mapTagArgs to look like a frame (i.e. having mapTagArgs.args). The error I got is "Modulo:Map alla linea 372: attempt to call method 'extensionTag' (a nil value).", where line 372 is frame:extensionTag(tag, geojson, tagArgs) and those parameters comes all from the "frame" passed to tag.
   Maybe it is necessary to establish a new frame object with mw.getCurrentFrame(). The main problem seems to be that a normal table has no frame object functions.
   If you are creating a new module you should provide functions both for use in modules and in #invoke statements. In the case of the map it wasn't prepared for the use in other modules. That's why we do not use this module at the German Wikivoyage any longer. --RolandUnger (Diskussion) 11:36, 14. Nov. 2021 (CET)
2. I've tried to integrate p.makeMarkerSymbol into the module calling it in line 87, but it doesn't work. The parameter args inside the function is empty. Could you help to understand this as well?

The args table inside the function was not empty. But you used completely different names tor table indexes so that the expected fields were not created and not existend. --RolandUnger (Diskussion) 11:36, 14. Nov. 2021 (CET)

Thanks for your time. --Andyrom75 (Diskussion) 10:36, 14. Nov. 2021 (CET)

Answers see above. --RolandUnger (Diskussion) 11:36, 14. Nov. 2021 (CET)

1. Ok, so for all the "frame:functions" I need to create a new variable frame=mw.getCurrentFrame(). Question. If I invoke from a template a function "f(frame)", I still need that init or I get it automatically? --Andyrom75 (Diskussion) 15:46, 14. Nov. 2021 (CET)
2. Gosh, you are right... yesterday night was late and I got confused... thanks for spotting it. --Andyrom75 (Diskussion) 15:46, 14. Nov. 2021 (CET)

This morning I've mad some minor changes to module to optimize the code and to get the same HTML code.

To complete this task I miss last step. The old template:Marker generate the following attribute: data-overlays="["mask","around","buy","city","do","drink","eat","go","listing","other","see","sleep","vicinity","view"]" while the new module:Marker generate this one data-overlays="["_3eadefe3283d18de8793204b6207780ac85dad0b"]".

I'm not able to state if they are equivalent or if there is a mistake. Any idea? --Andyrom75 (Diskussion) 15:46, 14. Nov. 2021 (CET)

ad 1: If you call a module via #invoke, the frame table is automatically generated. The problem of the map module is that it works only with a frame table. If a module should work both with modules and #invoke you need two functions:

function p.makeItAll( args ) -- for module use, complete
...
end
function p.makeItAllFromInvoke( frame ) -- for invoke use
  local args = frame.args
  return p.makeItAll( args )
end

If you want to call a frame function like frame:callParserFunction you have to create a new frame table if there is no one else. But you can use the same as provided by an invoke call.

ad data-overlay: You deleted two important lines from my code. show and group are really necessary! If show is missing then a code is created by the software.

--RolandUnger (Diskussion) 17:25, 14. Nov. 2021 (CET)

First point: got it.

Second point. I've deleted the code relevant to those parameters because comparing with the original Template:Marker and Module:Map there was (apparently) no need for further elaboration of those parameters. Am I wrong? --Andyrom75 (Diskussion) 17:52, 14. Nov. 2021 (CET)

Although I haven't changes anything singificant, show parameter seems to work correctly. --Andyrom75 (Diskussion) 18:02, 14. Nov. 2021 (CET)

If you have a look to Template:Marker you will learn that the group and show are defined! If you do not specify them both values are generated by the software and are identical (this is the mode for non-Wikivoyage projects). That also means that two objects of the same type cannot be shown at the same map because they are called by different Marker calls.

It is very important to understand group and show. group means the name of a map layer which presents all objects with that group. It can be only a single value (usually see, do, and so on). show defines all groups (layers) which should be presented on the map. It can consist of several values whereas the group value must be part of them. Strictly speaking, marker types are not types but groups.

That's why we (internally) made at the German Wikivoyage a redefinition. We have types (hotel, hostel, campsite, ..., and sleep, ..., for backward compatibility), groups (see, do, eat, sleep, ...) and mapgroups (similar to groups but their names are not restricted to the predefined see, do, eat, ... and can therefore freely be chosen). With the types table we translate these types to groups. There are two advantages: we can distinguish between several locations of the same group (see for instance Pages with marker types), and we can get this type from Wikidata in most cases (because we translate types to groups). If we need a marker for the Colosseum we can simply write {{Marker | wikidata = Q10285 }} (for better readability, we prefer {{Marker | name = Colosseum | wikidata = Q10285 }}). --RolandUnger (Diskussion) 18:37, 14. Nov. 2021 (CET)

I knew this difference. What I was saying is that in my original script, derived from the template, I already have the following two init instructions:

1. group = args.tipo or 'listing'
2. show = 'mask,around,buy,city,do,drink,eat,go,listing,other,see,sleep,vicinity,view'

I've seen in the past that de:voy goes much more beyond this differentiation, but for me right now it's enough. My current target is a general increase of my personal knowledge on LUA and the 1by1 conversion of the Template:Markup.

In this scenario, I need a confirmation and one more suggestion:

Confirmation: the above 2 code lines are enough, right? Or do I need to further elaborate?

Suggestion: which is the most elegant way to manage the frame in the two cases of function call: from template or from another module or debug console? Basically I'd like to change the lines 50-54 to allow the module to work on both cases. In other words my doubt is: should I use one single function for both cases changing the code, or do I have to create two different functions (like your example above), 1 for each case?

Thanks, --Andyrom75 (Diskussion) 19:02, 14. Nov. 2021 (CET)

After several tries I've landed to this solution:

function x( frame )
    local args = frame.args
    frame = mw.getCurrentFrame():getParent() or mw.getCurrentFrame()
    if mw.getCurrentFrame():getParent() then
        args = frame.args
    end
    ...
end

I'm not able to develop anything better than this in order to have a function that can work with both LUA functions and templates. Let me know your thoughts.

Now I've also understood better your above "ad1". According to your larger experience, which approach it's better (if any) between "ad1" (i.e. having two separate functions) and the above code (i.e. having one single function for both cases)? --Andyrom75 (Diskussion) 20:41, 16. Nov. 2021 (CET)

Sorry for disturbing you again with the same noob/academic question, but I've noticed that both approach have some missing parts. So I've tried to extend them according to my current knowledge.

Brief introduction of the problem. Each function can be called in "three different" ways, not "two equivalent" as I've initially supposed.

1. from a wiki-template
2. from an invoke inside a wiki-template
3. from a LUA function

That said, considering that for the main body of the module, I need both args parameters and frame object (properly created), I've developed the following two approaches, tested in it:Utente:Andyrom75/Sandbox/test#Test

1. Unique function that can be called in any way
2. Three different interface functions that will call a single process function

Approach 1 (see it:Modulo:Marker): more flexible than the following one, but spend more time to guess the correct context

function tablelength(T)
  local count = 0
  for _ in pairs(T) do count = count + 1 end
  return count
end

function p.Marker(frame)
	local args = frame.args
	frame = mw.getCurrentFrame():getParent()
	if frame and (tablelength( frame.args ) > 0) then --WIKI-TEMPLATE CASE
		args = frame.args
	else
		frame = mw.getCurrentFrame()
		if frame and (tablelength( frame.args ) > 0) then --INVOKE CASE
			args = frame.args
		end
	end
    ...
end

Approach 2 (see it:Modulo:Marker/sandbox): no need to "guess" the case, hence is quicker than previous one, but has three interfaces

function p.MarkerTemplate()
	return _Marker(mw.getCurrentFrame():getParent())
end

function p.MarkerInvoke()
	return _Marker(mw.getCurrentFrame())
end

function p.MarkerModule(frame)
	Cframe = mw.getCurrentFrame()
	Cframe.args = frame.args
	return _Marker(Cframe)
end

What do you think? Do you see any improvement on both approaches? Note for approach1: that's the only way I've found to check the case, any suggestion is more than welcome.

Furthermore, any personal preference according to your experience? --Andyrom75 (Diskussion) 16:00, 21. Nov. 2021 (CET)

@Andyrom75: I prefer the second approach. Normally, at least all modules are called by invoke so a frame table is available. This table will be later used only for calling frame functions. It can be transferred to functions to prevent calls like mw.getCurrentFrame():getParent().

I think your aim is to reuse the marker module for a (future) listing module. Maybe it makes more sense to develop marker and listing modules separately and to move all commonly used funtion to a submodule. I think that this procedure is more flixible in future even if you need additional but the same information (for instance interwiki icons) at different positions (I used this method at the German Wikivoyage). --RolandUnger (Diskussion) 06:51, 24. Nov. 2021 (CET)

Thanks, your suggestion works:

function p.MarkerTemplate(frame)
	return _Marker(frame:getParent())
end

function p.MarkerInvoke(frame)
	return _Marker(frame)
end

Now looks also more clear the different behaviour of the frame object that is automatically created when called from the wiki-environment.

I took the chance for another question on this module/template. I've noticed that in it:voy we still have the call to #coordinates, but I tend to suppose that is not needed since all the POIs are managed by the extension maplink. Also a test on it:Modulo:Marker/sandbox seems to confirm it. Do you agree? --Andyrom75 (Diskussion) 10:44, 24. Nov. 2021 (CET)

I've removed the #coordinates call also in the main module. I haven't seen any issue in the articles, but I don't know if there is a side effect. I've only kept it on the Quickbar with "primary" parameter. If I'm not wrong this should be used for the "near by" function. What do you think? --Andyrom75 (Diskussion) 00:34, 3. Dez. 2021 (CET)

Let me know if the previous question is clear or not, in case I'll try to rephrase.

While waiting I have another simple question. Which is the Kartographer parameter to show in the bottom line of the map the name of a marker/listing on the right side of the number of such listing. I've just noticed that in it:voy this information is missing while here in de:voy is present. Thanks for your support, --Andyrom75 (Diskussion) 23:44, 11. Dez. 2021 (CET)

Regarding this simple question, I'm referring to:

<div class="mw-kartographer-captionfoot" title="1">1</div>

I get always and only the POI number, while you where able to customize adding also the POI name like this:

<div class="mw-kartographer-captionfoot" title="1: POI name">1: POI name</div>

--Andyrom75 (Diskussion) 19:34, 13. Dez. 2021 (CET)

Maybe I've understood it. I've noticed that you leverage on the parameter data-name stored in the marker A tag. So most likely you use MediaWiki:Gadget-MapTools.js improve the description. I think it should be better to install this behaviour server-side; what do you think? I'm going to open a ticket on Phabricator.

PS Please let me know if I disturb you or in any case if you don't have time to reply, last thing I want is to annoy other people. Thanks, --Andyrom75 (Diskussion) 10:25, 14. Dez. 2021 (CET)

I am now abroad, and it is difficult to have contact to the web. I will try to answer within the next time. --RolandUnger (Diskussion) 20:49, 18. Dez. 2021 (CET)

I hope your foreign travel is proceeding well. Here the opened ticket: https://phabricator.wikimedia.org/T297675 Andyrom75 (Diskussion) 09:00, 14. Jan. 2022 (CET)

Yes, I returned well. Thanks for the phabricator hint. It is true, that I wrote MediaWiki:Gadget-MapTools.js to make map workarounds and new map features to do not wait for WMF developments. --RolandUnger (Diskussion) 07:30, 18. Jan. 2022 (CET)

Do you know any map WMF developer to be pinged on the ticket? Furthermore, if you have some insight to speed-up their job feel free to add it in a ticket's comment. Thanks and welcome back :-) --Andyrom75 (Diskussion) 09:32, 19. Jan. 2022 (CET)

Sperrung

Ich bin seit Sommer 2021 gesperrt für das Projekt Wikivoyage. Werden Sperren über andere Projekte, wie die Wikipedia synchronisiert? Wer kann mich für das Projekt Wikivoyage freischalten? (nicht signierter Beitrag von FolkertM (Diskussion | Beiträge))

@FolkertM: Den Nutzer FolkertM haben wir auf diesem Wiki nicht gesperrt, siehe Benutzersperr-Logbuch. Wenn er auf diesem Wiki gesperrt worden wäre, könnten unsere Admins die Sperrung rückgängig machen. Wenn du einen anderen Nutzernamen verwendet hast, so solltest du uns das mitteilen. Möglicherweise ist die Sperre global. In diesem Fall solltest du auf der Wikipedia nachfragen, da wir bisher keine globalen Sperren beantragt haben. --RolandUnger (Diskussion) 16:27, 20. Jan. 2022 (CET)

Schriftgröße

Hallo Roland, zunächst einmal vielen Dank für Deine Änderungen der Schriftgröße in den von mir eingefügten Info-Boxen "Sicherheit im Watt". Das Aussehen jetzt gefällt mir wesentlich besser. Aber trotzdem frage ich mich, warum habe ich "small" falsch verwendet? Warum ist der Befehl "small" hier nicht richtig? Er wird doch sonst auch genutzt. Danke im Voraus, --Eduard47 (Diskussion) 12:48, 30. Jan. 2022 (CET)

Man kann <small> nicht über die gesamte Liste anwenden, sondern muss dies für jeden Eintrag machen, was eine ganze Menge Tipperei bedeutet. Also jedes Mal * <small>Eintrag</small>. <small> ist ein Inline-, kein Block-Element, so dass der Linter (Fehlerprüfer) hier berechtigterweise herummeckert. --RolandUnger (Diskussion) 12:59, 30. Jan. 2022 (CET)

Man lernt ja nie aus. Die Ausgabe hatte zwar trotzdem funktioniert, dass eine Fehlermeldung kam konnte ich nicht sehen und auch nicht ahnen. Danke. --Eduard47 (Diskussion) 13:05, 30. Jan. 2022 (CET)

Die Fehlerliste kennen nur wenige, was wohl auch gut so ist. --RolandUnger (Diskussion) 13:07, 30. Jan. 2022 (CET)

.voy-multicols-box

Hi. Ist die Angabe der Hintergrundfarbe in der Klasse .voy-multicols-box eigentlich notwendig? Der Hintergrund im Wiki ist doch eh' weiß. Würde es Leuten einfacher machen, die ihre eigenen CSS-Styles nutzen (wie mir). Die Template Styles kommen leider nach den eigenen. Ich habe zwar mittlerweile einen Trick gefunden, selbst im Tag hart codiertes CSS noch zu überschreiben. Ist aber halt nur Aufwand. -- DerFussi 08:51, 31. Jan. 2022 (CET)

In dem Fall ist es wohl nicht notwendig. Das Problem sind die umlossenen Boxen, die schon mal mit Überschriften kollidieren. Ich habe es herausgenommen. --RolandUnger (Diskussion) 12:57, 31. Jan. 2022 (CET)

Oh, daran habe ich auch nicht gedacht. Ist auch nur ein nice-to-have, dass di eindividuellen Frickeleien etwas vereinfacht. Danke! VG -- DerFussi 13:16, 31. Jan. 2022 (CET)

Modul:Location map

Du kennst dich im Modul:Location map wahrscheinlich besser aus. Ich möchte/muss wegen meines Dark Skins in den Quickbars den Ortsnamen in der Lagekarte der Ortsquickbar einfärben, bzw. wieder zurück nach Schwarz umfärben. Allerdings besitzt kein Element unterhalb von table.locationMap in den Lagekarten eine (brauchbare) Klasse, was den Zugriff ziemlich erschwert. Könntest du für die wichtigsten Elemente (z. B. Karte und POI ) bei Gelegenheit eine Klasse reinfrickeln? Ich baue bestimmt wieder Mist, wenn ich mich da durchackere. -- DerFussi 22:14, 23. Feb. 2022 (CET)

Ja, das lässt sich machen. --RolandUnger (Diskussion) 06:20, 24. Feb. 2022 (CET)

Danke. Ist aber nicht eilig. -- DerFussi 07:48, 24. Feb. 2022 (CET)

Bisher gibt es fünf Klassen:

• voy-locmap für die gesamte Karte
• voy-locmap-object für ein in die Karte eingefügtes Objekt
• voy-locmap-marker Gruppe für Markersymbol und -label
• voy-locmap-marker-symbol Markersymbol
• voy-locmap-marker-label Markerlabel

--RolandUnger (Diskussion) 10:13, 24. Feb. 2022 (CET)

Perfekt! Danke. -- DerFussi 11:21, 24. Feb. 2022 (CET)

@DerFussi: Ich habe die Beschreibung in Wikivoyage:Location map um die neuen Klassenbezeichner ergänzt. Es sind noch ein paar mehr geworden. --RolandUnger (Diskussion) 14:44, 26. Feb. 2022 (CET)

Tabular Data

Ich habe mich gestern nach dem Anlegen einer Karte auf Commons mal kurz mit dem Data-Namensraum beschäftigt. Nach dem ersten Lesen macht es aus meiner Sicht Sinn, unsere in den Sub-Modulen verwendeten Wertelisten auf Commons zu speichern. Zum einen ist in dem Json-Format Internationalisierung vorgesehen, und zum anderen kann man es einfach als Lua-Tabelle direkt beziehen. Die Lua-Funktion scheint die Daten sogar gleich in der gewünschten Sprache zu liefern. Das würde die Pflege der Listen immens vereinfachen, besonders die, die inzwischen auch in anderen Sprachversionen verwendet werden. -- DerFussi 07:58, 4. Mär. 2022 (CET)

Ich muss mir die Sache in Ruhe ansehen. Große Sorgen mache ich mir um die Rechenzeit (die schon jetzt viel zu groß ist, auch wenn sie hauptsächlich von Wikidata und dem eigentlichen maplink-Aufruf stammt). Hierzu sagt niemand etwas. So war ich auch sehr darüber erstaunt, dass mw.loadData manchmal mehr Zeit braucht als require, von Problemen abgesehen, dass sich diese Tabellen nicht wie Lua-Tabellen verhalten und programmtechnisch teilweise anders behandelt werden müssen. Lua-Module werden offensichtlich gecached, bei den Tabular Data weiß ich es einfach nicht. Aber ansehen werde ich es mir. Und vielleicht gibt es ja in der Wikipedia hierzu Erfahrungen.

Eine andere Anwendung könnten Klimadaten sein. Die wären weniger zeitkritisch, weil meist nur einmal Daten aufgerufen werden. --RolandUnger (Diskussion) 08:39, 4. Mär. 2022 (CET)

An Klimadaten hätte ich auch gedacht. Aber zum Thema Verhalten. So wie ich die Funktion mw.ext.data.get("Example.tab") dort verstehe, hätte ich erwartet, dass sie die Daten als echte Lua-Tabelle zurückgibt, wenn es eine Lua-Funktion ist. -- DerFussi 12:40, 4. Mär. 2022 (CET)

Zum Thema require. Keine Ahnung. Aufgrund dieser Ungewissheit benutze ich auch möglichst wenig andere Module. Sie müssen ja immer geladen und ausgeführt werden. Ich habe auch immer Bedenken, dass ich durch das require zusätzlichen Ballast an Bord hole, weil man nicht alles braucht. Deshalb nur, wenn es wirklich mehrfach und immer gebraucht wird. -- DerFussi 12:56, 4. Mär. 2022 (CET)