Currently, on the taxonomy term listing page (admin/structure/taxonomy/vocab_name), one can add new term by clicking on "Add term". I think we can change this to "Add new [vocabulary_name]" and passed through t() to allow flexibility, where [vocabulary_name] is replaced dynamically.
Though this can be achieved by writing a hook_menu_alter() but including this in the core seems to be fine.
This code works for me currently
<?php
function my_fixes_menu_alter(&$items){
$items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add']['title callback'] = 'current_vocab';
$items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add']['title arguments'] = array(3);
}
function current_vocab($arg){
$vocab_name = check_plain($arg->name);
return t('Add new @vocab_name', array('@vocab_name' => $vocab_name));
}
Can this be ported to Drupal core taxonomy module?

Comments
Comment #2
dpiIncorrect status usage.
Comment #3
djalxs commentedI have implemented and tested said functionality, patch uploaded.
Comment #4
djalxs commentedComment #6
adigunsherif commentedWhy did the patch fail testing?
Comment #7
djalxs commentedI have tested the patch on my dev build again and it works without issue.
This is pure speculation, but I feel it could be to do with the filename. I have removed special characters from the filename to see if the patch validates & passes.
Comment #8
djalxs commentedSo we must not be able to use special characters in patch filenames.
Comment #9
Aanal.addweb commented@djalxs,Thanks for the patch but still i face some issues which i mentioned in attachment.Please have a look & let me know if you have any query.
Comment #10
djalxs commentedI'm unsure what the attachment is supposed to show with regards to this patch.
If you can give me some more information I will be more than willing to help you out however, one thing I will mentions is that, by the looks of the attachment you are running Drupal 8. This issue is for Drupal 7, therefore the patch is also for Drupal 7.
Comment #11
adigunsherif commentedI can see also that she's running Drupal 8. This issue is for Drupal 7.
...testing the patch right away
Comment #12
Aanal.addweb commented@djalxs & @adigunsherif , Sorry i've uploaded wrong image instead of the attached image.
i mentioned the needed changes in "New attachment" file.
please have look & let me know if i'm wrong.
Comment #13
adigunsherif commentedThat's very correct. It should be replaced dynamically everywhere "add term" appears.
Comment #14
gg24 commentedI have updated the required changes, also added a interdiff. Please review.
Thanks!
Comment #15
gg24 commentedSome minor changes in the above patch.
Thanks!
Comment #16
dhruveshdtripathi commentedAfter applying patch #15, Add Term changed to Add new "[vocabulary_name]". I created News Taxonomy so it changed to Add new news. Great work @gg24
The changes are not applied on the main Taxonomy page.
Comment #17
gg24 commentedComment #18
gg24 commentedHi @dhruveshdtripathi
This issue has been created for "taxonomy term listing page (admin/structure/taxonomy/vocab_name)" only as mentioned in the issue description. If we really want to change it on Vocabulary listing page as well, lets create a new issue and open it for further discussion.
Thanks!
Comment #19
dhruveshdtripathi commentedOK then the last patch works fine. Changing status to RTBC.
Comment #20
David_Rothstein commentedInteresting idea - I'm not sure if people always name their vocabularies so that it would make perfect sense in this context, but overall I like it because it gives more information and makes things more consistent with other areas of Drupal (such as creating content).
It would need to go in Drupal 8 first though.
Also, for the code, make sure everything is properly translatable using placeholders (see https://www.drupal.org/docs/7/api/localization-api/dynamic-strings-with-...) rather than manual check_plain() calls.
I also don't understand the point of the strtolower() - that pattern is not used on the content creation page, right?
Comment #21
David_Rothstein commentedAnother option (consistent with #2596207: More specific titles for term and vocabulary edit forms) would be to make it something like "Add term in the [vocabulary_name] vocabulary".
Comment #22
adigunsherif commentedI actually don't know of many other use cases. But in most of my use cases, it's better to have Add new [vocabulary_name]. Say for example, a vocab name "car". It makes more sense to have "Add new car" than "add term in car". Likewise "tag" => "Add new tag", and "category" => "Add new category".
And in the case of a School Management System built with Drupal where there are 3 academic terms in a session, it makes perfect sense to have "Add new session" instead of "Add term" which might be confusing to administrators who don't know about Drupal.
However, the [Add new] should be translatable t().
Comment #25
joachim commented> "Add new [vocabulary_name]"
That might not always make sense with the name of the vocab.
Also, there might be translation issues.
Comment #28
sumithb commentedThe patch is given for Drupal 7. This is not implemented for Drupal 8?
Comment #29
aaronchristian commented@sumithb, looks like the patch just needs to be re-rolled, however you can keep and eye on this one as it is similar and seems to be more active.
See https://www.drupal.org/project/drupal/issues/2596207#comment-12541541
Comment #30
berdirAs others pointed out, this is extremely hard to generalize and localize properly.
#2765065: Allow plurals on bundle labels is about allowing different versions of bundle labels, which might make this easier but not in any way easy. It's quite common to use plural labels for vocabularies right now, even Standard profile uses "Tags" and not "Tag".
Forced lowercase is a problem for german, other languages will have problems with order of words and so on.
Additionally, the term "term" is still everywhere, the empty text with the patch still has "No terms", there's the "List terms" operation, there's "Terms are grouped into vocabularies" and so on. It's not possible to "contextualize" them all properly, so honestly, I'd suggest to won't fix this.
Edit: This pattern also doesn't exist for nodes either, that has a single overview and "Add content", which then contains a list of available node types.