Правильное «размещение» данных локали в консольном Javascript приложении

0

1

есть абстрактное консольное приложение написанное на Javascript которое может исполнятся только в чем-то похожем на node.js. Сие приложение имеет локализацию. аппликуху писали не бородатые дядьки а хипстота и потому локализация хранится не в .po файлах а в как хеш в js файле. см пример ниже

some_i18n_lib.addDictionary("en_us", {
    'some_key': 'string shown to user'
    ...
});

так дело обстоит в репе. при сборке все собирается в один файл. и кодируется в cp1251 (такие были требования. не спрашивайте почему). сейчас требования изменились и кому-то захотелось unicode. так вот, теперь настойчиво рекоммендуют следующую схему: результат сборки остается в cp1251 а локали нужно держать как

внешний текстовый файл в UNICODE содержащий строковые данные

говорят что так удобнее. на вопрос сделать возможность кодировать результирующий файл в unicode говорят что «не видят острой необходимости».

собственно вопрос: а как по вашему более правильно, удобно и надежно (для конечного пользователя) нужно делать: все в 1 unicode файл или программа отдельно, локали отдельно?

Ссылка

←	Самый быстрый способ увидеть картинку (битмэп)?

Большой террайн в Cryengine

→

У меня вообще покомпонентно всё сгруппировано, иначе задолбишься потом определать, провис перевод после убирания кода или нет.

Локали отдельно, каждая в своем ямловском файлике.

Вообще мне кажется ты неправильно вопрос задаешь. Правильный вопрос - как ты это потом будешь автоматизировать, чтобы юзать вебсайтеги для переводов. Ну напишешь скриптов, делов-то. Делай так как удобнее.

Сколько там фраз? Если в пределах сотни то вообще по барабану как делать.

PS. Минутка рекламы. https://github.com/nodeca/babelfish/ - удобный i18n от скромного русского умельца. С макросами для плюралов и т.п.

Vit ★★★★★
(27.01.15 00:35:51 MSK)

Ответ на: комментарий от Vit 27.01.15 00:35:51 MSK

У меня вообще покомпонентно всё сгруппировано, иначе задолбишься потом определать, провис перевод после убирания кода или нет.

у меня компоненты не имеют своих «переводов», но тем не менее хеш с локализированными строками не плоский а многоуровневый

Локали отдельно, каждая в своем ямловском файлике.

почему ямль? локали всегда отдельно? они как-то еще потом дополнительно модифицируются? склеиваются?

как-то не хочу тащить в проект ямль только ради локалей. кроме того в JS есть JSON который из коробки делает тоже самое (ну почти).

Вообще мне кажется ты неправильно вопрос задаешь. Правильный вопрос - как ты это потом будешь автоматизировать, чтобы юзать вебсайтеги для переводов. Ну напишешь скриптов, делов-то. Делай так как удобнее.
Сколько там фраз? Если в пределах сотни то вообще по барабану как делать.
PS. Минутка рекламы. https://github.com/nodeca/babelfish/ - удобный i18n от скромного русского умельца. С макросами для плюралов и т.п.

тема с выбором либы для локализации висит внизу страницы (и ты в ней так же советовал babelfish :) ). в итоге я выбрал либу которой я не доволен. и переход предстоит на чтото другое. но точно не сейчас. ибо время релиза итак затянулось. потому вопрос с автоматизацией, переводами и тп немного не в тему.

сейчас стоит следующий вопрос «как лучше»: все клеить или поставлять отдельно и считывать с фс помощью местных аналогов? у меня сейчас 1й вар-т и мне нравится то что пользователь получает 1 файл и его больше ничего не беспокоит..

// есть две локали: русская (полная, 114 строк; используется как основная) и английская (статус - мусор).

ZuBB ★★★★★
(27.01.15 11:19:24 MSK) автор топика
Последнее исправление: ZuBB 27.01.15 11:20:43 MSK (всего исправлений: 2)

Тебе нужен ключ побольше и каска. Без каски не сработает. А потом ты знаешь что делать.

anonymous
(27.01.15 17:54:02 MSK)

Ссылка

Ответ на: комментарий от ZuBB 27.01.15 11:19:24 MSK

почему ямль?

Вкусовщина. Потому что напрягать мозг над расстановкой запятых и кавычек ни у меня ни у моих программистов желания нет. Предпочитаем думать над более интересными вещами.

локали всегда отдельно? они как-то еще потом дополнительно

модифицируются? склеиваются?

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

как-то не хочу тащить в проект ямль только ради локалей. кроме того в JS есть JSON который из коробки делает тоже самое (ну почти).

сейчас стоит следующий вопрос «как лучше»: все клеить или поставлять отдельно и считывать с фс помощью местных аналогов? у меня сейчас 1й вар-т и мне нравится то что пользователь получает 1 файл и его больше ничего не беспокоит..

Делай так, как удобнее тебе лично. Я описал, как удобнее для меня на моем конкретном проекте :)

При твоих размерах переводов на оптимизации можно забить болт.

Для оценки размеров - берешь все файлы переводов и сжимаешь gzip-ом.

// есть две локали: русская (полная, 114 строк; используется как основная) и английская (статус - мусор).

На таком количестве сильно загоняться по поводу расположения переводов смысла нет. Они вторичны, и сильно зависят от общей архитектуры. Хоть в один файл слепи.

Vit ★★★★★
(27.01.15 20:34:44 MSK)