Як керувати завданням перегляду локалізованих рядків не розробником?

У .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-файли перед реєстрацією та надсилати оновлені вами розділи нерозробникам для ознайомлення. Оновлення - це те, чому потрібно тримати версії файлів рецензування.

Спроба використовувати Excel ускладнить все надзвичайно важко, оскільки різні інструменти для excel залишають бажати кращого. Ви також ризикуєте додатковими коментарями, що прокрадаються в зайві комірки в електронній таблиці. Ці коментарі потребують додаткового поводження з вашою стороною, щоб знову їх об'єднати.

У попередньому житті ми використовували досить подібний процес для ряду перекладів з боку зовнішніх організацій. Наші файли були по суті текстовими файлами з подібною, але різною формою, ніж XML. І у нас відбулися багато змін, поки файли були на огляді, тому я ціную задоволення від вашої ситуації.

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

Якщо ви обробляєте ключі в базі даних і зберігаєте там кожну мову, це дозволить інтегрувати зміни та перекладачеві побачити, що потребує оновлення. Тоді ви можете просто експортувати в специфічний для мови XML-файл, який ви повернете в контроль версій, або перекладач міг би.

Ми використовуємо подібний метод до нашого коду Rails, ми ніколи не редагуємо або навіть надаємо файли, що відповідають конкретній мові, всі вони підтримуються та експортуються зовнішньою програмою, яку використовує наша команда перекладу. Вибачте, я не знаю, чи є їх програмне забезпечення на замовлення чи поза поличкою, але складати щось просте разом не повинно.

Звідки ви знаєте, що у вас є всі рядки та що вони правильно відформатовані в додатку? Звідки ви знаєте, що цифри, валюта, часовий пояс та інша інформація про місцевість відформатована правильно? Що все завантажено і багатобайтова серіалізація справно працює?

Ні. Локалізація - це особливість, як і будь-яка інша. Перевірте це. Складіть збірку. Нехай тестер отримає збірку і переконається, що функція виконана правильно, як і будь-яка інша. Коли ви робите нову збірку, ви робите тест регресії локалізації - як і будь-яка інша функція.