I have localized my app and set up the Localization.string file.
Now that I want to add new strings, how do I make it so the corresponding files get the new strings automatically? Or do I have to manually add them?
Just not sure how I should organize my translators to be able to see that there are new strings to translate without having to just keep track of it manually.
I don't think there is an automatic way to manage them.
What we do is add a "//New" or "//Changed" to the end the english resource string, and our translators remove it when they add the other umpteen versions.
We actually put a \ tag with the date the item was added in order to let the translators know what is new and when it was added.
Another thing that we do is leverage a tool which auto translates our English localizable.strings files into target languages using Google's api service. While Google's translations aren't perfect, they are a great start for our translators. This really jumpstarted our translation process. Link to Apple Store app.
Related
I am new to iPhone App development (I am using XCode 4.2) and I was wondering if there is a way to translate all the strings , caption etc ... internally without having to translate them one by one .
an idea I have in mind is to use NSUserDefaults to save the language as a global variable and translate everything accordingly
another option is to make a look up table (is it even possible in Objective-C ?)
Thanks
You can use NSLocalizedString(#"<#key#>", #"<#comment#>") and one file (named Localizable.strings( per language. If you use the above function you can use the App Linguan (available on the Mac App Store) to generate the Localizable.strings files.
There is also a command line tool called genstrings that will create the file for you, but believe me that Linguan app will pay for itself in minutes.
You should always add a comment to allow a better translation and to provide context about the key.
You can read a step-by-step tutorial of the process here:
iPhone Localization Tutorial
Here's a high-level overview of the basics (the above tutorial has details):
1) Change all your coded strings to call: NSLocalizedString(#"My text", #"Context for the translator")
2) Export all your strings using the genstrings Terminal command.
3) This creates a text file called Localizable.strings with all your English (source) strings. It looks like this:
/* Context for the translator */
"My text" = "My text";
You send that file to the translators. They'll translate the right side like this: "My text" = "Mi texto";
4) You place each translated Localizable.strings file in its proper language folder: en.lproj, fr.lproj, es.lproj, etc.
When your app loads on the iPhone it will check the user's language settings. If the user has chosen French as the system language, the Localizable.strings inside your fr.lproj folder file will load. If there are any untranslated strings, it just defaults to English (or whatever your source language is) for those.
It's worth following the whole tutorial and note that the file/folder names have to be exact!
Look up the documentation for NSLocalizedString. And how to localize your .xib files (you make localized copies in English.lproj, de.lproj, fr.lproj, etc.).
All you will have to create are the files with the key-value pairs for each language you want to translate and name them accordingly i.e. _en, _fr and so on.
Then all you have to do is send a message to this method:
NSLocalizedString(#"myKey", nil)
And this will return the localized String, in whatever language the current iPhone configuration is.
any recommendations for saving four strings into an own file format that is read by the application and can be shared?
In my app, you will be able to enter some text in some boxes and the app shows a view with an background image and those strings. Now, I am already able to save this as a picture, but I actually want to save it to an own file format so that you can save different files that can be modified afterwards as well or even exchanged via email and opened from another iphone with the app.
Now, I wrote the code for accessing the documents folder of the app, as well as saving and deleting. Thing is, i dont know how to store those strings in a file (perhaps in a xml?) and read them easily afterwards from my application.
For the exchanging part, I found that link which would be a nice feature indeed: http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
Parsing xml seems not that difficult (never done it before): http://ipad.about.com/od/iPad-App-Dev/a/How-To-Parse-Xml-Files-In-Xcode-Objective-C.htm
If it's only a small bit of infomation then the easiest way to store your data in a file would be using a plist - there's a good tutorial here - http://www.icodeblog.com/2009/02/14/loading-data-from-plist-files/
In addition to the plist, you could also do the following approaches:
1) simplest - open a file in your documents directory, write the 4 strings (using whatever delimiter/end of string marker is useful - carriage return?) and overwrite them each time through. (i.e. it's your file, you can format it how you like)
2) mildly harder - use Apple's NSArchive to pack and unpack the strings.
3) possible overkill - store them directly in a SQLite database
4) major overkill - store them in CoreData.
Of course, the "overkill" options also provide you with extra features which may be of use if your app functionality extends beyond what you've outlined.
By sharing, I would think that simple copy and paste might be enough, but there's also sending it via email, or tripping another app's URL scheme to make it open it and sending the strings as part of the URL. You'd have to know that the other app would be able to interpret your strings as part of the URL, so you might have to write it yourself.
Okay guys I found that very nice method in the NSString documentation:
–writeToFile:atomically:encoding:error:
I think I am gonna separate my strings by /n and save them to a .txt. When I am gonna read the file afterwards, i am getting the string, divide it to substrings. That will do it, I guess.
One last question: Is it possible to replace the content of my file so that I won't need to create a new file every time i want to change something?
Thanks!
I'm currently in the process of adapting an existing iOS app into what will be a family of very similar apps (each app instance will probably map to a different country/region).
I'm planning on having a different build target for each of these instances, and the only differences between them should be:
Images (probably just the splashscreen and icons)
Localizations
String variables: base URL for remote services, application ID, support e-mails, etc (possibly half a dozen of such variables)
The code itself should be the same on all apps.
What I'd like to know is what you consider to be best practices for managing a family of applications like this.
Regarding images and localizations (or resources in general), it should simply be a matter of adding/removing the appropriate files from the target (and I guess I can even use the same name for images, in different directories).
The main thing I'm not sure about are the other configuration variables.
I've heard / thought of a few options:
Using preprocessor macros and a main configuration header file with the different URLs, IDs, etc
Loading them from a plist (or similar configuration file) whenever the application launches, and having one such file per target
Creating an empty .sqlite file (this app already uses Core Data) and populating it with the default configuration variables, and having one such file per target
I think the first option is the fastest to get out of hand once I have a few instances of this app, plus I have to recompile every time I change one of these settings.
The third option I'm also not sure about, because I'll be adding entities to my database which don't feel like they belong there, plus it kind of feels like overkill for what will probably be 5-10 settings. I'm also not sure about how to add new settings on updates.
So I'm leaning more towards the second option.
Thoughts? Any alternatives to these?
UPDATE #1:
Regarding the second option, there is also a drawback that those strings (ids, URLs, etc) will be slightly more exposed (i.e. if someone was to open the app and look through the plist) than if they were in the source code. Not that this is that big of a problem, but it's just something to consider.
Update #2:
How about using the app's info.plist directly and storing it there? (thus having an info.plist for each target configuration) Even though originally I was thinking of having a separate plist, and having a "configuration singleton" which would load everything from there on startup, I think it may be simpler to simply have it in the info.plist and then reading it via [[[NSBundle mainBundle] infoDictionary] objectForKey:#"com.example.mykey1"].
I would take the preprocessor option. You can put all your preprocessor in one file/method and it will not be too messy. Like oefe said, change the .sqlite is overkill. And with the multiple plist, you will find yourself dragging things around and doing a lot of error prone actions.
However, I would not make a lot of apps. I would just make one app, let the user select his city at launch. You could also add in-app purchases to let the user add more cities when he wants to.
Your app will be easier to maintain : do you want to upload, change description and screenshots for 10+ apps at each update? I find this painful to do with 1 app...
You will not spam the AppStore : having 10+ more apps in the AppStore with the exact same purpose is ridiculous... That's exactly why Apple made in-app purchases, to avoid that situation.
You will have to find different icon for each of your city : your icon is one of the most important aspect when selling your app on the AppStore. You want it to be as polished as possible. Apple won't allow multiple apps to have the same icon and differentiate icon by putting a label on it is not a good option.
I ended up going for the plist, but instead of creating a new one I used the info.plist file for this, thus no need for extra files per target, as I already needed to have a separate info.plist for each one. I simply load them directly from the bundle with:
[[[NSBundle mainBundle] infoDictionary] objectForKey:#"com.example.mykey1"]
I also used preprocessor (with flags set on the target settings) for a couple of things, but that was mostly for when I wanted to disable/remove completely some parts of the app (e.g. to make sure I got everything I commented out enumeration values and even includes in a couple of places).
I think it's relatively clean and I can easily replicate this for future builds without too much of a mess.
Given that the variation is per country/region, and these variables are strings, why don't you simply treat them as localizable strings, thus reducing the problem to one already solved?
Otherwise, I would go for the plist. Sqlite seems to be an overkill, and is not source-control friendly. And conditional compilation will get messy fast.
In my project, I need to support the Korean language. How is it possible - can anyone explain briefly with example, whether it is possible or not?
It's certainly possible.
You just tell Xcode to add a Korean localization to any of your application's localizable resources that need to change for that language. (Localizable resources include strings files, xib files, and potentially any images containing text.) Xcode will create a copy of your existing English resource, which you can modify and replace with a Korean-language equivalent.
Then when your application is run on a device with Korean set as its preferred language, iOS will automatically use the Korean resources intead of the English ones to present the application's user interface. If you have used good localization code practices (such as using NSLocalizedString to reference strings you present in the user interface) you shouldn't have to change any of your code to support different languages.
Check this guide on how to localize your apps for iPhone: http://www.icanlocalize.com/site/tutorials/iphone-applications-localization-guide/
i have an app that i have to localize. I am already localizing the nibs and some texts, i just have a doubt.
I need to pull a plist from the bundle which contains some texts, for the other languages i would have other plists. How can i accomplish the loading of them in a nice simple way.
My initial though is to have a text.plist , text-sp.plist , text-fr.plist and retrieving the current language then if language == english grab the text.plist, if language == spanish grab text-sp.plist and so on.
Is there a better way to do this?
I'd rather somehow make the .plist localizable and do something similar to what i do with texts using NSLocalizedString, but i am not sure how to use it in this case.
Sorry, just found the solution.
Just right click the .plist file and add new localizations like any other file. Then the OS handles which one to load according to the current locale settings.
I had to clean my targets in order for the changes to take effect, thats why i initially thought this was not working.