Implement Android native Firefox Account sign up/sign in UI

RESOLVED FIXED in Firefox 29

Status

()

Firefox for Android
Android Sync
RESOLVED FIXED
5 years ago
9 months ago

People

(Reporter: nalexander, Assigned: nalexander)

Tracking

(Blocks: 1 bug)

unspecified
Firefox 29
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa+])

(Assignee)

Description

5 years ago
This will track all the bits and pieces for making a first class Android native sign up/sign in UI.
(Assignee)

Updated

5 years ago
Depends on: 951306
(Assignee)

Updated

5 years ago
Depends on: 951264
Whiteboard: [qa+]
(Assignee)

Updated

5 years ago
Depends on: 956816
(Assignee)

Updated

5 years ago
Depends on: 957381
(Assignee)

Updated

5 years ago
Depends on: 958879
(Assignee)

Updated

5 years ago
Depends on: 959438
Assignee: nobody → nalexander
Status: NEW → ASSIGNED

Updated

5 years ago
Depends on: 961135

Updated

5 years ago
Depends on: 961170

Updated

5 years ago
Depends on: 961176

Updated

5 years ago
Depends on: 961180

Updated

5 years ago
Depends on: 961184

Updated

5 years ago
Depends on: 961187

Updated

5 years ago
Depends on: 961198
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 "…".
(Assignee)

Comment 5

5 years ago
(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.
(Assignee)

Comment 9

5 years ago
(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
(Assignee)

Updated

5 years ago
Depends on: 961521

Comment 11

5 years ago
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.
(Assignee)

Comment 12

5 years ago
(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.
Target Milestone: --- → Firefox 29
(Assignee)

Updated

5 years ago
Depends on: 962542
(Assignee)

Updated

5 years ago
Depends on: 962597
(Assignee)

Updated

5 years ago
Depends on: 962601
(Assignee)

Updated

5 years ago
Depends on: 962622
(Assignee)

Updated

5 years ago
Depends on: 962713
(Assignee)

Updated

5 years ago
Depends on: 963184
(Assignee)

Updated

5 years ago
Depends on: 963442
Blocks: 963833
Split out remaining work into Bug 963833.

Updated

9 months ago
Product: Android Background Services → Firefox for Android
You need to log in before you can comment on or make changes to this bug.