Ну а что ты туда можешь ещё получить, если ты сам написал этот текст? Выведи туда лучше err.message или
err.getStackTrace()
От этого будет больше пользы. По крайней мере узнаешь, что на самом деле провоцирует ошибку.

Скорее всего ты что-то не то передаешь в метод getXML(). Что выдает этот трейс? trace (file.nativePath);





п.с.

..если ты загружаешь одним файлстримом один единственный файл.. так будет точнее.

Да. Но здесь как раз такой случай.

Пожалуй опишу свое видение сабжа...
Обычно создаю один файл с несколькими локалями, с примерной структурой типа: или вроде того, чтобы id прописывать только раз. Это дает некоторые плюсы: загрузка только одного файла, сложно перепутать id, можно менять интерфейс в рантайме, удобно видеть все версии переводов в одном месте под одним id.
Для удобства я написал пару классов которые отвечают за локализацию:
1. Отвечает за глобальную поддержку локали (хранит переменную текущей локали, при смене генерирует событие смены языка, видим глобально)
2. Транслятор. Отвечает за смену интефейса и отдает нужную строку в зависимости от глобальной локали.
3. Event локали.

Самый важный компонент - это Транслятор, именно через него проходят все строки... Так же он хранит в себе все, что нужно поменять в интерфейсе в данный момент. Реализовано это примерно так: Чтобы вывести строку в textfield, я предварительно регистрирую этот textfield у транслятора и если в рантайме происходит смена языка и этот зарегистрированный textfield находится в списке отображения, его свойство text меняется на текст соответствующей локали. Впрочем, вместо texfield может быть любой объект DisplayObject с любым именем свойства. Так же можно запросить строку определенного id с нужной локалью.
Собственно такая система решила большинство проблем с локализацией.

Загрузка только одного файла с одним языком чем-то отличается? А, ну да, он меньше весит, а надо же напихать туда сразу все сто языков.
А как его можно перепутать, разделив языки на файлы?
Можно менять интерфейс в рантайме, подгрузив другой язык и отправив событие изменения языка.
ИМХО, при добавлении новых языков ваш код станет нечитаем. Ладно когда языка всего 2, но в наше время этого мало.
Вообще не понимаю, зачем так делать.
Один раз написал XML для русского, потом Сохранить как, и перевёл на инглиш, потом сохранить как, и перевёл на немецкий. Удобно, красиво.

Чтобы "налету" сменить язык, он должен быть уже подгружен, это означает, что вам придется грузить сразу все локали или грузить нужную после смены языка пользователем, а это время. В зависимости от скорости доступа к файлу (тут нужно учесть откуда этот файл грузится, локально или удаленно и конечно скорость доступа к данным), нужно соблюсти баланс между обновлением интерфейса и условиями ТЗ заказчика. На моем опыте было не более трех-четырех языков в приложении. Конечно это не относится к сервисам worldwide типа. Я описал типичный расклад. В случае XML который я указал как пример, тут спорно по объему данных в случае локалей. Структура одного файла может быть компактней 20-ти и наоборот.

Перепутать id даже в трех файлах довольно легко... Переводчик мог просто запариться и перепутать id (он же гуманитарий скорее всего :) ) и вместо "Привет" на другом языке у вас может быть, к примеру, "Exit" Я привел упрощенный вид XML просто для понимания(хотя и в таком виде использую если точно знаю, что это конечный продукт который дальше меня не пойдет и развития не получит). Структура может быть изменена не нарушая концепции одного id. Благо у XML есть куча возможностей для этого, и все будет читаемо. Намеренно, конечно же, можно любой текст превратить в нечитаемый.
"Ты явно не бывал в Сингапуре..." (с) Pirates of the Caribbean :)

Не должен. Его можно так же "на лету" подгрузить. Собственно, обычно так и делают. Да и зачем может потребоваться смена языка на лету? Единственное, где я вижу в этом какой-то смысл - это языковое приложение типа разговорника или словаря.
А в теме, очевидно, речь идет об игре, для которой язык можно сразу установить равным языку устройства.
Для этого существуют тесты. Ошибки возможны всегда. И лучше не использовать такие непонятные ID, а использовать человекочитаемые строки, вместо них. Типа
Вероятность ошибки человека в таком случае, сводится к минимуму. Да и дебажить такой код зрительно будет гораздо проще.

п.с. Я тоже переводчик по образованию, но это не мешает мне быть программистом ;)

Так делают, когда не важно время обновления интерфейса.
На вскидку - навигаторы ТЦ, информационные киоски, анкетные, рекламные приложения...
Я лишь описал реализацию которая может быть полезна как по теме, так и в последующих проектах.
Зачем тогда собственноручно повышать вероятность этих ошибок? Допустим, есть 100 строк, и три языка. Это 100 id в трех файлах... Заметить ошибку перевода будет достаточно сложно, даже если просто перепутать id фразы, она с высокой вероятностью пройдет в продакшн. Куда проще сравнить три-четыре перевода под одним id
В таком случае ошибку заметить гораздо легче еще на этапе переводов, причем зачастую ее может заметить человек даже не владеющий языком. Это опять же ИМХО и возможно не универсально для абсолютно всех проектов, но мы же тут как раз и собираемся для обсуждения, а реализация остается на усмотрение каждого.

Навигаторы ТЦ и инфо киоски - это не персональное устройство, тут вообще другая сфера применения. Рекламные приложения вполне могут сразу адаптироваться к языку ОС или браузера, так же как и анкетные.
Что мешает открыть два блокнота / ide с одним и тем же текстом рядом, и точно так же сравнить?
Проверять вот таким образом даже 100 строк в трех языках, тоже совсем не камильфо. Если уж на то пошло, то гораздо лучшим вариантом будет сделать небольшую утилитку, которая будет брать по порядку ID и для каждого языка выводить все переводы на экран рядом, без лишних тегов. Но хранить все переводы в одном файле - плохо, особенно для мобильников. Подгрузка нового файла с переводом, с локального диска, даже на слабом устройстве займет несколько милисекунд. Для человека это будет мгновенно + лишнюю память жрать не будет.

Смена языка - это единоразовое действие, скорость обновления интерфейса при котором совершенно не должна быть важна.
К тому же, это загрузка текстового файла, она выполняется за доли секунды даже со слабейшим интернетом(может занять дольше, только если это мобильный инет)
Тут скорее надо переживать за скорость доставания данных из XML документа, которая при включении всех языков в один документ будет ниже.