Re: [Proposal] On-the-fly NIB localization
Re: [Proposal] On-the-fly NIB localization
- Subject: Re: [Proposal] On-the-fly NIB localization
- From: John Stiles <email@hidden>
- Date: Tue, 16 Nov 2004 00:24:47 -0800
On Nov 16, 2004, at 12:16 AM, mmalcolm crawford wrote:
On Nov 16, 2004, at 12:03 AM, Martin Wennerberg wrote:
I did the localization this way in my small freeware MorphX.
Basically, I recursively translate all the strings in the menu and
the windows after loading them. When designing the nib-files I make
the text fields a little extra long so that all translations fit.
If you're going to do simply leave extra space, recursing through the
UI at runtime seems like a lot of overhead.
I've written more than one application which fixes up strings at
runtime based on a localized string table. (My work usually has to be
cross-platform, so it's a lot easier for me to load the string table
from the PC build as-is, than to have to dynamically load and convert
the PC string table to nib format at build time.) This approach has
never caused any measurable effect whatsoever on performance--and I do
use Shark while navigating the GUI from time to time, usually just
because it's interesting to see the code paths that come up. (You can
get some pretty interesting views into the guts of the OS this way :)
)
Let's put it this way--the time it takes to load four or five strings
out of a dictionary and do [myTextField setStringValue:whatever] is
literally millions of times faster than the time it takes for the sheet
containing these strings to appear on-screen, thanks to OS X's fancy
animation effects :)
Optimize when it makes sense. In this case I don't see a benefit.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden