Интернационализация настольного приложения через пару лет ... Что нам теперь делать?

Question

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

Я полагаю, другими словами, есть ли какая-то интернационализация, которая сейчас проста, но может быть намного хуже, если мы позволим основанию кода взрослеть, и это не сильно замедлит нас, если мы решим начать делать это сейчас?

Используемые технологии: C #, WPF, WinForms

Answer 1

Подготовьте его сейчас, прежде чем писать все строки в самой кодовой базе.

Все после будет слишком поздно. Сейчас или никогда!

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

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

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

1. Приложения для развивающихся стран

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

Маленький экстракт:

1. Переместите все локализуемые ресурсы в отдельные библиотеки только для ресурсов. Локализуемые ресурсы включают элементы пользовательского интерфейса, такие как строки, сообщения об ошибках, диалоговые окна, меню и ресурсы встроенных объектов. (Перемещение ресурсов в DLL впоследствии будет проблемой)
2. Не жестко кодировать строки или ресурсы пользовательского интерфейса. (Если вы не подготовитесь, вы знаете, что будете жестко кодировать строки)
3. Не помещайте нелокализуемые ресурсы в библиотеки только для ресурсов. Это вызывает путаницу у переводчиков.
4. Не используйте составные строки, которые создаются во время выполнения из объединенных фраз. Составные строки трудно локализовать, потому что они часто принимают английский грамматический порядок, который не распространяется на все языки. (После проектирования интерфейса изменение фраз становится все труднее)
5. Избегайте неоднозначных конструкций, таких как «Пустая папка», где строки могут переводиться по-разному в зависимости от грамматических ролей компонентов строк. Например, «пустой» может быть как глаголом, так и прилагательным, и это может привести к различным переводам в таких языках, как итальянский или французский. (тот же выпуск)
6. Избегайте использования изображений и значков, содержащих текст, в вашем приложении. Их дорого локализовать. (использовать текст поверх изображения)
7. Оставьте достаточно места для длины строк, которые можно расширить в пользовательском интерфейсе. В некоторых языках фразы могут занимать на 50-75 процентов больше места. (та же проблема, если вы не планируете это сейчас, редизайн дороже)
8. Используйте класс System.Resources.ResourceManager для извлечения ресурсов на основе культуры.
9. Используйте Microsoft Visual Studio .NET для создания диалоговых окон Windows Forms, чтобы их можно было локализовать с помощью редактора ресурсов Windows Forms (Winres.exe). Не кодируйте диалоговые окна Windows Forms вручную.

Answer 2

ИМХО, утверждать, что что-то произойдет "через несколько лет", буквально переводится как "мы надеемся, что однажды", что на самом деле означает "никогда". Хотя я бы все же просмотрел различные уроки, чтобы убедиться, что вы не делаете никаких ужасных ошибок. Правильная поддержка интернационализации сейчас будет означать меньше работы в будущем, и как только вы к ней привыкнете, это не окажет реального влияния на сегодняшнюю производительность. Но если вы можете измерить цель в годах, возможно, сейчас это вообще не стоит делать.

Я работал над двумя проектами, которые выполняли интернационализацию: приложение C # ASP.NET (существовавшее до того, как я присоединился к проекту) и приложение PHP (самодельный собственный метод, использующий бесплатный контроль интернационализации и мое собственное приложение управления).

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

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

Я бы просмотрел документы MS на эту тему: http://www.microsoft.com/globaldev/getwr/dotneti18n.mspx

Некоторые основные вещи, которых следует избегать:

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

Answer 3

Я добавлю, чтобы хранить и манипулировать строковыми данными как Unicode (NVARCHAR в MS SQL).

Answer 4

Вы можете использовать NGettext.Wpf (его можно установить из NuGet, и да, я автор, но я сделал это из разочарований, перечисленных в других ответах).

Он размещен в этом репозитории github , и вот начальный раздел на момент написания:

NGettext.Wpf предназначен для работы с внедрением зависимостей. Вам необходимо позвонить по следующему пункту подачи заявления:

NGettext.Wpf.CompositionRoot.Compose("ExampleDomainName");

Строка "ExampleDomainName" - это имя домена. Это означает, что когда текущая культура установлена ​​на "da-DK", переводы будут загружаться с "Locale\da-DK\LC_MESSAGES\ExampleDomainName.mo" относительно того, где работает ваше приложение WPF (вы должны включить файлы .mo в ваше приложение и убедиться, что они скопированы в выходной каталог ).

Теперь вы можете сделать что-то подобное в XAML:

<Button CommandParameter="en-US" 
        Command="{StaticResource ChangeCultureCommand}" 
        Content="{wpf:Gettext English}" />

Что демонстрирует две особенности этой библиотеки. Наиболее важным является расширение разметки Gettext, которое гарантирует, что Content настроен на перевод «английский» по отношению к текущей культуре, и обновит его при изменении текущей культуры. Другая особенность, которую он демонстрирует, - ChangeCultureCommand, которая изменяет текущую культуру на данную культуру, в данном случае "en-US".

Я также настоятельно рекомендую прочитать Подготовка строк из руководства по утилитам gettext.

Answer 5

Некоторые вопросы к думаю о…

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

Будете ли вы продолжать торговать, если не получите денежный поток от быстрой доставки английской версии?

Каким образом вы получите правильный интерфейс, если не получите отзывов быстро от некоторых клиентов об этом?

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

Хотите ли вы, клиенты из Англии, иметь возможность настраивать строки в пользовательском интерфейсе, например, не все называют «накладной» одно и то же.

Поскольку большая часть усилий по интернационализации заключается в том, что вы не нарушаете английскую версию, лучше ли инвестировать в автоматизированное тестирование системы пользовательского интерфейса?

Единственное, что я всегда буду делать, это: «Не используйте составные строки, которые создаются во время выполнения из объединенных фраз» и, если вы это сделаете, не распространяйте код, который создает до одной строки по множеству методов.

Автоматическое изменение размера (и макета) пользовательского интерфейса в зависимости от длины меток и т. Д. Сэкономит вам много времени на протяжении многих лет, если вы сможете сделать это дешево. Существует множество сторонних наборов элементов управления для Windows Forms, которые позволяют помечать текстовые поля и т. Д. Без необходимости надписывать ярлыки как отдельные элементы управления.

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

Answer 6

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

1. Поддержка международных символов - используйте только типы данных Unicode в файлах и базах данных.
2. Поддержка международных форматов даты, времени и чисел - используйте CultureInfo.InvariantCulture при хранении данных в файловом или машиночитаемом хранилище, используйте CultureInfo.CurrentCulture при отображении данных или парсинге пользовательского ввода, никогда не выполняйте собственный анализ, никогда не используйте другие объекты культуры .
3. текстовые данные, введенные пользователем, должны рассматриваться как черный ящик, не пытайтесь разбивать их на слова или буквы, особенно при отображении их пользователю - на разных языках действуют разные правила и ОС знает, как отображать слева. к правильному тексту.

Локализация - это перевод программного обеспечения на разные языки, это сложно и дорого, хорошее начало - никогда не создавать жесткие строки кода и никогда не создавать предложения из более мелких строк.

Answer 7

Если вы используете тестовые данные, используйте неанглийские (например, русские, польские, норвежские и т. Д.) Строки. Кодирование заглядывает, это маленькая уродливая голова на каждом углу. Если не в ваших собственных библиотеках, то во внешних.

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