What I've done that works for pre-Lion sizing and works for practically all needs for a single NIB is to do this:
1. Devise a specially-designed key path that tells me the following: A. A tag that identifies it's my localized format B. String key C. The string table name (if empty, fall back to Localizable) D. Visual pinning of the object E. A tag that marks the item as a tooltip 2. Write a function that parses the key to see if it's encoded with my special mechanism and its settings. 3. Add a -valueForKey: method to my application delegate and see if the key matches my pattern. If not, just call the super class's method (including any application-specific needs first). 4. For text fields, add a value binding to the application with self.delegate and the specially-designed key path. 5. For tooltips, add a tool tip binding to the application with self.delegate and the specially-designed key path, adding the tag for a tool tip. No need for the visual pinning value. 6. For buttons and button cells in a matrix, add a title binding to the application self.delegate and the specially-designed key path. 7. Add a call to a function within -windowDidLoad or other post-NIB-handling method that will call a function that adjusts views based on a pinning tag (left, right, top, bottom, or some relevant combination). The function will traverse all views and matrix cells to see if they have the same kind of key for bindings with adjustment pinnings and resize them accordingly and modify each frame. 8. For lookup of localization settings while running your app (i.e., the string table and key being used), utilize some special setting, such as a debug menu option or special modifier key toggle, and when retrieving the actual string, return the table name and key rather than the desired string. Once you've done the heavy lifting of defining, parsing, and sizing with the key paths, this method works beautifully. You can still add the default language values within each text field or control for visual identification within Interface Builder. -- Gary L. Wade http://www.garywade.com/ On 02/23/2012 7:24 AM, "Ulf Dunkel" <dun...@calamus.net> wrote: >> I believe that the "single nib" approach has been made more viable by >>Auto Layout in Lion, and expect to see more developers using "single >>nib" in the future. > >When Auto Layout will auto-adjust the size of text containing objects in >each and every NIB by giving us some smart controls how the adjustments >should work, then the single NIB approach could be nice. > >Removing the quantity of NIB files in the deployed app bundle could also >add to the minimization of app weights. > >Until then, we still prefer having separate localized NIBs, but with the >One For All NIB layout method, where the English (or say your Base >language) NIB objects are adjusted to the minimum size which is required >by the longest text in one of the available languages. > >A while ago, I have written a web page which explains how to optimize >NIB layouts for localization. > >http://www.icalamus.net/ioda/howto_niblayout.php?lan=en > >And - oh, adjusting NIBs in multiple languages from a changed base >language NIB layout is a piece of cake, using iLocalize. > >Just my 2 cents, >---Ulf Dunkel _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
