WordPress plugin translation

Plugin translation has never for me seemed an easy task, i could never quite follow the mish mash of differing information around the web, and none of the guides available ever seemed to answer the specifics of what i needed to know about setting up a plugin for translation.

Well a couple of months have passed since i last put my head down and read up on the translation process, and fortunately for me the persistance in grasping the technique has paid off, i’ve managed (well i hope) to grasp the fundamental points of how to prepare a plugin for translation, and additionally how to run through a translation process.

Those of who would just prefer to see example code can skip straight to the plugin download.

NOTE: This is intended for code literate users, those of you who can already code but just need a quick run down on how to utilise the translation functionality inside a plugin.

Firstly your plugin will need to register a text domain for performing translation tasks, you can read more on that here. Of course the codex entry does leave a little to be desired, not really giving much in the way of an easy to follow example.

However, let’s just run by the parameters for load_plugin_textdomain very briefly.

1. $domain

This is basically the name for your text domain. You’ll have to reference this alot in your plugin, so it certainly helps to make it something easy to remember and quick to type. The name (or domain) declared here will also prefix all translation files used in your plugin, so do try to KISS.

2. $abs_rel_path

We will ignore this parameter because it’s no longer used as of WordPress 2.7, originally you would use this parameter to declare the path to the language files in your plugin, based on the WordPress ABSPATH. I will not be using this parameter for the example, so i’ll stop there.

3. $plugin_rel_path

I think the codex description sums up what this parameter does pretty well (not perfect though).

Relative path to WP_PLUGIN_DIR. This is the preferred argument to use. It takes precendence over $abs_rel_path

Ok, so now the description is out of the way, where should you place the call to load_plugin_textdomain?

As far as i know textdomains should be registered at the init stage, so depending on whether you want to translate front side, admin side or both, will depend where you hook the registration onto, but for the sake of this example i’ve hooked mine onto admin_init.

Inside the main function of my plugin class is a line like so.

				// The action hook
				add_action( 'admin_init' , array( &$this , 'register_plugin_settings' ) );

Various other pieces of code are present in the functions, so to keep this blog trim here’s the line inside the above referenced function that registers the textdomain.

				// How the text domain looks inside the register plugin settings function referenced above
					$this->l10n_prefix,                        // Plugin text domain reference
					false,                                     // False - deprecated parameter
					basename( dirname( __FILE__ ) ) . '/lang'  // Path to translation files

In the case of my example plugin(at the end of this post) i’ve used a variable to store the name of the textdomain, this means i don’t have to keep remembering the reference name, i simply type in the variable each time i want to make some text translatable.

More information and a very similar example of load_plugin_textdomain can be found here.

Here’s my text domain variable for reference.

			$this->l10n_prefix = 'translatable_demo';

Also note the third parameter used in the text domain registration, this sets where to look for the translation files, you can however (as the codex entry suggests), leave this blank and WordPress will assume they reside in the same folder as your plugin. Of course it’s good to keep things organised, i know i do(just a little), so i’ve opted to have the text domain reference a folder called “lang” (no quotes) inside my plugin’s folder.

Ok you’ve come this far, you’ve registered a text domain, what next?

Next you’ll need to start converting all the strings in your plugin you wish to make translatable, and this is probably the most easiest step in the whole process, and rather then repeat the guides and information already available i’ll simply point you here, and provide a very brief example below based on my example plugin.

Example strings:

$var1 = 'WordPress';
echo 'Hello world';

Translation ready: (remembering the text domain name)

$var1 = __( 'WordPress', 'translatable_demo' ); // __() return value
_e( 'Hello world', 'translatable_demo'); // _e() - echoed value

That’s it as far as making the plugin translation ready, honestly, what more did you expect?

Techinically there is nothing left to do on your part, the plugin can be translated, but a good practice for plugin developers (or so i hear) is to include a .POT file along with the plugin. In the most simple terms this is a base translation file, that will in essence be like any translation of your plugin, but not include a translation for each string, providing a .POT file just means a translator can pick up that file and get translating without having to run your plugin’s folder/files through a translation program (you save them a few minutes, but it’s really very easy, and the process is pretty much identical to that of the translator).

You can download the example plugin here or here(sorry couldn’t host it here, not allowed zips on WordPress.com blogs).
EDIT (02/07/13): New download link(hopefully this one won’t just random expire)

