[Feature]: Translate game log and move it clientside

[itsalaidbacklife]

Feature Summary

We should internationalize the game log/history so that players can read it in their preferred language

Detailed Description

Currently the game log is generated serverside via the helper api/helpers/game-states/get-log.js which creates a log entry (text) for every GameState in a given game. It appears like this:

Because the text is generated serverside and translation is only managed on the client, the text can't be translated as it currently stands. We should update the src/stores/gameHistory.js store's log computed property so that instead of just reading from the existing log property in the game store, it actually parses the priorGameStates executing the same computation as the current serverside get-log.js helper except formatting it in a way that allows for internationalization.

In order to work properly, the translated logs will need to be parameterized to accept different cards, players, or whatever variables are read by the log. This would most likely work best by having the gameHistory store directly utilize the t() function from vue18n to translate the text so the returned log computed property is the pre-translated text. It could work roughly like this

// src/stores/gameHistoryStore.js
const { t } = useI18n();

const log = computed(() => {
  return priorGameStates.value.map((gameState) => {
    switch (gameState.moveType) {
    case MoveType.DEAL:
      return t('game.log.deal', {
        player: gameStore.players[gameState.playedBy].username,
        opponent: gameStore.players[(gameState.playedBy + 1) % 2].username
      });
    // other cases
    }
  });
});

And then in the language files e.g. en.json

"game": {
  "log": {
    "deal": "{player} dealt; {opponent} will go first"
    }
}

We should then delete api/helpers/game-states/get-log and clean up its usages once this is moved clientside, removing it from the generated socket event etc.

See the vue-i18n docs and the existing get-log implementation for further details

[Haviles04]

Would it make sense to make this an action in pinia and then just call it in updateGame()

[itsalaidbacklife]

Would it make sense to make this an action in pinia and then just call it in updateGame()

I think it's better as a computed property because it should always be fully determined by the list of gamestates. That list already lives in the gameHistoryStore, which is why I'm thinking it should live there