Katat0nyx

.

The last time he was active was in 2015, so i doubt he will tell you anything

I don't think anything was locked down as a standard. I have not seen Nickembrey make any major edits for the past few months. Someone did anonymously make a bunch of edits on all the contracts to make them more consistant but there were no standards discussed. 

No standards discussed?
Did I imagine participating in this thread? Did I imagine reading your responses there? Please help me understand what happened in that thread, because I now am thoroughly confused.

Sorry, I meant to say they were discussed, agreed upon but never implemented. Should have said 'not locked in' as in 'not ever put into practice'. Nick's original items were set (those you mentioned above) but the additional stuff as well as modify the over all page (such as addition of sets below the contracts and modify template to include a summation of rewards in addition to the final) were never finalized and obviously never implemented. 

We can go back to Mrs.Wilma to verify that the agreed upon item were implemented and make any other adjustments to make it the "standard" that gets implemented everywhere.

Gotcha. In great part, the non-implementation rests on my shoulders because of my absence. Mea culpa.

One small adjustment: Use Mrs. Wilma and Johann for the verification and as examples on which to model other contractors. Mrs. Wilma's contracts don't use all the features we discussed. Both her page and Johann's page should represent the implementation of everything that was discussed and agreed. I think even Johann may be missing one or two small tidbits, but their use is uncommon, anyway.

Nah, the non-implementation rests on my shoulders as well. Have been very busy with work as of late and haven't been able to devote enough time to make improvements. Plus the numours other editors we had at one time also seem to have all been absent recently. Probably something to do with nice weather :)

LIttle confused because all of that information is already on the JRF EH200 page

well not to sure as to why your confused as much as i am because when i tried looking up this name it was NOT showing any info at all on the engine but now it is some how but thanks for checking it out 

No worries, it is a big site and I'm sure there is lots of other details we are missing somewhere out there. Thanks for taking the time to post the info.

your welcome Mhommer and im slowly working on stuff trying to update the if if i know for a 100 % that its right 

Passenger and Mail wagons were never broken out seperately on the menu bar because they were originally all on one page. Since you divided up the pages I just need to add the links and another sub-layer for them similar to the cargo wagons.

OK opted against the sub menu since there is no clean landing page similar to Cargo. Change has been made.

Ahhhh... Okay, that makes sense now.

What did not make sense was having combined info about the three types on one category page. The reason it did not make sense is because {{Infobox wagon}} automatically adds every wagon to a category, and Category:Passenger and Mail Wagons contains only the dual-type pax/mail wagons in it. The other two categories were sitting there with 885 and 116 wagons in them, respectively, while all the info about them was sitting on a category page that contains only 20 wagons.

Admittedly, the main nav menu looks a bit awkward now, but I guess that's only because the 16 cargo wagons are in a submenu. If the main nav menu had 20 entries, that probably would be even more awkward.

It made perfect sense two years ago (maybe three?) when I set it up and there were only about 100 wagons total :)  But yes, it has grown massively since then and needed to be split out. The menu only supports about 6-8 entries off of the main menu (Wiki limitation, also the reason the contracts are arranged the way they are). The submenu is actually some add-on code that does not have a limit that I know of. 

Ah, there we go. The old "It Hasn't Been Updated in Three Years" trick. Gets 'em every time. ;-)

Well, since we're on the subject of updating the navigation menu, anyway, do you have time for a few small edits? I've noticed a few things that need to be edited, plus some things that I think should be edited. Here goes:

• Shop
  • Extensions
    • Primary Station ==> Main Station (name change in the game)
  • Themes
    • Extra Themes
      • Black Hills Theme
      • Night Theme (combined with Snowfall)
      • Day Theme
      • Snowfall Theme
      • Clear Weather Theme
      • Bavaria Theme
      • Nordic Summer Theme
    • Award Theme
      • add between existing entries: Steamtopia Theme
      • add at end of list: Red Planet Theme :-D
    • Seasonal & Limited Themes (items missing and out of order)
      • Starfall Night Theme
      • Transylvania Theme
      • Christmas Night Theme
      • Polar Theme
      • Santa's Polar Theme
      • Snowy Metropolis Theme
      • Winter Lake Theme
• Activities
  • Contracts
    • Medium (items out of order)
      • Bobby
      • George
      • Otto
      • Sam
      • Jules
      • Alan
      • Wolfgang