For those of you still interested in learning how to create a .POT file and developing language files read on, i’m going to run down the procedure i followed for creating a .POT file. I’m a windows user, so those of you on another OS, you’ll unfortunately have to look toward existing guides on how to translate. Anyone still with me, read on..

  1. Download and Install Poedit (it’s free).
  2. Open Poedit and click on New Catalog, under File.
  3. Fill in a name for the project, and choose the appropriate language you write in (not required but i tend to do it anyway).
  4. Click on the Paths tab at the top of the box.
  5. Click the second little icon, and put the directory location of your plugin in, for example “C:\Documents and Settings\USER\Desktop\MY_PLUGIN”
  6. Click on the Keywords tab at the top of the box.
  7. Click the second icon, and enter “__” (no quotes, and that’s two underscores).
  8. Click the second icon again, this time entering “_e”
  9. Now click the Ok button.
  10. A save dialog will appear, so enter a name for your POT file and change the extension to .pot
  11. Choose an appropriate place to save the file (you’ll probably want to choose to the language folder inside your plugin).
  12. Click Save.
  13. Various things will happen now and poedit will shows some boxes on the screen. Don’t do anything, this is what a translator will see when he or she is translatin your POT file. Just close the file, job done.

NOTE: It’s most likely a good idea to name your POT file with the same prefix the translation files will require. The prefix is the name you gave you text domain inside your plugin, ie. the first parameter.

Doing translations is the easy part, so i’m leaving that out of my blog for now, but if anyone finds this useful and would like to see an additional “How to make a translation file” or similar, then post a comment, let me know.

If you struggled to keep up with anything covered above, or you think anything above could do with refinement, again feel free to provide feedback, i’m not the world’s best blogger, and my mind can wander when writing, so critique is most definately welcome..


Prevent front and posts page being the same

I’m sure those of you familiar with WordPress will be acustom to the two settings provided under Admin -> Settings -> Reading, known as the Front Page and the Posts Page. Whilst some users find their usage easy, and others find it somewhat confusing, these two settings have never been intended to share a page, in short both should never be set to the same.

The following simple jQuery based plugin will prevent a user from applying the same page to these settings. This could be useful for those of you providing clients with WordPress sites that do not understand such features and attempt to configure these both to the same page.

