Module talk:Element

translation table

That gigantic translation table should probably be moved into a separate modul, e.g. Module:Element/translations, and use mw.loadData() to get it. Basically have a table with language -> value, and use those values. --Yurik (talk) 17:15, 30 September 2018 (UTC)

Basically, I agree but I am hoping that we will switch to the Translate Extension. This would probably mean that we have to change that again. There was actually an agreement years ago but this was never installed and I do not have the capacity and experience to start a new investigation in that. I do not even know if this is still community consensus. --Tigerfell  (Let's talk) 21:02, 30 September 2018 (UTC)

TBH, i'm not a big fan of that ext. It requires very complicated translation markup that not many people fully understand. Also, while this would be a bit of a hack, we can already use items for that :) Not sure what's better. Regardless, it would be very straightforward to convert your table, with the biggest being much easier understanding of what language is what (it is a bit confusing because of the nested ifs. --Yurik (talk) 21:32, 30 September 2018 (UTC)

In my eyes, we need some system reporting the language status of a page and monitoring changes. We have currently huge struggles to keep the information updated in some languages. The extension would not fully solve this, but make it easier to spot changes.

Anyway, the nested ifs basically assemble a binary tree structure to minimize the comparisons. Theoretically, one could just delete them and iterate through all possibilities. --Tigerfell  (Let's talk) 22:10, 30 September 2018 (UTC)

The binary structure makes the code somewhat more difficult to read and maintain, at least you would have to be very careful not to add something in the wrong branch. I guess this was done for performance reasons only. Did you run any performance measurements where you compared different options, like this binary structure vs. something like a local lookup table? (e.g. local lookupTable = { de = "Name", en = "Another name", af = "geskiedenis" }). Was is worth the effort? Mmd (talk) 10:19, 3 October 2018 (UTC)

No, I did not do that. I read in the documentation that conditionals with many branches were no performance problem but I also heart from User:Wynndale that his change in Module:Langcode gave certain languages a speedup (think it was Chinese) and I thought it was due to this branching but actually I never checked that. I only did performance tests comparing the old and the new version of the template. The new version was (obviously) in all aspects better except for Lua resources.

I am planning to change this structure to a data table with the next change. Again, I will probably do no performance test for this part as data tables seem superior to me because they are loaded just once for every page (instead of every Lua call).^Manual --Tigerfell  (Let's talk) 19:30, 3 October 2018 (UTC)

That was Mediawiki markup. I have no idea how Lua behaves.--Andrew (talk) 21:02, 3 October 2018 (UTC)

Ok, I implemented the language table. It is located at Module:Element/translation. I also changed the module accordingly (including other changes). It can be found at Module:Sandbox/Tigerfell. If no one objects I would replace the current version with the sandbox version. --Tigerfell  (Let's talk) 12:47, 5 October 2018 (UTC)

Generated sortkey should default to the link label, not the relation ID

When placed in tables, the generated <bdi class="sortkey"> is always the relation ID, even when the template is called with parameter 2 defining a label. When sorting a table column containing this template, the result is not what the reader expects, it looks randomized. It seems the only necessary change is on the assignment of output[2] in function elementText. --Fernando Trebien (talk) 10:37, 17 November 2018 (UTC)

Ok, it would just need to fall back to the ID if no label is provided. --Tigerfell  (Let's talk) 23:07, 18 November 2018 (UTC)

Tools: short but JOSM only

In my area, people have used the wiki to reference major relations. This is because working with them and monitoring them is more difficult than on other geometry (ways and nodes). We would also prefer to stimulate using JOSM to edit them, given the extra features it provides to properly maintain them easily. As such, some have asked for the possibility of calling the template rendering only JOSM as a tool, but without rendering the icon. There are two ways to achieve that: add a parameter to remove the icon (cumbersome), or add a new value for the tools parameter, such as "shortjosm" or "shortj". The result would be like tools=short, but with only J within parenthesis. What do you think? --Fernando Trebien (talk) 14:52, 19 November 2018 (UTC)

One of the ideas behind the recoding with Lua was to reduce the number of variations. Executing this suggestion would increase them again. Why do you not use 23452345  {{Relation|2345|tools= short }}? --Tigerfell  (Let's talk) 10:00, 21 November 2018 (UTC)

There is some concern about encouraging editing complex relations using the simpler editors, which lack validation of specific types of relations and lack other tools to facilitate the editing (such as reordering members and checking that routes are complete). But if that is an issue, we'll use tools=josm or tools=mini. --Fernando Trebien (talk) 10:20, 21 November 2018 (UTC)

Adding waymarked trails to relations

Hi, I tried adding support for this but the change was reverted by @Tigerfell:. Would it be more suitable to have it as a special tools=waymarked_trails or tools=wt? I need it when working with https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/Hiking_trails --PangoSE (talk) 18:20, 3 January 2020 (UTC)

This is supposed to be a general purpose template. The other links point to common tools which are usable for all kind of relations. You link is very special for hiking routes. Copied from Module:Element:

Why are there so few tools only?

This is a general purpose template, if you need special links, you can add them directly to your page. Please remember that the parser is not able to cache this template, so if you link to five relations, it has to create 35 (= 5 * 7) links in the worst case (i.e. displaying all tools).

In your case it might be interesting to have a template "ElementHiking"? Please also consider that 8143 pages use this template. --Tigerfell  (Let's talk) 12:02, 4 January 2020 (UTC)

Thanks for the input. I solved my need by creating a bookmarklet instead see https://wiki.openstreetmap.org/wiki/Waymarked_trails --PangoSE (talk) 09:54, 7 January 2020 (UTC)