Чи розвиваєтесь ви з локалізацією на увазі?

Працюючи над програмним проектом чи веб-сайтом, чи розвиваєтесь ви з локалізацією?

Під цим я маю на увазі напр

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

Що стосується проектів, над якими ви працюєте, вони входять у категорію «приємно мати» і дозволяють команді з локалізації переживати про інше, чи у вас є процес локалізації вбудований у ваш процес розробки? Мені цікаво почути, як розробники розглядають локалізацію загалом.

Я працюю у великій компанії Fortune 500, і ми завжди починаємо з локалізації. Наші проекти, як правило, тільки для США, але занадто багато разів за ці роки ми напишемо додаток для клієнта, і тоді хтось ще побачить це і скаже "ей, це було б приголомшливо для країни X". Тоді наступне, що ви знаєте, - ви переживаєте код, додаючи локалізацію. Насправді не потрібно більше часу, щоб створити додаток з ним з самого початку, тому ми це просто робимо. Плюс додатковою перевагою є те, що коли клієнт приходить до нас і просить, щоб його додаток було (вибираємо вашу мову), ми передаємо їм файл і кажемо їм перевести його (вибрати вашу мову), і ми закінчили .

Я думаю, що це було важливо 10 років тому. Останні технології вирішили проблему .

Я живу в країні, де є 3 національні мови , і лише одна з них є меншиною.

Щоб зрозуміти проблеми, які можуть виникнути через це, це як те, що західна частина США говорить (дуже) іншою мовою, ніж східна. Подумайте, що в центрі країни чисельність злиття населення, і тому ви повинні користуватися обома мовами всюди.

Наявність 4 мов у настільних додатках та веб-сайтах було і є дуже поширеним явищем (3 національні мови + англійська). Іноді це зобов’язання.

Мені було відомо про локалізацію, оскільки мене зумовило моє оточення. Так так, кілька років тому я переживав це.

Зараз я не дуже переймаюся локалізацією, оскільки останні інструменти IDE дозволяють дуже просто перетворити будь-який статичний додаток у повністю локалізований.

Інструменти, які я використовую у Visual Studio .NET:

• CodeRush , плагін Visual Studio, який дозволяє переміщувати жорстко закодовані тексти у файли ресурсів.
• Easy Localizer , витягніть мітки у файлі Excel, в який ви додаєте всю додаткову мову, а потім об'єднаєтесь у свої файли ресурсів.

Більшість моїх клієнтів потребують лише однієї мови, і фактично вказати цю одну мову. Тому ми не витрачаємо час на локалізацію програми. Однак це не означає, що ми можемо повністю ігнорувати інші мови. Тож ми дотримуємось основ:

• Використовуйте Unicode скрізь. Це 2k10, немає виправдання цього не робити.
• Дизайн для деякої еластичності в макеті. Навіть з усією англійською мовою різні шрифти мають дуже різні відбитки екрана в одному розмірі точки.
• Зберігайте функції програми / моделювання даних поза шаром подання

Особисто, коли потенційна мова локалізації принципово відрізняється від тієї, яку розробляв додаток, там відбувається набагато більше, ніж простий підбір тексту. Хоча заміна тексту допомагає та дозволить компанії порівняно раніше отримати "швидку та брудну" реалізацію на новому місці - це не вирішує принципових відмінностей у тому, як думають користувачі іншою мовою.

Я вивчав японську мову, і хоча можу вважати себе лише новачком з цієї мови, я знаю досить, що є деякі поняття, для яких немає прямого перекладу. Існують різні ідеї того, що робить щось корисне. Хоча основні основні поняття можуть бути подібними, але деталі дійсно мають значення для користувачів.

Для того, щоб по-справжньому відповідати потребам зовсім іншої культури, вам потрібно зовсім нове обличчя для вашої заявки. Ось чому поділ моделі / перегляду / контролера стає ще важливішим. Поки додаток функціонує однаково, частина перегляду може бути повністю замінена. Коли це станеться, хтось планує заплатити реальні гроші, щоб правильно вирішити проблему.

Ми зробили це за потребою: зараз націлені на клієнтів речі, все це зроблено з урахуванням i18n, оскільки ми розширили ринки збуту, а деякі внутрішні речі тепер доступні для i18n, тому працівники, які використовують це, не повинні розмовляти англійською.

Отже, ми робили це за потребою, як стартап.

Звучить, що люди докладають зусиль l10n досить легко. Особливо, використовуючи англійську мову як оригінальну мову, легко нехтувати тим фактом, що для інших мов зазвичай потрібно навіть 30-40% більше місця для тексту. Це вимагає від перекладачів використання скорочень, які не так легко зрозуміти, що, звичайно, погано для роботи користувачів.

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

Я пишу програми для Android, і локалізація досить прямо вперед за допомогою рядкових файлів у стилі Java. Майже нульові зусилля для повної інтернаціоналізації на всіх мовах Android.

Відповідь: Так. Хоча в середовищі, де я працюю (Python / Zope / Plone), згодом локалізувати рядки дуже просто, тому я пропускаю це, якщо це не є вимогою з самого початку.

Але я зберігаю текст у об’єктах unicode тощо.

Отже, так. Я переконуюсь, що мої програми досить легко локалізувати, і навіть якщо вони не локалізовані, вони працюватимуть у міжнародних умовах. Якщо цього не зробити, це помилка, оскільки необхідні зусилля невеликі, а користь велика.