Интернационализация с помощью Nibs. Это точно хорошая идея?

В Apple Docs говорится, что Nib позволяет интернационализацию, просто переведя Nib на многие языки. Сейчас я думаю о худшем, но реалистичном сценарии: вы создали огромный пользовательский интерфейс. Затем вы переводите это на 25 языков. Таким образом, вы получаете 25 разных Nib. Вы также получаете огромную избыточность в дизайне и определение пользовательского интерфейса: в 25 раз больше. То же самое Связывает, то же самое. Только текст отличается.

Итак, я действительно думаю, что это очень плохой подход. Вместо этого я бы предпочел просто соединить все тексты с набором ресурсов или что-то в этом роде. Просто файл с текстовыми строками, который связан во время выполнения с соответствующим языковым ресурсом. Тогда у вас есть только "проблема", связанная с текстом, который на самом деле не делает ничего интересного. Но тогда вы можете вносить изменения в свой UI ONCE без необходимости повторять один и тот же шаг 25 раз снова и снова. Новая привязка в каждом нобе. Это было бы так ужасно!

Теперь, пожалуйста, скажите мне, что я ошибался. Apple не предполагает, что мы делаем что-то такое creazy?

Ответ 1

Локализация не идеальна. Хотя элементы Cocoa UI поддерживают некоторую динамическую гибкость в их размере (флагов ausosizing), очень сложно организовать их в представлении, чтобы они могли размещать любой размер текста.

Как указывает Хэн-Чонг, это обычно означает, что для каждой локализации требуется некоторая корректировка макета. Apple поддерживает процесс, называемый инкрементной локализацией, с помощью инструмента под названием "ibtool", в комплекте с инструментами разработчика. Этот процесс далек от интуитивного и, кажется, имеет некоторые тонкие ошибки, но помогает сделать процесс проще, чем, скажем, отдельно, поддерживая 25 разных перьев вручную. Этот процесс по существу включает в себя изменения картографии, которые вы делаете в своем первичном наконечнике, на другие локализованные наконечники. Apple описывает процесс более подробно:

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html

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

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

Ответ 2

Иногда локализация включает в себя не только замену текста, но и изменения в макете. Например, строки в одном языке/языке могут быть значительно длиннее, чем в другом, что приводит к изменению макета. Язык справа налево часто будет означать и некоторые изменения в макете.

Ответ 3

Основываясь на предыдущих двух ответах, есть инструмент под названием iLocalize, целью которого является упрощение процесса, чем ibtool (и он старше чем ibtool). Я никогда не использовал его сам, но мой друг Эван использует его как в Adium, так и в Growl и любит его.