User talk:Nephele/Sandbox/2

Keeping track of some of the experiments I'm doing, why, and what questions have come up

How to fix redlinks on User and Template pages

Instead of a line like this for the Health label:

<includeonly>{{SkipLink|{{Namespace}}:Health|Health}}</includeonly><noinclude>Health</noinclude>

I'm trying to simply have:

[[{{NS_FULL:{{NS_PARENT}}}}Health|Health]]

All of the rest of the processing (SkipLink, includeonly, noinclude) is there just to get rid of the red-links that appear on User and Template pages.

The ns_base definition at the top of the template takes care of all the special namespace treatments -- only once per template, instead of repeating it for each link. Instead of being de-linked, the links are all transformed into links to Oblivion articles. If a user wanted Morrowind links on his/her userpage, that's now possible, by calling NPC Summary with |ns_base=Morrowind .

• Questions
  • Should the special treatment for the User and Template namespaces be incorporated into the NS_FULL, etc. magic words instead? It would mean that the above ns_base definition would not have to be repeated on dozens of templates. However, putting the code into the magic words ultimately seems too inflexible and limiting. I think we should be able to choose whether or not to alter the links on a template-by-template basis. I also think we should be able to change the default namespace if appropriate.

Huh tags

Do we really want huh tags to automatically appear in empty cells on tables? I'm starting to think we don't. We're doing alot of work to get the tags to appear -- but then even more work to make them not appear anywhere where they're a nuisance. All for a temporary placeholder that even on newly created articles is hardly ever used.

Alternatives to automatic huh tags could include:

• When someone puts together an incomplete summary, place a cleanup tag on the whole article or a single VN tag stating that the information is incomplete.
• Manually add huh tags when they're needed. Instead of skipping the race parameter, use something like |race={{huh}} in the template call. If an editor has left the fields blank, a patroller could add the huh tags. Ultimately, this gives us more options, such as the ability to specify why the data is blank.

Or else, if we really do want automatic huh tags, I think it would be better to somehow move the feature into a separate template, along with the empty variable check, the namespace checks, etc.

• Questions
  • Any arguments in favor of continuing to automatically add huh tags?

Simplify class and race

The race and class cells have been dramatically simplified. A large part of the simplification comes from using NS_PARENT and (within autolink) NS_FULL. Some also comes from getting rid of the huh tags. The Autolink template is new (and requires the new template features), but its basic function is one we're already using for race (but not class): if race already is a link, then don't turn it into a link. (And, no, the current broken template at Autolink isn't the real version of the code.)

The final chunk of simplification is from getting rid of classns, classmod, racens, and racemod. Instead, I've opted to have articles provide the full class/race link if they need to override the default link (since race already has this, I'm not sure why racens and racemod were added...). This approach reduces the number of parameters necessary for the template, with associated peripheral benefits such as saving editors the trouble of remembering all the extra parameter names. I think it's also more flexible overall, since it can be used to deal with any odd type of link, not just changes of namespace.

However, there's one other required tweak to make this work. Currently, plugging in a full link for the class parameter will break the class category -- which I think is probably why we haven't done this before. The category can be fixed with one simple adjustment: use {{#trimlinks:{{{class}}}}} in the category definition. For race we already had a racecat category; I'm just changing racecat so that it uses trimlinks by default.

• Questions
  • What's the best way to do race/class? Some problems with the new approach are (a) It's somewhat counterproductive to have to call trimlinks every time, just to accommodate the unusual cases (b) A second race parameter is still needed, namely racecat (although it needs to be called less often than before). Is the current approach the best balance of readable code and efficiency? Or are there better ways?