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 wp_register_script( 'some_handle', 'path/to/myscript.js' ); // Localize the script with new data $translation_array = array( 'some_string' => __( 'Some string to translate', 'plugin-domain' ), 'a_value' => '10' ); wp_localize_script( 'some_handle', 'object_name', $translation_array ); // Enqueued script with localized data. wp_enqueue_script( 'some_handle' );
<script> // alerts 'Some string to translate' alert( object_name.some_string); </script>
<script> // Call a function that needs an int. FinalZoom = map.getBoundsZoomLevel( bounds ) - parseInt( object_name.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