Description: ------------ IMO having the country names hardcoded in Validate_Finance_IBAN is not good practice. The user should instead be advised to use I18Nv2_Country instead. Related to that, why not $_iban_countrycode_countryname populate the array directly on the static declaration in _getCountrycodeCountryname(), the isset() section is too much. This method is to basically create a class static property. In the same vein, why again making it static in validate, there's not much to gain, just clutters the code. Also some minor PEAR CS, such as missing spaces around = signs, or after some , commas.

added a patch for the Coding Standards issues. I would imagine the reason why I18Nv2_Country isn't being used, is that not every country has/supports IBAN values; having a distinct array here rather than reusing I18Nv2_Country is probably in part to prevent false positives from being detected; ie prevents a fake IBAN value from being determined to be valid.

For the moment adding some code-improvements from kguest's patch. I'll want to discuss the "long-lines" codingstyle-things with him though. About the country-codes: Haven't yet made a final decision on that. You are right that I18Nv2_Country might be a good idea - but using that inside the lib now would add an "unneeded" dependency. And removing it altogether would "needlessly" break BC (although the package is alpha, I know). But maybe we can discuss that part in more detail via email, Philippe, if you agree? For the moment I'll leave the bug open to track your yet unfullfilled suggestion to use I18Nv2_Country.

Since I18Nv2 is deprecated, it might be worthwile to also see whether using the intl-package from PHP might be an option. Available in several installation as a module or even bundled. 1) using PEAR::I18Nv2 require_once 'I18Nv2/Country.php'; $country = new I18Nv2_Country(); $country->setLanguage('de'); echo $country->getName('fr'); 2) using PHP-Module php-intl echo Locale::getDisplayRegion('sl-Latn-fr', 'de');