On Thu, Mar 24, 2016 at 6:59 PM, Brian Nicholson <bnichol...@mozilla.com>
wrote:
> 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.
>
Do we also want to group related strings as much as possible in separate
string tables? Does that make sense or is it good enough to have a
hierarchy in the key name?
For example the Login Manager feature has all its strings in a
"LoginManager' table. If we instead had keys like "loginmanager.password"
and "loginmanager.username", would that be enough structure?
I'm thinking of the scenario where we may want to find out if a specific
feature is localized for all locales. To decide if we can ship / enable it.
>
> 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.
>
Why is that? Why can't the localization tools deal with that? Shouldn't
they notice if the Source string changes in the XLIFF?
>
> 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.
>
We should confirm with the L10N team is that is still needed. I think this
is a really odd practice and if possible i'd like to avoid it.
S.
_______________________________________________
mobile-firefox-dev mailing list
mobile-firefox-dev@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
