[api-minor] Re-factor NullL10n and remove the hard-coded l10n strings (PR 17115 follow-up)
#17146
Conversation
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/2d103322c62414d/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/2d103322c62414d/output.txt Total script time: 1.44 mins Published |
…gs (PR 17115 follow-up) *Please note:* These changes only affect the GENERIC build, since `NullL10n` is only a stub elsewhere (see PR 17135). After the changes in PR 17115, which modernized and improved l10n-handling, the `NullL10n`-implementation is no longer a good fallback for the "proper" `L10n`-classes. To improve this situation, especially for the *standalone* viewer-components, this patch makes the following changes: - Let the `NullL10n`-implementation extend an actual `L10n`-class, which is constant and lazily initialized, to ensure that it works *exactly* like the "proper" ones. - Automatically bundle the "en-US" l10n-strings in the build, via the pre-processor, such that we don't need to remember to manually update them. - Ensure that the *standalone* viewer-components register their DOM-elements for translation, similar to the default viewer, since this will allow future code improvements by using "data-l10n-id"/"data-l10n-args" in most (if not all) parts of the viewer. - Remove the `NullL10n` from the `AnnotationLayer`, to avoid affecting bundle size too much. For third-party users that access the `AnnotationLayer`, as exposed in the main PDF.js library, they'll now need to *manually* register it for translation. (However, the *standalone* viewer-components still works given the point above.)
Snuffleupagus
force-pushed
the
NullL10n-refactor
branch
from
3a4ea91 to
f07675a
Compare
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/7ef2b845d142b14/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/872ff168aff45d2/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/7ef2b845d142b14/output.txt Total script time: 24.80 mins
Image differences available at: http://54.241.84.105:8877/7ef2b845d142b14/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/872ff168aff45d2/output.txt Total script time: 36.46 mins
Image differences available at: http://54.193.163.58:8877/872ff168aff45d2/reftest-analyzer.html#web=eq.log |
|
This PR should also fix https://github.com/mozilla/pdf.js/security/code-scanning/404, simply by removing the affected code. |
Please note: These changes only affect the GENERIC build, since
NullL10nis only a stub elsewhere (see PR #17135).After the changes in PR #17115, which modernized and improved l10n-handling, the
NullL10n-implementation is no longer a good fallback for the "proper"L10n-classes.To improve this situation, especially for the standalone viewer-components, this patch makes the following changes:
Let the
NullL10n-implementation extend an actualL10n-class, which is constant and lazily initialized, to ensure that it works exactly like the "proper" ones.Automatically bundle the "en-US" l10n-strings in the build, via the pre-processor, such that we don't need to remember to manually update them.
Ensure that the standalone viewer-components register their DOM-elements for translation, similar to the default viewer, since this will allow future code improvements by using "data-l10n-id"/"data-l10n-args" in most (if not all) parts of the viewer.
Remove the
NullL10nfrom theAnnotationLayer, to avoid affecting bundle size too much.For third-party users that access the
AnnotationLayer, as exposed in the main PDF.js library, they'll now need to manually register it for translation. (However, the standalone viewer-components still works given the point above.)