Localize verification and password reset emails

[ckarlof]

Localize emails sent in #151.

[dannycoates]

The account's preferred locale needs to be set before we send mail, so /account/create should add it as a parameter.

@jedp @zaach are you able to get locale info from the device, and what does it look like?

[kparlante]

FWIW, it will be useful to have the locale for "kpi" metrics logging. We can segment by locale, and then compare by locale, and give localizers a heads up if a given locale's metrics look off.

[ckarlof]

Legal needs to be notified that this is extra data we're storing about the user in FxA. I'll take care of it.

[lloyd]

Time wise if we optimistically assume we'll get live traffic in mid march, that means localization kickoff should be in early january (meeting with l10n leads) and we should start localization in late jan / early feb.

Happy to share all that I know about l10n at moz when the time comes.

[ckarlof]

We need to start this.

/cc @lloyd @zaach @shane-tomlinson

[ncalexan]

A design question: does an account have an associated language, or is language a transient thing determined by the currently interacting client? Android will send Accept-Language with all requests very shortly, since we're biased towards a transient state. I have no idea what other systems do.

[rfk]

It's current dynamic based on the Accept-Language; IIRC we discussed caching the last-used language as metadata on the users account, but the overhead wasn't worth it. This was back when we were targetting FxOS first though, we should sanity-check if the approach still works fine for sync.

[zaach]

I've extracted the current strings here: https://gist.github.com/zaach/8659734#file-auth-messages-pot

[rfk]

@zaach does it make sense to combine l10n efforts for auth-server and content-server into a single process/repo. And if so, can we assign this bug to you? :-)

[zaach]

@rfk for extraction, having all of the resources in one place would help. For packaging/deployment, each server handles the strings differently and will likely need independent scripts. We also have i18n-abide but it's very Persona centric.

[rfk]

@zaach sounds good. What's the next concrete step to be taken here?

[zaach]

@rfk after talking with @ckarlof, we'll just keep things seperate and have grunt tasks in each repo for exporting and importing strings and building templates. I can pick this up after we get strings taken care of for desktop.

[ckarlof]

See: #536 (comment)

If we move these templates over to the content server and have the auth server fetch them as needed, we can centralize the localized strings in one place.

[ckarlof]

PR #567 should close this one too, correct?

[ckarlof]

PR #567 should close this one too, correct?

Duh. :)