Closed Bug 701027 Opened 13 years ago Closed 12 years ago

BrowserID has no localizations

Categories

(Mozilla Labs :: Identity, defect)

Product:
Mozilla Labs
Component:
Identity
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: tofumatt, Unassigned)

References

Details

Hi there Identity/Labs folks. I'm a webdev at Mozilla. I work a lot on Mozillians, which is planning on dogfooding BrowserID. I know skinny (Crystal Beasley) has been helping improving the UX of BrowerID's flow and its integration into Mozillians so the experience is less jarring. That's great, however:

I've noticed a serious shortcoming to BrowserID adoption: it is English-only. BrowserID, and the notion of cross-site single sign-on not attached to an identity like Facebook, is a strange concept in general -- even if it's a good idea. For many users, I imagine we'll need to do some on-the-spot education (even if it's just a sentence or two on the BrowserID popup) so they know what's up. But both the log in popup and the BrowserID site aren't localized at all. I'm worried this will confuse non-English-speaking users.

We should localize at least the BrowserID sign in/sign up flows.
OS: Mac OS X → All
Hardware: x86 → All
Blocks: 665373
Matt, Aakash: agreed that this is a short-coming, and we are working on it. However, I would ask that we not make this a blocker. I understand some confusion will result, and I'm happy to be upfront about it in a public post that blames the identity team, but we need to be able to move forward on dogfooding even if all the wrinkles are not ironed out.
Hey Ben,

I'm afraid I don't agree here. Mozillians.org will have 19 languages it's translated to by the time of release for our next iteration:

https://localize.mozilla.org/projects/mozillians/


I'm afraid this does block as a half-translated website, especially one as important to our very geographically diverse community,is a big no-no and will likely de-motivate localizers quite a bit. With that said, tofumatt and I have been talking to Milos from the L10n team and they've been notified of the need to localize on Affiliates and Mozillians.org. Can you or ozten speak with them on the needs of BrowserId as well as the roadmap? 

It pays to care about localizer community who do great things for us here at Mozilla to localize our web properties and products to their own native countries (and increasing adoption for those products by significant amounts!).
I filed this as a more general BrowserID concern -- it's my understanding that Mozillians is going BrowserID regardless of localization. I'm not super stoked about that but it's not my chief concern right now.

I'm voicing my concern because Mozilla is all open community and a global presence, and BrowserID is a foreign, uncommon flow for a lot of "average" users -- they're used to passwords, mostly. Even as a technical user I had to read about BrowserID to create my account and sign up/log in with it.

I'm worried that adoption of non-English users will be frighteningly low if BrowserID isn't localized. If I visited an entirely English or French site with a Russian log in pop-up I'd never seen before and didn't recognize, I'd close it (and, in fact, most online safety tips include "don't sign in to things you don't recognize/seem fishy"). If a user is one of our sites in a non-English language, we're basically exposing them to this flow.

Localization is work, and I also know you folks are doing a lot of UX/string work, so translations may change quickly. Failing translations, is there some kind of non-linguistic imagery we can use to illustrate the flow to those non-English users out there?
Matt: agreed, there will be some confusion, that's why we're doing a lot of outreach, and writing things like: http://identity.mozilla.com/post/12950196039/deploying-browserid-at-mozilla

And I hear your concern about internationalization. It's not that I don't care, it's that we're blocking on *everything* except actually helping our users manage identity. I think making identity the very last thing we consider is quite wrong, and hurts our users.

Aakash: I really need your help here. Saying BrowserID has to be perfect before you adopt it is not a workable approach for dogfooding.
> And I hear your concern about internationalization. It's not that I don't
> care, it's that we're blocking on *everything* except actually helping our
> users manage identity. I think making identity the very last thing we
> consider is quite wrong, and hurts our users.
> 
> Aakash: I really need your help here. Saying BrowserID has to be perfect
> before you adopt it is not a workable approach for dogfooding.

I'm with you on dogfooding the product, actually. Yet, you're asking to have this feature that breaks flow for a high priority set of my users (South Americans, Asian locales) that can't use the site. You can't ask users to dogfood something they don't understand or can even give product feedback when they're likely to only give feedback about the fact that they can't understand the text.

For example, lets say I'm a Portuguese speaker (our entire Brazilian community) or Spanish speaker (pretty much all of our South American community) and was told that Mozilla wanted my help in testing this piece of software (which is what we'll do when it gets out onto Mozillians.org, I'm assuming). How could I if I go to the site, see Portuguese or Spanish, but then only see a new log-in feature that I've never used and is in another language? 

It doesn't need to be perfect, but it needs to get to a point that it's usable for the people that you're asking to dogfood it to.
We have people using sites like AMO or SUMO that don't really understand English, so before sites like that adopt BrowserID, it needs to be localized. I'd see it as a blocker for adoption on those sites for sure.
On more developer-oriented sites I could see it being used before it's localized into major languages, but those consumer-facing ones can't do without a localized experience.
Btw, two things to note and then a question:

1. It does not take long for localizers to finish their translations as long as they have a week's worth of time, generally.
2. I said the strings for BrowserId should be localized, but I did not say that all localizations need to be completed. We're working with a volunteer force, so I'm just looking for them to be included.



