fix: Rendering of translations based on the user's locale (#13211)

Previously, translations were generated and resolved purely based on the
account locale. This caused issues in multi-team, multi-region setups
where agents often work in different languages than the account default.

For example, an account might be set to English, while an agent prefers
Spanish. In this setup:
- Translations were always created using the account locale.
- Agents could not view content in their preferred language.
- This did not scale well for global teams.

There was also an issue with locale resolution during rendering, where
the system would incorrectly default to the account locale even when a
more appropriate locale should have been used.

With this update, During rendering, the system first attempts to use the
agent’s locale. If a translation for that locale does not exist, it
falls back to the account locale.


**How to test:**

- Set agent locale to a specific language (e.g., zh_CN) and account
language to en.
  - Translate a message.
- Verify translated content displays correctly for the agent's selected
locale
  - Do the same for another locale for agent.
- With multiple translations on a message (e.g., zh_CN, es, ml), verify
the UI shows the one matching agent's locale
- Change agent locale and verify the displayed translation updates
accordingly

lib/integrations/google_translate/processor_service.rb

@@ -11,7 +11,7 @@ class Integrations::GoogleTranslate::ProcessorService
 
     response = client.translate_text(
       contents: [content],
-      target_language_code: target_language,
+      target_language_code: bcp47_language_code,
       parent: "projects/#{hook.settings['project_id']}",
       mime_type: mime_type
     )
@@ -23,6 +23,10 @@ class Integrations::GoogleTranslate::ProcessorService
 
   private
 
+  def bcp47_language_code
+    target_language.tr('_', '-')
+  end
+
   def email_channel?
     message&.inbox&.email?
   end