Usually you have a lot of codes which are just abreviations, so you have tables with "code" "description", and you may use "code" where is not enough space for full description. In multi-language design, you want to avoid that, because code in one language might not mean anything (or worse, is common-sence widely-used abreviation for something else) in another language.
In example, we were developing loan servicing system, and used 2 and 3-letter codes for different statuses, i.e. "BK" was "loan is in bankruptcy". And sure we were checking for hardcoded status in our code. When faced with need to port this to italian, we could not. Database was able to display language dependent fields and labels, but not codes. We had to train users and added feature to display all current statuses with relevant description. Which is not bad even for native englich users;)

Every string what ever you might to display on user-friendly screen needs to have ID, code (short abreviation meaningfull in user language) and description. In your programs you'll use ID instead of code. In my case mentioned earlier, we might want to use 'bk' as ID, and "BK" as english code for bankruptcy.

And back to perl, you can create functions using global $user_language returning proper code and description for each ID, so implementation details will be hidded to your scripts.
HTH

pmas
To make errors is human. But to make million errors per second, you need a computer.