Улучшение рабочего процесса как для переводчиков, так и для разработчиков

На нашем веб-сайте asp.net мы поддерживаем несколько языков. Текущий рабочий процесс перевода выглядит следующим образом:

  • Сайт создается с использованием «языка разработчика»
  • Переводы хранятся в базе данных и используют настраиваемый поставщик.
  • В определенный момент в цикле разработки переводчики получают отрывок (совместимый с Excel xml ) БД для работы над
  • Заполненный файл получает команда разработчиков и конвертируется (автоматически) в sql-скрипт

Преимущества:

  • Переводчикам не нужно работать с недружественными для переводчика инструментами
  • У них есть простой обзор всех литералов
  • Язык разработчика легко отличить из-за начального символа '_', который позволяет обнаружить непереведенные литералы.
  • Скрипты Sql повторно развертываются и поддерживают версии

Недостатки:

  • Переводчики не имеют представления о том, как их переводы будут выглядеть в приложении.
  • Переводы часто теряют верстку из-за проблем с длиной (например: русский язык, как правило, более подробный, чем английский)
  • Трудно передать контекст
  • Переводы добавлены после файл извлечения трудно отследить и ведет к mi stakes
  • Распределенные переводчики + excel (xml) make для разрешения конфликтов синхронизации и слияния

Я пытаюсь найти лучший способ общения с переводчиками.
Существующий инструмент будет предпочтительнее того, что реализовано внутри компании.
Предоставление переводчикам рабочего обзора своей работы имеет высокий приоритет.
Должно улучшиться управление версиями файлов переводов.
Мы надеялись, что файлы Excel xml будут поддерживать версии, но сравнение и объединение практически невозможно.
Предоставление переводчикам Visual Studio для работы с файлами resx не вариант.

10
задан Boris Callens 29 August 2011 в 09:33
поделиться