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.
+1 on starting to do that for new features requiring strings.
To give more background, there are cases where English is inherently
ambiguous: "bookmark" can either be the name of the bookmark object
(noun), or the action "to bookmark" (verb). The only way to work around
that in the current system is to use something like "Add to bookmark"
for the action.
Also, some locales use different forms for button labels (verb) and
titles (noun), while English often uses the same.
For old strings, we need to do a clear evaluation before even thinking
about it, since it would basically invalidate all existing
localizations. The only fix for that is to script a string IDs remapping
in the XLIFF file, but that doesn't fix the issue for external
localization tools: Pontoon should be fine with (sync with repository is
bidirectional), Pootle not so much, it would probably require an ad-hoc fix.
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.
See
https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices#Changing_existing_strings
And that document is a good read in general for developers ;-)
Francesco
_______________________________________________
mobile-firefox-dev mailing list
mobile-firefox-dev@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
