Also Gettext zu verwenden würde ja die reinste Abhängigkeitshölle losbrechen. Da gefallen mir die anderen Lösungen besser.

Die Idee mit den eigenen Modulen je nach Sprache hatte ich auch schon, allerdings spricht folgendes dagegen:
- Ein möglicher Übersetzer müsste Perl-Code schreiben. Und selbst wenn dieser Übersetzer ich selbst wäre, würde mir das ein ungutes Gefühl geben, weil man bei Code schnell mal was falsch tippt. Bei einem simplen Text-Format ist das Risiko geringer.
- Um herauszufinden, welche Sprachen vorhanden sind, muss ich doch wieder auf Datei-Operationen zurückgreifen. Und darauf bin ich angewiesen, weil ich es ermöglichen will, dass die Sprache anhand des Locales ermittelt wird. Wenn die Sprache des aktuellen Locales nicht vorhanden ist, soll auf den Default englisch geschaltet werden. (Second thought: Natürlich kann man einfach per eval probieren, ob es zu einem Ladefehler kommt. Wenn man allerdings jemals eine Liste der vorhanden Sprachen generieren will, steht man wieder vor dem gleichen Problem.)
- Wenn ich ohne Datei-Operationen auskommen will, muss ich jedes neue Modul per use oder require in irgendeine Sammelklasse laden, was es unpassend schwer macht, neue Sprachen hinzuzufügen.

Dieser ganze Automatismus mit Locales und dynamisch ermittelten Dateien ist natürlich nicht immer erwünscht, aber wenn der User keinen Stress will und für ihn verständliche Fehlermeldungen, dann soll das auch funktionieren.

Ich finde es übrigens sehr interessant, wie du die import-Routine verwendest, um die Sprache an das Msg-Modul zu übergeben.

Das konfigurierbare Verzeichnis ist zwar eine flexible Lösung, aber wegen der nötigen Installation nicht akzeptabel für mich. Davon abgesehen kriege ich ein mulmiges Gefühl, wenn eine so grundsätzliche Sache wie ein Fehlertext so dynamisch ermittelt wird. In meinem inneren Auge sehe ich ein Programm, das mein Modul verwendet, schon ausgeben: "Fehler! Bitte geben Sie den Pfad für den Fehler an, den ich Ihnen hier anzeigen müsste."

Man kann sich wirklich darüber streiten, ob Fehlermeldungen mehrsprachig sein müssen. Evtl. können sie auch gar nicht als Text vorliegen, sondern als Nummern, die in der Dokumentation erklärt werden. So ist es bei meinen Modulen erstmal auch, allerdings will ich eben auch eine Schnittstelle zur Verfügung stellen, die im Bedarfsfall einen perfekten Fehlertext generieren kann.

Daher ist %INC für mich die perfekte Lösung: Simpel aber flexibel und ohne Extra-Preis. Hätte ich in meinem klugen Perl-Buch nicht immer wie gebannt auf @INC gestarrt und die Augen ein bisschen nach oben wandern lassen, wäre mir die Idee auch früher gekommen. ;)

Wie wäre es mit einem Modul -- sagen wir mal "ModuleFileDirectory" -- das anhand des Callers herausfindet, welches Modul eine Anfrage stellt und dann Operationen für die Dateien dieses Modules zur Verfügung stellt? Zu diabolisch? 8)