The Sims Wiki talk:Development Portal

Archives 1 2 3 4

Community

Community Portal (talk) · Community Discussions forum
Fanon Portal (talk) · Game Guide Portal (talk) · Development Portal (talk) · Admin Portal (talk) · Main Page talk

Information

Here you can post updates on what you're working on or a notice to others concerned with the development of the wiki. For general discussion see the Community Portal talk and for minor news see the Development Portal main page.

Giving TS4 Headshots Black Background

Is it an idea, that like the TS2 headshots and the TS3 headshots to give all TS4 headshots a black background as well? It might not be necessary, but it gives the wikia a consistent look doesn't it? I'd like to hear your thoughts DeSims ^(talk) 19:59, September 19, 2017 (UTC)

Updating {{Pagecover}}

*Blows dust off the Development Portal Talk Page*

So, I have no idea where else I would start a discussion related to this. Here goes!

As I've been working on the new infobox conversion, I've started to wonder whether some of our other wiki templates may benefit from a re-working of their existing code. To that end, I took a copy of Template:Pagecover over to my test wiki and redesigned it so that the base code for the template is located in MediaWiki:Wikia.css, instead of within the template itself (through in-line css). After a couple hours' worth of work, I think I've got the template fully converted. As far as I can tell, it functions exactly the same as the present Pagecover, save for two deliberate and minor changes. However, I can't be totally sure that the template does work in 100% of cases, and as {{Pagecover}} is used on (by my estimate) about 500 pages on the wiki, I wanted to see if anyone else (*cough*Nikel23*cough*) could take a look at the template and css code and see if they could spot any deficiencies or bugs.

Like I said, I'm pretty sure that the template is fully converted, so the css code for the template's functionality has been added to The Sims Wiki's MediaWiki:Wikia.css page (but not yet added to "MediaWiki:Common.css"). I have also put the new template code at Template:Pagecover/test for further experimentation and tweaks. Any assistance that anyone could lend would be appreciated!

P.S. the two aforementioned "minor changes" from "old" Pagecover to "new" Pagecover are:

• There is no "noname" parameter in the "new" design - in the "old" design, this parameter would stop the header and text from displaying on top of the image, allowing a user to use Pagecover as a sort of "large image frame." (see this blog post of mine for a real-world example of this feature in action) In the "new" design, the "name" parameter is no longer mandatory and, if left blank, the header and all text will be kept invisible, even if other text parameters are filled in. This change should not affect the appearance of the template in instances where "noname" is invoked, since it will be a blank parameter with no built-in functionality; additionally, in those cases, "name" already would've been left blank, so the overall effect will be the same either way.
• There is no "toc" parameter in the new design. Anecdotally it seems that the table of contents feature in "old" pagecover is very rarely used, so it seems pointless to include it in the new design.

Thanks -- LostInRiverview ^{talk · blog · contribs} 08:09, February 11, 2018 (UTC)

Families from...

I personally think that the Families from categories (ie this category) should be renamed into "Households from <game> <pack>". Since there are households that aren't blood related, such as the Roomies household and the BFF household. Other categories including families should also be replaced. Also, they're just officially known as households vs. families. Maybe separate categories could work too.

Sorry if this is in the wrong place btw, I'm not really familiar with this wiki. --akumi (talk) 16:26, June 8, 2019 (UTC)

That's not a bad suggestion. Unfortunately, it's not simply as easy as renaming a few pages. Categories, unlike articles and templates, cannot be renamed once they are created. In order to do as you've suggested, we'd have to create brand new category pages and then delete the old ones. Even then, this still is not an insurmountable obstacle. What would be difficult, however, would be the second part of your suggestion; splitting categories. Right now, the template {{Infobox family}} auto-categorizes family/household pages, but there is no mechanism built into the template as of now to differentiate between a family and a household. It is possible to create such a thing, but I'd wonder whether the end result is worth the effort. -- LostInRiverview ^{talk · blog · contribs} 16:31, June 8, 2019 (UTC)

Hmm, that's fair. --akumi (talk) 18:49, June 8, 2019 (UTC)

TS4 neighborhood categorizing bug

For awhile now, we've had an issue where TS4 neighborhood pages (not world pages, but the pages about the neighborhoods within the worlds) were getting categorized into Category:Neighborhoods in, which is a glitch category. I am happy to say that, with a single exception, that is no longer a problem and all TS4 neighborhood pages should now be automatically categorizing properly.

