Интернационализация позже действительно дороже?
Большинство людей согласятся с тем, что интернационализация существующего приложения обходится дороже, чем разработка интернационализированного приложения с нуля.
Это действительно так? Или когда вы пишете интернационализированное приложение с нуля, стоимость I18N просто амортизируется из-за нескольких небольших заданий, и никто не чувствует на себе всю тяжесть задачи интернационализации?
Вы даже можете утверждать, что у зрелого приложения есть много и много LOC, которые были удалены в течение истории проекта, и что они не должны быть I18Ned, если интернационализация сделана как запоздалая мысль, но были бы I18N, если проект был интернационализирован с самого начала.
Как вы думаете, проект, начинающийся сегодня, должен быть интернационализирован, или это решение может быть перенесено в будущее на основе успеха (или нет) программного обеспечения и географического распределения спроса.
Я не говорю о способности манипулировать данными Unicode. Это у вас бесплатно на большинстве основных языков, баз данных и библиотек. Я говорю конкретно о поддержке пользовательского интерфейса вашего программного обеспечения на нескольких языках и в разных регионах.
10 ответов
"Когда вы пишете интернационализированное приложение с нуля, стоимость I18N… амортизируется"
Однако это еще не все.
Обратно отслеживать каждое сообщение для пользователей - в некоторых случаях - невозможно.
Не трудно. Невозможно.
Учти это.
theMessage = "Some initial part" + some_function() + "some following part";
У вас будет ужасное время на поиски всех подобных ситуаций. В конце концов, some_function просто возвращает строку. Вы не знаете, является ли это ключом базы данных (никогда не показывается человеку) или сообщением, которое необходимо перевести. И когда он переведен, грамматические правила могут показать, что объединение строк из трех частей было глупой идеей.
Вы не можете просто выполнить GREP для каждой функции со строковым значением, поскольку она содержит возможное сообщение I18N, которое необходимо перевести. Вы должны фактически прочитать код и, возможно, переписать функцию.
Понятно, когда some_function В этом есть какая-то сложность, вы озадачены тем, почему одна часть вашего приложения все еще на шведском языке, в то время как остальная часть была успешно переведена на другие языки. (В частности, не для шведов, замените его любым языком, используемым для разработки, отличным от окончательного развертывания.)
Хуже, конечно, если вы работаете в C или C++, у вас может быть некоторая разница между макросами препроцессора и правильным синтаксисом языка C.
А на динамическом языке - где код может быть построен на лету - вы будете парализованы дизайном, в котором вы не можете точно идентифицировать весь код. Хотя динамическая генерация кода является плохой идеей, она также делает вашу обратную работу I18N невозможной.
Я собираюсь не согласиться с тем, что добавить его в существующее приложение дороже, чем с нуля с новым.
- Большую часть времени i18n не требуется, пока приложение не станет "большим". Когда вы добьетесь больших успехов, у вас будет большая команда разработчиков, чтобы посвятить себя i18n, так что это будет меньше нагрузки.
- Возможно, вам это и не нужно. Многие небольшие команды прилагают большие усилия для поддержки интернационализации, когда у вас нет клиентов, которые в ней нуждаются.
- После того, как вы интернационализировались, дополнительные изменения занимают больше времени. Это не займет много дополнительного времени, но каждый раз, когда вам нужно добавить строку в продукт, вам нужно сначала добавить ее в комплект, а затем добавить ссылку. Нет, это не много работы, но это усилие и занимает немного времени.
Я предпочитаю "переходить этот мост, когда мы к нему придем" и интернационализироваться только тогда, когда его ищет платящий клиент.
Да, интернационализация существующего приложения определенно обходится дороже, чем разработка интернационализированного приложения с самого первого дня. И это почти никогда не бывает тривиальным.
Например
Message = "Do you want to load the " & fileType() & " file?"
не может быть интернационализирован без каких-либо изменений кода, потому что многие языки имеют грамматические правила, такие как гендерное соглашение. Вам часто нужна другая строка сообщения для загрузки всех возможных типов файлов, в отличие от английского, когда можно собрать вместе подстроки.
Есть много других проблем, таких как это: вам нужно больше места для пользовательского интерфейса, потому что некоторым языкам нужно больше символов, чем английскому, чтобы выразить ту же концепцию, вам нужны большие шрифты для Восточной Азии, вам нужно использовать локализованные дату / время в пользовательском интерфейсе, но, возможно, английский США при связи с базами данных, вам нужно использовать точку с запятой в качестве разделителя для файлов CSV, сравнения строк и сортировки культурные, номера телефонов и адреса...
Так как вы думаете, проект, начинающийся сегодня, должен быть интернационализирован, или это решение может быть отложено на будущее на основе успеха (или нет) программного обеспечения и географического распределения спроса?
Это зависит Насколько вероятно, что конкретный проект будет интернационализирован? Насколько важно быстро получить первую версию?
Если вы действительно думаете, что получаете "обработку юникода" "бесплатно", у вас может возникнуть сюрприз, когда вы попробуете.
Если вы не используете платформу, которая доказала способность i18n за пределами языков с ANSI или очень похожими наборами символов, вы обнаружите несколько проблем и более серьезных проблем, когда обработка юникода не совсем правильна или просто недоступна. Даже с относительно распространенными языками (например, немецким) вы можете столкнуться с трудностями при сокращении или увеличении количества букв и API, которые не поддерживают юникод.
А потом подумайте о языках с разным порядком чтения!
Это одна из причин, по которой вы должны действительно планировать это с самого начала и проверять материал на предмет разрушения на множестве языков, которые вы планируете поддерживать.
И не забывайте, что изменение базы данных базы данных для поддержки интернационализированных данных также может быть дорогостоящим. Просто попробуйте изменить это поле varchar на nvarchar, когда у вас уже есть 20000000 записей.
Я думаю, что это зависит от языка. Каждое j2ee(java web) приложение - это i18n, потому что оно очень простое (даже IDE может извлекать строки для вас, а вы просто называете их).
В j2ee дешевле добавить его позже, однако культура заключается в том, чтобы добавить их как можно скорее. Я думаю, потому что j2ee использует много open-source и почти все библиотеки с открытым исходным кодом i18n. это отличная идея для них, но не для большинства приложений j2ee. большинство корпоративных приложений предназначены только для одной компании, говорящей на одном языке.
Кроме того, если у вас есть плохие тестеры, слишком быстрое их размещение заставляет их сообщать об ошибках, связанных с ярлыками и переводами(я только один раз видел переводы, сделанные НЕ разработчиками). После того, как тестеры покончат с этим, у вас будет глючное приложение с отличной поддержкой i18n. Однако пользователям может быть интересно поменять язык и посмотреть, смогут ли они его использовать. Однако использование вашего приложения для них просто скучная работа, так что они даже этого не сделают. Единственными пользователями i18n являются тестеры.
Странное соединение строк не в культуре j2ee, так как вы знаете, что однажды кто-то захочет сделать это i18n. Единственная проблема заключается в извлечении меток из HTML-шаблонов.
Это зависит от вашего проекта и от того, как организована ваша команда.
Я принимал участие в интернационализации веб-сайта, и это был один разработчик, работающий полный рабочий день в течение года, вероятно, около 6-8 месяцев, занятых неполный рабочий день для меня, чтобы справиться с последствиями установки при необходимости (реорганизация файлов и т. Д.) И другими разработчики вовлекаются время от времени, когда их проекты требуют серьезного рефакторинга. Это было в приложении, которое было на v3.
Так что это определенно дорого. Вы должны спросить, насколько дорого стоит обеспечение системы локализации с самого начала, и как это повлияет на проект на ранних стадиях. Ваш проект в v1, возможно, не сможет пережить задержки и неудачи, вызванные проблемами со спешно разработанной структурой интернационализации, в то время как стабильный проект v3 с широкой клиентской базой может иметь капитал, чтобы инвестировать в это правильно.
Это также зависит от того, хотите ли вы интернационализировать все, в том числе сообщения журнала или только строки пользовательского интерфейса, а также количество этих строк пользовательского интерфейса, кого у вас есть для выполнения локализации и обеспечения качества, сопровождающего ее, и даже какие языки. вы хотите поддерживать - например, должна ли ваша система поддерживать строки Unicode (что является обязательным требованием для азиатских языков).
Концепция i18n и l10n шире, чем просто перевод строк на некоторые языки.
Пример: рассмотрим ввод даты и времени пользователями. Если вы не имеете в виду интернационализации при разработке
а) интерфейс для пользователя и
б) механизм хранения, поиска и отображения
вы получите действительно плохое время, когда захотите включить другие схемы ввода.
Согласитесь, в большинстве случаев i18n не нужен в первую очередь. Но, и это моя точка зрения, если вы не будете думать о некоторых областях, которые должны быть затронуты для i18n, вы обнаружите, что в конечном итоге переписываете большие части исходного кода. И потом, добавление i18n намного дороже, чем потратить некоторое время на предварительные размышления.
Одна вещь, которая кажется большой проблемой, - это разные символы для сообщения на разных языках. Я немного работаю над приложениями для iPhone, особенно на маленьком экране, если вы создаете пользовательский интерфейс для сообщения длиной 10 символов, а затем пытаетесь выполнить интернационализацию позже и обнаружите, что вам нужно 20 символов для отображения того же, что и сейчас, чтобы переделать свой пользовательский интерфейс. разместить. Даже с настольными приложениями это может быть большой PITA.
Я не могу сказать, что это дорого, но я могу сказать вам, что чистый API позволяет интернационализировать ваше приложение по очень низкой цене.