Re: [Proposal] On-the-fly NIB localization
Re: [Proposal] On-the-fly NIB localization
- Subject: Re: [Proposal] On-the-fly NIB localization
- From: mmalcolm crawford <email@hidden>
- Date: Tue, 16 Nov 2004 09:39:17 -0800
To elaborate on other aspects...
Optimize when it makes sense. In this case I don't see a benefit.
I certainly agree that premature optimisation is in general a Bad
Thing, however here it's not so much a case of prematurely optimising,
as simply not doing something you know will use extra cycles and
memory.
There are a number of aspects to this:
First of all, you're writing extra code, that has to be implemented
properly maintained (you have to make sure you follow the same steps
for all UI loading). Using nibtool (or other tools) in effect gains
you the benefit of reuse, and is (or should be) less error-prone.
When you load a localised nib file, then, you're done. There is no
additional overhead. Using the recursive translation technique, even
loading a nib that doesn't require localisation requires you to load
the .strings file (additional disk access) and do a lot of string
comparisons. If you are localising, then you end up with two strings
in memory for each unique string in the UI.
Moreover, you're constrained (at least in the implementation shown) to
putting all your translations into Localizable.strings. This almost
certainly means that your strings file will probably be larger than
necessary, less maintainable, and you will end up loading a number of
strings that you don't need. It also (per the implementation shown)
precludes the use of loadable bundles.
To clarify: your application will presumably need translations of all
relevant strings. But it's likely (admittedly not certain, it depends
on how your app is packaged, but this is probably true for the majority
of cases) that you won't need all the strings when the app is first
launched. Others will be needed if particular panels are displayed
(loaded dynamically). If you put everything into Localizable.strings,
you therefore load more strings into memory than are required,
increasing overhead. As a *general* rule, it is better to factor
localisable strings into different tables so that they're loaded only
as and when necessary.
Is any of this noticeable to the user? Probably not directly. I'd
argue, though, that in this case working with the frameworks and not
unnecessarily increasing resource usage are in general Good Things...
as are reducing the code maintenance burden and scope for error.
mmalc
_______________________________________________
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