Make iOS and OS X SDKs localizable

[1ec5]

This PR makes the iOS and OS X SDKs localizable. It separates strings from logic and establishes some infrastructure for localizing the SDKs, but actually adding localizations or support for a specific localization tool is out of scope for this PR. Also out of scope for this PR is any form of map localization: as explained in #1108, the map’s localization is currently controlled by the style and source; dynamically switching languages would require #837 and potentially more language support in the source. So this PR is about the “chrome” only.

Hard-coded English strings are now wrapped in calls to NSLocalizedStringWithDefaultValue() that pair the English strings with unique identifiers, so that changes to the English strings don’t affect other localizations. In code shared between the iOS and OS X SDKs, the strings come from the “Foundation” table. The NSLocalizedString(), NSLocalizedStringFromTable(), and NSLocalizedStringWithDefaultValue() macros are redefined in NSBundle+MGLAdditions.h to look in the SDK bundle rather than the main application bundle. This redefinition has no effect on the host application, because it’s in an internal header. That header must be included in all files that contain localizable strings. See the header for a full explanation.

Removed the text from the iOS SDK compass view’s image, leaving only the compass plate. A localizable string is drawn atop it at runtime, along the lines of #949. Unlike in that PR, no translations are hard-coded (other than the default English string), and the system font is used.

Added a make rule that runs genstrings and ensures UTF-8 output, since genstrings insists on UTF-16. The encoding is converted in place using the built-in textutil utility. The workflow is that, whenever you add a string that should be localized, you’ll use the NSLocalizedStringWithDefaultValue() macro (making sure to import NSBundle+MGLAdditions.h), run make genstrings, and commit. Eventually, if we start using a localization service, we could use Xcode or xcodebuild to export an XLIFF.

With iOS SDK resources coming from three different directories, the resource-copying part of package.sh has gotten unwieldy. Instead of copying individual resource files around to build the static framework, package.sh now moves Mapbox.bundle into the appropriate directory. Mapbox.bundle is produced by a new build target. Now, when you add a new SDK resource, make sure to add it to both the “dynamic” and “bundle” targets in Xcode.

Replaced $BUNDLE_RESOURCES and $PLACE_RESOURCE_BUNDLES_OUTSIDE_FRAMEWORK with a single variable, $SELF_CONTAINED, that determines whether the output static framework is self-contained – that is, whether it contains Mapbox.bundle, Settings.bundle, and LICENSE.md. Eliminated the ability to produce a static framework that has the same layout as a dynamic framework. Now, resources are always in Mapbox.bundle; self-containment only determines where that bundle resides.

Added a separate source Info.plist to be placed in both the static framework and its resource bundle, but only after we give the build system a chance to expand variables within it. Now nearly all the Info.plist keys are filled in by the build system rather than using plutil in package.sh.

Implemented a localizable CLLocationCoordinate2D formatter in iosapp for use with dropped pin callouts. (Split out into #4802.) Rely on subclasses of MGLPointAnnotation instead of annotation titles to distinguish between different kinds of point annotations.

• Adopt NSLocalizedString() throughout shared “Foundation” code
• Improve localizability of coordinate and direction formatters
• Adopt NSLocalizedString() throughout iOS SDK
• Adopt NSLocalizedString() throughout OS X SDK
• Adopt NSLocalizedString() throughout iosapp
  • iosapp requires far more strings than the SDKs for little gain.
• Pass unique identifiers into NSLocalizedString() and add -a to genstrings
• Get strings from the SDK bundle instead of the main bundle
• Add make rule to run genstrings
• Share formatter localizations between iOS and OS X SDKs
• Ensure that .strings files use UTF-8 to facilitate diffing and merging
• Draw iOS compass text at runtime
• Add Mapbox.bundle target
• Streamline package.sh
• Squash 🎃

/cc @friedbunny @boundsj

[1ec5]

Translations for the coordinate formats and compass indicator are available for a wealth of languages in the CLDR package (example).

[friedbunny]

Translations for the coordinate formats and compass indicator are available for a wealth of languages in the CLDR package (example).

Coordinate format strings are definitely available (e.g. the ones you linked to, 北緯35度32分 東経135度0分 — N35°32”, E135°0”), though I don’t see the string I would expect for a compass: plain ole 北.

[1ec5]

That’s true, but I don’t foresee us automatically pulling translations from CLDR, so the choice of compass text would be up to the translator. CLDR would just be a starting point or backfill.

[1ec5]

Since I first filed this PR, I’ve made a number of changes tangentially related to localizability and made the OS X SDK localizable to boot. The additional localization resources forced my hand in refactoring and cleaning up package.sh. I left half a spaghetti dinner in there for anyone who’s interested in cleaning up the rest. 🍝 I’ve rewritten the PR description to walk through all the changes.

With our increased reliance on Xcode for project management, it isn’t clear to newcomers what each target is used for and where each build product ends up. I’ve written up a brief guide to common workflows like adding source code files and resources. Folks who’ve contributed to the iOS or OS X SDKs in the past should also take note of recent workflow changes by reading DEVELOPING.md in the respective platform/ directories.

[1ec5]

57f0a21 fixes an issue causing make genstrings to reconvert a UTF-8-encoded file from UTF-16 to UTF-8, garbling it.