Remove on-demand JavaScript translation parsing and do everything on rebuild

Created on 3 November 2015, about 9 years ago
Updated 17 January 2024, 12 months ago

Problem/Motivation

JavaScript string translation, and particularly the discovery of the translatable strings, was designed for the D5/D6/D7 asset handling system's lowest common denominator, which was: drupal_add_js(). This function allowed you to add any JS asset to be loaded at any time during the request.

Consequently, the system to discover translatable strings had to be equally dynamic: detect all JS files on the fly, track which ones we've already seen, if we encounter one we haven't seen yet, rebuild the JS translation file.

In Drupal 8, that has changed: all assets must be defined in asset libraries, and to have an asset be present in the HTML/loaded by the browser, you must "attach asset libraries". (Already supported and recommended in Drupal 7, but not enforced; as of Drupal 8, this is the only supported mechanism.)

Proposed resolution

In Drupal 8, we can generate the translation files (one per language) all at once, without having to do that iterative building! That will mean, after a cache clear or a deployment:

fewer I/O (no need to first build a translation file for the strings on page A, then expand it for the additional strings discovered in page B, etc.)
no need to update the entry in the State system in sync with 1, hence avoiding race conditions/stampedes

_locale_rebuild_js() and friends can go away.

๐Ÿ“Œ Task
Status

Needs work

Version

11.0 ๐Ÿ”ฅ

Component
Localeย  โ†’

Last updated 20 days ago

Created by

๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

Live updates comments and jobs are added and updated live.
  • Performance

    It affects performance. It is often combined with the Needs profiling tag.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024