Какие существуют стратегии для обеспечения того, чтобы все операции с учетом локали выполнялись правильно во всех локали?
Отчасти из-за необходимости я разрабатываю программное обеспечение с моим языковым стандартом, установленным на "C" или "en_US". Трудно использовать другой язык, потому что я говорю только на одном языке с чем-то даже отдаленно приближающимся к беглости.
В результате я часто не замечаю различия в поведении, которые могут быть вызваны разными настройками локали. Неудивительно, что игнорирование этих различий иногда приводит к ошибкам, которые обнаруживает только какой-то неудачливый пользователь, использующий другой языковой стандарт.В особо тяжелых случаях этот пользователь может даже не говорить со мной на каком-либо языке, что усложняет процесс сообщения об ошибке. И, , что важно , большая часть моего программного обеспечения имеет форму библиотек; хотя почти ни один из них не устанавливает языковой стандарт, он может быть объединен с другой библиотекой или использоваться в приложении, которое устанавливает поведение, генерирующее языковой стандарт, которого я никогда не испытывал сам.
Чтобы быть более конкретным, типы ошибок, которые я имею в виду, не связаны с отсутствием локализации текста или ошибками в коде для использования этих локализаций. Вместо этого я имею в виду ошибки, при которых языковой стандарт изменяет результат работы некоторого API, учитывающего языковой стандарт (например, toupper (3) ), когда код, использующий этот API, не ожидал возможности такого изменения (например, в турецком языке toupper не изменяет «i» на «I» - потенциально проблема для сетевого сервера, пытающегося передать конкретный сетевой протокол другому хосту).
Несколько примеров таких ошибок в программном обеспечении, которое я поддерживаю:
- AttributeError в турецком языковом стандарте
- imap использует языковой стандарт C для форматирования даты
- Исправление для форматирования даты, зависящего от языкового стандарта, в imap и conch
В прошлом один из подходов, который я использовал для решения этой проблемы, - это написать регрессионные тесты, которые явно меняют языковой стандарт на тот, где известно, что код не работает, проверяют код, проверяют правильное поведение, а затем восстанавливают исходный языковой стандарт. Это работает достаточно хорошо, но только после того, как кто-то сообщил об ошибке, и охватывает только одну небольшую область кодовой базы.
Другой подход, который кажется возможным, состоит в том, чтобы настроить систему непрерывной интеграции (CIS) для запуска полного набора тестов в среде с другим набором локалей. Это несколько улучшает ситуацию, обеспечивая такое же покрытие в этой альтернативной локали, какое обычно дает набор тестов. Другой недостаток состоит в том, что существует много, много, много локалей, и каждая из них может вызывать разные проблемы. На практике, вероятно, существует только дюжина или около того различных способов, которыми локаль может нарушить работу программы, но наличие десятков дополнительных конфигураций тестирования требует больших ресурсов (особенно для проекта, который уже расширяет свои ограничения ресурсов путем тестирования на разных платформах, с другой библиотекой). версии и т. д.).
Другой подход, который пришел мне в голову, - использовать (возможно, сначала создать) новый языковой стандарт, который радикально отличается от языкового стандарта "C" во всех отношениях - иметь другое сопоставление регистра, использовать другой разделитель тысяч, формат по-разному датируется и т. д. Этот языковой стандарт можно использовать с одной дополнительной конфигурацией CIS, и мы надеемся, что он будет использоваться для обнаружения любых ошибок в коде, которые могут быть вызваны любым языковым стандартом.
Существует ли уже такая среда тестирования? Есть ли недостатки в этой идее тестирования на совместимость языковых стандартов?
Какие другие подходы к тестированию языковых стандартов использовали люди?
Меня в первую очередь интересуют локали POSIX, поскольку это те, о которых я знаю. Однако я знаю, что в Windows также есть некоторые похожие функции, поэтому дополнительная информация (возможно, с дополнительной справочной информацией о том, как эти функции работают), возможно, также может быть полезна.