MediaWiki talk:Gadgets-definition

Syntax highlighter

Swept in from the pub

Although I am a a relatively junior wikivoyager, I think I may have found something cool that many of you may enjoy: the "Syntax highlighter" gadget know from (among other places) English Wikipedia's preferences works well here, if one installs it manually on their common.js page (here is mine: User:Piotrus/common.js). Try it out, it remains one of my fav wiki editing hacks. (Note: this is for source editing, not Visual Editor). --Piotrus (talk) 06:15, 24 September 2015 (UTC)

I've installed this script on Wikivoyage as a gadget to make it easier to use, so it can be installed by going to Preferences → Gadgets and selecting "Syntax highlighter". -- Ryan • (talk) • 06:24, 24 September 2015 (UTC)

Nice! Thanks for the tip :-) Syced (talk) 09:04, 25 September 2015 (UTC)

Edit request 1

Please replace * mobile-sidebar[ResourceLoader]|mobile-sidebar.js with * mobile-sidebar[ResourceLoader|skins=vector-2022,vector,timeless,modern,cologneblue,monobook]|mobile-sidebar.js. This gadget breaks mobile site. Thanks. Yahya (talk) 11:10, 1 July 2023 (UTC)

@Andyrom75:, by any chance, are you able to fix this? SHB2000 (talk | contribs | meta) 11:37, 1 July 2023 (UTC)

Also consider disabling the RTRC, UTC Live Clock, EditTop, vector-headanchor, ListingEditor2 (beta) gadgets on mobile devices. These gadgets are not necessary for mobile sites and have been observed to negatively impact the loading speed of the site. Yahya (talk) 14:20, 1 July 2023 (UTC)

The ListingEditor2 (beta) has same issue as ListingEditor. Yahya (talk) 14:21, 1 July 2023 (UTC)

SHB2000 thanks for the ping.

Yahya I've disabled mobile-sidebar and ListingEditor2 that creates problems with Minerva skin. The others, as per my understanding, shouldn't, but please correct me if I'm wrong.

Jon, since the ListingEditor is not loaded by the ResourceLoader, do you think that I can remove the patch on Gadget-ListingEditor.js, or, to be conservative, we should keep it? --Andyrom75 (talk) 15:07, 1 July 2023 (UTC)

@Andyrom75 The EditTop gadget is indeed unnecessary for mobile devices since there is already an option to edit the lead section available by default. This gadget was initially created to address the lack of such an option on desktop devices. Additionally, the RTRC gadget is not mobile-friendly (screenshot). I would recommend at least disabling these two. Yahya (talk) 16:35, 1 July 2023 (UTC)

@Yahya EditTop done.

Although I totally agree with you that RTRC gadget is not mobile-friendly, but there is no alternative gadget for Minerva, so since it's an optional gadget that user shall activate on purpose, I think that we should let the users free to decide to use it with a ruined layout or not activating it at all. What do you think? Andyrom75 (talk) 17:46, 1 July 2023 (UTC)

Edit request 2

User:Andyrom75 I've workshopped the ListingEditor gadget (https://github.com/jdlrobson/-Gadget-Workshop) and have refactored it into an equivalently but performant alternative.

I've registered the gadget in MediaWiki:Gadgets-definition. It is currently listed under the existing gadget.

Could you please switch to the gadget and confirm everything is working as expected, and if you deem it make the following edit requests to MediaWiki:Gadgets-definition :

Delete the line

* ListingEditor[ResourceLoader|default|skins=vector-2022,vector,timeless,modern,cologneblue,monobook|type=general|dependencies=mediawiki.util,jquery.ui]|ListingEditor.js|ListingEditor.css

Add default to ListingEditor2023:

* ListingEditor2023[ResourceLoader|skins=vector-2022,vector,timeless,modern,cologneblue,monobook|type=general]|ListingEditor2023.js

to

ListingEditor2023[ResourceLoader|default|skins=vector-2022,vector,timeless,modern,cologneblue,monobook|type=general]|ListingEditor2023.js

Thanks in advance!

I'm happy to workshop it more if something's not quite right. Jon (WMF) (talk) 23:00, 13 July 2023 (UTC)

@Andyrom75: Jon (WMF) (talk) 23:00, 13 July 2023 (UTC)

Sure Jon, I'll take care of it.

It would be great if you could do the same with it:MediaWiki:Gadget-ListingEditor.js. Since it:voy is my "main environment", it would be easier for me to check the new tool version. Thanks, --Andyrom75 (talk) 11:08, 14 July 2023 (UTC)

