This will track all the bits and pieces for making a first class Android native sign up/sign in UI.

https://hg.mozilla.org/services/services-central/rev/8fc7a4a60b60 https://hg.mozilla.org/services/services-central/rev/7663f31addd1 https://hg.mozilla.org/services/services-central/rev/f6bb819d8fc6 https://hg.mozilla.org/services/services-central/rev/ddf2f427b7b5

Follow-up for a missing file. https://hg.mozilla.org/services/services-central/rev/9989dd9ce6fd

https://hg.mozilla.org/mozilla-central/rev/8fc7a4a60b60 https://hg.mozilla.org/mozilla-central/rev/7663f31addd1 https://hg.mozilla.org/mozilla-central/rev/f6bb819d8fc6 https://hg.mozilla.org/mozilla-central/rev/ddf2f427b7b5 https://hg.mozilla.org/mozilla-central/rev/9989dd9ce6fd

Using this bug since it's referenced in the landing. Are these strings final? All links point to mozilla.com. It doesn't look right. Please tell me these aren't just placeholders and need updates later ;-) <!ENTITY fxaccount.status.syncing 'Firefox is syncing...'> Is this hard-coded "Firefox" OK? It shouldn't be "..." but "…".

(In reply to Francesco Lodolo [:flod] from comment #4) > Using this bug since it's referenced in the landing. Are these strings final? > > All links point to mozilla.com. It doesn't look right. Please tell me these > aren't just placeholders and need updates later ;-) > > <!ENTITY fxaccount.status.syncing 'Firefox is syncing...'> > > Is this hard-coded "Firefox" OK? It shouldn't be "..." but "…". Nah, not final. I have no idea what the URLs will be. All strings are prefixed fxaccount. and we'll be doing a final pass as 29 Nightly merges into Aurora. Thanks for the reminder to be more clear on this!

Exposing not final strings to the localization process is never a great idea (see bug 961009, same feature but for Firefox OS). First consequence is that you'll need new IDs for every single string you change, another consequence is that localizers on central will have to localize them twice. I must admit that I don't fully understand Android when it comes to string. Since these are not final, would it be possible to strip the HTML from those strings with links? It's extremely confusing and error-prone.

(In reply to Francesco Lodolo [:flod] from comment #6) > Exposing not final strings to the localization process is never a great idea > (see bug 961009, same feature but for Firefox OS). First consequence is that > you'll need new IDs for every single string you change, another consequence > is that localizers on central will have to localize them twice. In this case, we're under enough time pressure (a brand-new feature that needs to ship in 29, and involves testing across server, desktop, and Android) that the needs of getting UI landed and testable outweighed our usual inclination to wait for final strings. We just don't have the time to hold off on landing core patches. We'll be sure to rev string IDs when we're updating the UI, as normal, and I do apologize for creating extra work for localizers. We're doing the best we can to avoid having to land new UI and new strings during Aurora or Beta, which I understand to be an even bigger inconvenience to our localizers.

That target version terrifies me… Do you have any info it this is possible on Android? > I must admit that I don't fully understand Android when it comes to string. > Since these are not final, would it be possible to strip the HTML from those > strings with links? It's extremely confusing and error-prone.

(In reply to Francesco Lodolo [:flod] from comment #8) > That target version terrifies me… Very reasonable, but so it goes. > Do you have any info it this is possible on Android? > > > I must admit that I don't fully understand Android when it comes to string. > > Since these are not final, would it be possible to strip the HTML from those > > strings with links? It's extremely confusing and error-prone. What would you prefer? I figured it was better to translate a single sentence with two links in it than 3 sentence fragments and 2 links that are supposed to be concatenated together in some inflexible way.

There are two strings with HTML code in it <!ENTITY fxaccount.old.firefox '&lt;a href="http://mozilla.com"&gt;Using &syncBrand.shortName.label; with an older version of &brandShortName;?&lt;/a&gt;'> In this one is clearly unnecessary, since it wraps the entire string. About the other one (fxaccount.policy): concatenations are bad, substitutions are good. fxaccount.policy.text "By proceeding you agree with the $1 and $2." fxaccount.policy.linktos "Terms of Services" fxaccount.policy.linkprivacy "Privacy Policy" Replace $1 and $2 with active link+string

FWIW: If you want to hack on UI with non-final strings, just don't expose the strings to l10n. You can hard-code the en-US content directly in strings.xml.in as long as they're temporary, and then externalize them when they got final copy.

(In reply to Axel Hecht [:Pike] from comment #11) > FWIW: > > If you want to hack on UI with non-final strings, just don't expose the > strings to l10n. You can hard-code the en-US content directly in > strings.xml.in as long as they're temporary, and then externalize them when > they got final copy. Axel, thanks for this. Super useful to know; we'll be doing this from now on. If we back out all the existing strings from the dtd files, and move them to strings.xml.in right now, can we stop (most) localizers from seeing them?

Seven locales already translated these strings, and from my point of view only some of them need updates (3 of 42), so it would be bad to waste this work. My suggestion is to keep the strings already landed in sync_strings.dtd, and start updating/adding strings in strings.xml.in as they're needed, without exposing them to localizers. When the copy is final, merge them to sync_strings.dtd, removing obsolete strings and adding new ones. This process can work as long as you don't update strings already landed in sync_strings.dtd If you have any doubt about strings in the meantime, feel free to cc me to bugs.

Split out remaining work into Bug 963833.