Plugin Name: Prevent front and posts page being the same.
Description: Prevents the posts page and front page settings be set to the same page.
add_action( 'admin_head-options-reading.php' , 'postspage_frontpage_not_same' );
function postspage_frontpage_not_same() {
	<script type="text/javascript">
	jQuery(document).ready(function($) {		
		// Get the current selected values
		var wp_frontpage = $('#page_on_front option:selected').val();
		var wp_postspage = $('#page_for_posts option:selected').val();
		if( wp_postspage != '' ) {
			$('#page_on_front').find('option[value=' + wp_postspage + ']').attr("disabled","disabled");
		if( wp_frontpage != '' ) {
			$('#page_for_posts').find('option[value=' + wp_frontpage + ']').attr("disabled","disabled");
		// Attach a change function to the front page dropdown
		$('#page_on_front').change(function() {
				// Re-declare the variable for use inside the scope of the function
				var wp_frontpage = $('#page_on_front option:selected').val();
				if( wp_frontpage != '' ) {
					// Find a matching option in posts page dropdown
					$('#page_for_posts').find('option[value=' + wp_frontpage + ']').attr("disabled","disabled");
				$('#page_for_posts').find('option[value!=' + wp_frontpage + ']:disabled').removeAttr('disabled');
		// Attach a change function to the posts page dropdown
		$('#page_for_posts').change(function() {
				// Re-declare the variable for use inside the scope of the function
				var wp_postspage = $('#page_for_posts option:selected').val();
				if( wp_postspage != '' ) {
					// Find a matching option in the front page dropdown
					$('#page_on_front').find('option[value=' + wp_postspage + ']').attr("disabled","disabled");
				$('#page_on_front').find('option[value!=' + wp_postspage + ']:disabled').removeAttr('disabled');

As always feel free to post a comment, or if you have any suggestions regarding the code, please do share them.

WordPress post or page has embed

Recently someone on the WordPress forums asked if there was an easy way to determine if a post has any content embedded and if so, a link could be provided to indicate the visitor should click it to see the full post where the embedded content is available.

The well known function the_excerpt() does not show embedded content, so an archive listing displaying excerpts would have no ordinary way to indicate content such as a Youtube video is available inside the full posting.

I wrote this very simple function for checking if a post(or page presumably) has any content embedded inside.

function has_embed( $post_id = false ) {
	if( !$post_id )
		$post_id = get_the_ID();
		$post_id = absint( $post_id );
	if( !$post_id )
		return false;

	$post_meta = get_post_custom_keys( $post_id );

	foreach( $post_meta as $meta ) {
		if( '_oembed' != substr( trim( $meta ) , 0 , 7 ) )
		return true;
	return false;

The function is not designed to output any link, or data, it’s simpy a true or false return statement so you can determine if a given post(or page) has embedded content, what you place inside the conditional check is up to you, but here’s a very basic example that i provided along with the function initially.

<?php if( has_embed() ) : ?>
	<a href="<?php the_permalink(); ?>" title="Click to see the Video">Click here to see the Video</a>
<?php endif; ?>

What goes inside that condition is entirely down to you and what you want to have there, the example is simply for illustration of how to use the function.

Code works under the current release 2.9.2 and also has been tested under WordPress 3.0 Beta2.

If you find the function useful please feel free to share a comment or rate the post, no registration is required but i do moderate your first couple of comments (can you blame me with all the spam around?).

QuickPress Category – Extending Functionality

Following on from a discussion on the WordPress.org support forums, and posts to both the ideas section, and trac which deals with bugs, features, enhancements and the general WordPress source code, i’m turning my efforts to blogging about changes i’d like to see in the QuickPress widget shown in the WordPress dashboard.

For reference, the relevant tickets and discussion.
Trac ticket: http://core.trac.wordpress.org/ticket/13038
Ideas ticket: http://wordpress.org/extend/ideas/topic/quickpress-category-need-hooks
Forum topic: http://wordpress.org/support/topic/317373

Seems WordPress.com users also want categories in QuickPress.

In my comments on the trac ticket i mentioned a proof of concept(PoC) for using arrays to sort and filter the form elements in the QuickPress widget. Now bear in mind this is still a concept and by no means is intended as a proper patch, but below you will find a rewrite of the QuickPress widget function that i spent some time working on and testing (it’s also in patch form for Trac if anyone wants a patch/diff to test against).

Click here to skip past the function code (it’s 205 lines).

function wp_dashboard_quick_press() {
	$drafts = false;
	if ( 'post' === strtolower( $_SERVER['REQUEST_METHOD'] ) && isset( $_POST['action'] ) && 0 === strpos( $_POST['action'], 'post-quickpress' ) && (int) $_POST['post_ID'] ) {
		$view = get_permalink( $_POST['post_ID'] );
		$edit = esc_url( get_edit_post_link( $_POST['post_ID'] ) );
		if ( 'post-quickpress-publish' == $_POST['action'] ) {
			if ( current_user_can('publish_posts') )
				printf( '<div class="message"><p>' . __( 'Post Published. <a href="%s">View post</a> | <a href="%s">Edit post</a>' ) . '</p></div>', esc_url( $view ), $edit );
				printf( '<div class="message"><p>' . __( 'Post submitted. <a href="%s">Preview post</a> | <a href="%s">Edit post</a>' ) . '</p></div>', esc_url( add_query_arg( 'preview', 1, $view ) ), $edit );
		} else {
			printf( '<div class="message"><p>' . __( 'Draft Saved. <a href="%s">Preview post</a> | <a href="%s">Edit post</a>' ) . '</p></div>', esc_url( add_query_arg( 'preview', 1, $view ) ), $edit );
			$drafts_query = new WP_Query( array(
				'post_type' => 'post',
				'post_status' => 'draft',
				'author' => $GLOBALS['current_user']->ID,
				'posts_per_page' => 1,
				'orderby' => 'modified',
				'order' => 'DESC'
			) );

			if ( $drafts_query->posts )
				$drafts =& $drafts_query->posts;
		printf('<p class="textright">' . __('You can also try %s, easy blogging from anywhere on the Web.') . '</p>', '<a href="tools.php">' . __('Press This') . '</a>' );
		$_REQUEST = array(); // hack for get_default_post_to_edit()
	$post = get_default_post_to_edit();
	$form_el = array();
	// Indexes - Visual order of fields
	$indexes = array( 'title' => 1, 'media' => 2, 'content' => 3, 'tags' => 4 );
	// Tab Indexes - Tabbing order of fields that have a tab index
	$tab_indexes = array( 'title' => 1, 'content' => 2, 'tags' => 3 );
	$form_el = array( 'indexes' => $indexes, 'tab_indexes' => $tab_indexes );
	$form_el = apply_filters( 'quickpress_fields', $form_el );
	// Check indexes if filter is attached
	if( has_filter( 'quickpress_fields' ) ) {
		if( !isset( $form_el['indexes'] ) || !is_array( $form_el['indexes'] ) || empty( $form_el['indexes'] ) )
			$form_el['indexes'] = &$indexes;
			$form_el['indexes'] = array_map( 'absint', &$form_el['indexes'] );
		if( isset( $form_el['tab_indexes'] ) ) {
			if( !is_array( $form_el['tab_indexes'] ) || empty( $form_el['tab_indexes'] ) )
				$form_el['tab_indexes'] = &$tab_indexes;
				$form_el['tab_indexes'] = array_map( 'absint', &$form_el['tab_indexes'] );
		else {
			// If the tab index array is unset, create as empty array
			$form_el['tab_indexes'] = array();
		$form_el['indexes'] = array_filter( $form_el['indexes'] );
		foreach( $form_el as $el => $data ) {
			$el = esc_attr( $el );
			switch( $el ) {
				case 'tab_indexes':
				case 'indexes':
				case 0:
					unset( $form_el[0] );
					$form_el[$el] = $data;
	$title_tab = $content_tab = $tags_tab = $draft_tab = $save_tab = '';
	if( isset( $form_el['indexes']['title'] ) ) {
		if( isset( $form_el['tab_indexes']['title'] ) ) 
			$title_tab = 'tabindex="' . $form_el['tab_indexes']['title'] . '" ';

		$title_field = array(
			'label'        => '<label for="title">' . __('Title') . '</label>',
			'label_before' => '<h4>',
			'label_after'  => '</h4>',
			'input'        => '<input type="text" name="post_title" id="title" '.$title_tab.'autocomplete="off" value="' . esc_attr( $post->post_title ) . '" />',
			'input_before' => '<div class="input-text-wrap">',
			'input_after'  => '</div>'
		$form_el['title']   = $title_field;
	if( isset( $form_el['indexes']['content'] ) ) {
		if( isset( $form_el['tab_indexes']['content'] ) )
			$content_tab = 'tabindex="' . $form_el['tab_indexes']['content'] . '" ';
		$content_field = array(
			'label'        => '<label for="content">' . __('Content') . '</label>',
			'label_before' => '<h4>',
			'label_after'  => '</h4>',
			'input'        => '<textarea name="content" id="content" class="mceEditor" ' .$content_tab . 'rows="3" cols="15">' . $post->post_content . '</textarea>',
			'input_before' => '<div class="textarea-wrap">',
			'input_after'  => '</div>'."\n\t".'<script type="text/javascript">edCanvas = document.getElementById(\'content\');edInsertContent = null;</script>'
		$form_el['content'] = $content_field;
	if( isset( $form_el['indexes']['tags'] ) ) {
		if( isset( $form_el['tab_indexes']['tags'] ) )
			$tags_tab = 'tabindex="' . $form_el['tab_indexes']['tags'] . '" ';
		$tags_field = array(
			'label'        => '<label for="tags-input">' . __('Tags') . '</label>',
			'label_before' => '<h4>',
			'label_after'  => '</h4>',
			'input'        => '<input type="text" name="tax_input[post_tag]" '.$tags_tab.'value="' . get_terms_to_edit( $post->ID , 'post_tag' ) . '" />',
			'input_before' => '<div class="input-text-wrap">',
			'input_after'  => '</div>'
		$form_el['tags']    = $tags_field;
	// Sort index by array values
	asort( $form_el['indexes'] );
	if( isset( $form_el['tab_indexes'] ) && !empty( $form_el['tab_indexes'] ) )
		$tab_current = max( $form_el['tab_indexes'] );
		$tab_current = 0;

	if( !0 == $tab_current ) {
		$draft_tab = 'tabindex="' . $tab_current . '" ';
		$reset_tab = 'tabindex="' . $tab_current . '" ';
		$save_tab  = 'tabindex="' . $tab_current . '" ';
	echo '<form name="post" action="' . esc_url( admin_url( 'post.php' ) ) . '" method="post" id="quick-press">';
	do_action( 'quickpress_before_fields' );
	// Fields to be output are required to have a place in the index
	foreach( $form_el['indexes'] as $field => $index ) {
		// If no data for this index item, carry onto next item
		if( !isset( $form_el[$field] ) )
		// If data but missing required input, carry onto next item
		if( !isset( $form_el[$field]['input'] ) ) {
			unset( $form_el[$field] );
		if( 'content' == $field ) {
			if ( current_user_can( 'upload_files' ) ) {
				echo "\n\t";
				echo '<div id="media-buttons" class="hide-if-no-js">';
				do_action( 'media_buttons' );
				echo "\n\t";
				echo '</div>';
		echo "\n\t";
		// Before label
		if( isset( $form_el[$field]['label_before'] ) )
			echo $form_el[$field]['label_before'];		
		// Label
		if( isset( $form_el[$field]['label'] ) )
			echo $form_el[$field]['label'];
		// After label
		if( isset( $form_el[$field]['label_after'] ) )
			echo $form_el[$field]['label_after'];		
		echo "\n\t";
		// Before input
		if( isset( $form_el[$field]['input_before'] ) )
			echo $form_el[$field]['input_before'];
		// Input
		echo $form_el[$field]['input']; // Required toward the top of the loop
		// After input
		if( isset( $form_el[$field]['input_after'] ) )
			echo $form_el[$field]['input_after'];
	do_action( 'quickpress_after_fields' );
	echo "\n\t" . '<p class="submit">';
	echo "\n\t\t" . '<input type="hidden" name="action" id="quickpost-action" value="post-quickpress-save" />';
	echo "\n\t\t" . '<input type="hidden" name="quickpress_post_ID" value="' . (int) $post->ID . '" />';
	echo "\n\t\t" . '<input type="hidden" name="post_type" value="post" />';
	wp_nonce_field( 'add-post' ); 
	echo "\n\t\t" . '<input type="submit" name="save" id="save-post" class="button" ' . $draft_tab .'value="' . esc_attr('Save Draft') . '" />';
	echo "\n\t\t" . '<input type="reset" value="' . esc_attr( 'Reset' ) . '" class="button" ' . $reset_tab .'/>';
	echo "\n\t\t" . '<span id="publishing-action">';
	echo "\n\t\t\t" . '<input type="submit" name="publish" id="publish" accesskey="p" ' . $save_tab . 'class="button-primary" value="' . 
	( current_user_can( 'publish_posts' ) ? esc_attr( 'Publish' ) : esc_attr( 'Submit for Review' ) ) . '" />';
	echo "\n\t\t\t" .'<img class="waiting" src="' . esc_url( admin_url( 'images/wpspin_light.gif' ) ) . '" />';
	echo "\n\t\t" . '</span>';
	echo "\n\t\t" . '<br class="clear" />';
	echo "\n\t" . '</p>';
	echo "\n" . '</form>';
	echo "\n";
	if ( $drafts )
		wp_dashboard_recent_drafts( $drafts );

If you’d like to test out the code, simply overwrite the original function in wp-admin/includes/dashboard.php with the one provided above.

Do be aware, by replacing this function, nothing will visually change in the widget yet, all this code does is provide a rewrite of the existing function, making it pluggable. The new hooks allow resorting of the form fields, resorting the tab index or removing it all together, aswell as allowing the removal of unwanted form fields, eg. tags.

The rewritten function provides one new filter and two new actions. Here they are for reference to save you having to look over all the code.

// Contains the fields indexes(positions) and tab indexes
// Also supports adding new fields
apply_filters( 'quickpress_fields', $form_el );

// Runs before the quickpress form fields have been output
do_action( 'quickpress_before_fields' );

// Runs after the quickpress form fields have been output
do_action( 'quickpress_after_fields' );

The quickpress_fields filter available contains only two keys, indexes and tab_indexes. Indexes is an array of key => value pairs representing input positions(key is the field, value the position), this in the most simple terms determines the order in which the various inputs display in the widget, but it’s also an integral part of the new filtering system, only items with a key and value in this array are displayed, if a filter were to remove that index it would in effect remove that field from the widget.

Tab indexes are simply for accessibilty and simply exist to aid users adding additional fields, and therefore can be adjusted or removed totally, the fields will render appropriately regardless of whether they are given a tab index. Tab indexes are the order in which the tab key on your keyboard moves through the various items of a webpage or form. By default the tax indexes in the widget as they exist in WordPress right now are…

Name – Tab-index
Title – 1
Content – 2
Tags – 3
Save Draft – 4
Publish – 5

The tab index array, like the main index array is comprised of key => value pairs, again key is the field name and value is the tab index. By passing these into the filter, they can be adjusted by users(you/me/anyone) alongside any extra fields we choose to add in via hook.

The new actions like any other in WordPress are just a quick shortcut to inserting some extra content into an area, in this case a dashboard widget, either before or after the existing fields (it didn’t make sense for me to place these in static positions amongst the existing fields since i’ve provided a method for sorting – so before and after fields were my preference).

Code speaks louder than my blabbering though, so here’s a basic example filter that adds a new text field below the existing ones. Please see the notes that follow the example.

add_filter( 'quickpress_fields' , 'my_quickpress_fields' , 10 , 1 );

function my_quickpress_fields( $form_array ) {
	// Add new field into index *required when adding new fields via this filter*
	$form_array['indexes']['myfield'] = 6;
	// Invalid (tab index is simply for re-sorting, if required)
	//$form_array[tab_'indexes']['myfield'] = 6;
	// Register a new element into the form array 
	// Required, array - key is the new field name, value should be an array of key -> value pairs for the supported fields
	$form_array['myfield'] = array(
		// Not required
		'label'        => '<label for="myfield">' . __('My field') . '</label>',
		// Not required
		'label_before' => '<h4>',
		// Not required
		'label_after'  => '</h4>',
		// Required
		'input'        => '<input tabindex="6" type="text" name="myfield" value="" />',
		// Not required
		'input_before' => '<div class="input-text-wrap">',
		// Not required
		'input_after'  => '</div>'
	// Return the data
	return $form_array;

Looks simple enough right? Do bear in mind, this doesn’t mean you can just go plonking in any form elements you want and expect them to save data, post.php does have limitations on what $_POST data it expects and will save.

The good news is, custom taxonomies are already supported, which whilst exciting is still held back by restrictions that leave us stuck using the “post” post_type. I’d have liked to have been able to add an additional filter to allow switching the post type(tried already), but due to restrictions in how post.php deals with the data sent from quickpress unfortunately that’s something that will have to be given much further consideration and more brainstorming as it would require patching post.php to accept something other than posts from QuickPress.

The above code example is a working example, in so much that it will appear as an element in the QuickPress widget, it won’t however save data(and only an illustration to show the available and required items), because as said above, post.php must receive one of the supported $_POST fields.

However!! below are some working examples filters and actions you can use alongside the new function.

Category Dropdown

add_filter( 'quickpress_fields' , 'my_quickpress_fields' , 10 , 1 );

function my_quickpress_fields( $form_array ) {
	$form_array['indexes']['category'] = 2;
	$form_array['category'] = array(
		'label'        => '<label for="post_category">Category</label>',
		'label_before' => '<h4>',
		'label_after'  => '</h4>',
		'input'        => '<p>'. wp_dropdown_categories( array( 'echo' => 0 , 'hide_empty' => 0 , 'name' => 'post_category[]' ) ) . '</p>'
	return $form_array;

Hidden Category Selection

add_action( 'quickpress_after_fields' , 'my_quickpress_fields' );

function my_quickpress_fields( ) {
	echo '<input type="hidden" name="post_category[]" value="23" />';

NOTE: 23 is an example category ID (change accordingly)

Remove Post Tags & Media Uploads from QuickPress

add_filter( 'quickpress_fields' , 'my_quickpress_fields' , 10 , 1 );

function my_quickpress_fields( $form_array ) {
	unset( $form_array['indexes']['tags'] , $form_array['indexes']['media'] );
	return $form_array;

If you like the function replacement, please show your support (pingback, trackback, etc), hopefully someone on the dev team will spot the idea and be able to create something more inline with WordPress coding practices as part of future functionality for the widget (or i can always refine my code, if someone wants to pick it apart, kindly).

Comments welcome…. 🙂