Age of Swords comes out next week, but that didn’t stop this Barnes & Noble from putting it out early. If I were willing to go non-digital I’d be reading it right now.

Jeff Rosenstock’s WORRY. came out last October. Since then, I’ve listened to it dozens of times. I can’t think of an artist that I’ve listened to more over the years. His writing and music style just blows me away.

I’m looking forward to Iron Gold. It’s the fourth book of the Red Rising series which explores distant future humans splintered into sub-groups with one dominant over the solar system.

Personal names around the world explains the complication of names. The biggest take away: ask users for their full name and short name. Don’t try and parse out first names or separate first and last into separate fields.

Butterick’s Practical Typography has recommendations and pointers about laying out and writing copy. The ranking of system fonts is especially useful. Love the dislike of title case in headings.

Vault 11 in the game Fallout: New Vegas contains an interesting experiment: how would people react if an authority tells them to sacrifice one of their own? Oxhorn examines the vault and draws parallels to the Milgram experiment. Excellent worldbuilding.

I’ve been listening to The History of English Podcast. It’s not easy to binge but it’s a mainstay in my weekly podcast rotation. I’m currently around the fall of the Roman Empire. It’s fascinating that our alphabet has bounced between cultures but with only minor changes.

Automating iOS app builds

I believe an important part of the development process is getting a working version into the hands of others. As part of this, being able to install the latest and greatest on the fly is paramount. It took me a lot of time to find a reliable way to build, sign, and distribute apps as part of this internal continuous delivery.

Continue reading “Automating iOS app builds” →

Localizing attributed strings on iOS

In an iOS app, localization can be especially difficult when dealing with attributed strings. Fairly often, designers request something like:

Read our Terms of Service, Privacy Policy, or contact us with any questions.

or like:

Searching for burgers in SOMA, San Francisco, CA:

The golden rule of localized strings is to treat them as atomic units:

Never concatenate strings to form sentences. Many languages have different sentence structure or gender rules than English and you cannot just substitute a single word or phrase in for any other.
Never use substrings for searching in an original string. If you depend on the standalone translation of “Privacy Policy” matching the sentence version, you will likely find translators do not understand this intent. You may also find the same search term multiple times (imagine if the user searched for “Search”).

Often these complexities are cited as reasons to avoid localization. But, unless you have geographic constraints, you will find a substantially larger audience with a localized application.

ZSWTappableLabel and ZSWTaggedString are two open-source libraries I have released to help solve these problems.

ZSWTappableLabel makes links inside your attributed strings tappable, as the name suggests. It’s a UILabel subclass which does not do any drawing itself, making it fast and easy.

ZSWTaggedString is the powerhouse. It transforms an HTML-like syntax into an attributed string. You can read more about the syntax and advanced usage on its GitHub page, but here’s how you might use it for the examples above:

Read our <i><tos>Terms of Service</tos></i>, <i><privacy>Privacy Policy</privacy></i>, or <i><contact>contact us</contact></i> with any questions.

Searching for <term>%@</term> in <location>%@</location>:
Code language: HTML, XML (xml)

In my experience, localizers¹ are familiar enough with HTML to have no issues with localizing these strings. By marking the regions you intend to be visually distinct, they can more easily understand your intent, producing better localizations.

While on the subject, here are a few best practices for localization in iOS:

To handle the current locale changing, or the dynamic type setting changing, reload your UI when observing:
- NSCurrentLocaleDidChangeNotification
- UIContentSizeCategoryDidChangeNotification
To represent dates, durations, distances, lengths, etc., use an appropriate formatter.
To create your own date formats, use +dateFormatFromTemplate:options:locale: on NSDateFormatter. Remember that these need recreating if the locale changes.
To combine a first and last name, use ABPersonGetCompositeNameFormatForRecord with a temporary ABPersonRef, or use the new NSPersonNameComponentsFormatter.
For sending non-user-facing data to a server, use en_US_POSIX as your locale.
Read more tips and tricks at NSHipster about NSLocalizedString and NSLocale.

If you’re looking for recommendations on localization, working with Applingua has always been wonderful. ↩

T-Mobile: good ideas, bad experience

When T-Mobile entered the wireless scene as the “Uncarrier” I was impressed. Their greatest contribution to the carrier ecosystem is consistently adding features, forcing other carriers to keep up. Instead of rationed text and voice, we’re in a world where data is king.

However, if you are considering T-Mobile service, I suggest reconsidering. The plans and features look appetizing, but their execution leaves a lot to be desired. I would not count on their unique features; just the now-basics with worse coverage.

I wrote off my initial experiences as anecdotal, but it became cumulatively enough for me to leave their service.

Continue reading “T-Mobile: good ideas, bad experience” →