I'm learning the basics steps to internationalize an app and I have a question about localizing interface NIB files... I've seen that in Xcode you can click on a AppViewController.xib interface file and click on the + in the Localization section of the inspector window to add another language along with the default English one (I add Italian for example)... This allows me to translate the interface in Italian... but then how do you maintain future evolution of the App? If you need to add a button, for example, you have to add it by hand to all the localized versions of your interface NIB file? Documentation says also
Objects in a nib file typically have connections between them that should not be broken. Make sure you lock all connections before handing your nibs off to translation. For information on how to lock down your nib file, see “Localization” in Interface Builder User Guide.
Can you explain me this concept? I've seen the Localization Locking section within the inspector which allows you to lock Properties, Localizable Properties or Un-localizable Properties, but I don't understand very well what it does.
So, to sum up a bit, I'd like you to suggest me what is the workflow to design localized versions of your interface and maintain the multiple NIB files when the interface evolves.
EDIT: any idea and/or link that can help me?
iLocalize provides an easy way of localising an app and updating translated nibs. If you'd rather use ibtool, --localize-incremental, which will handle the changes in a nib and copy them to the translated nibs, is explained well here.
Alternatively, you could use NSLocalizedStrings and one nib which is useful in some instances. Set each control's title in code and you need only worry about making the controls wide enough for the longest translation.
Related
I have developed the application in ios. It is working fine. I have converted it as a framework(library) so that My codebase remain same.
I have multiple clients for this app. So I need to change the following things
Colors (As it will change the background colors, text colors etc)
Strings (Like headings and labels in some views)
Some files like Images etc
What I want:
As I am android developer, So in that I can create another color file in my client app with same color name, that replaces the color value in Library. and this it just require only one file to be replace and it automatically overrides in library. Same was the case with the String.xml and image files
Looking for something like that as I have described above.
What I searched and found so far:
After searching alot I have found that I need to make outlets public and then I can give them color by accessing them. But What If I have a 1000 of views and 1000s of outlets to make to use this technique, Isnt it better to use it as same way as in android I described above.
Confusions:
Is there anyway in IOS to declare color in a file and to use them in IB and code as well. Well I read about Color.xcassets but that is for ios 11 I think
How to make strings file and to use them in IB and in code. Like strings.xml file in android?
So I short, I want to updated colors,Strings and file per client wise and I do not know how to do it and what is a best way of doing this??
Please help and thanks in advance. Please share your views.
You should configure your framework to read from predefined files in .plist file. this will require only changing the files content in the client application.
Easy way to handle colors and theme using SkinKit. This is too old code. You just reuse idea or create custom themes configuration file(plist,JSON),Strings and images as .bundle read all color and customization from that bundle. So easy to change Colors, Strings and Images assert for various clients.
You seem to have a misconception about what IB is — in particular, what a nib is, and what it means to edit a nib, which is what Interface Builder does. A nib is a file expressing potential instances, typically views. You edit it on your computer using Xcode (IB). When your app runs, the nib is loaded and the views are actually instantiated. That is the only thing you can do with a nib when the app runs. You cannot modify the nib in some way when the app runs; all you can do is load the nib and get the instances.
So, if you want to change all the titles of buttons or all the colors of views when your app runs in accordance with some configuration file, you can do that, but that has nothing to do with nibs or IB. You would just load the nib as usual to get the views, and then change them all, one by one, in code. You could use tags or some other identification mechanism to help you find each view, but that would be entirely up to you to work out.
When I click new file and go to user interface tab, I don't see the application or window options. The application file description should say "An Interface Builder document suitable for creating an iOS application, including an application delegate and window." I tried searching in the search bar in Xcode but application did not show up for iOS.
Please see screen shots and difference for clarity.
app delegate screenshot 2
my screen
Apple introduced storyboards back in 2011. Before that, developers used a .xib file to specify their user interfaces, and the "main" .xib file, i.e. the first one that the app loaded, included a proxy for the app delegate so that it was easy to connect objects to outlets in the app delegate. As matt has indicated, though, things haven't really worked that way for a while. As he says, it sounds like you're working from an old book or online tutorial, and as a result your expectations don't match the reality of modern iOS development.
These days, apps generally use a storyboard to specify all or part of the user interface. A big problem with .xib files was that you had to load an entire file at once; if you instantiated a view controller with -initWithNibName:bundle:, the entire file was loaded. That meant that you could only specify a single view controller in a given .xib file, and managing the relationships between view controllers was harder than it should be. Storyboards address this problem -- a single storyboard typically contains several view controllers.
I agree with matt that you really shouldn't work from material so old that it expects you to use .xib files to build your application. That story again:
STOP USING THAT INFORMATION
There are plenty of great resources (notably matt's own iOS 9 Programming Fundamentals with Swift) that will teach you how to write modern iOS code. Apple's own documentation is a great place to start.
I'm looking for an information that I haven't found on the Internet. I would like to know in which iOS version did NSLocalizedString appear ? (maybe it's here since the first version of iOS ?)
I also would like to know in which case using localization in the .xib and in which case using NSLocalizedString ?
I'm asking this question because I'm working on an iOS project using localization in the .xib files AND NSLocalizedString, and I don't really know why the two methods are used... (it's an old project, that's why I'm asking the first question ^^)
Last question, for a new project, which one of these two methods would be your preferred one ?
Sorry for all this questions, and thanks for the answer ! =)
Localisation using xib files is used when we want to localise elements on a UI e.g., when you want to show different images which has a localised text for a particular UIButton. You can achieve this using localised xib files.
There will be separate xib files for each language.
And when you are setting any text on the UI from you controller, NSLocalizedString.
I hope this helps.
NSLocalizedString was first available in 10.0
So I localize programmatically w/ NSLocalizedString because this way I can have all of my strings in one location.
Instead of through .xib localization generation, because with that you'll have a strings file for each xib you have.
However, if you have a .xib that you aren't modifying programmatically (i.e you don't have a custom class set as the file's owner), then you won't be able to programmatically set the NSLocalizedStrings. In which case, you will have to generate the strings files through the .xib.
Also, it is slightly more difficult to access string files associated with a .xib because it's directly connected with the .xib
NSLocalizedString exists since iOS 1.
Basically you need NSLocalizedString for all dynamically created strings.
In a new project I'd recommend AutoLayout and Base Localization.
There is one .xib file and all localizations – and layout adjustments – are performed at runtime via .strings files
Probably this question is dead but I jumped here searching for a method to localize xib strings and this page was the first result.
You can use both NSLocalizedString and xib. Have a look a this answer:https://stackoverflow.com/a/21443515/907720 discussed in detail here: https://medium.com/zendesk-engineering/ios-how-to-add-adaptive-constraints-to-support-a-universal-app-273663475b12
In Android, you lay out a view with an AXML file, where you specify the hierarchy of sub views and their relationships, and the OS loads this file and renders the view.
In iOS, there's a NIB file, which is similar in concept, but it's completely human unreadable (in my opinion). You can create this file with the WYSIWYG editor in Xcode, but you can't just type it by hand, because it's immensely complex and impossible to get right.
I find the WYSIWYG editor unwieldy for any but the most trivial layout, and so I'm also finding that in iOS, it's easier to build the control tree in code than to use the NIB file. But the AXML approach seems much easier still.
So, I'm wondering if there's any iOS library that would let me lay out the code in a declarative way (that is, not with a designer), and then create a view from that, with automatic resizing and other conveniences.
The .storyboard format is a simpler format to read, use that instead of XIB files.
It seem like you are coming in iOS development from Android.
But Editing background XML (Back Source) view file is not style of iOS.
Yes you can see that file but Apple want that you design your app by using this two approach only.
How I can say that? Because apple have not provided any document for how to do that (At least I have not come across any).
Design in visual editor (XIB Or Storyboard)
By Using code (Create view and controls and addSubview)
Mostly we use mix approach we use top level and simple design by first one and use detail and complex design by second one.
Storyboard is new and very good one try to use that.
Our company is developing a quite large app for the iPad. Eventually we want to be able to customize the UI per customer (tenant) and maybe even per user (of that customer). We started off in HTML5 but are moving to native.
I've done some reading on downloading XML from the server (or even generated XIB/NIB files) and dynamically adding those to your app.
Now with iOS 5 (and even further in 6) storyboarding is playing a big role.
My questions:
- Would it be better to use (multiple?) storyboards or XIBs?
- What are my options for both if I want to deliver a dynamic user interface?
I'm not looking for a magic pill, nor a discussion on HTML5 vs native, just some information on how I could deliver a dynamic interface and what techniques could help in doing so.
my response to your two questions is:
storyboard is great for scene management; it creates a visual connection between
your various scenes/views. i prefer to use storyboard for as much of my UI as possible.
however, there are elements that i have in some apps that pick up existing or reusable
or otherwise dynamic XIBs. i simply tie these together with my storyboards by loading
the XIBs in code at the location at which i want them. so, my ultimate answer for your
first question is "both", where storyboards are used where possible, and XIBs used for
dynamic scenes/views.
your options for dynamic user interface include at least the following two options (of which, as stated above, i prefer the second):
create all code using XIB files, and perform all UI transitions without storyboards
in code
create as much UI as you know will remain relatively static in terms of relationships
between viewControllers with storyboard, and then load the dynamic parts of the UI
using initWithNibName:bundle:
finally, you can use multiple storyboards if the situation warrants, and this could even apply to dynamic UI, whether it comes from re-usable components created elsewhere in storyboard and maintained separately, or storyboard XML (if you look at storyboard source, it is just XML under the hood) whether acquired from something that generated or wherever. you can even decide to manage your UI with multiple storyboards at the design phase if your app will have several complicated interconnected view-controller scenes (e.g. each tab in a UITabBarController may have its own storyboard, where each storyboard's scene rootController is connected/loaded when a tab is chosen).
StoryBoard all the way! I use to absolutely dislike storyboards, but then i got use to them and now i love them. Storyboards are the way to go.
Layout seems a really powerful framework for developing dynamic GUIs on iOS.
DISCLAIMER: I'm not the author of that framework; the author is Nick Lockwood, who seems to have an account here on SO. I found both this question and Nick Lockwood's Layout framework by googling "ios dynamic gui".
I haven't tried it yet, but it looks really promising.
The project is even hosted at GitHub here, and it has a MIT license.