So, just how many strings are there in the app that need to be localized?
Aakash: I don't know yet. What I do know is that making this issue a blocker will almost certainly mean missing this quarter.
(In reply to Ben Adida from comment #8)
> Aakash: I don't know yet. What I do know is that making this issue a blocker
> will almost certainly mean missing this quarter.

I feel like I may be missing a piece of context here, is there a place where you or somewhere else has analyzed that the act of blocking based on localization will require a month and a half's time (or more) to perform?

If not, then how about we get the people that are actually doing this work to give us proper estimates of time and work needed to get this done and mitigate as needed from there before making any other assumptions?

This is outside of my roles and responsibilities, but I can follow up on the strings that are needed to localize BrowserId with Milos and Austin and then we can decide on this.
(In reply to Aakash Desai [:aakashd] from comment #9)
> I feel like I may be missing a piece of context here, is there a place where
> you or somewhere else has analyzed that the act of blocking based on
> localization will require a month and a half's time (or more) to perform?

The issue is not the translation itself. I understand that this is a few days of work. The issue is that BrowserID itself is not ready for translation (server framework, frontend JS framework). Adding that capability when we're spending a chunk of December moving to the production environment is fairly unlikely.

We were not expecting this blocker.
I was not proposing this be a blocker when I submitted the bug. Like I said, I wanted to bring up the issue and have it on file, because localization is important to our web apps in webdev.

I also said that I didn't want to discuss this being a possible blocker for Mozillians here. It seems the conversation has migrated that way because Mozillians will be one of the first web apps to ship using BrowserID, so it's not entirely misplaced, I suppose.

I'm gonna try my best to capture my thoughts on what's happening here, both in regards to BrowserID and Mozillians. Here's my take:

* I don't like launching web apps, particularly small ones focused on community, that aren't localizable. Including BrowserID on any website effectively makes it impossible to localize 100%.

* We want BrowserID to succeed, and I think launching it without polish -- like localization -- isn't putting our best foot forward.

* I understand that some larger web apps ship with translations that are not 100% completed. I understand that sometimes it's better to get the product out there and translate things later (Twitter is a good example; their localizations came late in the game and are still relatively low in number to the best of my knowledge).

* English is a pretty common default language on a lot of the web, and if the English copy for BrowserID is clear enough (and there's some kind of non-language-based guides too?), it can be understood by second-language English web folks or even translators. That could help.

* My life as a developer, from what I can tell, will be made vastly better by using BrowserID in Mozillians. I can cut out a lot of templates, code, etc. I can even offload some localization to BrowserID when it's ready for that. I am not against implementing BrowserID and in fact benefit from it as a developer immensely.

Ultimately, I don't think it's my decision to decide what's up with Mozillians implementing BrowserID. I also don't want my criticisms of the current state of BrowserID's localization to be taken as my advocating we not use it on Mozillians. My concerns are largely focused on BrowserID and its UX, not Mozillians.

I _don't_ see this as a technical blocker. I might be a loudmouth and like to be involved in non-technical discussions, but my job on Mozillians is one of development lead. In that "official" capacity, I don't advocate this being a blocker.

I _do_ worry about the UX issues of non-English users going through BrowserID. That is a somewhat technical issue, I think.

I _don't_ think this is a lot of heads-up on a blocker that essentially stops a lot of stuff from happening with both BrowserID and Mozillians for this year.

I _do_ think the decision here is a simple one: is it more important to have BrowserID in Mozillians, or have a Mozillians that is 100% localizable?

**What is better for our users?**

I don't think I'm the one to make that call -- or at least I don't think I have the authority to make it. Furthermore, I'm not sure either outcome is particularly super-happy. Is Mozilla's commitment to identity and our goals of using BrowserID more important than localized web apps? If so: this isn't a blocker.
Thanks for the analysis and thoughts, Matt. It's much appreciated and you added some insights that I didn't know about. Ultimately, any decision for Mozillians.org is my call. 

(In reply to Ben Adida from comment #10)
> (In reply to Aakash Desai [:aakashd] from comment #9)
> > I feel like I may be missing a piece of context here, is there a place where
> > you or somewhere else has analyzed that the act of blocking based on
> > localization will require a month and a half's time (or more) to perform?
> 
> The issue is not the translation itself. I understand that this is a few
> days of work. The issue is that BrowserID itself is not ready for
> translation (server framework, frontend JS framework). Adding that
> capability when we're spending a chunk of December moving to the production
> environment is fairly unlikely.
> 
> We were not expecting this blocker.

Ben,

Neither was I and, sadly, do not know about where the app really is at in its charge to be production ready. 

If BrowserId was simply a secondary option to the normal log-in procedure, then I would have no issue blocking L10n. Yet, that's the not the case here. 

After speaking with Milos from the l10n team, I believe he'll have an answer for us sometime today. I'll wait on that to make a decision.
HI all,

Just jumping as the Affiliates product owner as we have been working to add browserID to Affiliates as well. Adding browserID without localization will create a really bad experience for a least 30% of our users (esp since we're adding more locales every few weeks). 

I agree that we need to dogfood browserID, I really want it on this site, but this will effect too many of our users negatively and sends a really bad message to the locales we've already been working with. 

Do we have an estimate on when browserID will be localized? I know there have been a lot of conversations going on with this, but I'm in Asia right now, so I'm more than a little out of the loop.

Let me know when you can and thanks!
Hi Chelsea,

Thanks for your input on this.

We do not have the mechanism for i18n in BrowserID yet. I don't think we'll be able to have l10n ready until January at the earliest, probably more like February.

As I've mentioned to Milos and Aakash, I'm concerned that we seem to be blocking on every feature *except* that of streamlining login for our users. Dogfooding comes with some inherent pain, and waiting until BrowserID is sufficiently stable that it can be fully l10n is not the right priority, in my opinion.
Aakash: on the phone today, Milos said he was okay with Mozillians moving forward without l10n given that 90+% of users are en-US. I'll let him confirm, but since I'm away on PTO next week I thought I would mention it now in case it unblocks other issues.
(In reply to Ben Adida from comment #15)
> Aakash: on the phone today, Milos said he was okay with Mozillians moving
> forward without l10n given that 90+% of users are en-US. I'll let him
> confirm, but since I'm away on PTO next week I thought I would mention it
> now in case it unblocks other issues.

True. Given that more than vast majority of our userbase are en-US users, and that probably all of them know English, I can give a green light for the l10n part of Mozillians.

Anyhow, I still do not agree with having unlocalizable login as the only option on Affiliates website. As Chelsea said, that's going to affect one third of our users, and there's no way for us to know whether they can actually read English. Also, UX is going to be really damaged, thus I still strongly object to BrowserID replacing legacy login.
Yep, we're good. BrowserId won't block Mozillians.org, but we do need localization to be added asap.
(In reply to Ben Adida from comment #14)
> Hi Chelsea,
> 
> Thanks for your input on this.
> 
> We do not have the mechanism for i18n in BrowserID yet. I don't think we'll
> be able to have l10n ready until January at the earliest, probably more like
> February.
> 
> As I've mentioned to Milos and Aakash, I'm concerned that we seem to be
> blocking on every feature *except* that of streamlining login for our users.
> Dogfooding comes with some inherent pain, and waiting until BrowserID is
> sufficiently stable that it can be fully l10n is not the right priority, in
> my opinion.

Hey Ben, 
I completely understand that, but as such a large part of our user base is not EN-US it would create a negative experience for too many users. Having an affiliate arrive at the site to have to deal with a new login is one thing to ask them to adjust to (a change I support), but asking them to deal with that change in a different language at the same time sends a very bad message IMO.

Let me know if you'd like to have a meeting with Jane and I next week to discuss this in more detail.
Watching from the sidelines, but having been involved heavily in both community and L10n for a long time, I need to says that 1) it's sad that the BrowserID UI hasn't been done in a localizable way from the beginning, which should be good style for any Mozilla web app nowadays, 2) I agree with not blocking the switch of things facing to our community only like Mozillians to BrowserID on this being fixed and just have it as "highly wanted there" but 3) think that switching anything faced to the larger public like Affiliates, AMO, SUMO, MDN etc. to BrowserID should be blocked on this.
> blocking the switch of things facing to our community only like Mozillians
> to BrowserID on this being fixed and just have it as "highly wanted there"
> but 3) think that switching anything faced to the larger public like
> Affiliates, AMO, SUMO, MDN etc. to BrowserID should be blocked on this.

Kairo, I don't think it's fair to lump these four sites together. After talking to Jay about MDN, most of that site is not localized (there's far too much content) and he's said that many tech doc writers don't want to have that highly technical documentation localized either way (check out Webtrends).

On a semi-related note, if BrowserId is a secondary option to log-in then I don't think this is that big of a deal. This increases user choice, while allowing for greater adoption and testing of BID. The hard part here is that the BrowserID team is taking the option of making this a primary option on sites as their strategy of adoption and testing which is a tougher pill to swallow for product owners and users.
Dan or Ben, is there some sort of whiteboard entry we can add that labels this as a Q1 goal for your team?
(In reply to Aakash Desai [:aakashd] from comment #21)
> Dan or Ben, is there some sort of whiteboard entry we can add that labels
> this as a Q1 goal for your team?

it's definitely a goal already, with Austin leading. Is there a place we should make that more explicit?
> it's definitely a goal already, with Austin leading. Is there a place we
> should make that more explicit?

Wherever the team puts down their quarterly goals. There's a number of avenues that folks use: the intranet wiki (e.g. /Goals if they're high-level), the team's public wiki page, google spreadsheets, bugs in Bugzilla (e.g. using the whiteboard entry), feature wiki's, product roadmap wiki's or others. 

Where does the identity usually put down your roadmap and/or goals information?
I CAN HAZ LOCALES? I THINK SO.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
YEEAAAAAAA BOOOOYYYYYYYYYY
Wooo Hoooo!
:-)
You need to log in before you can comment on or make changes to this bug.