Unfortunately this is still not enough for translations. In some languages, the order of elements is different, like "le bateau rouge" (French) vs. "the red boat" (English). To handle this, most substitution systems require or have optional numeric placeholders, like "%1$d" and "%2$s", and thus you can change the order of substituted items if necessary.

Given this extra complexity, I wonder if you can find an existing function somewhere that implements this. No sense reinventing the wheel.

I wonder if you can find an existing function somewhere that implements this

CheckServerMessage does to a large degree, but is on the client side. Should I look into sharing its logic between client and server, and extend it to support positional params?

I was thinking more of third-party code, i.e. someone who has already solved this problem.

I've got it working using fmtlib and supporting a few tags: TAG_INT, TAG_STRING, TAG_TEMP_STRING, and TAG_RESOURCE. This would support a resource string like so, "{1} was killed by {0} {2:d} times.", such that the following call would produce Admin1 was killed by Admin2 5 times. If this seems right, I'll submit it for closer review.

resources:

system_user_killed_test = "{1} was killed by {0} {2:d} times."

messages:

BuildStringTest(what=$,killer=$)
{
  local sString;

  sString = BuildString(system_user_killed_test,
     Send(what,@GetTrueName),
     Send(killer,@GetTrueName),
     5);

  debug("BuildStringTest: ", sString);

  return;
}

Produces: BuildStringTest: Admin1 was killed by Admin2 5 times.

I've integrated fmtlib, which should cover the needs described above. This is new territory for me, and I ended up following header-only instructions that don’t match how we typically handle external libraries. Let me know if there’s a better way to include it.

Struggling with the Linux build--sorry for the spam. Could use some guidance there if we like fmtlib as a solution.

I think the issue is that the Linux build is using C++11. I’m relying on fmt features that need C++17, like vformat and dynamic arguments. Any chance we can bump the build up to C++17?

This is somewhat tricky. Going to C++17 would mean upgrading the compiler on the serving machines (and the github autobuild), as well as the C++ runtime library, then rebuilding the server and hoping it works. Downgrading in the case of problems isn't guaranteed to be possible. I have done this once before but it makes me nervous. I may need to think about this one some more.

I was wrong about this. The versions of gcc we have installed do support C++17 already, and in fact it's the default (which we've been overriding with C++11 due to ancient history). I've checked in the change, so if you merge you should be able to get farther.

I was wrong about this. The versions of gcc we have installed do support C++17 already, and in fact it's the default (which we've been overriding with C++11 due to ancient history). I've checked in the change, so if you merge you should be able to get farther.

Awesome, thanks. Seems my build struggles are over and its now working. Ended up using an older version of fmtlib because later versions appear to have a type mismatch bug whose warnings get treated as errors and thus fail to compile. The version I ended up adding--11.1.0--should support everything we need.

@Meridian59 This is ready for another round of review.