Нужен совет опытного флешера по мультиязычности.

[Wolsh]

Мне такая схема кажется избыточной и недостаточно гибкой.
Гораздо приятней выглядит хранение локализаций в отдельных языковых файлах и один мастер-файл со списком существующих локализаций.
+ Маленький вес языковых файлов.
+ Меньше памяти съедается в рантайме.
+ Структура проста и красива.
+ Поддержка проста и удобна.
Вместо

<string id="str_id" ru="текст" en="text" sp="texto" />

будет

<str_id>текст</str_id>

Не нужно хранить совершенно ненужную информацию.
Не нужно устраивать динамический разбор присутствующих атрибутов или проверку их наличия; вообще как-то возиться с этой динамикой. Всегда есть только одно конкретное значение текста. При смене языка просто загружается новый файл и все значения заменяются.
По поводу размеров — больная тема)) Раньше у Адоба в русской версии Фотошопа были широченные панели, очень неприятно закрывавшие все поле действия, так что редактируя стиль какого-то слоя, ты не видел результатов, потому что окно редактирования стиля закрывало всю рабочую область)) В английской версии всё было компактненько. Недавно посмотрел CS6, в котором локализация меняется просто выбором языка в настройках. Даже при выборе английского панели все-равно остаются широкими, как для русского. Это ад.

[Партизан]

Сообщение от Wolsh

Гораздо приятней выглядит хранение локализаций в отдельных языковых файлах и один мастер-файл со списком существующих локализаций.

Не всегда так удобно. В моей схеме упор сделан на моментальную смену языка интерфейса в рантайме. Времени грузить нужный файл локализации нет. Хранить три файла в памяти считаю сомнительной выгодой. И поскольку строка по уникальному id возвращается, с целью уменьшения ошибок, считаю, лучше оставить id уникальным, не более чем в одном экземпляре.

[expl]

Недавно посмотрел CS6, в котором локализация меняется просто выбором языка в настройках. Даже при выборе английского панели все-равно остаются широкими, как для русского. Это ад.

Ну если уж Adobe на это забила, то куда уж нам, простым смертным.
Хотя, можно в паре критических окошек/панелей подписаться на событие изменения локализации и перевалидировать размер по этому событию.

[Wolsh]

Времени грузить нужный файл локализации нет.

Не верю. Это не игровое действие в RTS. Пользователь подсознательно готов подождать 2-3 секунды "перевода", потому что это "подготовительный" процесс, а не основное его действие по использованию приложения.

Хранить три файла в памяти считаю сомнительной выгодой.

Не предлагал.

лучше оставить id уникальным

Никто не заставляет Вас называть теги одинаково. Как раз предлагается избавиться от мультициклов поиска по XMLList'ам, ограничившись простым и быстрым доступом к XML.

[iNils]

Сообщение от Партизан

Не всегда так удобно. В моей схеме упор сделан на моментальную смену языка интерфейса в рантайме. Времени грузить нужный файл локализации нет.

Смена языка довольно специфичная операция, чтобы для этого не было времени на загрузку)

Хотите еще частный случай? Бывает, что часть переводов не готова и вместо них используется дефолтный язык. Но переводы делаются. И когда приложение открыто сутками (не все браузеры закрывают и машину могут в спящий режим отправлять, то есть перегрузки приложение), при смене языке можно обновить перевод, если версии не совпадают.

А вообще, речь идет об оптимальном варианте, а не о единичном. У вас в примере 3 языка, а попробуйте 35 языков и не 20-50 слов, а 1000 слов или готовых фраз и предложений.

[searinox]

Всем спасибо. Очень интересные варианты как у Wolsh так и у Партизана, но изначально я использовал подход, который потом предложил Wolsh, и пока более или менее доволен. Еще раз спасибо за исчерпывающую информацию по этому вопросу.