If I saw this behavior, the first thing I'd look at would be the contents of your data hash. The data hash has clearly been set up improperly if the value is a null string-- most likely you're accessing keys that aren't actually in the hash. In particular, this is a great opportunity for the data dumper:

use strict;
use Data::Dumper;

my %lang_dev;

# ...

print Dumper(\%lang_dev);
[download]

Incidently, if you want to dereference a hash reference and lookup a key at the same time, it's cleaner to write $hash_ref->{$key} although it's the same as ${$hash_ref}{$key}.

Watch out for the proper bracing with references though. The following code doesn't do what you think it does:
my @foo = @$hash_ref->{$key}
The @ will try to reference $hash_ref first, instead of decoding $hash_ref->{$key} into a reference-to-array. In such a situation, use braces to force context:
my @foo = @{$hash_ref->{$key}}
I only bring this up because the reference precedence rules have cause me heartache in the past. Is there a good formal rule for determining which decoding gets done when in situations like this? I just add extra braces when I don't know, but this could cause unnecessarily unreadable code.

-Ted

Originally posted as a Categorized Answer.