in reply to Re: Planning ahead for product name changes
in thread Planning ahead for product name changes

I'm astounded by how much text, usually English, typically appears in code. The most common is seldom issued error messages that are, for whatever reason, presented to the end user.

I started noticing the same thing in my own code and specifically wrote an object class to let me centralize the management of error and similar messages, including ones containing run-time content, like this:
  print $error_messages->file_open_failed($input_file);

You don't actually have to define a file_open_failed object method; that's syntactic sugar that AUTOLOAD turns into the conceptual equivalent of print $error_messages->construct_message('file_open_failed', 'myfile');.

In my case the issue wasn't I18N as much as wanting to have consistent messages across a sprawling code base, and keep them in a single place for easier documentation -- but the basic issue is not dissimilar.

I've made the module available here; sorry for the off-site link, but I haven't yet gotten around to CPANning it. Feedback is welcomed!

As for things like the name of a program, I sometimes consider that a candidate for use constant..., though unfortunately that doesn't help if you need to change the name in documentation and other collateral. Even macro expansion or search-and-replace isn't perfect, because if you're not careful your documentation may contain phrases like "a FooBar report may contain Bazzes", which after transforming, say, {FooBar => AlphaBar and Baz => Blarg} can become something rather convoluted like "a AlphaBar report may contain Blargzes".