I can do that today! Jon (WMF) (talk) 16:00, 14 July 2023 (UTC)

Hi Andyrom, I've updated the English Wikivoyage version to support Italian by comparing the two scripts and generalizing the code.

It's been installed here: it:voy:MediaWiki:Gadget-ListingEditor2023.js and should now be shown on preferences.

Please disable the original and try out the new one and let me know of any issues here: https://github.com/jdlrobson/-Gadget-Workshop/issues

thanks in advance! Jon (WMF) (talk) 22:58, 14 July 2023 (UTC)

@Jon (WMF), actually there are few differences between en:voy script and it:voy script so the simple redirect can't be used. For example, it:voy don't use "last edit" field, or there a section "IT CUSTOM LOGIC" to properly fill the eat/sleep section, maybe other aspects but in this moment I don't recall. That said, would you have time to recreate the two separate script in it:voy as well? --Andyrom75 (talk) 07:16, 15 July 2023 (UTC)

I am aware they are different and I took that into account. I looked at the differences between both scripts and upstreamed the Italian specific bits into the English one, so the English version when run on Italian Wikivoyage should have identical functionality to the existing italian (and the English version now supports Italian translation). If there's something speicific in the new script that's not working let me know and I'll fix it. I definitely ported some code relating to the sleep section so maybe you found a bug? Can you share replication steps?

Maintaining multiple forks is not really sustainable and a lot of work. I'd rather generalize and improve the code so we have one unified version that works for all. You can review my github commits to get a sense of how I consolidated the differences between the two.

Changes relevant to the sleep section:

• https://github.com/jdlrobson/-Gadget-Workshop/commit/a1909bcc76da2b3ea45f5fb023eac2cb055b1b92
• https://github.com/jdlrobson/-Gadget-Workshop/commit/a376817835478dc0b8d453256a97abf60b4ed869

Jdlrobson (talk) 19:32, 16 July 2023 (UTC)

@Jdlrobson I agree with your approach to improve the maintainability.

I've made a test on adding a listing on it:Città Alta (Bergamo)#Cosa_fare and I get JS error. Clearly it works with the old one. On the other hand, with the new script I was able to delete the test done with the old script. Please check and thanks for your time. Andyrom75 (talk) 19:43, 16 July 2023 (UTC)

Could you share the JS error in the console. Ill take a look later today. Jdlrobson (talk) 19:49, 16 July 2023 (UTC)

@Andyrom75 it should be working now. I just made an edit with it here: https://it.wikivoyage.org/w/index.php?title=Citt%C3%A0_Alta_(Bergamo)&diff=prev&oldid=800420 (I undid it afterwards :-)) Jdlrobson (talk) 01:24, 17 July 2023 (UTC)

@Jdlrobson, actually it store the listing in the wrong point; at the beginning just below the incipit, instead of the section from where the script has been called. Andyrom75 (talk) 16:55, 17 July 2023 (UTC)

I've tried to open the listing editor relevant to "Palais de Chaillot" in it:XVI arrondissement di Parigi, but I got a JS error. Please check this as well. Andyrom75 (talk) 18:11, 17 July 2023 (UTC)

I found the source of all our woes, and I believe these issues are both fixed now. Jdlrobson (talk) 05:05, 20 July 2023 (UTC)

@Jdlrobson, I'm not able to test it because currently the editor doesn't open to add a new listing becuase of a JS error relevant to the property "tipo" (an optional property, that practically is never used in it:voy and almost never in en:voy). It just opens to modify an existing listing. Andyrom75 (talk) 17:27, 20 July 2023 (UTC)

Can I have more details on this? How do I replicate this (what URL)? What steps should I take to see the bug? What exactly is the JS error you are seeing? Jdlrobson (talk) 21:58, 20 July 2023 (UTC)

@Jdlrobson, please ping me on your replies to speed up mine :-)

"Today" the behavior is slightly different. The editor opens but it gives an error upon submission.

Steps:

1. Open it:XVI arrondissement di Parigi
2. Go to "Acquisti" section
3. Click on "[ aggiungi elemento ]"
4. Fill the "Nome" field with "test"
5. Click on "Submit" button

Normally the editor closes and the page is reloaded with the new content. In my case nothing happen because of a JS error. The JS error is: "Uncaught TypeError: Cannot read properties of undefined (reading 'tipo')".

Let me know if you need further info. Andyrom75 (talk) 15:42, 24 July 2023 (UTC)

@Jdlrobson, I've noticed that also the window mask is different and not only for the position of the used fields, but also because are shown fields not used.

