iOS NSAttributesString - localization?

dantastic said:

Just started to look in to NSAttributedString as I've been able to drop support for iOS5.

I feel I'm missing something here, how do you work with dynamically loaded text? I have very few strings hard coded into the app itself. Strings either come from localization files or from plists. I haven't been able to suss out how to deal with these things without just simply hardcoding.

So consider (google translations in case I got it wrong )
The brown fox jumped over the new iPhone

In German
Die braune Fuchs sprang über das neue iPhone

In French
Le renard brun saute par dessus le nouvel iPhone


So I'm looking for some kind of markup language I suppose. I have seen a few github projects where people have been suggesting their own versions. Is there an Apple way? I don't want to have to cook my own here but from the examples I have seen so far that is really the only sensible option.

Click to expand...

It would be nice if iOS supported RTF files, but it doesn't. We had to roll our own solution.

Here's what we did:

The Mac OS version of NSAttributedString lets you create attributed strings from rtf files.

I created a command line tool that takes an RTF file as input. As luck would have it, NSAttributedString conforms to NSCoding. So the command line calls archiveRootObject:toFile to convert the .rtf file to a data file with the suffix ".data" that contains the archived data of my NSAttributedString. Our app supports iOS 5 and above, so I actually save both the attributed string data (as a .data file) and the vanilla text (as a .txt file)

I then created a build rule that acts on all files of type .rtf. It runs my command line tool on each file, and copies the output .data file (and the .txt file as well) into the application.

Finally I created a category of UIView that works for UILabel, UITextField, and UITextView, and adds an extra method loadStyledTextFromFile:insubdirectory: to those view types.

At runtime, if the field supports attributed text, it loads the .data into an attributed string and installs it in the field's attributed text property. If not, it loads the .txt file and uses that.

To handle localization, I add each language code as a suffix for my source filenames. (So in the Spanish localization, a file foo.rtf would be named foo_es.rtf, and would be output as foo_es.data and foo_es.txt.

At runtime I look up the current language and try appending that language code to the filename and loading text from that filename. If that fails I revert to the content in the development language (English, in my case) which does not have a language suffix.

Now that it's all done, it works great. We just drag .rtf files into our project, and rtf files with a language suffix for the localizations, and the build process takes care of everything else.