It looks like you have one registry that maps from types to dirs and texts, and to urls and regexes. Then you have different functions that operate on particular subkeys for particular types. ("Type" is a name you are using; in more abstract notation it is just another key that happens to be top-level.)
This suggests a few things.
There is one registry. Make it global.
You have business-logic functions that do particular things on one type at a time. So these functions should get the type (probably by name -- that's easier), and know about the registry. Since we are making the registry global (or if this is a package, at least a lexical with the same scope as the package) you don't need to explicitly pass a reference to the registry.
You need generic functions for manipulating the registry too. You'd mentioned adding a new type; maybe that's all you need right now but this approach will also let you cleanly write code to delete a type, clone it, and so on. Implement these as you need them, but the trick is--
What is referred to by a type always has the same structure. This suggests a class (though you don't have to go OO all the way if you don't want to). You then write a "loader" function to translate from data to a series of objects that will be less bulky (visually, at least) than writing out the code explicitly, inline. The big win here is that you can also pull out the data from the code completely and put it in a configuration file (or a database, or whatever). When you update the structure of a type, you have to update this loader, but now you have an encapsulated object which everybody accesses through a well-defined interface, so they don't have to change their code.