 As Aurora is the sunrise, there was a project called DONG to get rid of Aurora, and at that point we merged into what we do today in terms of... Oh, that sounds different. Okay, is this now with... Okay, I keep talking. So now we chained all that, we have one localization repository in these channels. It builds twice a day now. With the latest of the localization update, we have beta releases twice a week for desktop or laptop, however you want to call it. The sign-off process still exists, but it is something that we do as a team. Every other day we go through a list of updates on our localizations and say, well, let's do something new for it. Beta and ESR is the latest version of beta for that version. So we freeze release and ESR right now, but we intend to change that. I haven't noticed. One of the things that's new, what's indicated here is Harold. Harold is part of a fabricator, which is a revenue tool, a suite of revenue tools. Originally developed by Facebook. And Harold is the tool that allows you to say, whatever someone submits a patch that touches this file, they're making the revenue process. So whenever someone attaches a patch to a fabricator that touches a localization file, they need to move one of those. So that gets me now a vestibule registrant in full that even land on ESR. So that's really helping us to kind of improve the localization readiness of our code by the time that things hit Mozilla Central. There's still one blind spot left, and that is if developers change the way that they use an existing string and don't touch the localization file, we don't find it. If you have a different project and it is on GitHub, you can use code owners, a magic file, to actually say, I want these people to be CCD on the pull request whenever someone goes in and changes this file in the pull request. We have problems reaching Mozilla Central, and we don't want to expose all of these problems and their back-outs and stuff to every localizer on the problem and the hundred languages that we do. We created a little place where we can current state of our strings and not expose them to the world yet, and our nickname for that is counter time, because then might be the pest in it, but we don't wear it. Provisers work on that directly, Francesco is wrong, Tom is wrong, and they find problems, and then you get back to the developers and say, hey, this doesn't work right, can you fix this? Or we ask the showers to actually just back it out until it's fixed. This is something that we do quite aggressively for a lot of test failures these days at Mozilla. We back things out that don't work perfectly, and we also do this for localization problems. Then Francesco goes in and publishes that to all localizations when it's ready, and that is Gecko strings. It only comes with English strings, so no code or something that is in Mozilla Central, the test cases, etc. It contains the unit of all the strings that we intend to localize. So it has the strings that are in Mozilla Central, it has the strings that are in Mozilla Beta, it has the strings that are in Mozilla Release, it has the strings that are in Com Central, in Com Beta, and in Com Release. So everything that we use to ship Firefox, Firefox for Android, Thunderbird, Seamunkey, is all gotten together and is creating one of these localization repositories that only has English strings. So that repository is then current time, and when Francesco says it's good to go, then it goes into Gecko strings, where it is synchronized from pontoon directly, and then the localizations that are done in pontoon or are done locally are written back to Elton and Central. And then they go into Firefox builds twice a day. The nickname of the code is Cross Channel because it's working across localization channels. We have not yet included our extended support releases into that scheme. We intend to do so. Right now we're rewriting our localizations from DTDs and properties into Fluent, so we don't want to keep our old files around for a year and a half, so we're a little bit hesitant to do that right now, but technically we can. And that would allow us to do localization updates on ESR. So if you had a fix that you actually wanted to publish to our enterprise releases, we could do that. Onwards to Android. There are a couple of good parts about Android. The localizable strings are actually already in an externalized file. It's called strings.xml. The strings have comments. That's nice. They're reviewed as part of the code review. They have proper ordering. That's all kind of nice. Also the engineering teams around our Android applications decided to use linear git history and no merge commits, so that's also easy to convert. So that's kind of all set for continuous localization, but there are also ugly parts, in particular around the localization infrastructure in Android. There's a bug that they will never ever fix, because if they do, they break the world. If you use quotes or apostrophes in that localizable string file, quotes are just dropped. Ampersand are apostrophes, depending on which version of the tool chain it is, I think either cut the string off or completely break the build. And if you want to escape a string like that in an XML file, you either quote it in double quotes or you use a backslash, which I think tells a lot about how that tool was written in its first iteration, and that's what we have. So it's really difficult to find out what to do with that stuff. Also, the file locations contain something that is similar to a locale code, but is never a locale code. So instead of saying DE minus DE for German as in Germany, they put an R in, because that's a region. And then they have this thing where they say, and now we actually have unicode locale codes, but instead of using a minus or an underscore, they decided to use a plus as a separator between those things. So if you want to support a tool chain that writes these files back, you need to have completely custom logic for Android locale codes, not to mention that they still live with an old Java bug that used IN for Indonesian and weird locale codes for Hebrew and there are four locale codes that have absolutely nothing to do with each other. The way forward. We need to kind of talk to the engineers and say, please only do the things that we know we understand, because the documentation is really dodgy and you can put strings wherever you want. They don't need to be in strings XML. And with that subset, you can write tests that ensure that the things are actually the way they are. And we add support for like locale codes. And then pontoon can actually be made to localize Android apps directly. So if we have an Android app and we want to localize it, we can just set up pontoon directly to that repository. It can decide on whether it writes to master or to a branch and then things can just go. The other thing is that a lot of our Android applications share a lot of strings. So Firefox for Echo Show is pretty much the same thing as Firefox for Amazon TV. And Focus has a lot of overlap with it and Firefox Lite has a lot of overlap with it. But then Phoenix probably won't and Android Components doesn't and we still want to get one project for the whole thing. So what we want to do is we want to start with like the Android product repose which is like all the Android related application repositories plus Android components. Build a unified repository out of them, put them into quarantine because also that needs a quarantine. If that succeeds, get them into ENUS, get them into pontoon, write back localized files into the same repository as Android strings would expect them and then write that content that is required for each application back to the Android product repository probably on a nightly basis. And then because Android just builds what's in the repository, you automatically get localized builds. We can publish them on developer channels and we can also run screenshot tests because that is something that has pretty good infrastructure on mobile devices. Sadly it doesn't on desktop which is something we might fix eventually. And that is as far as my slides go. And now I would love to get some questions and I might have some answers. So my question is how big a team is doing only localization at Mozilla? Any other question? We want to share something.