На нашем сайте asp.net мы поддерживаем несколько языков.
Текущий рабочий процесс перевода выглядит следующим образом:
- Сайт создается с "языком разработчика"
- Переводы хранятся в базе данных и используют пользовательский поставщик
- В определенный момент переводчики devcycle получают экстракт (совместимый с Excel XML) БД для работы на
- Заполненный файл принимается командой разработчиков и конвертируется (автоматически) в скрипт sql
Преимущества:
- Переводчикам не нужно работать с недружественными к переводчику инструментами
- У них есть простой обзор всех литералов
- Язык разработки легко различим благодаря ведущему символу '_', позволяющему обнаружить непереведенные литералы
- Сценарии Sql можно повторно развертывать и обновлять
Недостатки:
- Переводчики не имеют представления о том, как их переводы будут выглядеть в приложении
- Переводы часто переворачивают макет из-за проблем с длиной (например: русский, как правило, более многословен, чем английский)
- Трудно передать контекст
- Переводы, добавленные после извлечения файла, трудно отследить и приводят к ошибкам
- Распределенные переводчики + Excel (XML) делают для синхронизации и конфликтов слияния
Я пытаюсь найти лучший способ общения с переводчиками.
Существующий инструмент предпочтительнее, чем реализованный в доме.
Предоставление переводчикам рабочего взгляда на их работу имеет высокий приоритет.
Управление версиями файлов переводов должно улучшиться.
Мы надеялись, что Excel Excel будет версионным, но сравнение и объединение практически невозможно.
Предоставление переводчикам Visual Studio для работы с файлами resx не вариант.