Re: DateTime::Locale::load
On Sat, Nov 20, 2010 at 8:09 PM, Dave Rolsky auta...@urth.org wrote: If there is a locale in DateTime::Locale for the id, then it will provide the same set of datetime localization information as any other locale. Does that answer your question? Yes. Thanks. -- Bill Moseley mose...@hank.org
DateTime::Locale::load
First, in load() there's this line: die Invalid locale name or id: $name\n; Can the newline be removed? It's not that hard to track down, but it would be nice to see where it's coming from. Second, is all locale information provided in the DateTime::Locale classes? I guess my question is if we start supporting more languages in our app is there other system-level language files that need to be updated other than just DateTime? (i.e. system locale packages). Thanks, -- Bill Moseley mose...@hank.org
Re: DateTime::Locale::load
Bill Moseley wrote:
Can the newline be removed? It's not that hard to track down, but it would
be nice to see where it's coming from.
A useful workaround:
use Carp ();
$SIG{__DIE__} = \Carp::croak;
-zefram
Re: DateTime::Locale::load
On Sat, 20 Nov 2010, Bill Moseley wrote: First, in load() there's this line: die Invalid locale name or id: $name\n; Can the newline be removed? It's not that hard to track down, but it would be nice to see where it's coming from. That might be better as a croak anyway. Second, is all locale information provided in the DateTime::Locale classes? I guess my question is if we start supporting more languages in our app is there other system-level language files that need to be updated other than just DateTime? (i.e. system locale packages). What is all locale information? If you mean everything in the CLDR project, no, it's not even close. In fact, it's not even all the datetime-related info in CLDR. I've been wanting to write a full Locale::CLDR module for a while, but my round tuits seem to have gotten lost in the mail. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: DateTime::Locale::load
On Sat, Nov 20, 2010 at 10:17 AM, Dave Rolsky auta...@urth.org wrote: That might be better as a croak anyway. Yes, probably. I have full backtrace on errors in the logs, but the error that gets emailed out is just the message. But, might be helpful for others. What is all locale information? If you mean everything in the CLDR project, no, it's not even close. In fact, it's not even all the datetime-related info in CLDR. I've been wanting to write a full Locale::CLDR module for a while, but my round tuits seem to have gotten lost in the mail. Sorry, I knew I asked the wrong question after sending. I realize my knowledge in this area is lacking... We use Locale::Maketext in a web application (with language classes like MyApp::I18N::en_us) and when a user selects a language a Locale::Maketext handle is created for the request. We also call DateTime-DefaultLocale( $tag ) to localize formatted dates. What happened was our translators added a new language file that didn't use the correct language code, so that's when we saw the Invalid locale name or id error. That was fixed by just renaming the language file so the correct code was used. At least it made DateTime not throw an error. But that made me wonder if there was anything additional required to support the new languages on the server -- or if the fact that DateTime didn't complain about the locale was enough. I.e. does our translation team need to notify the team that manages the servers when a new language is added. -- Bill Moseley mose...@hank.org
Re: DateTime::Locale::load
On Sat, 20 Nov 2010, Bill Moseley wrote: We use Locale::Maketext in a web application (with language classes like MyApp::I18N::en_us) and when a user selects a language a Locale::Maketext handle is created for the request. We also call DateTime-DefaultLocale( $tag ) to localize formatted dates. What happened was our translators added a new language file that didn't use the correct language code, so that's when we saw the Invalid locale name or id error. That was fixed by just renaming the language file so the correct code was used. At least it made DateTime not throw an error. But that made me wonder if there was anything additional required to support the new languages on the server -- or if the fact that DateTime didn't complain about the locale was enough. I.e. does our translation team need to notify the team that manages the servers when a new language is added. If there is a locale in DateTime::Locale for the id, then it will provide the same set of datetime localization information as any other locale. Does that answer your question? -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