The issue was in the way that {{Infobox neighborhood}} assigned categories. The infobox would take the input name of the neighborhood, and cross-check it against {{Checkgame}}; the purpose of that template is to simply say which base game a particular world/neighborhood belongs to. The problem is that Checkgame only included the TS4 worlds, but did not include the TS4 neighborhoods. When I thought about it a bit, I realized that having a template to check which game a neighborhood/world appears in is unnecessary. So I reworked Infobox Neighborhood so that it looks for the game parameter instead of the neighborhood's name, and then checks to see if the game is on the {{MGL}}. The MGL outputs a code for the base game, even if the name that is input is an expansion/game/stuff pack, and then I plug that output into {{Vgcode}} to spit out the full name of the base game. I did it this way because our current operating principle has been to categorize all neighborhoods/worlds within a given game together, even if some were introduced in expansions (for instance, we don't have a category Category:Neighborhoods in The Sims 2: Seasons, even though that expansion introduced Riverblossom Hills).

The end result of all these workings is that neighborhood pages for TS4 no longer need to be manually categorized into "Category:Neighborhoods from The Sims 4" or "Category:<world> neighborhoods"; the template will do both automatically. When I get a chance, I'll take a look at {{Infobox world}} as well and try to prevent similar problems on that front. My goal is to make it so that {{Checkgame}} isn't used on any templates and can be deleted.

I tested the changes out before I implemented them. While I cannot see any errors in what I've done at this point, if you encounter any problems with the change, please let me know so I can address it. -- LostInRiverview ^{talk · blog · contribs} 04:25, June 16, 2019 (UTC)

Template:User contributions

{{User contributions}}, which is a userbox for user pages, is currently broken. The template references Special:Editcount in order to work, but as you can see, that page no longer exists. Does anyone know a different way to fetch a user's edit count, or will we need to scrap the userbox? -- LostInRiverview ^{talk · blog · contribs} 20:49, 18 March 2021 (UTC)

Major concerns regarding Special:AbuseFilter

I have big concerns about the validity of and initial implementation of Special:AbuseFilter/52, especially in light of [1] where even good-faith improvement file moves by registered users are prohibited and locked behind a "Mods and higher only" wall. I strongly wish to request that the implementation of that filter be reconsidered and likely changed in some way. Dandelion Sprout (talk) 01:02, 10 February 2024 (UTC)

The filter was created to restore the previous pre-UCP behaviour on the wiki, which was that files could only be moved by admins and content mods. This is also default behaviour on Wikipedia and other related projects. There are a few reasons for this:

• Files can be used on many pages, and so restricting file moves can limit the potential for damage from page move vandalism.
• When a file is moved, links pointing to it need to be updated; most users forget to do this, which can cause problems if the file is ever moved again (as double redirects are not followed).
• Pre-UCP, non-admins could not suppress redirects when moving pages; but post-UCP, this was changed. The ability to suppress redirects can cause widespread damage if misused, and most non-admins and non-content mods don't understand the ramifications for suppressing redirects (there is rarely a case where a redirect would need to be suppressed when moving a page).

Lastly, files with bad names generally aren't a huge issue, compared to an article with a bad name. There's rarely a need to urgently move files because of their name. Unlike articles, most readers don't search for files by their name, and it's only shown to them when they click on a file; it's not shown or relevant when they are simply reading an article. As such, file maintenance—although important—is something that is risky enough that it shouldn't be open to everyone, but also not critical enough that admins and content mods would need to delegate the task to non-admins.

Presently, file renaming can be requested on the administrators' noticeboard, which is linked to in the message the filter provides. If there is consensus, the file move restriction can be adjusted (say, to allow accounts above a certain age and edit count), à la filter 51, which was created because we had some particularly bad cases of brand new accounts moving pages (i.e. this and this). Thankfully they didn't move any files, but it's a much bigger hassle to have to clean up after file move vandalism, especially if NSFW images are involved. I would still prefer only users that understand what file moving entails to be able to move files, though; in particular, understanding that suppressing redirects shouldn't be done unless there's a good reason for it. —k6ka 🍁 (Talk · Contributions) 02:30, 10 February 2024 (UTC)