Codex tools: Log in
Though localization is the primary use, it can be used to make any data available to your script that you can normally only get from the server side of WordPress.
<?php wp_localize_script( $handle, $name, $data ); ?>
<?php // Register the script first. wp_register_script( 'some_handle', 'path/to/myscript.js' ); // Now we can localize the script with our data. $translation_array = array( 'some_string' => __( 'Some string to translate' ), 'a_value' => '10' ); wp_localize_script( 'some_handle', 'object_name', $translation_array ); // The script can be enqueued now or later. wp_enqueue_script( 'some_handle' );
<script> alert( object_name.some_string) ; // alerts 'Some string to translate' </script>
<script> // Call a function that needs an int. FinalZoom = map.getBoundsZoomLevel( bounds ) - parseInt( data.a_value, 10 ); </script>
<script> tag containing your localization variable occurs at the time that the enqueued script is printed (output/included on the page). This has some significant repercussions if you enqueue your script as you should using the appropriate actions (wp_enqueue_scripts and admin_enqueue_scripts), but wish to localize later using data that is not available at enqueue time.
In this case, consider enqueueing your script with the in_footer argument set to true, to delay the printing of your script include until much later in the page build (ie:
wp_enqueue_script( $slug, $URL, $deps, $ver, true ); ). The last chance to localize your script would then be on the 'wp_print_footer_scripts' hook.
wp_localize_script() is located in