My personal suggestion is to divide the work into two steps.

1. apply the same "upgrade" to the it:voy script
2. once the it:voy and en:voy have again the same structure, I could try to support to segregate the "core" part from the "custom" one, because I think the custom one is not so small

Andyrom75 (talk) 15:34, 25 July 2023 (UTC)

Thanks for your patience here @Andyrom75 - it's a steep learning curve for me :-) Thanks for the replication steps that was super helpful!

The issue is not with making the enwikivoyage script work on itwikivoyage - it's an issue with my "upgrade" (this was also broken on enwikivoyage). I'm having a lot of difficulty following the code. Hopefully once we've got this working, the rest will be smooth sailing.

It should be working now. Found a couple more bugs but my edits went through..  : https://it.wikivoyage.org/w/index.php?title=XVI_arrondissement_di_Parigi&diff=801768&oldid=801766 .. maybe I've found the magic formula this time... :-) ?

Jon Jdlrobson (talk) 23:38, 28 July 2023 (UTC)

@Jdlrobson, this time no JS error, that's a great step forward :-)

Now we can explore all the customization one by one. To test the first one you should follow a very similar set of steps:

1. Open it:XVI arrondissement di Parigi
2. to "Dove mangiare" section
3. on "[ aggiungi elemento ]"
4. the "Nome" field with "test"
5. on "Submit" button

Currently it wrongly store the listing on top, while it should replace the following block:

<!--=== Prezzi medi ===-->

<!--* {{eat

| nome= | alt= | sito= | email=

| indirizzo= | lat= | long= | indicazioni=

| tel= | numero verde= | fax=

| orari= | prezzo=

| descrizione=

}}-->

with the following one:

=== Prezzi medi ===

* {{eat

| nome=test | alt= | sito= | email=

| indirizzo= | lat= | long= | indicazioni=

| tel= | numero verde= | fax=

| orari= | prezzo=

| descrizione=

}}

Once done we'll pass to the next :-) Andyrom75 (talk) 07:58, 29 July 2023 (UTC)

This should be fixed now. I was missing some translations. Jdlrobson (talk) 05:40, 3 August 2023 (UTC)

Good, I've seen your test and it seems that it works.

Now the listing editor mask.

The disposition of the various field is different from the en:voy one, also because there are some fields that one version use while the other don't; for example fax in it:voy and lastedit in en:voy (associated to the "mark the listing as up-to-date?" checkbox).

After this macro different the other should be deep dive and I'll be on vacation for 2 weeks. When I'll get back I'll perform a detailed check.

Thanks for your support! Andyrom75 (talk) 08:58, 3 August 2023 (UTC)

PS I forget to ping you :-) --Andyrom75 (talk) 08:59, 3 August 2023 (UTC)

does the order itself matter? I see URL for example is on the right rather than left but I think supporting this different order would be very difficult to maintain. Hiding fields shouldn't be a problem. Will look at that later. Jdlrobson (talk) 14:42, 3 August 2023 (UTC)

Also forgot to ping! @Andyrom75: Jdlrobson (talk) 15:51, 3 August 2023 (UTC)

@Jdlrobson I tend to agree. In this case, follow the scheme in it:voy that has a logic: free values on the left and wikidata values on the right.

Furthermore in it:Voy we have a "tool" to insert specific char into the description. This can be hidden on en:voy. Andyrom75 (talk) 16:19, 3 August 2023 (UTC)

@Andyrom75:

> @Jdlrobson I tend to agree. In this case, follow the scheme in it:voy that has a logic: free values on the left and wikidata values on the right.

Ack. So to confirm I should favor the ITWikivoyage layout over the ENWIKIVOYAGE layout? Do you think anyone in enwikivoyage would be annoyed by that or will that be uncontroversial?

> Furthermore in it:Voy we have a "tool" to insert specific char into the description. This can be hidden on en:voy

Could you share a screenshot of what that looks like just to make sure I'm looking at the correct thing?

Thanks in advance! Jdlrobson (talk) 18:56, 3 August 2023 (UTC)

Hi @Jdlrobson, I just came back from holidays.

I don't think there would be complains, but in that case we should have two different layouts. Notwithstanding a common layout, let's consider that some parts would be visible only in it:voy and some others only in en:voy.

Regarding the above mentioned tool, look for the label "Descrizione" (i.e. description) and pay attention to the clickable chars that are just under it, i.e. "( È è é )". Those chars are useful in Italian, but can be customized, if needed, in English as well. Andyrom75 (talk) 11:05, 21 August 2023 (UTC)

