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

9

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

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

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

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

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

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

Что делать?

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

Арсений Мурзенко
источник
17
Я не верю, что контроль версий затруднен для разработчиков. У меня были графические дизайнеры, бизнес-аналитики, не-вычислительные инженеры, технические писатели и менеджеры, которые раньше использовали контроль версий. Вы пытались научить своего не-разработчика, как использовать контроль версий?
Томас Оуэнс
Почему бы не экспортировать / импортировать их как простой текстовый файл, чтобы рецензент мог работать в любом произвольном редакторе? Являются ли данные более сложными, чем простые пары ключ / значение?
Кевин Клайн
1
@kevincline Вы рискуете, что любой текстовый редактор не сможет прочитать символы UTF-8. В результате импорт изменений может быть катастрофой.
Адриан Дж. Морено
1
@iKnowKungFoo - Простое решение - выберите текстовый редактор, который МОЖЕТ читать символы UTF-8. Есть также много хороших редакторов XML и множество хороших инструментов, которые могут сравнивать XML-документы, такие как Beyond Compare.
Ramhound
Извините, мой вопрос был неоднозначным (я редактировал его сейчас), но файлы с локализованными строками редактируются в Visual Studio, которая отображает их в виде таблицы. Учитывая схему этих файлов, нет необходимости изменять XML вручную.
Арсений Мурзенко

Ответы:

6

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

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

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

Актон
источник
@KateGregory Извинения, если это звучало конфронтационно. Это не было предназначено. Сообщение отредактировано.
Актон
8

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

редактирование ресурсов

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

Кейт Грегори
источник
1

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

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

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

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

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

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


* Я использовал xml блокнот, и это терпимо, я подозреваю, что есть лучшие


источник
1

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

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

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

Билл Липер
источник
-1

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

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

Telastyn
источник
-1 Значит, вы хотите, чтобы специалист по языку был юзабилити-тестером? Лучше надеяться, что он не пропустит путь, а затем пропустит плохой перевод где-то из-за этого.
SoylentGray
@chad - Вы хотите нанять преданного парня только для проверки перевода строк? Тестеры родного языка никогда не будут работать в X локали. Проблем с локалью гораздо больше, чем простого перевода.
Теластин
Да, дело не в полной локализации, а в том, чтобы убедиться, что язык правильный.
SoylentGray