This module really fills an annoying gap, and therefore 4 stars. It's also well documented and easy to use. But ...
Data files in a Perl distribution always make me frown. Why do you parse a file LL.dat from a Perl module? Turn them into Perl modules themselves, and let the Perl interpreter do the job. It can do it a lot better, faster, and additionally - with a nice, perlish interface - your users would have it a lot easier to extend your module.
Why do you read "INCDIR/Locale/Country/Multilingual/LL.dat" yourself, but not simply "require Locale::Counry::Multilingual::LL". That has several big advantages (apart from being faster and perlisher):
- People can add more languages by simply placing a language module somewhere in @INC. Currently they have to place that in a directory, where they maybe don't have write access.
- People can override translations for a particular language.
- With a minor internal change it is also possible to override one particular translation. I would actually turn all the data into subroutines. The translation for country "cn" in language "bg" would then be retrieved by a call to Locale::Country::Multilingual::bg::cn(), and if you want to override that, you just override that particular method.
With that change, you can also elegantly solve the problem with country-specific translations. The module Locale::Country::Multilingual::ll_CC would simply have to inherit from Locale::Country::Multilingual::ll, and override only those few methods, where it is needed, instead of redefining the entire data.
An internal change like that described above would then suggest an alternative API: You could turn the module into a mere factory class for the translator objects. These translator objects all inherit from a base class that handles the nasty I/O aspects (utf-8 flag ...), and the users would invoke the methods like CA(), GB(), and so on themselves.
Implementation that falls back to a default language? No problem. Define an additional import flag, where you can define base language(s). In presence of this flags, the translator objects created by the factory simply inherit from the translator for that language (by fiddling with @INC, no problem), and voilÃ ! you get a translator that gives you a country name for country CC in the selected language, or falls back to some default language.
The only thing that becomes tricky is to get a list of the countries that a particular translator knows translations for, but even that is feasible and not an important feature anyway.
The author is well-aware, that a similar module Crypt::TEA (uppercase!) already existed on CPAN when he uploaded the module. The similarity isn't the problem, but on case-insensitive or case-preserving file systems, the two modules will conflict. Since this violates a fundamental CPAN law, the overall rating cannot be higher than 1.
The embedded documentation is wrong! It documents functions that are not exported, others are exported but not documented. Furthermore, no license information is given.
As far as the interface is concerned, I cannot see a reason why non-standard asciify-functions should be exported at all.
The test script does not follow the conventions used for CPAN modules.
A custom installer (the file "Install") may be a nice exercise for Perl beginners but is rather a waste of space than a helper. By convention, files named "INSTALL" contain installation information, not an install script.
Apart from that, the module is probably usable, but it violates a lot of unwritten and written conventions for CPAN modules, hence the bad rating.
1) Rename the module to "Crypt::TEA_PP" (following the general convention in the Crypt:: namespace).
2) Implement the complete interface required by Crypt::CBC (i. e. make it compatible with Crypt::TEA).
4) Add the test suite from Crypt::TEA to the module. A standard and exhaustive test suite gives the user a much better feeling with cryptographic modules, because of issues like endianness or integer sizes.