NSLocalizedString...with value

Brian Nicholson bnicholson at mozilla.com
Thu Mar 24 22:59:18 UTC 2016


Hey iOS peeps,

So far, we've been using NSLocalizedString like so:

NSLocalizedString("Cancel", comment: "Title for URL bar cancel button")

This means the string is uniquely identified by itself; in other words, the
localization key and value in this example are both "Cancel". If we use the
string "Cancel" anywhere else in the app, they'll share the same key, so
the values will be collapsed when we export strings for localization.

This isn't a problem in most cases, but there are situations where we use
the same strings in different contexts. And because the contexts are
different, other languages may want to translate them differently -- but
that's not possible if they share the same key. A workaround we've been
using is to assign a different tableName to the string after localizers
point out conflicts, but that's a hack if we wouldn't otherwise logically
group the strings into separate tables.

iOS provides an extension to this API: the value parameter. This uses the
value as the key rather than the string itself. Building on the example
above:

NSLocalizedString("urlbar.cancelbutton.label", value: "Cancel", comment:
"Title for URL bar cancel button")

The export key is now "urlbar.cancelbutton.label", meaning any other
"Cancel" strings will not be collapsed into this one.

Barring any objections, let's start using this for all new strings. If we
want, we can later go through our existing NSLocalizedStrings and l10n
translations to add IDs to our current strings, but we don't need to do
that now.

One important detail: since strings are no longer identified by the English
string, changing an English string alone will *not* produce a new string
for localizers to translate. If you're making any meaningful change to an
existing string, *remember to change the key!* Trivial changes (e.g.,
fixing spelling or grammar mistakes) are exceptions; in those cases, we
wouldn't expect the translations to change in other languages.

Note that this is also how strings are defined on Android (see
https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/locales/en-US/android_strings.dtd).
You'll see lots of IDs that have trailing numbers -- these are strings that
have been updated with revved IDs.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/mobile-firefox-dev/attachments/20160324/0311b278/attachment.html>


More information about the mobile-firefox-dev mailing list