Как справиться с задачей проверки локализованных строк не разработчиком?

В .NET Framework локализованные строки находятся в файле XML (или нескольких файлах). Эти файлы являются частью проекта и передаются в систему контроля версий, как и любой другой файл исходного кода. Обычно Visual Studio используется для отображения этих файлов в виде таблицы и редактирования локализованных строк.

Я работаю в небольшой команде над продуктом, который должен иметь многоязычный интерфейс.

1. Как разработчик, я черновую локализованные строки на обоих языках, учитывая, что перевод может быть неточным,

2. Другой человек из группы (не являющийся разработчиком) просматривает контент на обоих языках и исправляет его при необходимости.

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

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

Что делать?

Как это происходит в других командах?

Локализация намного сложнее, чем просто редактирование XML в Visual Studio, а именно:

1. Хотя то, что говорит KateGregory, является правильным, Visual Studio стоит дорого, и покупка копий для локализаторов часто непозволительна.
2. Если локализатор также не является разработчиком, они не могут видеть строки в продукте и проверять, правильно ли отображаются строки (неевропейские символы, такие как азиатские языки, или текст справа налево, например, арабский), правильно подгонять / переносить (длинный немецкий слова) и не вызывают инъекционных атак (таких как использование апострофами французов)
3. Хотя контроль версий не является сложным инструментом, предоставление доступа к управлению источниками удаленным или контрактным локализаторам является риском. Они могут копировать исходный код без ведома команды или фиксировать критические изменения (преднамеренно или непреднамеренно).
4. Также предполагается, что единственное, что вы локализуете, - это файлы RESX. Некоторые продукты могут иметь локализованные данные, такие как имена отчетов.

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

Редактирование XML отстой. Visual Studio имеет представление, которое вы можете использовать для редактирования ресурсов:

Я думаю, что проверка на редактирование в сочетании с минутой демонстрации окна «ожидающие изменения» должны позволить вашему не-разработчику использовать столько исходного контроля, сколько им нужно.

Я хотел бы найти XML-редактор * для не-разработчика для использования.

Затем вам нужно будет предоставить версионные выдержки не-разработчику для проверки.

Как только они закончат с обзором, вы можете проверить файл обратно.

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

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

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

Одним из вариантов является создание вспомогательного приложения, в котором переводчик может видеть список строк на одной панели и вводить язык, специфичный для другой. Таким образом, данные сохраняются обратно в XML, и тогда вы можете заставить это приложение экспортировать файл.

Если вы обработаете ключи в базе данных и сохраните там каждый язык, это позволит интегрировать изменения, а переводчик увидит, что нужно обновить. Затем вы можете просто экспортировать в языковой файл XML, который вы вернули в систему контроля версий, или переводчик.

Мы используем метод, аналогичный этому, с нашим кодом Rails, мы никогда не редактируем и даже не предоставляем файлы для конкретного языка, все они поддерживаются и затем экспортируются внешним приложением, используемым нашей командой переводчиков. Извините, я не знаю, является ли их программное обеспечение нестандартным или готовым, но не должно быть так сложно собрать что-то простое.

Откуда вы знаете, что у вас есть все строки и что они правильно отформатированы в приложении? Откуда вы знаете, что числа, валюта, часовой пояс и другая информация о локали правильно отформатированы? Что все загружено и многобайтовая сериализация работает нормально?

Нет. Локализация это особенность, как и любая другая. Проверьте это. Сделайте сборку. Позвольте тестеру получить сборку и убедиться, что функция выполнена правильно, как и любая другая. Когда вы делаете новую сборку, вы делаете регрессионное тестирование на локализацию - как и любая другая функция.