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
