localization/internationalization support generally runs unter the name L10N and I18N. Under Linux the gnu library gettext provides functions to translate strings from one language into other languages through a pregenerated database

In perl the library can be accessed through Locale::gettext for example. Another approach would be Locale::Maketext, the reasons for this more programmatic approach are detailed in Locale::Maketext::TPJ13

If you are lucky and have only fixed strings you could pregenerate the templates after any change to the templates, but normally you would have to add the translate step to your templating

PS: There is HTML::Template::Compiled::Plugin::I18N

UDPATE: You migh also want to read http://rassie.org/archives/247 for a critique of the Maketext approach

UPDATE: As dsheroh rightly commented it should be L10N, not I10N

Just a minor correction: Shouldn't that be "L10N" for "localization"?

And, since I'm here, I suppose I'll also throw in NLS (National/Native Language Support) and g11n (globalization) as other possible names for it.

I second the Locale::Maketext suggestion. I can also add that you really should:

1. Separate your strings and your source files. Keep the strings in a separate file.
2. Use Unicode everywhere. Save your source files, your template files and your strings files as Unicode. Make it UTF-8, unless you have a very good reason to use any other representation. see perlunicode.
3. Even though it's a good idea to save your source files as UTF-8, it's even more important to keep your strings separately - and in UTF-8. I'm repeating myself, but it WILL save you a lot of trouble.

(Edit: spelling.)

Please take a look at http://rassie.org/archives/247, it explains the flaw with the quant approach.

Thanks a lot. A very interesting read. I never bothered to look beyond Maketext.