Интернационализация настольных приложений в течение пары лет ... Что нам теперь делать?

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

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

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

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

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

1. Разработка готовых приложений для всего мира

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

Небольшой отрывок:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые вопросы к считать о…

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

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

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

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

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

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

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

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

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

Вы можете использовать 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.