That description doesn't tell us what's inside that variable. It's not straight-forward as the reader encounters player and allies

The function should be defined where the other functions are, not in between these two big objects.

(Hm, seems like there was a bug in the previous code. The guid isn't used as far as I can see. Since it's the network client identifier, the GUID should only be set if a player sends a chat.) Nuking this line

In fact it looks like we can just push these two things to playerFinished. Renaming the latter to indicate that its called for multiple players now.

whitespace stuff

Also notice something? Since we now have one message for multiple defeats / victories, we also only have one sendLobbyPlayerlistUpdate call, which means we reduce useless traffic :-)

msg.message.message is a bit awkward to read. Nicer to pass players and message

playerId still unused

We can use newlines within the string, according to BuildRestrictions.js whose string shows up in the l10n directory

markForPluralTranslation

;

missing %

relic captured -> relic victory or Capture the Relic

(Only the ConquestCritical structures are relevant, but explaining that in the string would make it ugly)

This one must explain the that those reasons are functions mapping to a plural string (since this file is supposed to make things easier for modders)

Even more a comment is needed now, because the win function needs a function, this one gets the string straight away!

nice function for the future.
We could do all sorts of stuff here, cheering, playing some cinematic path, playing a special soundfile, marking some objectives as done, informing the AI,...

At least in this revision of the patch, we use the variables only once, so can be inlined + \n

I'm not too happy about "last players alive" nor "allied victory" being shown if all enemies are defeated. It feels more like "Conquest" to me.

alliesNotification -> winners, or winningPlayers
enemiesNotification -> losers, or defeatedPlayers

if( -> if (

if (alliesNotification.length) sufficient

We need the cmpGUIInterface only once, so it can be moved outside of the if's and outside of the loop..

(Some negligible thought:
Having "player 1 has won (wonder victory)" and "player2, player3 have won (allied victory)" seems more intuitive, but makes no sense for relic games.
Since one might argue that despite only one player having the relevant wonder, the other players might still have had to pay the same share to achieve victory, using this string makes sense in the wonder victory case too.
There might be other modes where only one player can win.
F.e. the player with most resources after 15min or the first player who found one treasure wins, while the others win by allied victory.
Don't see the reason to add that complexity now however.)

unneeded newline

alliesNotification and allies are the same, no?

cmpGUIInterface already defined above

A function comment is crucial here.
The users of this function have to know that they can use undefined or a function mapping from n to markForPluralString

players are the ones who we send the message to, It's kind of pointless historical garbage, but not going to clean it in this diff.
Unfortunately this forces us to use allies, even though the defeated enemies might not be allies. Meh

You had asked whether we could sometimes send a plural string, and other times (like here) only a singular string.

It's possible in fact, quoting from input.js:

						if (result.pluralMessage)
							message = translatePlural(result.message, result.pluralMessage, result.pluralCount);
						else
							message = translate(message);