I think it depends on how ambitious your projects are.

If they're small scale and are unlikely to get used by the wider community, use whatever way you're happier with.

But if you're looking to get projects used by the wider community, you need to make it as easy as possible for other programmers and translators to work on your codebase.

This means going with I, and I would seriously consider using Locale::Maketext::Lexicon.

When writing your app, use localization function names (typically __ or x) to mark all strings that need i18n. You then run xgettext.pl to extract these strings to a .pot (Portable Object Template) file and that's the file used for creating .po files containing the translated strings.

Why all this hastle? PO files are pretty much the universal standard for translation files, and are used by most programming languages. There are many free and commercial tools for editing such files - check out kbabel if you run linux, and read the kbabel help to get a good introduction to how the whole thing works.

If you go with this suggestion, even if translators know little or nothing about your code, they still have the .pot file and can translate this without problem...almost!

Say you go with II, and have the key FILE_ERROR, what can the translator do with that?

Not a lot really, but if your key is:

"A file write error has occurred while trying to save %1.
Please check that device %2 is available and has 
enough free space to complete this action"
[download]

The translator knows exactly what you mean and can provide a good, accurate translation without having to look at the source code or contact you directly, and is far more likely to do the work rather than say stuff it, it's too much hastle!

Anyway, it's great to hear that you're going to i18n your app - I really hope perl coders start to consider this more often - modern open source apps that ignore i18n are doomed to fail, and rightly so IMHO.

Cheers, and hope this helps,
Rich