Make it easy to change user facing text from "register/registration" to other stuff

Thanks for brining up this important issue. It actually came up when we first kicked off the project and discussed it over in the signup queu. Our conversations at the time, combined with available namespaces, led us to registration / Entity Registrations.

The big challenge we face of renaming the project at this point is really time and resources. We already have the code base in production on 2 sites, and in staging for 2 other large, complex projects. In addition to the time involved in changing the namespace within the module code, we'd need to migrate those existing projects over to the new namespace, namely Feature exports, system module information, and glue code that's using the API calls. We're a small team that has our hands full, and really can't take a break to make it happen right now. I imagine that many of the 380 reported installs would be in a similar situation.

In general, we've also found that the larger nonprofits we tend to work with are much more comfortable with Registration / Register nomenclature around events than Sign-up. Folks also tend to say signup for an account as often as they do register for an account. So there's potential confusion either way.

I think the potential confusion around core's register namespace is valid and an imperfect situation, as is any confusion with signup, and we're certainly open to working with the community towards a solution. But I am saying that in the near term, at least, we're not in a position to make that switch. We're eager to help release a top notch event registration system for Drupa, whatever the namespace is!

I suppose the question should also be whether there is a better name. 'Attendee/ance'. Thats all I've got.

Registration is a good name, in any case, this should be figured out before 1.0.

Folks also tend to say signup for an account as often as they do register for an account. So there's potential confusion either way.

Folks do, but core is pretty consistent around the idea that creating an account on the site is registering. I think contrib modules should try to respect that.

What about just changing user-facing strings to say "Signup" and let the t() system handle site-specific situations? Is that a lower level of effort task?

It also seems like - if you're going to solve it - now is the time to solve this problem before 380 becomes 7,000+

Greggles, I have a ton of respect for your opinion, as well as that of Ezra. And Lev and I really want to work with you all to get this module into COD.

However, the clients who have helped pay for this module to be developed specifically needed to use "registration" as their vernacular. It would still cost us a lot of unbillable time to make this change to the contrib module, and then go back to all of our client projects and hook in to translate the "sign up" strings back to "registration" strings. Our estimate for supporting this change across the half-dozen sites where we're using this module (as well as its redhen_crm_registrations counter-part) is ~40-50 hours. Moreover, from our perspective, the term "sign-up" is less professional in the vertical market we're serving, so the change presents a risk to us for getting future projects in the "nonprofit event registration" space.

We're a six person shop that invests 30 hours a week on contributed code. We're stretched thin. We're doing our best to provide the community with a tool that we needed for our own work. Strictly speaking, we're within Drupal's namespacing policy. I know that the name is less than ideal from your perspective, but I'd really like to punt on this - unless you can help us find financial sponsorship from a larger organization (say, Acquia ;) ).

If you find the language confusing for projects that you are working on - you could always release your own helper module that replaces the "registration" strings so that they meet your needs.

Thanks for understanding. Again, we're scraping together to abstract a contrib module from the client work that feeds us. We'd hate to potentially lose the opportunity to partner with you, but we need to respectfully say no to this request. We also need to move forward with code and gently put this thread to rest.

Again, I'm not trying to be rude in any way. It's awesome that you and Ezra and Acquia are investing time into considering this module for COD - but we need to jump back into code and push forward.

Cheers,
Sean Larkin
ThinkShout, Inc.

Finally, greggles, I don't want to close this ticket on you after the last time that we did that hurriedly. However, at this point, Lev and I do feel that this warrants a "won't fix." Do you mind closing this ticket once you've had time to digest?

Okay, one last post - because Lev and I really do feel bad saying "no" to you two.

As I mentioned, we're trying to build an enterprise-worthy event registration solution in Drupal 7.x, one that will hook into RedHen CRM to provide a larger enterprise-worthy "association management solution."

If you google "event sign up", you'll see that the vast majority of the enterprise tools that we're trying to compete with use "event registration" as their terminology. Most of these solutions do the SEO thing to capture searches for "event sign-ups", but then their own language refers to "event registrations."

To build an open source solution that can compete, this is an issue for us.

Again, thanks for hearing us out. I would like to close out this discussion. Not trying to have the last word, I just want you all to understand that we definitely hear your concern. We've thought about it a lot. But we need to pass on the request.

Thanks,
Sean

30 hours for a 6 person shop is a great achievement, so congrats on that.

Ultimately it comes down to people who need something doing the work. If this doesn't match your needs it makes sense you can't prioritize it and that's justification enough. If I remember correctly signup does (or did) provide an admin setting to let folks change the label on the button for the signup form so it's understandable that there's not a single perspective on how to do this now.

I've changed the title/category/status to reflect where I think this stands now: people are likely to want to change this text so the module should make it easy (even if that just means confirming everything is translatable and providing a set of string overrides that can be used) and it's postponed until someone has time to work on it.

Thanks!

Now that is actually a great idea. Currently, if you set the registration field to display as a link, it presents the link as the human-readable name for the registration entity bundle. For client projects, I've just been implementing hook_node_view() to change this text to "Register Now!" or the like.

Adding a UI for managing global registration settings would save us time on client projects.

I'm going to kick this to Lev. Then, maybe we can get someone from the issue queue community (@dpi - you know we love you, and we don't want to burn you out...) to work on this.

Thanks again, Greggles and Ezra for raising the issue, talking through it, and finding a solid compromise.

Non-developer puts hand up.

My feature request at http://drupal.org/node/1525104 also falls into the language category and is rather closely related I think.

Again many thanks to the dev team.

This is a great thread. There are now almost half a dozen requests for small form setting options for customizing registration links, capacity display, etc. I'm going to close this ticket out since the overall request is being addressed in a number of places.