Get Sideshow localized

[callahad]

We've got string extraction working, now we need to get translators on the scene.

[seanmonstar]

we contact @mathjazz? I assume its better though email?

[mathjazz]

Hey, no need for an email, GH issue is fine with me.

First, I'd like to learn more about browserid-slideshow. Is this a new project (https://wiki.mozilla.org/L10n:NewProjects) or just another part of BrowserID, like BigTent?

Figuring out the project's long-term ambitions is crucial in defining the priority of the projects to localize. "An experiment" in the GitHub project description scares me a little. :)

[callahad]

@mathjazz I'll update the description. The initial plan was for the single mozilla/browserid-bigtent repo to support all 3 identity bridges -- yahoo, gmail, and hotmail.

I was curious as to what a smaller, gmail-specific codebase might look like, so I started on mozilla/browserid-sideshow.

The experiment was a success -- our current plan is to use this codebase to support Gmail users in production. Sideshow (Gmail) is a long-lived peer to BigTent (Yahoo).

[seanmonstar]

@mathjazz is there anything else you need? Our strings are good to go from master, and './node_modules/.bin/extract-pot --locale locale .' should extract them. On Jun 26, 2013 6:09 AM, "Dan Callahan" notifications@github.com wrote:

@mathjazz https://github.com/mathjazz I'll update the description. The initial plan was for the single mozilla/browserid-bigtent repo to support all 3 identity bridges -- yahoo, gmail, and hotmail.

I was curious as to what a smaller, gmail-specific codebase might look like, so I started on mozilla/browserid-sideshow.

The experiment was a success -- our current plan is to use this codebase to support Gmail users in production. Sideshow (Gmail) is a long-lived peer to BigTent (Yahoo).

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/browserid-sideshow/issues/86#issuecomment-20045516 .

[mathjazz]

@callahad Thank you for the explanation, it makes much more sense to me now.

@seanmonstar Thanks, but I'm getting http://pastebin.mozilla.org/2568615.

[mathjazz]

Also...

ATM we have 2 BrowserID l10n projects in SVN/Verbatim: https://localize.mozilla.org/projects/. Adding the 3rd one and maybe 4th and 5th later on sounds a bit messy, because same people will be working on all o them.

So I'm thinking about merging all these projects under one umbrella project (BrowserID), which will have all these different GitHub projects in separate files (browserid - messages.po & client.po, browserid-bigtent - bigtent.po, browserid-sideshow - sideshow.po etc.).

@ozten, are you ok with that?

[callahad]

@mathjazz That sounds like a good idea to me, so long as there's an easy way to manage merging the templates?

[mathjazz]

@callahad There will be, the only thing thing that will change on your side is the URL to the l10n files in SVN.

[seanmonstar]

I believe that's saying the directory doesn't exist. Looking at other projects, do we check that directory in? I don't see it in others.

You'd need to do "mkdir -p locale/templates/LC_MESSAGES" On Jun 27, 2013 10:20 AM, "Matjaž Horvat" notifications@github.com wrote:

@callahad https://github.com/callahad There will be, the only thing thing that will change on your side is the URL to the l10n files in SVN.

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/browserid-sideshow/issues/86#issuecomment-20140738 .

[mathjazz]

@seanmonstar Whoops, I wasn't paying attention. Thanks, it works now. I'll get the repo ready for the same 50 locales that we have for the main BrowserID project.

What is the deadline for this?

[callahad]

It's 7 small strings, including "Error" and "Loading..." if we could get something in the next week, that would be fantastic.

[ozten]

Typically the directory is added from SVN in the RPM bulid.

http://svn.mozilla.org/projects/l10n-misc/trunk/browserid/locale/ http://svn.mozilla.org/projects/l10n-misc/trunk/browserid-bigtent/locale/

I'd imagine many of the strings overlap with BigTent, would be good to reuse strings to reduce L10n volunteers work.

[mathjazz]