That's it for now. ;-)

And now that we're also on the subject of themes, here's something else that bugs the hell out of me and I'd like to see changed, if possible.

All of the basic themes have buildings and decorations under their respective umbrellas. Steamtopia, Polar, and Transylvania do, too. It makes sense for these themes to be categories, so we can associate the buildings and decorations with them.

None of the other themes have things to associate with them, yet most or all of the other themes also are categories. I'd very much like to see non-stuff themes get changed from categories to articles. I don't know what's involved with that, though. Should I simply create article pages and then ask you to delete the category pages? Or is there a way to just to change the namespace of these pages from :Category to :Main? Obviously, the second option would be faster and cleaner, if it can be done.

Thank you for the feedback, I have now added it. Please find it at: JNR DD51 Sumo

If you and Mhommer are still working on this, you should both be able to edit it, because it is not yet on full lock out. As you work on it, tsmeta should be renamed to something appropriate. My recommendation is to follow previous formatting (Infobox_Trainset & Trainset or some such) or just modify Trainset to incorporate the tsmeta template.

I'm sorry, I've been extremely busy, and I don't forsee me having time to help you until late January at the earliest.

Kat, thanks for the reply. I'll bring Mike into the discussion, and we'll take it from here.

Mhommer, I like the idea of renaming the templates for consistency. This particular pair of templates will be tricky, though.

To conform to the naming format of the other templates, we need these changes:

• {{Trainset}} ==> Infobox trainset
• {{tsmeta}} ==> Trainset

Ordinarily, we would announce the change, most people would start using the new names, and redirects would pick up the slack. In this case, though, we can't tell "Trainset" to redirect to "Infobox trainset" because "Trainset" would have a new purpose.

I still like the idea of renaming the user/editor template to "Infobox trainset", and doing so definitely will require a redirect, at least in the short term. Here, then, are a few ideas for {{tsmeta}}:

• Leave it as is.
• Rename it to "Train set".
• Rename it to "Set".
• Something else.

Edited to add: This just occurred to me. While we're changing template names, maybe we should change {{Infobox train}} to "Infobox loco". It's more accurate, and it matches {{OfferLoco}}. The names "OfferWagon" and "OfferItem" match their respective infobox templates. Why not make it unanimous?

P.S. I reformatted Template:Infobox train/doc so it looks like the the wagon and trainset pages. The new format shows on the /doc page, but not on the template's page. Would you please do a null edit on the {{Infobox train}} so it will use the new documentation page?

Thanks.

By the way, why are there two templates for each of these?

• {{Infobox train}} and {{Train}}
• {{Infobox wagon}} and {{Wagon}}
• {{Trainset}} and {{Tsmeta}}

In each case, the first template does nothing other than accept input parameters and forward those parameters to the second template. Why? Why not save processing time and simply call the template that does the work?

I'm guessing that there's a historical reason for the duplication, and that the reason made sense when the templates were created. From what I can tell, those reasons—whatever they are—no longer exist. Do they?

If not, I propose moving the "work code" from the second template in each pair to the first, then deleting the second template. If so, I'm all ears.

The templates have been transistioned a few times. I was not directly involved in coding the first templates nor the first few transitions either. My best guess was the nesting allowed for a slow transition, maintaining the old style until editors could get to the pages to implement the new style. Such considerations would be even more critical now given that the page count has exploded since our last transition.

That said, if we can combine them and simplify the overall process, I am all for it.

I would love that. Here's what I propose.

• Merge the six templates listed above into three templates.
• Rename {{Infobox train}} to "Infobox loco". Rename {{Trainset}} to "Infobox set" (or "Infobox trainset", if you like that better. I was going for simpler.) {{Infobox wagon}} can keep its name.
• Create redirect templates for the two renamed templates, so the existing pages on the site don't blow up during the transition process.
• Within all three updated templates, create consistency among the names of their parameters. Ideally, all of them—plus the new {{Infobox item}}—should use the same parameter names to refer to the same things.
• Install code within the new templates to accept old parameters and deal with them appropriately.
  • This, of course, is what the current two-layered system does. I'd rather see one template managing all the parameter names.
  • However, my idea behind this is that the situation would be temporary. Once we convert all the pages on the site to use the new templates, I'd rather see the new templates just be new, and consistent, and pretty. At the same time, I can hear you telling me that some editors will prove resistant to the change and will feed old parameters to the new templates, regardless, and that line of reasoning is not lost on me.
  • Rather than simply roll with the old parameters, though, I'd prefer that, post-conversion, the templates return something along the lines of, "This page is using old crap and needs to be updated" whenever they detect the deprecated parameters. That would act as a safeguard against the old formats creeping back in to our newly consistent site. If I dare to dream, it may even encourage editors to seek assistance with making the weird messages go away, and eventually learn the new stuff themselves. I know, I know... I'm asking for the moon on that one.

