Интернационализация является позже действительно более дорогой? [закрытый]

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

• В большинстве случаев i18n не требуется, пока приложение не станет «большим». Когда вы станете крупнее, у вас, вероятно, будет большая команда разработчиков, которую нужно посвятить i18n, так что это будет меньше бремени.
• Возможно, вам это на самом деле не нужно. Многие небольшие команды прилагают большие усилия для поддержки интернационализации, когда у вас нет клиентов, которым это нужно.
• После интернационализации инкрементальные изменения требуют больше времени. Это не займет много времени, но каждый раз, когда вам нужно добавить строку к продукту, вам нужно сначала добавить ее в пакет, а затем добавить ссылку. Нет, это не так уж и много работы, но это требует усилий и времени.

Я предпочитаю «перейти этот мост, когда мы подойдем к нему» и выйти на международный уровень только тогда, когда у вас есть платный клиент, который это ищет.

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

Если вы не используете фреймворк, который доказал способность i18n работать не только с языками с ANSI или очень похожими наборами символов, вы обнаружите несколько недочетов и более серьезных проблем, когда обработка юникода будет не совсем правильной или просто недоступной. Даже в относительно распространенных языках (например, немецком) вы можете столкнуться с трудностями, связанными с уменьшением или увеличением количества букв и API, которые не поддерживают юникод.

А если вспомнить языки с разным порядком чтения!

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

Да, интернационализация существующего приложения определенно дороже , чем разработка приложения как интернационализированного с первого дня . И это почти никогда не бывает тривиальным.

Например,

Message = "Do you want to load the " & fileType() & " file?"

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

Есть много других проблем, подобных этой : вам нужно больше места в пользовательском интерфейсе, потому что некоторым языкам нужно больше символов, чем английскому, чтобы выразить ту же концепцию, вам нужны более крупные шрифты для Восточной Азии, вам нужно использовать локализованную дату / раз в пользовательском интерфейсе, но, возможно, английский США при взаимодействии с базами данных, вам нужно использовать точку с запятой в качестве разделителя для файлов CSV, сравнения строк и сортировка - культурные, номера телефонов и адреса ...

Как вы думаете, проект начиная с сегодня, должны быть интернационализированы, иначе это решение может быть отложено на будущее в зависимости от успеха (или неудачи) программного обеспечения и географического положения распределение спроса?

Зависит от . Насколько вероятно, что конкретный проект будет интернационализирован? Насколько важно быстро получить первую версию?

Я не могу сказать, что дорого, но могу сказать вам, что чистый API позволяет вам интернационализировать ваше приложение по очень низкой цене.

Я думаю, что это зависит от языка . Каждое приложение j2ee (java web) называется i18n, потому что это очень просто (даже IDE может извлекать строки для вас, и вы просто называете их).

В j2ee дешевле добавлять его позже , однако культура должна добавлять их как можно скорее. Я думаю, это потому, что j2ee использует много open-source библиотек, и почти все open-source библиотеки i18n. это отличная идея для них, но не для большинства приложений j2ee. большинство корпоративных приложений предназначены только для одной компании, говорящей на одном языке .

Кроме того, если у вас есть плохих тестировщиков , если вы поставите его слишком рано, они будут сообщать вам отчеты об ошибках с метками и переводами (я только однажды видел переводы, выполненные НЕ разработчиками). После того, как тестеры закончили с ним, у вас будет глючное приложение с отличной поддержкой i18n. Однако пользователям может быть интересно переключить язык и посмотреть, смогут ли они его использовать. Однако использование вашего приложения для них просто скучная работа, поэтому они даже этого не сделают. Единственными пользователями i18n являются тестировщики .

Странное соединение строк не в культуре j2ee, так как вы знаете, что однажды кто-то может захотеть сделать это i18n. Единственная проблема - извлечение ярлыков из шаблонов html.

Концепция i18n и l10n шире, чем просто перевод строк на некоторые языки.

Пример: рассмотрим ввод даты и времени пользователями. Если вы не имеете в виду интернационализацию, когда разрабатываете

a) интерфейс для пользователя и

b) механизм хранения, поиска и отображения

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

Согласен, в большинстве случаев i18n вообще не нужен. Но, и это моя точка зрения, если вы не будете думать о некоторых областях, которые необходимо затронуть для i18n, вы обнаружите, что в конечном итоге переписываете большие части исходного кода. Кроме того, добавление i18n намного дороже, чем предварительные размышления.

Одна вещь, которая, похоже, может стать большой проблемой, - это разное количество символов для сообщения на разных языках. Я работаю над приложениями для iPhone, и особенно на маленьком экране, если вы разрабатываете пользовательский интерфейс для сообщения, состоящего из 10 символов, а затем пытаетесь сделать интернационализацию и обнаруживаете, что вам нужно 20 символов для отображения того же самого, вам приходится переделывать свой пользовательский интерфейс, чтобы приспособиться к этому. Даже в настольных приложениях это может стать большой проблемой.

Это зависит от вашего проекта и того, как организована ваша команда.

Я участвовал в интернационализации веб-сайта, и это был один разработчик на полный рабочий день в течение года, возможно, около 6-8 месяцев на неполный рабочий день для меня, чтобы справиться с последствиями установки, когда это было необходимо (реорганизация файлов и т.д.), и другие разработчики подключались время от времени, когда их проекты нуждались в серьезном рефакторинге. Это было в приложении, которое находилось на уровне v3.

Так что это определенно дорого. Вы должны спросить, насколько дорого обойдется создание системы локализации с самого начала, и как это повлияет на проект на ранних стадиях. Ваш проект v1 может не выдержать задержек и неудач, вызванных проблемами с наспех разработанной системой интернационализации, в то время как стабильный проект v3 с широкой клиентской базой может иметь капитал, чтобы инвестировать в это должным образом.

Это также зависит от того, хотите ли вы интернационализировать все, включая сообщения журнала, или только строки пользовательского интерфейса, и сколько этих строк пользовательского интерфейса, и кто у вас есть для выполнения локализации и QA, который идет с этим, и даже какие языки вы хотите поддерживать - например, должна ли ваша система поддерживать строки unicode (что является требованием для азиатских языков).

И не забывайте, что изменение серверной части базы данных для поддержки интернационализированных данных также может быть дорогостоящим. Просто попробуйте изменить это поле varchar на nvarchar, когда у вас уже есть 20 000 000 записей.