I've put the file gmail.po files into the bigtent project in SVN for now. See the example here: https://localize.mozilla.org/sl/browserid_bigtent/LC_MESSAGES/

I've also notified the localizers, let's wait for the outcome.

Question: is it possible for localizers to test the "gmail flow" somehow? I tried using @gmail.com email address on http://translate.123done.org/ but it still tells me to check my email.

[seanmonstar]

It definitely should be. I need to find out how to get this working with translate.123done.org.

[seanmonstar]

@mathjazz How's this going? Does it seem likely we can make the proposed July 15th ship, ideally with testing beforehand?

[mathjazz]

@seanmonstar We have 24 locales that are 100% complete: https://localize.mozilla.org/projects/browserid_bigtent/

Is there any non-100% complete locale on the list I should ping?

[seanmonstar]

@mathjazz what do we ship with for browserid main, and yahoo? all of them?

One that jumps out at me is Portuguese, since we're launching FxOS in Portugal and Brazil. While the Marketplace signin doesn't allow our Gmail Bridge to work, if they use Persona from anyone other site, they'll be able to use our bridge, I believe.

I don't know at all what is typical: is it normal to not have a "train" 100% before shipping?

[callahad]

@seanmonstar The main browserid project lives here: https://localize.mozilla.org/projects/browserid

For expediency, I wonder if it makes sense to just check the resulting po files directly into git? That way if we have to roll back a string change, we'd collect the old strings automatically. Is there any benefit to pulling in things from svn dynamically?

[mathjazz]

@seanmonstar As @callahad suggested, we use https://localize.mozilla.org/projects/browserid/ to localize the main BrowserID project.

We use https://localize.mozilla.org/projects/browserid_bigtent/ to localize BrowserID BigTent (messages.po) and BrowserID Sideshow (gmail.po). Sorry about the confusion, I guess we'll soon move all l10n files to one repository and use different files for different sub-projects.

And yes, since last year (I think?) we decided it's normal not to have a train at 100% before shipping.

[seanmonstar]

@mathjazz thanks!

@callahad why checking them directly in? we dont want to stay consistent with other browserid projects? We should get this done this week, so we can confirm that languages work on stage.

[callahad]

@seanmonstar Frankly, I feel really weird just grabbing the current SVN HEAD and slamming it into our RPM. What if we made string changes in a release, but later wanted to roll that release back? We don't have a good way of reverting both code and string changes.

[ozten]

As a data point, this is how it works for mozilla/browserid and bigtent, today.

You can always identify an SVN revision and a SHA when you file the release bug.

[seanmonstar]

@callahad current practice seems to be that we check the repo and pick the revision before calling rpmbuild.sh. So, if we want to use previous strings, we just checkout a previous revision in svn.

[callahad]

I've been thinking about this a bit.

@mathjazz @seanmonstar Instead of maintaining a list of enabled locales, is there any reason not to just turn on every locale that has a gmail.po?

Empty strings fall back to English, which is the same thing you get if the local was disabled anyways...

[seanmonstar]

@callahad seems right. So, what if localeList by default is an fs.readDir of the localeDir? That way, if we want to specify exact languages for testing, we can, but default is to use all that exist.

[callahad]

@seanmonstar That sounds great to me.

Also, any strong objections to checking the localizations into git, beyond breaking tradition? The lack thereof makes it harder for contributors (including yourself, iirc) to work with a localized version, and causes more gymnastics for building RPMs -- you have to ensure access to the subversion repo at the same time, the scripts don't work on Windows, etc.

[mathjazz]

@callahad @seanmonstar A list of enabled locales was needed when we only shipped 100% localized locales. Now that we ship all locales (after they get to 100% at least once), maintaining such list doesn't make much sense, I agree.

[shane-tomlinson]

@callahad - having two repos where the translations checked in means two sources of truth. Do you want to go down that path? Can a script take care of auto-updating?

[callahad]

Closing -- sideshow is localized.