Тестирование локализации, форматирование всех строк с XXXXX

Question

Мы пытаемся оптимизировать наше тестирование локализации.

Наша группа QA предложила специальный режим, чтобы все строки из ресурсов полностью содержались в X. Мы уже используем API LoadString и его реализацию MFC, поэтому это не должно быть серьезным препятствием.

Мой вопрос: как бы вы решили проблемы с форматированием?

Examples -

CString str ;
str . LoadString ( IDS_MYSTRING ) ;

where IDS_MYSTRING is "Hello World", should return "XXXXX XXXXX"
where IDS_MYSTRING is "Hello\nWorld", should return "XXXXX\nXXXXX"
where IDS_MYSTRING is "Hello%dWorld", should return "XXXXX%dXXXXX"
where IDS_MYSTRING is "Hello%.2fWorld", should return "XXXXX%.2fXXXXX"
where IDS_MYSTRING is "Hello%%World", should return "XXXXX%%XXXXX"

Таким образом, в итоге строка должна работать, если она используется в операторе printf или Format, она должна учитывать escape-символы.

Так что это вопрос чистого кода, C ++ / MFC,

CString ConvertStringToXXXX ( const CString& aSource ) 
{
   CString lResult = aSource ;

   // Insert your code here

   return lResult ;
}

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

приложение -L10NTEST

Answer 1

Если этот подход заключается в выделении отформатированных строк (или форматных последовательностей) в приложении (т. Е. Весь текст, отличный от XXXX), вы можете найти escape-последовательность (возможно, с помощью регулярных выражений) и вставить кавычки вокруг отформатированных (замещенных) значения,
например Some \ ntext -> Some [\ n] text

Вы получаете удобочитаемость (все строки, так как XXX может быть трудно использовать в приложении), а также обнаруживает нересурсные (жестко закодированные) строки.

Сказав это, если вы хотите обнаружить не загруженные ресурсом строки (жестко закодированные строки) вместо замены Xs, почему бы просто не поставить префикс строки? Вы легко сможете отличить загруженные ресурсом строки от жестко закодированных строк,
например. Некоторые \ ntext -> [EN] Некоторые \ ntext

Надеюсь, это поможет?

Answer 2

В этом вам может помочь функция псевдолокализации appTranslator : она изменяет непереведенные строки для использования диакритических знаков, расширения или сокращения текста и т. Д. Пока что тебе это не интересно. Интересно, что такие строки заключаются в скобки. Идея состояла в том, чтобы сделать более очевидным, что строка псевдо локализована. Вы можете использовать это, чтобы обнаружить, что строка на самом деле приходит из таблицы строк, а не из кода.

И, конечно же, поскольку псевдо-локализованная программа должна работать правильно, appTranslator сохраняет все средства форматирования (в том числе printf-подобные и FormatMessage-подобные форматеры) и специальные символы, такие как% или \ n. Что ты и ищешь.

Вам даже не придется изменять свой код: просто создайте «фиктивный» перевод. Под «пустышкой» я подразумеваю язык, на который вы не планируете переводить свое приложение. Установите языковые предпочтения вашего приложения на этот язык. Подождите, это еще лучше: ребята из QA могут сделать это самостоятельно. Они даже не должны беспокоить вас! : -)

Отказ от ответственности: я являюсь автором приложения Translator.

Редактировать: ответ на ваш комментарий: Рад, что вы уже используете appTranslator. Чтобы избежать проблем из-за диалогов или строк, отсутствующих в DLL-библиотеке L10N, вы можете просто перестроить библиотеки DLL (например, используя шаг после ссылки в вашем проекте VS). Процесс автоматически пересматривает исходный exe-файл и объединяет новые и измененные тексты во встроенных библиотеках ресурсов (не влияет на файл проекта appTranslator, в отличие от «Update Source»). Это помогает убедиться, что ваши библиотеки ресурсов всегда синхронизированы с вашим exe-файлом.

Answer 3

Я предпочитаю механизм, который мы использовали, когда я работал в Microsoft для псевдолокализации, который включал в себя установку скобок вокруг каждого локализованного ресурса. Ресурс => [-Resource-], например. Тогда вы всегда можете сказать, что у вас есть составная строка, и форматирование обычно не меняется, за исключением правил разрыва строки.

Мы также обычно делали некоторые расширения строк (добавляли различные символы вокруг исходной строки) и некоторые подстановки символов на основе словаря или рандомизации (конвертировали «o» в «ö»).

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

Answer 4

Мое окончательное решение заключалось в добавлении префикса к строке примерно так: * * [имя экземпляра ресурса] исходная строка ". Он работает очень хорошо, он показывает вероятные строки, которые не подходят, скажем, по-немецки.

Пример:

Исходная строка из appres.dll, «Мое приложение»

Новая строка из appres.dll, "* [appres] Мое приложение".

Спасибо за все предложения.

Answer 5

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

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

Answer 6

Вы можете применить здесь теорию компилятора и сгенерировать свой сканер и парсер, используя flex / bison (lex / yacc или любые другие инструменты). Вы можете определить \ w + как слово, которое может совпадать с "Hello" и "World" и т. Д.