@Jdlrobson, @Jon (WMF), do you have some spare time to continue the work on this script? Andyrom75 (talk) 08:12, 27 September 2023 (UTC)

Hi there. Just got back from a holiday myself. Hiping to get to this tomorrow or Friday! Sorry for the lack of updates and thanks for the ping! Jdlrobson (talk) 19:17, 27 September 2023 (UTC)

{{ping|Andyrom75}}:

• Wikidata values should now be on the right and non-Wikidata values on the left.
• The characters È è é are present in Italian but not English (this is customizable)

How is this looking? Jdlrobson (talk) 17:31, 29 September 2023 (UTC)

@Andyrom75: Jdlrobson (talk) 20:10, 29 September 2023 (UTC)

@Jdlrobson it seems that you have done a long and most likely beautiful trip; nothing more important than this ;-)

Coming back to our topic, now the fields are fine, and it's correct that the char selection "( È è é )" is an Italian customization. I would just implement the code in the core and if there is at least one customized char, that function will be activated.

Please make another couple of adjustment on the layout:

1. "Delete this listing?" should be put in the original position; top right as per Italian layout. the language version that doesn't have the "last edit" feature, can have a smaller window
2. "Sync shared fields to/from Wikidata (quick fetch)" should be put below "Wikidata" field, for the same reason.

Note that the Italian label of the second point is "Uniforma le informazioni con Wikidata (inserimento rapido)" and not "qni con Wikidata (inserimento rapido)".

In order to align the "Submit" button to the latest wiki-standard, we should change the label into "Publish changes"/"Pubblica le modifiche" (possibly with a blue background).

Once done, I'll make another round of test. Thanks for your support. Andyrom75 (talk) 09:42, 30 September 2023 (UTC)

@Jdlrobson, I've just noticed that the link (currently wrongly spelled) "qni con Wikidata (inserimento rapido)", doesn't work. It return a JS error. Please check it and let me know if you need further details. Andyrom75 (talk) 10:43, 7 October 2023 (UTC)

@Andyrom75 Done:

[x] Move "Delete this listing" <Fixed in 9d440f8262>

[x]"Sync shared fields to/from Wikidata (quick fetch)" should be put below "Wikidata" field, for the same reason. <Done in 84a3c4724>

[x] Note that the Italian label of the second point is "Uniforma le informazioni con Wikidata (inserimento rapido)" and not "qni con Wikidata (inserimento rapido)". <Fixed in e2cbe1a72d5>

[x] I've just noticed that the link (currently wrongly spelled) "qni con Wikidata (inserimento rapido)", doesn't work <fixed in 570b5c7157>

Not done:

[] In order to align the "Submit" button to the latest wiki-standard, we should change the label into "Publish changes"/"Pubblica le modifiche" (possibly with a blue background).

This will require getting off of jQuery UI which we'll tackle at a later date since that's complicated. Let's focus on the functionality and performance for now before standardizing on UI.

How are we looking now? Jdlrobson (talk) 16:43, 7 October 2023 (UTC)

Testing

Thanks Jdlrobson for all the fixes and I'm fine with the last point that you have not done: I understood what you say. I'm doing some test but I think it should be ok now; just give me some more time. One thing: it's several months that the listing editor window, in both Chrome and Firefox, doesn't appear in the center of the screen: the left side is out of the screen. To read the left labels I need to move the window toward the right. Is it something fixable? --Andyrom75 (talk) 09:34, 8 October 2023 (UTC)

I don't know what's happened but in this change it mistaken the language! Actually I've just opened the listing and saved directly without touching anything.

If I repeat the same thing with the below listing, all seems to be fine. The only difference between the two, is the fact that the first has some fields duly filled. Andyrom75 (talk) 09:44, 8 October 2023 (UTC)

Regarding the listing editor window positioning - jQuery.UI is in the process of being deprecated. I'm not sure what that means but it's possible the gadget will start degrading/breaking without any action which is why I'm hoping to find a path towards removing it. It's going to be a long journey though judging on what I've seen of the script so far. I've started adding some tests.

I think I've fixed the saving issue regarding saving fields in the wrong language. Let me know if that's not the case. Jdlrobson (talk) 00:40, 10 October 2023 (UTC)

@Jdlrobson I've heard about jQuery.UI, and I'm glad that you support the migration :-)

Regarding the wrong language, I'm doing some tests right now. I've noticed the following alert (in English) "Save skipped as there was no change to the content!". Do you think could be useful to create an external file that contains all the language customization?

