On Jul 4, 2011, at 9:35, Ulf Dunkel wrote:
> Hi Rick.
> Am 01.07.2011 13:11, schrieb Rick C.:
>> I don't know what you think about this:
> The approach seems to be nice at face value, but will run into the same issues as all other NIB layout methods which do not keep in mind that localized strings can be much longer. So you will also have to adjust the base language (English in most cases) NIB layout every now and then.
> Of course the generating of localized NIBs only in the build phase seems to be handy, but I don't see any advantage over having localized AND properly layouted NIBs at any time in your sources.
> And I do NOT agree with what the linked page claims: "Translators want strings files, not nib files". That's pretty nonsense, because real translators aka localizers don't simply translate but localize apps. So they need to check their localized app in run-time, without asking the developer all the time for new versions.
That's incorrect. Unless you are able to afford highly skilled translators. IME the UI I get back from translators ALWAYS needs tweaks, because the translators are not intimately familiar with some peculiarities of some (complex) UI, and often don't know (enough of) the HIG.
Moreover, you assume that translators want to pay for buying iLocalize or some other non-free localization app (or you pay them?). That may also be false, it certainly is for me. And in that case, localizing NIBs can be a real pain (I already said that Apple's approach does not work at all.)
So then translators do want .strings files. They can always be easily translated with any tool, including by hand.
Moreover, IMHO it is better for the developer to fix the UI in some way, rather than the translator, because he knows the HIG and the peculiarities of the particular UI.
This is why I (also) like the approach of Localization Suite, which leaves the job of translating to the translators, and the job of localizing to the developer. And moreover, it is able to work directly with the (source controlled) sources.
> This is what convinced me of the way how iLocalize implements localization and testing.
> IF (a very huge "if") Apple would finally implement any way to auto-adjust the size of text-containing UI objects, maybe from a given instructive way which tells the system in which direction objects may grow (or shrink!), the developer.casgrain.com method would be perfect. Until then, it is NOT.
> Localization still needs these things:
> - a well-thought and designed base language NIB layout
> - an easy way to localize and update localizations
> - an easy way to test localized layouts in run-time
> - glossary handling to keep localizations in sync
> ---Ulf Dunkel
I agree that something like this is sorely missing in Xcode's approach. But for some relatively simple UI the approach of developer.casgrain.com can certainly work, though it would not be my preference. Unfortunately all approaches have pros and cons, and which one is best really depends on your UI.
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden