### Overview On a multilingual site, page renders that include a Canvas asset library draft emit a PHP warning: ``` file_get_contents(canvas/api/v0/auto-saves/js/asset_library/global): Failed to open stream: No such file or directory in _locale_parse_js_file() (core/modules/locale/locale.module:771) ``` The interface-translation system (`locale`) scans every JavaScript asset of type `file` on a page to extract `Drupal.t()` / `Drupal.formatPlural()` strings, reading each one with `file_get_contents()`. Canvas registers the draft asset library's JS as a root-relative route URL (`/canvas/api/v0/auto-saves/js/asset_library/{id}`), which the library parser classifies as a local file. `locale` then tries to read that route as a file on disk and fails. Because Drupal's PHPUnit configuration fails on warnings, this also turns the `phpunit` CI job red — currently surfacing through `ApiAutoSaveControllerTranslationTest`, where the warning is triggered. ### Steps to reproduce 1. Install Drupal with `locale` (a non-English interface language configured). 2. Have a Canvas asset library with an unpublished/draft change. 3. Render a page that attaches the draft asset library. 4. Observe the `file_get_contents()` warning in the logs. ### Proposed resolution Register the draft asset library's JS asset as `external` instead of letting it default to `file`. The draft JS is served by a controller route, not a file on disk, so `external` is the semantically correct type: the library parser keeps the URL verbatim, `locale`'s scan skips it (it only reads `file` assets), and the browser still fetches the same URL. Only the draft JS entry is affected; the draft CSS entries are not scanned by `locale`. ### Remaining tasks - Mark the draft asset library JS asset as `external` in `hook_library_info_build()`. - Confirm the `phpunit` CI job passes and the warning no longer appears in `ApiAutoSaveControllerTranslationTest`. ### User interface changes None in this issue. ### API changes None. ### Data model changes None.