Enable 'delocalization' of scripts

[gkb6891]

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.

[scribu]

That patch looks fine.

The question is: why would you need to 'delocalize' a script?

[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. 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.

[westi]

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.

[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. In that context "delocalizing" a script might make more sense, like removing an action.

[SergeyBiryukov]

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.

[azaozz]

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.

[c3mdigital]

Closing as wont fix based on comments above. If anyone feels we should continue looking at this please re open.