As I said you have more than one option. If my hypothesis is right. I would do the following:

1) Make sure hypothesis is right: If possible, call the code from a small test-script which calls the code a few 100.000 times and time that. Then use two testfiles: One with a few translation strings at the beginning of a long file, the other with the same translation strings at the end of the file. If the first file takes much longer then you can be pretty sure that runaway regex search is the culprit.

Another possibility would be to execute the code (either all or a extracted parts with a test script) with a newer perl version and use debugging features like "use re "debug";".

2) Change your programm to do the search and replace in a loop. If you call a regex with g parameter in scalar context, it only finds one occurence and stops, but it remembers where it left of (you can find out with pos() and change where it continues with pos() as well). What I would propose would be something like this:

my $result="";
while ($trans=m/__\('.*?[^\\']'|".*?[^\\"]"(?:,,?.*?[^'"])?\)/gis) {  
+#changed to remove the two capture parens 
    my $pos=pos();
    $result.= substr($_,0,$pos);
    my $translen= length($trans);
    my $transtext= substr($_,$pos,$translen);

    <here $transtext has your complete translation string. Do the subs
+titution on $transtext, you can use the code you already used or even
+ simplify it>

    $result.= $transtext;
    #remove the already translated part from $_
    substr($_, 0, $pos+$translen)='';
    #we reset search to begin at position 0 again
    pos()=0;
}
$_= $result . $_;
[download]

Untested code but this should theoretically work. It has to parse the translation string twice, so it will naturally be twice as slow as your original simple regex. But it should not bring your webserver to its knees.

Clarification update: "twice as slow" only applies to the parsing of the string, not to the complete regex execution. gettr() will still be called only once,