Four years after the initial publish of the tool for editing translations for scripts on Dev, its second version finally arrived! This post serves as a changelog for the second version, an announcement to all translators that the features they requested are finally in the editor, as well as a call for a bug hunt in the new version (since the code was pretty much written from scratch). Without further ado, here are the new features:

• You can now translate into multiple languages at once

• You can choose which language to translate from, so reference messages in the editor will be in that language

• The translation interface has been improved, as it's no longer a table with all messages in it but rather a list of messages to select in the left panel, and a group of text boxes to translate the selected message in (screenshot below)

• Translation drafts are automatically saved so when refreshing the page or changing to a different page they won't be lost

• There is a button to discard translations of the current page

• The interface to edit English translations, message descriptions and metadata has been merged into a single interface (actually a regular translations editor but with additional buttons)

• There is a button to remove a message in the message management interface

• When you edit English translations, it sometimes requires updating messages in other languages too. The previous version of the editor allowed you to remove all changed messages upon saving, but that solution wasn't ideal, so the current version allows you three options: mark changed messages as outdated(!), remove changed messages or don't do anything.

• You can now edit Lua translations in the editor too! The option to switch is on the translation listing page, in the edit dropdown

• The translation listing page now allows you to filter by script name, as well as filter only to scripts whose translations to a certain language are missing (there are no translations in that language), incomplete (there are some translations in that language) or outdated (English messages changed since the translation was first done)

• There is also a translation creation wizard now! It lets you choose a translation name, then import your translations in JSON form and validate that JSON to make sure it's I18n-js-compliant (if you don't have any translations in JSON form, you can just skip this step) and then enter the editor to add or remove your messages before publishing your translation

• The language picker list and the add language modal are now in the same list that you can filter by language (if you filter by a language for which translations do not exist you can select that language for translation)

• You can now switch between editor screens without reloading the page (the URL will still update and your browser history will still function the same, it'll just be faster)

• The interface has been improved to use more Fandom Design System components to be consistent with other interfaces on FandomDesktop

• There are indicators in the translation editor screen next to messages which are translated to all languages (✅), outdated in some languages (⚠️) and not translated to all languages (❌)

At the time of writing, the script has not been approved, which means you'll have to use test mode to see the new editor (and that translations of the old editor are a bit broken), I will make an announcement when the script is approved, and you're welcome to test it out! For example, you can start by translating the messages newly added into I18nEdit.

Documentation is coming soon! We'll replace the redirect page with actual documentation, but until then you can leave feedback about the editor on its talkpage (you can do so in this thread as well, but doing it on the talkpage makes sure we see your feedback when developing future versions of the editor).

In Mediawiki:Common.js I'm currently using a switch as logic, along with mw.config.get('wgPageName'), to control what pages load custom JS.

Lets say I have a template and a separate MediaWiki:My_Calculator.js to add a tool to certain pages. The My_Calculator.js doesn't change and nor does the template.

Now the problem, every time I want to add this template to a page I have to edit the MediaWiki:Common.js switch statement.

Maybe it doesn't matter how many times I ask for review. But it seems smart to me to find a better way to do it. I should only need to ask for review if I change MediaWiki:My_Calculator.js.

Any suggestions?

~~~~

So I looked through this page but I don't know how to or where to put it.

https://dev.fandom.com/wiki/IgnoreNotifications

And I want to ignore all the notifications from one post or one wiki, how do I do that?

Also do I put those in my common.js?

I finally got around to fixing and finishing some things with UserLastActivity. I want to update the documentation page but there is a bit of a hiccup. The updates would change a substantial part of the documentation and there is already a Spanish translation of the page. This wouldn't be a problem if I had left things as they were but I also decided to parameterize (following KockaAdmiralac's example with ViewNotificationsUsers) the documentation page to make future translations easier.

The issue here is that, when I make the changes to the English page, I won't be able to translate and update the Spanish page since I don't know Spanish. I tried looking around and there doesn't seem to be any way to use an old version of a page when transcluding content. Any ideas? Perhaps I should revert the Spanish page to before the parameterization?

Hey, is it possible to control discussion with some sort of js/css codes? Like something to block posts that are over 30 days old? I write it here, because I heard that was dev tools to do it.

I Remember That Have a Way To Change The Coding of Pages

But I Don't Remember How

Example:

Wikitext to Javascript

GeoJson to Wikitext

Does FANDOM have:

• At least Jquery 1.12.4?

• At least Jquery UI 1.12.1?

• Jquery UI CSS? Or I'll just import one.

Because I want to create a project based on those

I'm curious to know roughly how difficult it would be to port a Lua module from another Wiki such as Wikipedia or MediaWIki, as they have quite the library that people have built. I know that there would be a number of things that would need to be changed such as refences, or usage of an extension that isn't available on Fandom, though I would hope the majority could still be made to work with enough time and effort?

