[#20903] - Caching of Javascript language strings broken?
- Closed
- 7 Jul 2018
- Medium
- Build: 3.8.10
- # 20903
Steps to reproduce the issue
It's difficult to give a test case for this, so I just wanted to get a sanity check before creating a test case and submitting a PR.
The problem is ... in an extension with cacheable views, if you add JS language strings with ...
JText::script('FOO_BAR');
The expected result ...
Expected result
... is that when your view loads from cache, you still have your translated strings in Joomla.JText in the Javascript.
But the actual result ...
Actual result
... is you get the untranslated FOO_BAR string.
System information (as much as possible)
3.8.10
Additional comments
The problem seems to stem from the cache workarounds ...
https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Cache/Cache.php#L529
... which calls setHeadData() in the document, which then does ...
https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Document/HtmlDocument.php#L257
And there's the problem. That line seems to assume you can set the language string to an already translated string, by doing JText::script($key, $string) ... but you can't ... that second arg is 'jsSafe', not a translated string. The translation happens inside JText::script(). And because we're doing this from the cache handler, the extension hasn't run, and its language isn't loaded. So a) we're passing a random 'jsSafe' value, and b) no translation.
As far as I can tell, there is no way to set a specific translated string, so the only way round this would be to add another method to JText, like JText::setScript($key, $string, ...) which does let you specify an already translated string to use.
Am I missing something obvious?
@cheesegrits can this Issue be closed?
| Status | New | ⇒ | Information Required |
I had similar issue, but with script options. It hard to reproduce.
Yes, it somehow related to Cache "workaround",
which is ignore (or wrongly parse/interpret) <script type="application/json" class="joomla-script-options">.
I not often use the cache enabled, do not really had a time to debug.
I do not see how #20843 is related
yes #20843 does not try to fix any caching issues so the purpose of #20843 is not related
But the discussion in #20843, about the 2nd parameter is discussed and analyzed there
And there's the problem. That line seems to assume you can set the language string to an already translated string, by doing JText::script($key, $string) ... but you can't ... that second arg is 'jsSafe', not a translated string. The translation happens inside JText::script(). And because we're doing this from the cache handler, the extension hasn't run, and its language isn't loaded. So a) we're passing a random 'jsSafe' value, and b) no translation.
I guess need to debug how Cache "workaround" works for <script> and fix it for our options tag,
just need a brave man and a time 
| Closed_Date | 2018-07-07 08:02:18 | ⇒ | 2018-07-07 08:02:19 |
| Closed_By | franz-wohlkoenig | ⇒ | joomla-cms-bot |
| Status | Information Required | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-07-07 08:02:18 |
| Closed_By | ⇒ | franz-wohlkoenig |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20903
PS ... the only other workaround would seem to be for me to load all my language in the controller before I call the cache on my view ... but for my extension that is (very) problematic, because my views can load any number of other plugins, with their own language files. So I'd pretty much have to just give up on caching and always run my display().
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20903.