The Sims Wiki talk:Development Portal

MediaWiki:Wiki-navigation error
I want to add Blog:The Sim's Pen to the navigation under blog posts button, but the editor doesn't allow me. It says the level 1 menu is too wide. It's odd, because it will say so even if you preview it without making any changes. Sooner or later if we need to edit the navigation, we need to shorten the level 1 menu name as well. I tried to change "Interact" into "aaa" and the editor allowed me. Any ideas which menus to shorten?  Nikel  Talk  –  Vote!  14:46, September 18, 2014 (UTC)


 * I'm getting the glitch on my other wiki too, which is strange, because it fits just fine. Looks like Wikia broke something here. Special:Contact it, maybe? --k6ka (talk &#124; contribs) 14:47, September 18, 2014 (UTC)


 * Well, the error tells us to go to w:c:community:Help:Navigation. The "error" seems intended, meaning it's more like they changed the limit (while keeping the preexisting navigations intact so they won't be broken).  Nikel  Talk  –  Vote!  15:03, September 18, 2014 (UTC)


 * Hmm, it seems like the error has been fixed. --k6ka (talk &#124; contribs) 14:03, September 19, 2014 (UTC)
 * ...only to be broken again! What's going on here, Wikia? --k6ka (talk &#124; contribs) 14:28, September 20, 2014 (UTC)


 * Okay, I have reported the issue at Community Central. --k6ka (talk &#124; contribs) 21:38, September 20, 2014 (UTC)


 * Alright, there are two solutions to this that I have tried on my test wiki and has worked.
 * Move the page MediaWiki:Wiki-navigation to another title, make your changes, and then move it back. This, however, will break the navigation bar while the original navigation page is a redirect, but it works.
 * Copy and paste the following code into your user CSS file:

/* Special thanks to User:452 for this! Original taken from http://community.wikia.com/wiki/User:452/global.css?diff=prev&oldid=1343313 */ /* This thing fixes the broken width check in MediaWiki:Wiki-navigation */ .ArticlePreviewInner .WikiHeader li.nav-item a { /* Because the width check is broken. */  margin: 0; padding: 0; }
 * This code works by reducing the width of the tabs in the preview window. It looks horribly squished while previewing, but it will fool the check into thinking that it's of the right size and will let you publish the edit. Just be careful! This could potentially allow you to save an invalid layout into the page, which can result in unpredictable results! It's best to test your changes on a test wiki to make sure nothing is out-of-place or broken before you save it on a real wiki.
 * You can also put this in your global CSS file so it loads on all wikis, which is useful if you're an admin on other wikis. See Help:JavaScript and CSS Cheatsheet for details. --k6ka (talk &#124; contribs) 01:59, September 21, 2014 (UTC)
 * The issue only appears to occur when using Google Chrome 37... other browsers and older versions seem to work without the fix above. --k6ka (talk &#124; contribs) 11:58, September 21, 2014 (UTC)

Sorry I was a little late to follow this up. Nice workaround! Thank you for reporting and finding a workaround for this issue, k6ka. :)  Nikel  Talk  –  Vote!  11:54, September 22, 2014 (UTC)

Introducing Edit conflict
Sick of running into edit conflicts while editing a talk page? Are people starting to think that you're an ignorant pig for not reading the comments right above yours?

If we could develop a magical extension that automatically resolved talk page edit conflicts, that would be wonderful. But we obviously can't do that -- talk pages are essentially the exact same as any other page. Really.

So here's another solution. If you ran into an edit conflict while editing a talk page, you can defend yourself against "Y U NO READ MY POSTS??!!" comments by adding Edit conflict in front of your comments. For example:

I'm not sure if this is the correct way to do it... --User 1
 * Oh for sure, it is! --User 2

Let's say you were typing a response right underneath User 2's comment. As soon as you click "Publish" you are told that there was an edit conflict. The current page looks like this:

I'm not sure if this is the correct way to do it... --User 1
 * Oh for sure, it is! --User 2
 * If you read the manuals at MediaWiki.org, you'll see it's correct. --User 3

You would normally go to the bottom of the page, copy your changes, and then paste them under User 3's comment. With the new template, however, you can now easily tell the world that there was an edit conflict and that there is no need for finger-pointing if your comment is the same as User 3, or if it tries using an argument that User 3 had just knocked down.

I'm not sure if this is the correct way to do it... --User 1
 * Oh for sure, it is! --User 2
 * If you read the manuals at MediaWiki.org, you'll see it's correct. --User 3
 * According to the MediaWiki.org manuals, yes, this is how you do it. --You

Which comes out as:

I'm not sure if this is the correct way to do it... --User 1
 * Oh for sure, it is! --User 2
 * If you read the manuals at MediaWiki.org, you'll see it's correct. --User 3
 * According to the MediaWiki.org manuals, yes, this is how you do it. --You

If you have experienced multiple edit conflicts you can also add an optional parameter to the template that indicates how many edit conflicts you endured. For example, if you encountered three edit conflicts, you can add  to show for it, which comes out as:

You can also use the shortcut template - Ec, which does the exact same thing.

Have fun! --k6ka (talk &#124; contribs) 15:01, September 27, 2014 (UTC)


 * This is a good concept, although I don't encounter edit conflicts that often. And even if I did, I would change some things in my post. u.u  Nikel  Talk  –  Vote!  12:19, September 29, 2014 (UTC)

Category:Families / Sims by neighborhood and world
While we've had resolved the issue to distinguish world from neighborhood by terminology, there's one thing I have in mind. Categorization has organizing purposes, and I believe that having two distinct categories, i.e. Category:Sims by neighborhood and Category:Sims by world, is redundant. We know how worlds and neighborhoods work differently, but we also know that these two are essentially the places where lots, in which Sims live, are situated. This means that worlds and (non-TS4-wise) neighborhoods are actually on the same level. Hence, I propose that these categories to be merged just for the sake of simplicity.  Nikel  Talk  –  Vote!  08:35, October 5, 2014 (UTC)


 * ETA: Other things that regard worlds and neighborhoods remain unaffected. I only want to discuss about these two (three, with Category:Families by neighborhood) in particular. Categories like Category:Worlds and Category:Neighborhoods should stay that way, I suppose.  Nikel  Talk  –  Vote!  08:36, October 5, 2014 (UTC)


 * I'm changing my mind. Now I'm starting to think that distinguishing worlds and neighborhoods in the category seems pointless and convoluted. They're deemed to be distinct in the main content, but I don't think it's very important to do that in categories. Therefore, I propose that we just combine the "Category:X by world" into "Category:X by neighborhood" for simplicity.  Nikel  Talk  –  Vote!  11:24, October 10, 2014 (UTC)

Fixing a link
Moved from The Sims Wiki:Administrators' noticeboard

I've been struggling to figure out how to fix the career parameter for Tiffany Burb. It's supposed to be categorized under fashion, but instead it's categorized under "Sims who work in the career". Also there is no link to "fashion" in the career parameter. It simply says " |Department Store Clerk ", but without a link.

I've been trying to resolve the issue by myself, but I just can't locate the cause of the issue. And I can't find any template documents that may appear broken. --  C.Syde  ( talk &#124;  contribs ) 03:58, October 6, 2014 (UTC)
 * It appears that this problem has been solved. For some reason, fashion wasn't included on the list of careers in Template:GetCareerCat and Template:GetCareerLink. We're missing an in-game icon for the fashion career from TS1, but if someone can find one and upload it, it should be added to Template:GetCareerImage. --  LostInRiverview talk ~ blog 04:22, October 6, 2014 (UTC)
 * Additionally, it's worth noting that the Sim/Simbio templates are among the most complex templates on the wiki. All of them ultimately are based off Sim which in addition to being a massive and complicated template in its own right, has dozens of secondary/auxiliary templates that feed into it. The best course of action in these cases is to determine what the issue is, and to find where in Sim the problem may originate. Most of the time if there's an issue in the bio template, it's an issue in Sim itself or one of its auxiliary templates. --  LostInRiverview talk ~ blog 04:25, October 6, 2014 (UTC)


 * @ LiR:Post1 - Oh, okay. I certainly would never have found that link by myself, without being tipped off first. As for the missing in-game icon, I guess we'll just have to wait until someone who owns The Sims: Unleashed uploads an icon.


 * @ LiR:Post2 - Well that explains it. While I do know how the Sim/Simbio templates, they are proven to be really massive compared to the other templates I use/edit. --  C.Syde  ( talk &#124;  contribs ) 04:29, October 6, 2014 (UTC)


 * I have The Sims: Complete Collection but I have no idea how to extract the information from the files... not to mention the icons. I've tried several tools with no luck.  Nikel  Talk  –  Vote!  11:54, October 6, 2014 (UTC)
 * Same here. --  LostInRiverview talk ~ blog 17:51, October 6, 2014 (UTC)


 * The only way I can think of extracting the icons is to go in-game, take screenshots of them, and then process it. The game files themselves are not well documented by modders and there is no "Sim1PE", or at least none that is free. --I am  k6ka  Talk to me!   See what I have done  19:28, October 6, 2014 (UTC)

Static headings
As part of the Halloween theme, we changed div.headingblue and div.headinggreen in the wiki's css page so that the headings would be purple and orange, respectively. While this solution is simple and effective most of the time, there are a few instances in which we would want to continue using the standard blue and green headings even if we implement a new temporary theme. So, I've added div.headingbluestatic and div.headinggreenstatic to the css page. If there is some need to use a blue or green header, and you wish to ensure that the header remains blue or green even if the wiki temporarily changes theme, you can use the static versions of the headings. This is useful on, for example, our new user welcome messages, since those messages are substituted and the colors chosen will never change once they're added.

--  LostInRiverview talk ~ blog 19:26, October 16, 2014 (UTC)

Eliminating Simbio
This is something that has been brought up several times in the past, but I'd like to start a discussion specifically about this topic. Right now on the wiki, we have two "biography infobox" templates for each game - the "Sim" and "Simbio" templates. For example, for The Sims 3, we have Simbio3 and Sim3.

In Forum:Organization for TS4 timeline, a particular issue with the Simbio system is mentioned, specifically regarding Simbio-start. Simbio-start lists a Sim's name and significant familial relationships. The problem arises when a Sim has a different name or different relationships between games; which information, if any, should Simbio-start display? Take for example Bella Goth. Her Simbio-start lists her name as Bella Goth, even though her name is Bella Bachelor in The Sims 3. It lists her marital status as "married" even though she is not married in The Sims 3. It lists her children as Cassandra and Alexander, even though she has no children in The Sims 3 and only Cassandra as a child in The Sims. Ultimately, it would make more sense to include this information on each Sim template.

On top of this, when you start looking at it more in-depth, it becomes obvious that Simbio-start is redundant; everything that the template does is already done by the Sim templates. Another item of note is Simbio-end. At one time, Simbio-end included links to player stories and player theories pages. But, those pages no longer exist or are deleted, so Simbio-end no longer serves any meaningful purpose.

Phasing out Simbio would not be difficult to do, since Simbio is actually based on the Sim template. It would only be a matter of moving the information from simbio-start onto the other Sim templates, and changing the template used on the pages (a task which could be handled by a bot). No syntax would need to be changed, to my knowledge, and no changes would need to be made to the Sim templates. --  LostInRiverview talk • blog  •  contribs 17:49, November 9, 2014 (UTC)


 * I'm aware of the problem where the information stored in Simbio-start may be inconsistent with the rest of the series and it uses the latest of the "main timeline" of the series, i.e. The Sims 2 and The Sims 3 Store worlds, but the problem gets even worse with The Sims 4. This is also apparent in Ruby Broke, the sister or Skip Broke. It's said that Skip and their parents are deceased, but that's following to the series in TS2, even though they're very much alive in TS3, and she's not even present in TS2.


 * For that reason... I would actually support this change. But before that, do you think any change is needed for Familybio-start?  Nikel  Talk  –  Vote!  03:08, November 12, 2014 (UTC)


 * Overall I support this change, but I did initially have a few concerns about it.


 * Will this mean, that we'll be seeing a huge surge of edits in the process?
 * Will fanon writers have to edit their fanon Sim info-boxes during this change?


 * If the answers to those questions are yes, then I might initially have opposed this change. But then I re-read LiR's message about the task being handled by a bot. And I also decided "Maybe it would be best if I just supported this change, assumed good faith (as I always claim to do), and trusted that the "highly experienced" editor responsible for making this proposal - in this case LiR - knew what they were doing, and doing it for the benefits of the community. --  C.Syde  ( talk &#124;  contribs ) 04:42, November 12, 2014 (UTC)
 * Assume Good Faith is an assumption that another person is contributing positively. AGF doesn't require you to assume that they are correct or that their ideas are any more valid than yours just because they've more experienced. You are totally free to agree or disagree with me or others for whatever reason(s) you want.
 * As for the handling of the task and other incidental issues... Changing Simbio to Sim could be handled by a bot, or it could be a gradual process. For starters, We can look into simply keeping the Simbio templates as redirects to their corresponding Sim templates, until the template links can be corrected. The same is true for Fanon pages. It's worth noting that the syntax for Simbio and Sim are nearly identical (in fact, all Simbio templates already use the base Sim template, and have for some time). The task of moving information from Simbio-start to the Sim templates would be a manual process, but we don't necessarily need to be in a rush to change everything and delete Simbio-start. Regarding Familybio... the idea had not actually occurred to me, but since family pages may encounter the same issues as Sim pages, deleting the Familybio and Familybio-start templates (after a transition period) would make sense as well. --  LostInRiverview talk • blog  •  contribs 05:28, November 12, 2014 (UTC)


 * Well yes. I assumed that you were contributing positively as usual, and I didn't think your ideas were any more valid than mine for any reasons. I can't really tell what most of the reasons are except that I assume that this proposal is correct.


 * P.S. I actually do know what assume good faith means. It is when one person assumes that another is contributing positively, whether or not they believe that person's contributions are correct. I'm just not the best at proving that I understand. --  C.Syde  ( talk &#124;  contribs ) 05:31, November 12, 2014 (UTC)


 * We could opt to put Familybio at the 2nd priority while handling the Simbio issue first. It's better to focus on one thing before taking care of another.  Nikel  Talk  –  Vote!  14:17, November 13, 2014 (UTC)

wikitable heading-blue
These two table classes, wikitable and plaintable (aside from prettytable), are commonly used in this wiki. They're pretty much alike:

Both tables use heading-blue class to make the headers blue. At some point, heading-blue no longer worked on wikitable class. This issue had lingered for years. I'm still unsure what's wrong, but my guess is that wikia's own wikitable settings succeed some elements this wiki's wikitable customization in MediaWiki:Wikia.css. Some elements are like background-color and padding.

So anyway, I figured that by adding to the css, it will change the header background to blue. It still doesn't fix the issue where heading-blue doesn't work on wikitable, and this will change all tables using wikitable class into blue header. I personally never like the gray header, but what do others think? Should we add this to the css?  Nikel  Talk  –  Vote!  14:26, November 16, 2014 (UTC)
 * Funnily enough I brought this up on IRC a week or two ago and I tried to code something to fix it but I never got around to finishing it. I'm curious to see what the tables would look like with green (specifically, I think I was testing with ) in the header instead of blue given the prevalence of green in the wiki's theme, however. As for implementing it feel free to do so given that this is better than the broken version you're saying we have now.


 * Alright, I've added the lines to the css. If there's any issues regarding this, please report here.


 * This is what the green header looks like. I'm feeling indifferent about this. I'm content with the current blue header, but if we are to change the header theme to green, that's fine for me too.  Nikel  Talk  –  Vote!  04:44, November 18, 2014 (UTC)


 * Maybe it's early in the morning, but it took me a while to distinguish the table on the left from the right. The green's not very visible. --I am  k6ka  Talk to me!   See what I have done  11:49, November 18, 2014 (UTC)

Emphasized section headers
I'd like to propose to emphasize level 3 section headers and higher a bit. I feel like these section headers are a little too plain. If you read townie page, it uses a lot of level 3 and level 4 section headers. These headers are just slightly larger than normal text, and it's a little difficult to distinguish them from regular text. I think we could give them a line border like level 2 section header, or perhaps make them bold?

The result of giving them line border will make them look like Wikipedia section headers, if one wonders. It kinda helps to know where a section ends. What do you think?  Nikel  Talk  –  Vote!  05:26, November 22, 2014 (UTC)

MediaWiki Emoticons
Apparently the D:< emoticon doesn't work properly in chat. It should come out as but instead it comes out as < --  C.Syde  ( talk &#124;  contribs ) 00:15, December 5, 2014 (UTC)


 * Hmm, you're right. Apparently you can't make an emoticon as a superset of another emoticon. I guess it's just a technical limitation. We can change the code for the angry emoticon.  Nikel  Talk  –  Vote!  06:45, December 5, 2014 (UTC)

Category placement on templates
We recently worked on cleaning up Category:Templates, and much of this work involved re-categorizing templates. I noticed that there is no clear standard regarding where the templates' categories should be placed. Some templates have the categories in 'noinclude' tags on the template itself, while other templates had their categories inside 'includeonly' tags on the template's documentation page. I noticed on at least one occasion, categories were included in both places, meaning I had to edit both the template and template documentation pages to find them. I think it would make sense to adopt a standard and implement it wiki-wide, to avoid future issues or confusion. --  LostInRiverview talk • blog  •  contribs 00:12, March 19, 2015 (UTC)