Я надеюсь, что этим постом получится пояснить во много ситуацию с неправильными или недостаточными переводами интерфейсов.

Как вариант, если тема свободного поиска и публикаций ошибок интересна, то логично развить идею до состояния, когда при нахождении ошибки члены сообщества связываются с авторами и рассказывают о том, что получилось в итоге (да, очень похоже на Bugtraq, но без клинов на безопасности). Это будет намного интереснее и полезнее для всех. И по меньшей мере, стоит задуматься о том, какую именно мыль вы хотите донести. Алексей Баранцев, например, делает это ввиде морали.

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

Возвращаясь к теме.

История первая. Однажды, в компании, которая создавала по настоящему отличное программное обеспечение для торговли, потребовалось сделать русскую локализацию. Хотя компания была иностранной, но в ней были и русскоговорящие сотрудники. Одному из их, владевшему одинаково и русским и английским языками было поручено сделать переводы. В результате появился шедевр, который, слава богу, сначала попал в руки разработчиков и тестеров, а не на продакшн. В переводе можно было встретить вот такие фразы: Загрузите ошибку! (Upload error!), Спасите настольный шаблон (Save Desktop Template), Подчинитесь (Submit) и Цвета удара головой (Header colors).

История вторая. Дело происходило в начале нулевых, когда AJAX еще не появился, а о глобализации еще никто особо не задумывался. Одной офшорной команде пришел заказ на разработку web-ориентированной системы для мобильного контента. Готовую версию планировалось представить на специализированной выставке. Сроки на разработку оказались достаточно жесткими, но разработчики справились и за несколько дней до выставки предоставили готовый продукт. Всем всё понравилось, но поскольку выставка проходила в Японии, то потребовалась японская локализация — фактически делалась копия всей системы, но на другом языке. Единственной сложностью оказалось то, что количество текста в системе потребовало бы работы более двадцати переводчиков, чтобы успеть к сроку. Это было слишком дорого, да и найти переводчиков нужной квалификации в таком количестве не представлялось возможным. Для экономии времени решили перевести навигацию, основные документы и только те страницы, которые предполагались самыми популярными. В итоге на выставке был показан не полный, но достаточный вариант. Позже, когда проанализировали посещаемость сайта, оказалось, что английской версии достаточно и японская осталась незаконченной, хотя ею продолжали пользоваться.

История третья. Директор по разработке одной европейской компании, был очень прогрессивным человеком. В частности, он считал, что залог эффективности — это автоматизация. Поэтому автоматизировалось всё, что было возможно. От разработки и тестирования и до создания отчётности. При проектировании любой новой функциональность должен был рассматриваться вопрос автоматизации чего-нибудь. Система управления и распространения локализаций не стала исключением. Планировалось, что все продукты будут брать необходимые переводы из одного места. Сложные фразы предлагалось составлять из простых предложений. Для этого из общей базы по ключу выбирались отдельные фразы и составлялись в единое целое. Если нужной локализации не было, возвращалась фраза на английском языке, который был выбран основным. При первом запуске оказалось, что переводов катастрофически не хватает и локализации выглядят как лоскутное одеяло — мешанина локализованных и английских фраз.

В качестве заключения.

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