Though the scam benefits me, I’ll have to agree with Josh here

Oh whoops, wrong CfJ. That was meant for the other one with the rebult -> rebuilt scam

I interpret the situation as “you have to format the ruleset page to look correct, even if that means changing the markup”. So, { should be written as <nowiki>{</nowiki> in order to appear correct on the tracker. Just copy-and-pasting onto the tracker is usually incorrect, because other markup (e.g. links and italics) also needs to be adjusted to MediaWiki markup.

As such, I think this CFJ should be worded along the lines of “add any necessary <nowiki> markup to the Ruleset page to ensure that its visible content matches the actual content of the rule”.

In the last dynasty we had a proposal that allowed the enacting admin to subjectively change “Snail” to the ‘correct’ one of Snail, Slug or Gastropod. They did their best and no obvious scams were carried out but there were still lots of incorrect changes that had to be tinkered with throughout the dynasty.

CfJs should avoid subjective instructions. My instructions here are clear and they work.

Well, under my interpretation, the ruleset tracker is wrong but the rules are already correct (just tracked incorrectly), and the correct way to enact this CFJ is to add appropriate formatting to the wiki page to make the literal string “<nowiki>” appear on the page at the start of the rule and “</nowiki>” to appear on the page at the end of the rule (i.e. by placing “<nowiki>” at the start of the tracking page, and “</nowiki>” at the end of the tracking page).

Or in other words, I make a distinction between “the content of the ruleset” and “the content of the Ruleset tracking page”. The correct fix is to add <nowiki> tags around the relevant part of the latter, but this CFJ is adding <nowiki> tags around the relevant part of the former instead.

Ugh, my comment appeared correct in preview but was incorrect once posted to ExpressionEngine; the second occurrence of <nowiki> and </nowiki> is supposed to be escaped, but even though I double-escaped it, apparently both levels of escaping got removed when I posted.

I don’t think I agree with that interpretation, but if it were the case then the CfJ wouldn’t be necessary, as the enactment of the proposal should have resulted in the tracker displaying properly and could be freely corrected under Representations of the Gamestate.

This CfJ, then, brings the two interpretations into line; attempting to force it to conform to an interpretation where it would not be needed risks making it useless in the case of the interpretation where it is.

(Your interpretation also runs contrary to strong recent precedent, which holds that mediawiki formatting in proposals be allowed to render as mediawiki formatting when transcribed into the tracker.)

It doesn’t, in that if you enact the CFJ with my interpretation, it adds extra text to the ruleset that wasn’t in the original rule.

I think you can make the CFJ bring the two interpretations into line simply by stating to add the nowiki tags around the rule’s content on the tracking page, rather than adding them into the rule itself.

Actually, that doesn’t work under your definition. Ugh.

I thought it might be better to just use a different character, but MediaWiki is using all the easily typed characters other than parentheses already, and we too often use parentheses for their regular English meaning. (The next-most-easily typed are «» but I suspect most players don’t know how to type those.)

Chevrons came up in discussion on Discord, where it was generally agreed that the knowledge of how to type them is scarce.

Would $ work? I know it doesn’t have the same instant ability to indicate begin and end like the various forms of brackets do, but as an easy-to-type and recognizable symbol that isn’t otherwise used for anything currently, it might be good enough.

I think I understand what the ambiguity is, even though I’m not sure how to fix it: if a proposal says “add {{{text}}} to the ruleset”, it is ambiguous whether the proposal means “add text to the ruleset that renders as ‘{{{text}}}’” or “add text to the ruleset whose wikimarkup is ‘{{{text}}}’”. In most cases it either a) doesn’t matter or b) is obvious, often both.

This is a rare case in which the intention is obvious (to have the curly braces be part of the rule rather than merely part of the markup) but where it does matter which meaning of the proposal is used, and where it’s unclear that the author’s intention is actually the correct way to enact the proposal.

This also matters for the ruleset itself; when it talks about replacing a character in a rule, is it talking about the rule’s markup, or the rule’s rendered text? (For what it’s worth, I prefer to think of the markup as an accident of tracking and not something that “belongs” to the rule at all, especially given that trackers can generally be freely reformatted.)

If beginning and ending characters are too important, maybe a combo of $ and ^ could work.

@JonathanDark: you need two different characters so that they can be matched, otherwise $$a$$ is ambiguous between $($(a)$)$ and $()$ a $()$.

I guess we could use / and \, although that might run the risk of people slipping / into rules with its normal English meaning as an abbreviation of “or”.

Yeah, I’d rather go with $ and ^ since they have no assumed English meaning otherwise.

As long as we don’t introduce “dollars” into any dynastic rules, that is.

Note that in some programming languages, ^ means “begin” and $ means “end” (is that where you got your suggestion from?), so they should probably be that way round to prevent the programmers getting confused.

As a programmer myself who likes the “vi” editor, I agree. So make the last part of the CfJ this:

revert any changes made to the rule The Bank {M} since it was enacted, and then add a ^ to the beginning of its content and a $ to the end of its content.

And if everyone is agreed to it, we can then change “Bolted to the Ground” to catch up.