Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.21.8

Bug #19816 Localization fails if translations contain unused internalnames
Submitted: 2013-02-11 01:50 UTC
From: adkorte Assigned: kguest
Status: Closed Package: Date_Holidays (version 0.21.8)
PHP Version: 5.3.21 OS: Linux
Roadmaps: 0.21.9    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 25 - 4 = ?

 
 [2013-02-11 01:50 UTC] adkorte (Arjen de Korte)
Description: ------------ If translation files contain internalnames that are not set every year with _addHoliday (because a holiday doesn't occur each year), after an initial call the second (and subsequent) calls to Date_Holidays::factory will fail. Two files that add an Example driver to demonstrate this are listed below: Date/Holidays/Driver/Example.php: -------- <?php class Date_Holidays_Driver_Example extends Date_Holidays_Driver { var $_driverName = 'Example'; function Date_Holidays_Driver_Example() { } function _buildHolidays() { $this->_addHoliday('newYearsDay', $this->_year . '-01-01', 'New Year\'s Day'); // $this->_addHoliday('newYearsEve', $this->_year . '-12-31', 'New Year\'s Eve'); if (Date_Holidays::errorsOccurred()) { return Date_Holidays::getErrorStack(); } return true; } function getISO3166Codes() { return array('nl', 'nld'); } } ?> data/Date_Holidays_Example/lang/Example/nl_NL.xml: -------- <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <driver-data> <holidays> <holiday> <internal-name>newYearsDay</internal-name> <translation>Nieuwjaarsdag</translation> </holiday> <holiday> <internal-name>newYearsEve</internal-name> <translation>Oudjaarsdag</translation> </holiday> </holidays> </driver-data> Test script: --------------- <?php require_once 'Date/Holidays.php'; Date_Holidays::staticSetProperty('DIE_ON_MISSING_LOCALE', false); for ($year = 2012; $year <= 2013; $year++) { $dh = Date_Holidays::factory('Example', $year, 'nl'); if (Date_Holidays::isError($dh)) { die('Factory was unable to produce driver-object for ' . $year); } $holiday = $dh->getHoliday('newYearsDay', 'nl'); print_r($holiday->toArray()); } ?> Expected result: ---------------- Array ( [internalName] => newYearsDay [title] => Nieuwjaarsdag [date] => Date Object ( [year] => 2012 [month] => 01 [day] => 01 [hour] => 0 [minute] => 0 [second] => 0 [partsecond] => 0 [tz] => Date_TimeZone Object ( [id] => UTC [longname] => Coordinated Universal Time [shortname] => UTC [hasdst] => [dstlongname] => Coordinated Universal Time [dstshortname] => UTC [offset] => 0 [default] => ) [getWeekdayAbbrnameLength] => 3 ) ) Array ( [internalName] => newYearsDay [title] => Nieuwjaarsdag [date] => Date Object ( [year] => 2013 [month] => 01 [day] => 01 [hour] => 0 [minute] => 0 [second] => 0 [partsecond] => 0 [tz] => Date_TimeZone Object ( [id] => UTC [longname] => Coordinated Universal Time [shortname] => UTC [hasdst] => [dstlongname] => Coordinated Universal Time [dstshortname] => UTC [offset] => 0 [default] => ) [getWeekdayAbbrnameLength] => 3 ) ) Actual result: -------------- Array ( [internalName] => newYearsDay [title] => Nieuwjaarsdag [date] => Date Object ( [year] => 2012 [month] => 01 [day] => 01 [hour] => 0 [minute] => 0 [second] => 0 [partsecond] => 0 [tz] => Date_TimeZone Object ( [id] => UTC [longname] => Coordinated Universal Time [shortname] => UTC [hasdst] => [dstlongname] => Coordinated Universal Time [dstshortname] => UTC [offset] => 0 [default] => ) [getWeekdayAbbrnameLength] => 3 ) ) Factory was unable to produce driver-object for 2013

Comments

 [2013-02-16 04:49 UTC] kguest (Ken Guest)
-Assigned To: +Assigned To: kguest
 [2013-02-16 04:58 UTC] kguest (Ken Guest)
-Status: Assigned +Status: Closed -Roadmap Versions: +Roadmap Versions: 0.21.9
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.