Furthermore, please don't stop the saving if no information has changed, because I often use the listing editor to restore the correct format of the wiki code when the editor has removed mandatory fields, or added not-existing fields. This one and this one are two examples where I've fixed the indentation. While in this example I've also restored the missing fields. Eventually, you can open that pop-up in case the final output-wikitext is identical to the input-wikitext. Andyrom75 (talk) 07:32, 10 October 2023 (UTC)

The alert only shows if absolutely no edit occurs. It shouldn't show for fixes to the indentation. Are you sure that prompt showed for those edits and not a previous one? If an edit occurs but corrects the format that will definitely go through. I just confirmed that now.

I introduced it as it confused me while debugging something as it gave the impression I was modifying the content when I wasn't. I can make that configurable and translateable it's not a big deal, but it seemed very misleading to suggest to the user they've made an editor when they haven't.

Regarding external file: yes that's my plan, it's just easier for development since we have this feedback loop to keep them together for now - I can separate these once you've informed me the gadget is an acceptable substitute for the existing one :) Jdlrobson (talk) 16:46, 10 October 2023 (UTC)

@Jdlrobson, maybe you are right, I just got the wrong impression during my tests. Now I'll deploy it in it:voy to check its usage from other people. If no other anomalous behavior will arise, you can proceed with language separation before the deploy in en:voy, so we can check it in advance. Andyrom75 (talk) 11:27, 11 October 2023 (UTC)

@Jdlrobson, I would say that now all is fine. If you want you can implement the separate file for the language customization. I would say that, that file, should stay in the landing community and not centralize in en:voy. What do you think?

Once done this step, I'll test again the tool, then I'll activate it in en:voy as well. Andyrom75 (talk) 20:48, 16 October 2023 (UTC)

That's great! I'll look into ways to package up the site specific code per project. Jdlrobson (talk) 15:12, 17 October 2023 (UTC)

Okay this should be done now! Let me know if I broke anything (I made some edits on our favorite test page it:XVI_arrondissement_di_Parigi and all seems good there). Jdlrobson (talk) 00:31, 21 October 2023 (UTC)

@Jdlrobson, there's an issue. If I modify an existing listing, the field "nome" (name) is not filled with the stored value and for example you test cannot be saved because name and address are missing. I've just tried to force a new name in the listing editor and the result is a mess (look at the last change). Please check it asap because the current bug affect the whole it:voy. Andyrom75 (talk) 08:25, 21 October 2023 (UTC)

Should be fixed now. My apologies I made a typo in the configuration in MediaWiki:Gadget-ListingEditor.json

Fixed here Jdlrobson (talk) 04:06, 22 October 2023 (UTC)

@Jdlrobson, thanks for fixing it. Now it seems to properly work.

I was checking both MediaWiki:Gadget-ListingEditor2023.js and MediaWiki:Gadget-ListingEditor2023Main.js: do you think would be possibile and make sense to centralize the custom language portion in just one local file? Andyrom75 (talk) 10:38, 22 October 2023 (UTC)

I've been thinking about this a but. One nice thing about the current structure is the interface can be translated e.g. on Italian I can view it in English.

Right now the payload is not a big concern - most of it is jquery.ui.

I guess we will monitor the size of the payload as we had more project/language support.

I think for readability/maintainability we can split up the language files into separate files but continue to host them on en.wikivoyage? Would that be okay with you?

I was also wondering if I could get interface editing rights on enwikivoyage with my personal account - as it feels like I am doing this more in volunteer time now. Do you think that would be possible? Jdlrobson (talk) 18:22, 28 October 2023 (UTC)

@Jdlrobson, the main problem I see on centralize the language customization, is that a community is not autonomous on apply a change. It's like on (de)activate specific feature, it should be better to store the "switching parameter" inside the community.

However, this is just my personal approach. Anything can have pros & cons. So if you don't like it, let's keep it as it is.

When you confirm me your preferences, I'll proceed accordingly.

Once we complete di upgrade for both it:voy and en:voy, the next Wikivoyage language version to support is fr:voy. But is a bit more complex because when they fork it, they have applied several changes and it seems that no more admin are active in this moment. I got interface admin roles for 3 months to fix several issues, around the code.

I have no concern on giving you interface admin role, but I'm not a bureaucrat in en:voy, so you should ask it in Wikivoyage:User rights nominations. I'll be glad to support your request.

PS Anytime you write me, please ping me, so I don't have to check this page everyday :-P Andyrom75 (talk) 15:07, 30 October 2023 (UTC)

