As has been note by Geert, you should not edit plug-in files: changes will be overridden with an update (… and you really should be keeping your plug-ins up to date…). The best thing to do is…
Ask the plug-in developers to add a hook to filter the label
For now however you can do one of two things:
Use a hook for when the post type is registered to update post type object
Take advantage of the fact the label is translatable
Method 1:
add_action('registered_post_type','wpse54367_alter_post_type',10,2);
function wpse54367_alter_post_type($post_type, $args){
if( $post_type != 'product' )
return;
//Get labels and update them
$labels = get_post_type_labels( get_post_type_object( $post_type ) );
$labels->name = 'Some things';
$labels->singular_name= 'Some thing';
//update args
$args->labels = $labels;
$args->label = $labels->name;
//update post type
global $wp_post_types;
$wp_post_types[$post_type] = $args;
}
Method 2:
since the label is ‘translatable’ you can use the gettext filter.
While Stephenâs answer is a great way to work with the current situation, a cleaner solution would exist if the plugin developers made a simple change.
Action to be taken by the plugin developers:
First of all, when registering a post type you should set the menu_name label. This label is specifically used for the menu; if itâs not set the name label is used by default.
When setting the menu_name label, the _x() translation function should be used. That way translators can supply a specific translation just for the menu name. Otherwise, the translation for ‘Products’ would apply to the normal name label as well.
Update: I opened a pull request on GitHub for these changes in WooCommerce. Jigoshopâs code is probably very similar.
Action to be taken by the plugin user:
Load a custom translation mo-file with a specific translation for the menu name string. In your po-file the entry would look like this:
msgctxt "Admin menu name"
msgid "Products"
msgstr "My Productzz"
To load a custom translation file you can hook into the load_textdomain() function. A well-built plugin would also allow you to drop custom translation files into the wp-content/languages/{plugin_name}/ directory. WooCommerce allows this, Iâm not sure about Jigoshop.
Inside the plugin folder check for File: jigoshop_taxonomy.php
Line no: 120
You will see
Update it as needed.
As has been note by Geert, you should not edit plug-in files: changes will be overridden with an update (… and you really should be keeping your plug-ins up to date…). The best thing to do is…
Ask the plug-in developers to add a hook to filter the label
For now however you can do one of two things:
Method 1:
Method 2:
since the label is ‘translatable’ you can use the
gettext
filter.You can use the Admin Menu Editor plugin.
While Stephenâs answer is a great way to work with the current situation, a cleaner solution would exist if the plugin developers made a simple change.
Action to be taken by the plugin developers:
First of all, when registering a post type you should set the
menu_name
label. This label is specifically used for the menu; if itâs not set thename
label is used by default.When setting the
menu_name
label, the_x()
translation function should be used. That way translators can supply a specific translation just for the menu name. Otherwise, the translation for ‘Products’ would apply to the normalname
label as well.Update: I opened a pull request on GitHub for these changes in WooCommerce. Jigoshopâs code is probably very similar.
Action to be taken by the plugin user:
Load a custom translation mo-file with a specific translation for the menu name string. In your po-file the entry would look like this:
To load a custom translation file you can hook into the
load_textdomain()
function. A well-built plugin would also allow you to drop custom translation files into thewp-content/languages/{plugin_name}/
directory. WooCommerce allows this, Iâm not sure about Jigoshop.