iOS Strings for Extensions

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

iOS Strings for Extensions

Stefan Arentz-5
I have been looking at the following bug:

    1196949 - Use Cancel string provided by Firefox language file

You can see this bug in action on the last 4.0 build by opening the “Firefox” or “Send Tab” extension. In the share dialog that comes up, we should replace the system provided “Cancel” with a localizer provided string. But we don’t, the english base string shows up.

The fix for this actually landed with https://github.com/mozilla/firefox-ios/pull/1677 but it did not work correctly. The fix adds those strings to our new new Strings.swift as follows:

    // SendTo extension.
    extension Strings {
        public static let SendToCancelButton = NSLocalizedString("SendTo.Cancel.Button”, value: "Cancel",
            comment: "Button title for cancelling SendTo screen")
    }

    // ShareTo extension.
    extension Strings {
        public static let ShareToCancelButton = NSLocalizedString("ShareTo.Cancel.Button”, value: "Cancel",
            comment: "Button title for cancelling Share screen")
    }

This looks good, but it does not work. Even though Strings.swift is a target member of both Client, SendTo and ShareTo, these strings are later only exported as part of the main application strings. That means that they just end up in the Client/Localizable.strings file. Which will be part of the main application bundle, where the extensions cannot access them.

It turns out this is easy to fix, because NSLocalizedString() also has a bundle: argument. So that means we can do this:

    /// Return the main application bundle. Even if called from an extension. If for some reason we cannot find the
    /// application bundle, the current bundle is returned, which will then result in an English base language string.
    private func applicationBundle() -> NSBundle {
        let bundle = NSBundle.mainBundle()
        guard bundle.bundleURL.pathExtension == “appex",
                let applicationBundleURL = bundle.bundleURL.URLByDeletingLastPathComponent?.URLByDeletingLastPathComponent else {
            return bundle
        }
        return NSBundle(URL: applicationBundleURL) ?? bundle
    }

    // SendTo extension.
    extension Strings {
        public static let SendToCancelButton = NSLocalizedString("SendTo.Cancel.Button”, value: "Cancel",
            bundle: applicationBundle(), comment: "Button title for cancelling SendTo screen")
    }

    // ShareTo extension.
    extension Strings {
        public static let ShareToCancelButton = NSLocalizedString("ShareTo.Cancel.Button”, value: "Cancel",
            bundle: applicationBundle(), comment: “Button title for cancelling Share screen")
    }

I think this is a good convention to follow. It means that:

• we can keep all our strings in a single file in the main app
• we do not have to do any of the custom copying / moving around of string files in the l10n python scripts
• for those strings that we know are used from multiple targets, we can simply use the bundle: parameter to do a custom lookup.

I think if we convert the other strings for extensions to do the same, we are simplifying things a lot wrt l10n.

I created https://github.com/mozilla/firefox-ios/pull/1768 (This fix needs to land for v4.x)

 S.

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n