@Jdlrobson, @Jon (WMF), since in it:voy all is working correctly, I've just activated the script in en:voy as well. Let's monitor the situation to be sure that also here all is fine (although I'm confident it will be).

Let me wrap up the other points:

1. User rights: candidate yourself in the nomination page
2. fr:voy: when you'll be more available, we can try to extend the listing editor implementation also to the French version

Thanks, Andyrom75 (talk) 11:40, 27 November 2023 (UTC)

@andyrom75: thanks for the update! In December I should have some bandwidth to continue with the next todos. How familiar are you with the remaining forks (e.g. german etc) and what order would you suggest converting them? Jdlrobson (talk) 15:00, 27 November 2023 (UTC)

The most similar is definitely the fr:voy one. It's just a matter of new/different fields to be managed. Andyrom75 (talk) 17:16, 27 November 2023 (UTC)

@Jdlrobson, @Jon (WMF), oops, I forgot the ping. Andyrom75 (talk) 12:23, 30 November 2023 (UTC)

@Jdlrobson, @Jon (WMF), happy new year's ping :-P Andyrom75 (talk) 09:33, 9 January 2024 (UTC)

This is still on my todo list which keeps getting longer than expected. I'm sorry it's taking so long but I haven't forgotten :-) Jdlrobson (talk) 01:40, 18 January 2024 (UTC)

@Jdlrobson, @Jon (WMF), I suggest to replicate the old approach that consists in having the listing beta version in the experimental section. We can improve the beta version first and once it has been successfully tested, to inject the new code in the official tool. This should mitigate the possibility that unexpected bug would prevent the tool to be used by the various users.

What do you think? --Andyrom75 (talk) 14:34, 25 January 2024 (UTC)

Sounds like a good idea. Could you setup the gadget and a testing group (ideally we should have at least 5 people using the beta gadget)?

I am going to also setup error logging for wikivoyage so that we can see the errors in real time. Jdlrobson (talk) 15:03, 25 January 2024 (UTC)

(Ping User:Andyrom75).

Once, Wikivoyage:User_rights_nominations is completed I'll copy the code there. Jon (WMF) (talk) 22:59, 26 January 2024 (UTC)

Experimental ListingEditor - where to place it?

@Andyrom75: how should we setup the new experimental gadget? I see there is already one under the experimental section. Should I reuse that? Once we've decided where, I can copy the latest code of the ListingEditor for us to test out.

Note: I'm now monitoring JS errors on Wikivoyage.org so I will also be able to monitor JS errors in real time! Jdlrobson (talk) 06:34, 4 February 2024 (UTC)

@Jdlrobson, in the experimental section there is the old listing editor, to be used in case of failure of the new one (like the situation that recently happened).

Now in the experimental section, we can substitute the old listing editor with the beta version of the new one.

Sorry if I haven't proceed, but I want to be sure to create it properly, avoiding "script overload".

With the old version it was easier the implementation because we used only two files: ".js" & ".css". Both linked to the same gadget line that a user can activate/deactivate.

The new version uses multiple files:

• ListingEditorConfig.js - hidden
• ListingEditor.json - hidden
• ListingEditor2023Main.js - hidden
• ListingEditor.css - hidden
• ListingEditor2023.js

Theoretically we should create the following beta version files:

• ListingEditorConfigBeta.js
• ListingEditorBeta.json
• ListingEditor2023MainBeta.js
• ListingEditorBeta.css
• ListingEditor2023Beta.js

But since only the last one (i.e. ListingEditor2023.js) is visible and under user control, we would have a conflict between the beta version and the "official" one, because the hidden files will be loaded in any case (if I'm not wrong...).

All that said. I was wondering if you think would be possible to collapse the following three lines:

ListingEditorConfig[ResourceLoader|package|hidden]|ListingEditorConfig.js|ListingEditor.json

ListingEditor2023[ResourceLoader|default|skins=vector-2022,vector,timeless,modern,cologneblue,monobook|type=general]|ListingEditor2023.js

ListingEditorMain[ResourceLoader|hidden|skins=vector-2022,vector,timeless,modern,cologneblue,monobook|type=general|dependencies=mediawiki.util,jquery.ui]|ListingEditor2023Main.js|ListingEditor.css

into just one line, like:

ListingEditor2023[ResourceLoader|default|skins=vector-2022,vector,timeless,modern,cologneblue,monobook|type=general|dependencies=mediawiki.util,jquery.ui]|ListingEditor2023.js|ListingEditor2023Main.js|ListingEditor.css|ListingEditorConfig.js|ListingEditor.json

PS I haven't tested, but if it works, it would definitely simplify the next steps. Andyrom75 (talk) 12:04, 5 February 2024 (UTC)

Okay I've revised the code to make this super simple. There's a new module that triggers the beta and displayed in preferences:MediaWiki:Gadget-ListingEditor2023Beta.js and there's a hidden module in MediaWiki:Gadget-ListingEditorMainBeta.js containing the latest code.

At any time it should be safe to promote (copy) the contents of MediaWiki:Gadget-ListingEditorMainBeta.js to MediaWiki:Gadget-ListingEditorMain.js when you think the code has been adequately tested.

Please opt into the beta - if you are in all links will show as add (beta) or edit (beta). Let me know if any issues!

Happy weekend! Jdlrobson (talk) 05:36, 10 February 2024 (UTC)

(Oh and ping @Andyrom75 :-) - not sure if you are subscribed to this thread!) Jdlrobson (talk) 16:45, 10 February 2024 (UTC)

@Jdlrobson I've moved the beta into experimental section.

Let me know what do you think about the following points:

1. If we need to change ListingEditorConfig.js, ListingEditor.json or ListingEditor.css we will impact both the beta version and the one in production. I would separate completely the two version.
2. If I'm not wrong, the hidden gadget are always loaded (please confirm). In the affirmative case I see the following potential issues:
   • These two files are loaded on every skins (even those where the listing doesn't work): ListingEditorConfig.js & ListingEditor.json
   • These two files are loaded at the same time on the specified skins: ListingEditor2023Main.js ListingEditor2023MainBeta.js

Andyrom75 (talk) 23:32, 10 February 2024 (UTC)

Thanks for reorganizing!

1. Theres no need to separate the config. At this point it's highly unlikely those files will change in a breaking way other than to improve or add translations. We can change if we realize that assumption doesnt hold but for now it does (all that file does is create the edit and add links)
2. Making the editor work on all skins is my next goal. The config is tiny relatively speaking so it is fine to load on page load. Main.js and MainBeta.js should never be loaded at the same time (there is an if statement). Where are you seeing that?

Jdlrobson (talk) 16:45, 11 February 2024 (UTC)

@Jdlrobson, I'm looking at the last two lines of MediaWiki:Gadgets-definition. What do you think? Andyrom75 (talk) 18:08, 11 February 2024 (UTC)

Neither are default so shouldnt be loaded until the ListingEditor loads them. Jdlrobson (talk) 21:18, 11 February 2024 (UTC)

@Jdlrobson, so if none of those are loaded by the ResourceLoader, why to keep them there? Could we eliminate those two lines? Andyrom75 (talk) 14:34, 13 February 2024 (UTC)

These hidden modules are lazy loaded when edit and create are clicked. This is why the new module is more performant - none of this code is loaded on page load, only on click.

You can move them or add a long comment explaining why they are there but we dont want to delete the lines.

Does this make sense? Sorry for not explaining better. Jdlrobson (talk) 14:51, 13 February 2024 (UTC)

@Jdlrobson, I'm familiar with LUA lazy loading but I wasn't aware that also the JS gadget works this way. Nice to know. Do you know where can I find a wikimedia tech page that talks about it?

PS I also didn't know about "night mode"; I've just patched it:voy :-) Andyrom75 (talk) 16:29, 13 February 2024 (UTC)

I would have thought one did exist but a quick search didn't yield anything. All I could find was the documentation of hidden on https://www.mediawiki.org/wiki/Extension:Gadgets#Options alluding to it and https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader#Client-side_(dynamically).

It seems like such a page should be linked to from mw:Extension:Gadgets so perhaps that's worth a suggestion on the talk page? Jdlrobson (talk) 03:09, 14 February 2024 (UTC)

Now, the lazy load explained in mw:ResourceLoader/Developing_with_ResourceLoader#Client-side_(dynamically) it's pretty clear to me. Thanks for the link.

Theoretically, if I'm not wrong, the above lazy load mechanism can also work without the hidden option.

Which is the benefit of the use of the hidden option?

Or maybe it's not a matter of benefit and it's just necessary, but it's not clearly written anywhere. Andyrom75 (talk) 09:12, 14 February 2024 (UTC)

The hidden option basically hides it from user's - we don't want user's to enable it via the preferences page - as that would ruin the benefit of lazy loading and might cause some confusion (for example it does nothing if not loaded with the main module)! Jdlrobson (talk) 20:13, 18 February 2024 (UTC)

@Jdlrobson, I didn't mean to keep the hidden gadget removing the hidden parameter. I was wondering what would happen removing the hidden gadget at all.

I mean, the JS lazy load embedded in the main script activated by the main gadget, would keep on working or not? Andyrom75 (talk) 22:19, 19 February 2024 (UTC)

Oh I see what you mean. Right now we're referencing this gadget and loading via the module name rather than the script, so if we removed it, it would cease to exist and stop working.

the relevant line is MediaWiki:Gadget-ListingEditor2023.js#L-6

We could of course refactor this not to load the gadget via mw.loader.using and directly access the script but we'd lose the benefits of ResourceLoader. Jdlrobson (talk) 22:48, 19 February 2024 (UTC)

Ok, now I think all is clear. Let try to rephrase as a double check :-)

