Was ich dabei an Locale::Maketext schätze, ist, dass man HTML aus den Sprachdateien raushält und stattdessen eine output-Funktion nutzt, also quasi (nicht unbedingt so, bin zu faul nachzuschauen):
"Weitere Informationen finden Sie bei [output,url,_1,_2]" und dann _1 als URL und _2 als Name des Links, was dann, wenn man im html-kontext ist, zu <a href="_1">_2</a> wird, aber, wenn man im console/plaintext-kontext ist, zu _2 <_1> o.ä. wird.

Das finde ich grundsätzlich toll, weil es die Abstraktion bringt, z.B. in Emails für HTML- und Textbodys die selben Bausteine nutzen zu können. Das selbe funktioniert auch mit strong und noch ein paar Sachen.

Wie Du nutze ich auch lieber messageids statt Sätzen in der Ausgangssprache, aber das kann man ja auch abbilden.

Das erledigt auch den Übersetzungskontext, den Locale::TextDomain dabei vorsieht, weil "view" bspw einem "Ansicht" und einmal "anschauen" heißen kann. Da kann man dann einen Kontext mitgeben, anhand dessen entschieden wird.

Für Locale::TextDomain spricht wiederum, dass es standard gettext-Dateien sind, man sie also mit jeder Menge Tools bearbeiten kann.

Hach, alles so kompliziert. Vielleicht hack ich einfach das setlocale aus L::TD raus und dafür Funktionsaufrufe rein. mmmmh mhhh.