#21547 closed enhancement (wontfix)
Enable 'delocalization' of scripts
Reported by: | gkb6891 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | General | Keywords: | has-patch |
Focuses: | Cc: |
Description
I created a patch to enable developers to 'delocalize' a script they added. Currently if somebody localizes a script with wp_localize_script() there's no going back.
Can someone look at it and offer feedback? I'm not a regular WordPress contributor, so there may be stylistic issues.
Attachments (1)
Change History (9)
#2
in reply to:
↑ 1
;
follow-up:
↓ 3
@
12 years ago
Replying to scribu:
That patch looks fine.
The question is: why would you need to 'delocalize' a script?
It's not necessarily for internationalization. In my case, at Automattic, the WordPress.com plugin I was working on uses wp_localize_script to pass dynamic properties to a static javascript file.
Here's the specific scenario: we run multiple a/b tests each of which needs some dynamic parameters passed to a static javascript file. Each of these a/b tests enqueues the static javascript file if it's not already been enqueued.
The current implementation of wp_localize_script simply creates a new JS object each time it's called. This often leads to duplicate objects or overwriting existing objects. A developer (like me in this case) might want to modify the existing JS object instead of creating a new one. It's easy to simply delocalize the script by passing the handle and calling wp_localize_script one more time.
#3
in reply to:
↑ 2
@
12 years ago
Replying to gkb6891:
Replying to scribu:
That patch looks fine.
The question is: why would you need to 'delocalize' a script?
It's not necessarily for internationalization. In my case, at Automattic, the WordPress.com plugin I was working on uses wp_localize_script to pass dynamic properties to a static javascript file.
Here's the specific scenario: we run multiple a/b tests each of which needs some dynamic parameters passed to a static javascript file. Each of these a/b tests enqueues the static javascript file if it's not already been enqueued.
The current implementation of wp_localize_script simply creates a new JS object each time it's called. This often leads to duplicate objects or overwriting existing objects. A developer (like me in this case) might want to modify the existing JS object instead of creating a new one. It's easy to simply delocalize the script by passing the handle and calling wp_localize_script one more time.
I'm not yet convinced this is a good justification for doing this.
I'm pretty sure we can re-work your code to make it not need this, we can talk about it later.
#4
follow-up:
↓ 5
@
12 years ago
An idea that I think is somewhat behind this ticket is that there should be an API for passing data to Javascript that isn't intertwined with localization. In that context "delocalizing" a script might make more sense, like removing an action.
#5
in reply to:
↑ 4
@
12 years ago
Replying to evansolomon:
An idea that I think is somewhat behind this ticket is that there should be an API for passing data to Javascript that isn't intertwined with localization.
This was previously discussed in #11520.
#6
@
12 years ago
This ticket is basically for the ability to "merge" the already set script_data with newly added values. Indeed this was possible to do with the proposed add_script_data()
in #11520 however it didn't make it.
Localizing a script (as done in WordPress) means setting a simple JS object as string_name : translated_value
, then the main script uses the translated strings as needed. Agree it doesn't make sense for this to be overwritten. Additionally html_entity_decode()
needs to be run on the translations.
Adding arbitrary "script_data" was supposed to be the underlying API method for localizing a script but with more possibilities like merging/overwriting already added data, i.e. exactly what you would use in this case.
That patch looks fine.
The question is: why would you need to 'delocalize' a script?