JS Lazy load could work also without the definition of ListingEditorMain and ListingEditorMainBeta in MediaWiki:Gadgets-definition, but we'll lose the benefit of ResourceLoader that compress the scripts server side before sending the code to the client.

Is it correct? Andyrom75 (talk) 18:37, 20 February 2024 (UTC)

Exactly! The compression is one benefit - but the other is being able to separate this into multiple files in future. Jdlrobson (talk) 04:53, 21 February 2024 (UTC)

Excellent. Now we are on the same page :-)

Last thing on Special:Gadgets. If I'm not wrong, differently from the "old" listing editor, when a user activate the beta version, it's not strictly necessary to deactivate the main gadget. Isn't it?

In the affirmative case, I have to modify the beta gadget description/alert that I've put in bold.

Once fixed this, I think we can definitely remove also the old gadget from the preferences (although I wouldn't delete the files for future reference). Andyrom75 (talk) 08:50, 21 February 2024 (UTC)

Correct. Beta can be enabled alongside the main one.

We should also disable the old one. In the current situation it's possible some logged in users might have both the old and new enabled. Jdlrobson (talk) 04:51, 22 February 2024 (UTC)

Done.

If you agree, it could be good to create a variable with the version ("v3.0.0" VS "Beta") that will be show in the windows title. Andyrom75 (talk) 08:10, 22 February 2024 (UTC)

Strange behavoir

@Jdlrobson, check this change. Wrongly the listing editor is adding the coords "0, 0", while the two fields should remains empty.

Same thing happened in the previous 3 changes. Andyrom75 (talk) 19:43, 30 May 2024 (UTC)

Yep this is the issue flagged in Wikivoyage:Travellers' pub#Significant problems with the listing editor. I will hopefully have a fix tomorrow. Sorry for disruption. Jdlrobson (talk) 20:07, 30 May 2024 (UTC)

Site script optimization

@Andyrom75 hey there hope you are well!

Firstly, I'm sorry I've not been as attentive recently. I'm hoping to have some time late November/early December for Wikivoyage gadget support and I'm hoping that I can also improve this situation in the process to make best use of that time!

I was reviewing Wikivoyage's performance and it's better now but still not as good as it could be. There are quite a few gadgets here marked as "Default" that are loaded on pages where they are not needed and I think we should aim to improve this in 2025.

Following the optimizations we made to ListingEditor, I would like to suggest we adjust the other gadgets to load with one of two patterns:

• Template gadgets (adding categories to the pages that use them)
• Loading them via a new proposed hidden single loader gadget (MediaWiki:Gadget-DefaultLoader.js) which will load code based on checks on the page e.g. present of certain elements on the page e.g. only load the Carousel code when there is a carousel on the page.

I know the carousel is used on the main page, but I'm wondering if there are other pages it is used.

To support this work, do you think we could as a first pass make sure pages that are using these gadgets have an associated category (possibly via an update to their templates?) - is this possible?

e.g.

• Pages that use the carousel gadget -> Category:Pages which use carousel
• Pages that use Mapframe gadget -> Category:Pages which use MapFrame
• Pages that use Maptool gadget -> Category:Pages which use MapTool

Is there anything I'm overlooking here or over simplifying? Jdlrobson (talk) 16:47, 5 November 2024 (UTC)

@Jdlrobson, thanks for your message. In this period I have some personal issues, so I'm forced to postpone my engagment. However, generally speaking, if you don't mind I would prefer to complete the previous pending tasks, before open other new tasks to avoid to have to much "half done jobs". Andyrom75 (talk) 07:29, 9 November 2024 (UTC)

Yes this is in addition to pending tasks. Jdlrobson (talk) 18:17, 9 November 2024 (UTC)