Fix rP14991 rename "aichat" to "chat", since its used by AI, maps and human players.
Fix rP15866 delete unused translateMessage in PETRA chatHelper
Fix rP15866 delete invalid translation of strings that are botnames translated in the gamesetup (rP14954) or should not be translated (rP17382) and colorized in the session (rP16533).
Fix rP17789 delete unused translateMessage in developer open message
Fix rP17796 delete unused translateMessage in promotion cheat
Fix rP18467 missing translateMessage for "upgrade" simulation command
Fix rP23114 translate -> translateWithContext for ReplayOutOfSync.
1.a. Delete unused translateMessage property from "aichat" commands.
1.b. Delete translateMessage property from GuiInterface TimeNotification and always translate GuiInterface TimeNotifications.
1.b. Rename "aichat" to "chat", since it is also used by cheating human players and map scripts.
2.a. Do not translate AI names in multiplayer matches for TimeNotifications and simulation chat.
2.b. Do not use startsWith("_player_") to test if a translated parameter should be a colorized playerID.
Achieve these two changes by passing the playerIDs in a separate playerParameters object instead of mixing that in with translatable sprintf arguments.
3.a. Create TimeNotifications exclusively with PushTimeNotification by replacing the AddNotification calls with type == undefined or type == "text" with PushTimeNotification calls.
This allows searching for all TimeNotifications globally without having to read and infer the results of code.
3.b. Rename AddNotification to PushNotification for consistency.
3.c. Construct the GUIInterface notification JS objects inside the PushNotification/PushTimeNotification call.
This allows the reader to determine solely from from the Push statement which properties will be sent. This makes it more obvious to the reader if there are wrong properties being sent (i.e. avoids repetition of the wrong property mistakes rectified in this diff).
- Let BuildRestrictions construct a valid TimeNotification object if and only if it is being read. Don't construct an object otherwise, especially do not construct an invalid TimeNotification object. Achieve this by removing the "success" property which is not a TimeNotification property and only used by BuildRestriction code. Replace it by testing success for the lack of a TimeNotification. If someone wants to return a TimeNotification on success, they may return do so by storing the success boolean outside of the TimeNotification (for instance by creating a new object).
- Delete emtpy "translateParameters", "parameters" objects.
- Change 12 hour Last-Man-Standing TimeNotification timeout to Infinity.
- Support pluralTranslation for TimeNotification. Achieve this and remove duplication by using the new translateNotification. Consider D1613 for the 4 resource string limit.