[Bug]: `shiny.18n` using browser-side & server side translations in modularized `{golem}` app

[yogat3ch]

Guidelines

• [X] I agree to follow this project's Contributing Guidelines.

Project Version

0.3.0

Platform and OS Version

MacOS Ventura 13.5.1 (22G90)

Existing Issues

73, #62

What happened?

Browser side translations do not occur when updates to i18n R6 object and update_lang occur in adjacent module.

Steps to reproduce

1. Clone Martin-McCoy/shiny.golem.i18n
2. Open the cloned repo in Rstudio
3. Use golem::run_dev() at the console
4. Click the toggle to change the language to es
5. Note that only the uiOutput value updates, the instances marked with i18n$t in mod_accessibility and mod_adjacent do no update with the translation.

Expected behavior

We would expect that the i18n object, once updated dynamically will render all subsequently rendered UI elements requiring translation in the newly set language. Additionally, when update_lang is called with the new language from an input observer, it will update all strings marked for translation with i18n$t that are already rendered.

I know this functionality can be achieved if i18n$t was wrapping each string with a span tag with a specific class, such as .i18n and if the update_lang function sent a message to the JS that aggregated all visible DOM elements with .i18n class and looped over them using jQuery html to replace each with their corresponding translation.

It seems like the current build of shiny.i18n forces a user to render everything using uiOutput for the language updates to occur, is this true? If so, can it be changed?

Attachments

No response

Screenshots or Videos

Video of behavior

Additional Information

No response

[yogat3ch]

I took a look at the shiny.i18n codebase and it does appear that the package is indeed doing the updating of values using the logic described in the issue description above. I'm unsure as to why this did not work the other day when I tried it but appears to be working now. The only thing I can figure is that that the browser might have cached an erroneous translation JSON which prevented it from working, but that doesn't feel accurate since it did translate all but one of the items marked for translation. Regardless, it appears to be functioning as intended now!