Ну тут я спорить не буду. Мне resx и локализация крупных проектов знакомы не понаслышке, посмотрите комментарии выше. Важно что вам в вашем проекте удобнее resx, а нам наш подход. Серебряной пули нет :-)
Идеальных решений не бывает. Бывают более или менее удачные, более удобные и менее :-) Согласитесь, что есть разница между простой правкой строки прямо в JS-коде и извлечением ключа в коде, поиском файла ресурса, затем поиском строки в нем по ключу, ее правкой и последующей перекомпиляцией и перезапуском проекта. Результат одинаков, а затраченное время разработчика и соответственно его продуктивность совершенно разные.
Такая схема на большом проекте будет чувствительна к человеческим ошибкам и не очень удобна. Надо добавить строку в ресурс в одном файле, потом ее заиспользовать совсем в другом при этом не ошибившись с ключом. Сам JS-код, особенно при большом количестве строк, становится не очень читаемым. Вместо понятных строк на английском — ключи ресурсов. Разработчику чтобы посмотреть реальный текст и возможно исправить его нужно лезть в ресурсы и искать соответствующую строку. Тот кто работал с большими файлами ресурсов в VS знает какой это адъ.
Схема рабочая, тут вопросов нет, но на мой взгляд сложноватая, хотя возможно в вашей ситуации с учетом «исторических причин» и самая оптимальная. У нас нет всех этих промежуточных шагов и все вопросы связанные с локализацией отделены от сборки проекта. Исправления в локализации и перевод новых строк можно делать фактически на лету. Мы вносим исправления и новые строки в staging-среду, а потом импортируем на продакшн. Все очень динамично и легко. Изменения сразу видны на сайте и их легко контролировать. В случае resx-файлов важная информация о контексте для переводчиков фактически недоступна (кроме ключа ресурса).
Также наш подход позволяет организовать и поддерживать переводы на различные языки силами сообщества поскольку для добавления нового языка кроме его самого и английского знать больше ничего не надо. Все происходит в визуальном, удобном интерфейсе.
Я думаю что мы просто тестовый проект выложим в публичный доступ, чтобы желающие могли попробовать и сами почувствовать разницу.
Что-то в вашем варианте есть, более того с использованием нашей либо такой вариант очень легко реализовать если базовый язык рассматривать как нейтральный, а не английский к примеру.
Но нам пока хватает английского как базового, удобства перевешивают недостатки. В конечном итоге все определяется трудозатратами на начальный перевод и его дальнейшее сопровождение. Пока я считаю в нашем проекте баланс оптимальный.
Отвечать вопросом на вопрос не есть хороший тон :-) К тому же встречный вопрос не имеет отношения к оригинальному.
Написать конвертер можно в какой угодно формат. Вопрос только зачем? Объясните плиз по шагам как использовать resx-ресурсы для локализации JS-скриптов.
Я нежно люблю resx и знаю всю подноготную промышленной локализации :-) Все-таки много лет руководил разработкой продукта, который переведен на 7 языков, включая китайский, и содержит тысячи фраз для локализации. И надо признать, что для современных веб-проектов локализация через стандартные resx-ресурсы это полный геморрой и извращение. Текущие проекты требуют новых подходов и решений.
В нашей библиотеке реализован стандартный экспорт-импорт через JSON-файл. Очень удобно и для обмена переводами и для взаимодействия с переводчиками. Можно реализовать и поддержку банального CSV, с ним точно проблем не будет поскольку даже MS свои стандартные ресурсы выдает в CSV.
У нас система заточена на то, что переводимое слово или фраза сами по себе являются ключом. Это очень удобно при разработке. Не нужно вводить каких-то идентификаторов, запоминать их. Мы просто обрамляем все строки подлежащие локализации вызовом функции, как показано в примерах выше. При этом код остается хорошо читаемым и легко поддерживаемым. Добавление в ключ имени файла позволяет решить вопрос с коллизиями, а также позволило сделать удобный виджет для перевода с группировкой всех строк по папкам и файлам.
Проблема рефакторинга имеется, строки фактически нужно заново переводить, но этот процесс существенно облегчен автоматическими подсказками. Система сама предлагает вариант перевода для уже имеющихся слов или фраз. Фактически надо только мышкой прощелкивать строки.
Имя файла все-таки нужно. У нас базовый язык английский и зачастую бывает что одно и то же слово является и существительным и глаголом. В этом случае без контекста совсем не обойтись. Простой пример — это слово map, которое может означать «карта», а может «отобразить/привязать»
Вы серьезно предлагаете все скрипты и JS-шаблоны держать в ресурсах? Переводить их целиком? Как их потом поддерживать при изменениях и командной разработке? В нашем проекте тысячи строк в скриптах и шаблонах если что.
Проблема достаточно общая. Значительная часть кода в проекте это скрипты и JS-шаблоны, которые от серверного фреймворка никак не зависят. Действительно удобных инструментов локализации JS для разработчиков мы так и не нашли. Пришлось сделать свой. Будем признательны если подскажете альтернативы
Вы попробуйте наш подход, вам понравится :-)
Также наш подход позволяет организовать и поддерживать переводы на различные языки силами сообщества поскольку для добавления нового языка кроме его самого и английского знать больше ничего не надо. Все происходит в визуальном, удобном интерфейсе.
Я думаю что мы просто тестовый проект выложим в публичный доступ, чтобы желающие могли попробовать и сами почувствовать разницу.
Но нам пока хватает английского как базового, удобства перевешивают недостатки. В конечном итоге все определяется трудозатратами на начальный перевод и его дальнейшее сопровождение. Пока я считаю в нашем проекте баланс оптимальный.
Написать конвертер можно в какой угодно формат. Вопрос только зачем? Объясните плиз по шагам как использовать resx-ресурсы для локализации JS-скриптов.
В нашей библиотеке реализован стандартный экспорт-импорт через JSON-файл. Очень удобно и для обмена переводами и для взаимодействия с переводчиками. Можно реализовать и поддержку банального CSV, с ним точно проблем не будет поскольку даже MS свои стандартные ресурсы выдает в CSV.
Проблема рефакторинга имеется, строки фактически нужно заново переводить, но этот процесс существенно облегчен автоматическими подсказками. Система сама предлагает вариант перевода для уже имеющихся слов или фраз. Фактически надо только мышкой прощелкивать строки.