Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#21547 closed enhancement (wontfix)

Enable 'delocalization' of scripts

Reported by: gkb6891's profile 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)

script_changes.diff (2.5 KB) - added by gkb6891 12 years ago.

Download all attachments as: .zip

Change History (9)

#1 follow-up: @scribu
12 years ago

  • Keywords has-patch added

That patch looks fine.

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

#2 in reply to: ↑ 1 ; follow-up: @gkb6891
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.

Last edited 12 years ago by gkb6891 (previous) (diff)

#3 in reply to: ↑ 2 @westi
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: @evansolomon
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 @SergeyBiryukov
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 @azaozz
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.

#7 @c3mdigital
11 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

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

#8 @SergeyBiryukov
11 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.