On that note, is there anything to look out for when looking at modules as a sign that they would not be able to be made workable on Fandom? (Again such as relying on an extension that can't be substituted, or some other restriction.)

From what I've read about how gadgets works, I believe you can use an importArticles block and @import statement to import JS and CSS files from the dev or any other wiki, similar to how you would on a global/personal page?

However, as they would still be used on custom JS pages I know that they would still need to go through the review process.

Also I want to confirm as I've only seen this implicitly implies when reading help articles, that scripts/CSS that are marked for personal use can be created as a gadget as long as they are not set to default on (for the obvious reason)?

Background/Context

As KockaAdmiralac and Pcj undoubtedly know, I submitted ImageMapEditZoom earlier today/yesterday for review. It is supposed to be an add-on for ImageMapEdit so users can more easily use the script on large images or images where there are small details.

The version I submitted works fine. I tested it a lot before even creating the script page on this wiki. However, after I submitted it, I noticed that ImageMapEdit "exposes" most of the functions and variables it uses. So much so that I was able to (relatively) quickly re-write ImageMapEditZoom to use what I refer to as a more "invasive" method to get the desired results.

The Different Versions

If you want to see the new version, you can view this revision of my common.js on Wreck-It Woodhouse Community. The script is the bottom portion of the JS page. Otherwise, here is a summary of how each version works.

The current version uses a mutation observer to watch the overlays. It infers which action has been taken in the main script based on the types of mutations it sees. It keeps an independent record of the sizes. Each time the user zooms or an update is made by the main script which "un-zooms" the overlays, the add-on resizes the overlays as needed for the current zoom level.

The new version takes advantage of the "exposed" functions and variables of the main script. Specifically, it manipulates the main script's scaling variable. This is what the main script uses to determine the relationship between the image map coordinates and the size of the overlays. During non-modified operation of the main script, this value wouldn't be changed after initialization. As for when the user zooms, the new version triggers the main script's map update function which includes redrawing the overlays. In doing this, the new version needs neither a mutation observer nor and independent record of the overlay sizes.

The new version is 3180 bytes smaller than the current version. This makes the file size about 60% that of the current version. From previous discussions, I have gotten the impression that there is quite a bit of value placed on keeping scripts as short as possible so they can load faster and whatnot.

Questions

The new version seems more "invasive" to me but perhaps it is just because I am not a frequent player in the opensource freeware community. I would have thought that the script wouldn't want others messing with its stuff because then it cannot rely on knowing the state of its own functions and variables. The intent isn't clearly stated in the repository but perhaps that is just because there is supposed to be an implicit understanding that I just don't have.

That said, perhaps this was done intentionally to allow add-ons/variations?

Is the method used by the new version of ImageMapEditZoom considered good or bad practice?

Regardless, is it worth using since it is simpler and shorter?

I have long been looking for the documentation for this endpoint. I remember there used to be documentation returned when visited, but now it is removed(?). Where can i find the documentation for the api?

{"status":404,"error":"ControllerNotFoundException","details":"Controller not found: ApiDocs"}

Hello.

Yeah I did ask this on CC, but I was told that this wiki is the preferred location for questions like the one I have.

Anyways, on the Juke's Towers of Hell Wiki, I've been trying to use AutoWikiBrowser to fix a common issue with some tables, by replacing the following source code:

{| class="wikitable mw-collapsible" style="text-align: center; width:100%;"
! colspan="31" style="text-align:center" |

Data from JToH Discord Server

With what's shown below:

{| class="wikitable mw-collapsible" style="text-align: center; width:100%;"
! colspan="31" style="text-align:center; background-color:#337800" | Data from JToH Discord Server

However, the bot does not seem to find any pages with the code I have given it to find, even though I literally copy-pasted this code from one of the pages with this issue, not to mention MANY pages have the same exact code (such as this page, check the code for the table in the "Tower Reviews" section)

Note that I am using the advanced find and replace tool, no regex and I have given the bot one rule. I have no idea if this might be the problem however.

It's basically a script that fetches the specified provider's API to get the sound file, and many other music services such as Spotify, Soundcloud, etc.

And then playing it in the page where the script is specified to play, for example, in a MediaWiki:Custom-BackgroundAudio:

Example|youtube|dQw4w9WgXcQ|5

It would play the audio from YouTube with the video ID of dQw4w9WgXcQ with a volume of 5 in the page "Example"

Is this possible? Or would it violate the customization policy?

This was a thread on the Community Central wiki, but we thought it would be more appropriate to discuss the issue here.

Can we do math/string operations with the edit count?

FYI, the edit count refers to {{Special:Editcount/Username}}, the number of edits on a wiki for a specific user. So say for example if I've made 351 edits here then {{Special:Editcount/Username}} should return 351 for me.

What I want to do, is to take each digit from the editcount value, meaning if my editcount was 351 I would want a function that could return "3", "5", "1" seperately, then the seperated digits would become images, I basically made images that display the digit in a "fancy" manner, so I should have [[File:3.png|50x50px|link=]][[File:5.png|50x50px|link=]][[File:1.png|50x50px|link=]] as the output.

Is this possible? Me and a few other users (that are far more skilled than me) have tried, but nothing worked.

Best regards,

Doz

I was just reading some of the public abuse filters on this wiki, and noticed that they are outdated. I understand that it might not matter much since the usergroups that are missing from the filters are able to bypass abuse filters

But I noticed how the "wiki-representative" and "wiki-specialist" groups aren't included in them. And the deprecated "vstf", "wiki-manager", and "content-team-member" groups are.

Hi, I don't know if I'm allowed to post this here. If I'm not, feel free to delete! :D

Hope you all like it! Made by Scr1pp3d

I don't really understand this part, can someone explain it to me? Thanks!

https://dev.fandom.com/wiki/CustomComments#Adding_groups

While leaving it as the default white may have been fine on the Oasis skin, due to the new default background on UCX having graphics on them, it can make it nearly indistinguishable to tell if I am on the Dev or CC wiki without having to specifically look at the name in the top left, as even the logo is very similar.

I understand the point is likely to remain similar to CC due to it's shared purpose, however I think there still needs to be some kind of visual distinction between the two even if only slight (such as keeping the same colour scheme but replacing the graphic/texture), so I don't get completely confused which wiki I am looking at.