• train or loco, either works for me

• set or trainset, again either works for me

The key will be to ensure no disruption while old and very old parameters are still floating around. Not being a template guru . . . . can we execute a multi-step process as we change over where-by we activate "This page is using old crap and needs to be updated" a section at a time so that we don't cluter the entire site or overwhelm ourselfs with what needs to be done. For example make the changes but then activate the "update old crap" code just for steam locomotives. Once those are corrected, do it for steam and electric, etc. Once all the locos are done, remove the old parameters from the template to complete the switch. Rinse and repeat for sub-sets of the wagons and trains sets.

Make sense or is it just clear in my own clouded mind?

Okay, I read you. It took my brain a long time to process that, for some reason, but I finally got it.

To be sure I'm understanding you correctly, you're proposing we write code that looks a little something like this:

1. If you get a new parameter name, use it.
2. If you get an old parameter name, use it.
3. If you get an old parameter name and the loco type is steam, tell the editor to come out of the Dark Ages.

Then we fix all the steamer pages. Next, we change line #3 from "steam" to "steam or diesel", fix the fossil burners, and so on. Sound correct?

Assuming the answer is yes, I'd like to expand your idea a bit. Changing "award" to "reward" has consequences that reach far beyond the infobox templates.

• Category pages must be renamed. Even if that process is mostly automatic, it's our job to make sure the system did it right.
• Every item assigned to any such category must be reassigned.
• Headers must be renamed in tables every-fricking-where.
• Probably more stuff, too.

Therefore, I propose that we follow your piecemeal solution in two major phases. Phase One includes all parameters other than "award". When all of that is done, Phase Two means starting over with the steamers and going down through the entire list again, this time for all parameters. Modifying the categories could be done between the phases, or Phase Two could occur simultaneously with the category project.

Just one more thing. You wrote: "Once all the locos are done, remove the old parameters from the template to complete the switch." While I definitely agree that's the ideal scenario, I imagined leaving the "old crap" code in the templates for at least a year after conversion is complete. Even after we bust our asses changing every infobox we have and broadcast to the world that we have a new format, there will be jokers who don't get the word or just don't care and will use old crap, anyway. Though your scenario is a fantastic use of the "old crap" idea, it's not the idea's primary purpose.

I see the "reward vs. award" as a nice to have rather than a need to have and I think both can co-exist while we make the change over so there is not such a rush in my mind. I would propose doing it in conjuction with changing the parameters. The difference between the two terms is subtle enough that I don't think it will confuse anyone.

As for removing the old parameters I think we can do that right away. Reason - there are very, very few editors (less than 2 that I have seen recently) who are still active since the last change over. Plus the main reason they were left in last time was so that we could easily change things over without breaking anything. We didn't think of this method last time or we probably would have removed the old parameters once the conversion was complete.

Thank you for providing the calming voice of reason. There's no reason why we can't have duplicate Award and Reward categories for a while, especially if we make notes about deprecation on the Award pages.

Good call on migrating the infoboxes all at once, too. Even though it was my idea, I wasn't exactly thrilled about us putting our hands on every single one of them, twice. ;-)

hmmmmmmm .... Here's a modification of the "old crap" idea that's much cleaner than the original idea. Since we're not actually looking to beat editors over the head as I first thought, then we don't actually need to change the visible output of the template. All we really need is to change step #3 above:
3. If you get an old parameter name and the loco type is steam, add the page to a special category--a place where the editors can find all pages that need to be updated in one place, together, without disrupting any content on the site.

It may be wise to keep the multi-step part of the plan, just to help us keep track of what has and hasn't been done. It becomes much less critical to do it in segments, though, when we're not spitting out "old crap" messages in the middle of infoboxes everywhere.