So here is the whole story.
I have done alot of code for a lot of platforms.
I really like the concept that I have found in Java and .NET with a resource file that can contain all the strings you will use in your app. Hopefully some of you know about it. It's basically an XML file sorted in a key=>value kind of way.
I have been looking for an equivalent in iOS but I'm unclear. There is infoPlist.strings, but that seems like the wrong path. I may be wrong.
So what we want is, we have a whole bunch of strings that get repeated in multiple places (alert boxes, direction text, etc.). We need that to be a change once kind of experience. There are multiple ways of doing this, I just don't know which one is the best.
I'm not really eloquent, so if anyone has questions or needs clarification, let me know.
If localization is not what you are trying to do, then you could just put them in a dictionary in a plist file. Have your app read the plist file at app startup and store in a global variable or some singleton that can be easily referenced throughout your app.
This is handled by the localization system. Look at NSLocalizedString() and Localizing String Resources. It should do exactly what you are looking for.
Related
So my main concern is being organized and doing it the right way. So I have a lot of strings in the app that I am working on. Some of the strings will be seen by the user but a lot of them are going to be internal to the app. So my question is how should I organize them all? I have been looking into NSLocalizedString which looks like a good offer but I just do not think that it makes sense to put all the strings that are not going to bee seen by the user into this file. What my understanding is, is that NSLocalizedString is made to create your app versatile for all languages. (Which I am still confused about how that works) and to reduce clutter, space etc. What I am currently thinking of doing is to put all the strings that will be seen by the user into the Localizable.strings file and all the other strings that are internal at the top of my files. Does this seem like the best practice? Am I missing anything? Any suggestions/tips would be a huge help.
Thank you prior for taking a minute to help a new developer. :)
I declare all my internal strings as constants in the implementation of my classes
NSString *const some_string = #"Some String";
that way they autocomplete so I am more confident with the type safety.
If I need them from another class you can also expose them in the header file of the class where they're defined.
extern NSString *const some_string;
For user visible strings that you want to later translate, localizable.strings is definitely the best place.
I am still paying dearly for learning iOS development, so please be kind.
I have an iOS application containing around 400 NSString litterals. I never thought that I would want to localize this app later on, so while being aware of NSLocalizedString I decided to not use them for my project. Now the world has changed and I need to localize this application. Is there any tool/script I can use that will run through my .m files and "search/replace" my NSStrings with NSLocalizedStrings before I extract them with genstrings?
Thanks
Roger
You made a mistake not writing your code correctly the first time, and now you have to pay the price.
You need to go through your program manually and change user-visible string literals to calls to NSLocalizedString.
Note that you do NOT want to globally change all string literals. Things like dictionary keys should not be localized.
Always, ALWAYS, use NSLocalizedString to create localized strings. It's only a few more characters to type, and it makes internationalizing your code DRAMATICALLY easier.
The good news is that the pain of doing this will serve as a bitter lesson and you likely won't make the same mistake again.
Yes! A find and replace regex will speed up this up.
In the find bar put:
(".*")
In the replace bar:
NSLocalizedString($1,comment:"")
This will change "normalString" to NSLocalizedString("normalString",comment:"")
So go through your code and on the ones you want to replace just press replace, this is a massive timesaver!
You generally don't want to replace ALL NSStrings with NSLocalizedString as not all strings are necessarily 'user facing'. You might have string constants that are used internally that the user never sees and these in general should not be translated. Hence, blindly replacing all NSStrings with NSLocalizedString is probably not a great idea.
There is a fair bit of work involved going through and doing this manually, but its a one-time effort - once you've done it once you'll know the correct way to handle any new user-facing strings and do it as you go. Having said that - there may very well be a tool out there somewhere that handles this elegantly, but there's no avoiding the manual picking which strings need to be translated and which don't.
From I have learned and checked out, there no automated method to turn your strings to localized one you wish. But there's a plugin for XCode called Lin, that makes your process easy.
When you are focusing on NSLocalizedString or other functions to get a localized version of a string, Lin shows the list of localizations that contains the inputted key string.
Lin
From the question and your comments it seems you have around 400 strings only 20 of which should not be localised. With that ratio, as you yourself say, changing them all and then undoing the change for 20 can make sense.
To do this get TextWrangler, or BBEdit, and perform a multi-file pattern matching search and replace. You can confine the search to files ending in .m or .h. The task will be quick and easy, apart from those 20...
HTH
Sorry for the generalized question...I have been hunting for a long time and haven't found anything I can use or easily adapt yet. I'd really appreciate any pointers!
I'm building a reference app that will contain several textbooks in plain-text format. I want the user to be able to perform a search, and get a table back with a list of results. I have a working prototype, but the search logic that I wrote isn't all that smart and it's been hell trying to make it better.
This is obviously a fairly common problem so I'm looking for a tool that I could adapt to the task. So far I've found Lucene (http://vafer.org/blog/20090107014544/) and Locayta (http://www.locayta.com/iOS-search-engine/locayta-search-mobile/)
Lucene appears to have been last updated for iOS 2...I don't even know if I'll be able to rework it myself. Maybe.
Locayta would probably work great, but a commercial license is $1,000 and I may not soon recoup that with this app, as it's a niche market.
Thanks!
We stumbled upon the same predicament where I work, and have yet to decide on a solution.
Locayta seems promising, but barring that, I've looked into SQLite's FTS3/FTS4 as well.
The only issue seemed the lack of a way to match partial words. It's easy to search for fields that contain whole words (eg. "paper" matches "printer paper", "paper punch", and "sketch paper"), or words that start with something (eg. "bi*" matches "binder", and "bicycle"), but there's no built in way to match a suffix.
If you don't require that functionality, FTS3/FTS4 might work.
I see you mentioned in the follow-up that your SQLite didn't recognize FTS3(), and I had the same issue at first.
Apparently it's not bundled into the iOS version by default, instead you have to download the SQLite3 amalgamation, and include it in the project manually. As found at is FTS available in the iOS build of SQLite?
Also note, the SQLITE_ENABLE_FTS3 variable is not enabled by default, you just have to add it to the configuration as detailed at http://www.sqlite.org/fts3.html#section_2
Hope this helps.
If you can translate plain C code to iOS Objective-C, then Apache Lucy (a loose "C" port of Lucene) might be worth a look.
I don't know if my approach to this is fundamentally wrong, but I'm struggling to get my head around a (seemingly trivial?!) localisation issue.
I want to display the title of a 'System' UITabBarItem (More, Favorites, Featured, etc...) in a navigation bar. But where do I get the string from? The strings file of the MainWindow.nib doesn't contain the string (I didn't expect it to) and reading the title of the TabBarItem returns nil, which is what stumped me.
I've been told, there's no way to achieve it and I'll just have to add my own localised string for the terms in question. But I simply don't (want to) believe that!! That's maybe easy enough in some languages, but looking up, say, "More" in already presents me with more than one possible word in some languages. I'm not happy about simply sending these words for translation either, because it still depends on the translator knowing exactly which term Apple uses. So am I missing something simple here? What do other people do?
Obviously, setting the system language on my test device and simply looking to see what titles the Tab Items have is another 'obvious' possibility. But I really have a problem with half baked workarounds like that. That'll work for most languages, but I'm really gonna have fun when it comes to Russian or Japanese.
I'm convinced there must be a more reliable way to do this. Surely there must be a .strings file somewhere in the SDK that has these strings defined?
Thanks in advance...
Rich
The simple and unfortunate answer is that aside from a very few standard elements (e.g. a Back button), you need to localize all strings yourself. Yes, UIKit has its own Localization.strings file but obviously that's outside of your app sandbox so you don't have access to it.
I filed a bug with Apple years ago about providing OS-level localization for common button titles, tab item labels, etc. That bug is still open but obviously they haven't done it yet (sorry, I don't have the radar # handy).
What's the best way to set up help (specifically HTML Help) for a Delphi application? I can see several options, all of which has disadvantages. Specifically:
I could set HelpContext in the forms designer wherever appropriate, but then I'm stuck having to track numbers instead of symbolic constants.
I could set HelpContext programmatically. Then I can use symbolic constants, but I'd have more code to keep up with, and I couldn't easily check the text DFMs to see which forms still need help.
I could set HelpKeyword, but since that does a keyword lookup (like Application.HelpKeyword) rather than a topic jump (like Application.HelpJump), I'd have to make sure that each of my help pages has a unique, non-changing, top-level keyword; this seems like extra work. (And there are HelpKeyword-related VCL bugs like this and this.)
I could set HelpKeyword, set an Application.OnHelp handler to convert HelpKeyword requests to HelpJump requests so that I can assign help by topic ID instead of keyword lookup, and add code such as my own help viewer (based on HelpScribble's code) that fixes the VCL bugs and lets HelpJump work with anchors. By this point, though, I feel like I'm working against the VCL rather than with it.
Which approach did you choose for your app?
When I first started researching how to do this several years ago, I first got the "All About help files in Borland Delphi" tutorial from: http://www.ec-software.com/support_tutorials.html
In that document, the section "Preparing a help file for context sensitive help" (which in my version of the document starts on page 28). It describes a nice numbering scheme you can use to organize your numbers into sections, e.g. Starting with 100000 for your main form and continuing with 101000 or 110000 for each secondary form, etc.
But then I wanted to use descriptive string IDs instead of numbers for my Help topics. I started using THelpRouter, which is part of EC Software's free Help Suite at: http://www.ec-software.com/downloads_delphi.html
But then I settled on a Help tool that supported string ID's directly for topics (I use Dr. Explain: http://www.drexplain.com/) so now I simply use HelpJump, e.g.:
Application.HelpJump('UGQuickStart');
I hope that helps.
We use symbolic constants. Yes, it is a bit more work, but it pays off. Especially because some of our dialogs are dynamically built and sometimes require different help IDs.
I create the help file, which gets the help topic ID, and then go around the forms and set their HelpContext values to them. Since the level of maintenance needed is very low - the form is unlikely to change help file context unless something major happens - this works just fine.
We use Help&Manual - its a wonderful tool, outputting almost any format of stuff you could want, doc, rtf, html, pdf - all from the same source. It will even read in (or paste from rtf (eg MSWord). It uses topic ID's (strings) which I just keep a list of and I manually put each one into a form (or class) as it suits me. Sounds difficult but trust me you'll spend far longer hating the wrong authouring tool. I spent years finding it!
Brian