 So yeah, I'm going to talk about my work with the New York Times, really the past year, I guess. Seems like every year I'm kind of talking about what my big project was for the year. And this year it was internationalization. Times has a big initiative called MIT Global, where figuring out what it means for the New York Times to be internationalized. And you know what it takes to do that within the company. So yeah, I'm here with my wife Allie. That's what I say real quick. She was voted for 40 under 40 in New York City politics. She works in animal rights. I'm very proud of her, so I just wanted to shout out to her real quick. She's the brilliant one in the relationship. I'm just going to talk about JavaScript and stuff. And then we have, those are our cats, Willa, Waffles, and Felindia, and I just wanted to shout out to them real quick. So yeah, I am Scott Taylor. You may know me from doing work in WordPress. But I've been at the New York Times for about three and a half years, I guess. Before that I was at a company called eMusic for about five years. When I first started at the Times, I was on the blogs team. The Times used to have a very traditional WordPress footprint where they had the main website. And then they had a bunch of blogs scattered about that used WordPress. Blogging in general has kind of collapsed into section fronts and just kind of columns and there really hasn't been a big thing at the Times lately. So a lot less stuff on that. Interactive News, the talks I gave last year were about the live coverage platform. We built using WordPress and at the time the newly christened REST API. And then now I'm actually on a team called Web Frameworks. We are working on building a new stack for the New York Times built on Node.js and React. So I'm going to take you through a lot of the different technologies we're using to do those things. So yeah, the New York Times recently launched New York Times in Espanol. If you go to nytimes.com.es, that's actually the first internationalization project we've done. And it's actually not a lot to it. This is what the homepage of it looks like. This is what sort of a section front or collection or in WordPress terms archive page looks like. And then this is, you know, an article. And in WordPress we already have these paradigms. You know, we have the next page, we have archive pages and we have posts. So it really wasn't doing anything crazy to do this in WordPress. In the Times general architecture for the website, these things are all separate apps. They're all separate PHP apps built on like a homegrown framework, which is a lot more complex. WordPress actually kind of exposes how easy it is to do this kind of stuff. But why did we use WordPress specifically when we wanted to do internationalization? Well, a couple of reasons. One was the CMS portion. The Times is built and kind of exists on this homegrown CMS called Scoop, which is written mostly in Java and CoffeeScript. And making changes to Scoop or trying to interrupt the publishing pipeline midstream is not, it's a little complicated and it's also dangerous and it's not as simple as doing the things we do in WordPress. They kind of wanted to do, let's try out internationalization on WordPress and then we'll fix all the stuff in our homegrown systems and then we'll get rid of the WordPress project. Well, the WordPress thing has been running for a couple of years now. So WordPress makes it easy to do something like internationalization because we can use a multi-site setup to where nytimes.com slash es. That slash es is just a site in the network. Each site in the network has its own specific options or settings, which you can include locale. So the thing about WordPress you get out of the box is that WordPress already has internationalization laced completely through it. So if you've ever used the translation functions to print out strings or numbers, it's already there. A lot of software at companies that write proprietary stuff, internationalization is not built in at all. So one of the initiatives with this nyt global thing is looking across the New York Times code bases and figuring out how do we first internationalize them. Because there's two pieces to internationalization. One is the taking your code base and setting it up to where it can be translated. And then there's localization, which is providing the translation files. And so you can actually, when you're in Spanish and you've set the locale to be in Spanish, you can provide translation files for it to render in Spanish. This stuff is actually pretty commonplace in WordPress. In software in general, there are tools to do this, but a lot of people don't approach their products with localization in mind. And even at the times, it never came up until we decided, oh wait, you know what, we want to have this global presence where we're actually presenting content in language. So once you've had the translation files, which is actually just translating the hard-coded strings that are throughout your code, WordPress also, because we're on the ES site and the multi-site network, they can just write in language. So there's nothing enforcing the content of the translation and the content of the fly. There's writing in language. But multi-site gives us a great way of partitioning by language. So if we wanted to do Portuguese or Japanese, whatever, we could then do slash JP for Japanese, and that would be all of our Japanese content and all that. And also, there was a pretty good workflow I had with using Gulp to be able to generate these translation files pretty easy. And the other thing about WordPress that makes it appealing for doing projects quickly or doing projects kind of isolated is that you control the front end and the back end. So at something like the New York Times with Scoop, Scoop's kind of like this back end that provides data and then we have this framework called MIT5, which is the front end. So MIT5 people can't really control the back end and Scoop can't control the front end. With WordPress, we have both, which is why WordPress was a pretty good choice for doing this. So I mentioned one of the things that really helped me was using Gulp so that it may end up in the future that we have 10 different languages we're supporting for translations. And all of those different sites are going to require translation files like these .po or .mo files. And one of the complicated workflow things is how do you generate these files and how do you, you know, how do you translate your code base to be in a certain language? Using Gulp, Gulp actually has a lot of plugins for doing stuff to generate profiles and to generate .mo files. Gulp is written in Node.js and it's similar to Grunt. If you've ever used Grunt, Grunt's very much configuration-based. Gulp supports a lot more Node.js paradigms and is a lot faster and more streamlined. We also built, our platform we used to deploy this stuff was built on Docker. And if you work at a bigger company that has to deploy to various servers, Docker and containerization are becoming a pretty common place for describing your servers or your setups. We've also used Puppet in the past, but it's basically Docker's a way of describing, I need Linux, I need Nginx, and then here's my code base, and that container will be the same on every machine it's deployed to. Docker, the way we deploy and interact with our deployments is through Kubernetes, which is by Google. It's instrumentation for Docker containers. And what this means is that through some configuration files, I can go in there and say, I want this deployed eight times. I want this deployed six times. It allows me to scale those instances. So some of the other things we used when we were internationalizing Amazon Web Services, we needed to hook into our search service at the New York Times so that when we update a post, our search team can dynamically update our sitemaps so we get highly ranked in Google very quickly. There's a lot of very newsworthy things in the New York Times, obviously, so if we have a live blog or a live coverage going, or if we have something that's very timely, doing this using SNS and SQS, which are from Amazon Web Services, allow us to get ranked highly in Google very quickly. We also provide, using the REST API, the data we have for the Spanish site. When you save a post, we actually generate JSON files in a New York Times JSON format and upload them into S3. Those files get served by a service called Sami's Dot, which is internal, which actually powers the data for Android app, iOS app, Kindle, that kind of stuff. We use RDS, which is a MySQL service from Amazon. We use ElastiCache, which is a memcached service from AWS. But none of this really matters because we're actually switching over to the Google Cloud Platform for a lot of this stuff. So one of the themes here, and you'll see as I keep going through my slides, is that there's a lot of stuff to kind of get your hands around to learn, and then everything's always changing as you're doing that. So just when I thought I had finally learned enough about AWS to where I could kind of manage a system and I could deploy stuff, and I kind of knew what was going on, we're moving a lot of stuff over to here. For a long time, there was really AWS, and then eventually there was Azure from Microsoft, which not a lot of people quickly ran over to. But Google's getting into the game now, and the things I was talking about, Docker and Kubernetes and like Container Engine, make it pretty easy to get on Google's infrastructure, which is extremely reliable and extremely fast. Some of the stuff Google offers is 52 or 100 times faster than AWS. Okay. So this begs the question, when we start projects like this, nowadays what is a PHP project? Because your project may start off something like this. This is a traditional WordPress setup for people that are doing a highly customized thing. You're not just going to plop WordPress files into a folder. You're actually going to have WordPress in a subfolder. You're going to have your WP content, which will serve your site stuff. You're probably going to have JavaScript there. If it's just either to do build processes, to do tasks, or to actually, you're going to use it to download your libraries and compile your JavaScript for the front end. But there's a lot going on. You really become like a full stack developer these days when it's like you're having to deal with the PHP, you're having to deal with the JavaScript, and sometimes actually having to deal with the back end, too, and the deployment itself. And so internationalization for us was a project to where we had a lot of control because we control the Docker file, which means we can control the version of the PHP we're using. We can control how we're talking to MySQL or Memcached, and we chose to use ElastiCache and RDS in those situations. But you can also like, WordPress is a very small part of this whole system. It's definitely a big part, and it's going to be our admin, and we're going to use the traditional structure of it providing our rewrites and our theme into extent. But there's a lot going on that has little to do with WordPress. Another thing, too, is that once you really understand WordPress and you're in kind of your own environment to where, you know, this is a lot different than starting a blog on Dreamhost or something, and WordPress is just kind of off to the side, and you're going to get auto updates and all that kind of stuff, and you're going to install plugins from the admin. WordPress is really just kind of a set of tools available to you, and you're kind of free to do with it what you want. This is actually our index.php. When you use, when you just download WordPress, WordPress actually has to do a lot of guessing and figuring out where your configuration file is, whether you have MySQL installed properly, whether you've actually installed your database, all that kind of stuff. But when it gets on the brass tacks, you're eventually just going to do this, and this is the equivalent of like index.php, blogheader.php, and the template loader kind of all in one. And in our version here, we're basically saying, yeah, load our config file, do the initial WordPress request, and then at the bottom there, we're going to say fire our action, which is how we're going to render our templates, which is not going to use the traditional theming that WordPress gives us. And when you see something like this, you can actually imagine a scenario where you're using a different framework to render your site, and then you can just fall back to WordPress when you need to. So you can imagine like an if-else statement where you could even have a different framework in here, and then if you're like, no, actually it needs to go to WordPress, you just load all this stuff. Okay. So one of the things that makes up a PHP project these days so if we look at like, I have a blank slate, I am going to start a PHP project. It's 2016. What would I do to start that project? WordPress may come into it, and WordPress may not come into it. Composer is a package manager for PHP, and Composer gives you access to a whole plethora of libraries that you can use to write PHP code. If you've never seen a file, it looks something like this. And what you'll notice if you've ever done anything with NPM or Node.js or your package.json file is it's actually very similar. So I think there's a difference between WordPress and a PHP project, and there's also a difference between a PHP project that uses WordPress or not. But if you were today going to start a PHP project, it might look something like this. And if you can see in here, there's a difference between a WordPress install that's going to be like a DreamHouse blog and a code base that you're going to have under version control and that you're going to want to lock the version numbers of plugins and libraries and all that. WordPress has a great auto-update system to where you don't have to do anything and WordPress will update your site for you. But that can be problematic switching from version to version if you're using version control and if you have a continuous delivery setup or if there can be breaking changes from version to version. The same thing is true for plugins. But what Composer can give you is there may be something WordPress doesn't provide and is available in the PHP ecosystem that you want to pull in for your project. And there's nothing stopping you from using WordPress and using other PHP libraries. Okay. And another piece here, you can see how in the bottom of the set here it says W Packagist. So the entire... I could be wrong about this, I think the entire plugin directory is actually mirrored in W Packagist plugin to where you can actually load your WordPress plugins for your project via Composer. And it'll put them in the proper directory in WP Content Plugins so that you can actually have a list of the stuff your project requires in here. And then you can either check that stuff in or you can have it where people's individual setups when they run Composer install, they get that stuff. And also your Composer file is where you set up your PSR4 namespaces so that if you're writing PHP 7, PHP 5, 5 code and you're using more of the object-oriented stuff, you're really describing your project here. And then something else you get with PHP projects that aren't necessarily WordPress projects is you can do more sophisticated things with registering stuff kind of in global scope to be available to your project. So one of the things I've been complaining about in WordPress for years is all the stuff that's in global scope. And you don't have to do that if you're using... And I'll show you some of these tools coming up, but if you're using a dependency injection container to where you have one place called App where you're putting all of your global stuff you want to use. This is also typical of a lot of PHP projects where once you include the autoload, the vendor autoload, then you kind of have access to everything. You don't have to require files to start using them. You just have access to whatever tools you've described in your Composer JSON. Okay, one of the other decisions I made when we were doing the internationalization project was to use Mustache, which is logic-less templating really in almost any language. One of the things WordPress does by default throughout the admin and throughout theming is actually uses PHP as a templating language, which is okay, but what happens is that you're not really describing your data ahead of time. A lot of times you get to the template and you're doing business logic or you're actually making database queries or you're making HTTP requests to get your data, and there's not a clear separation of what is code that's running and what's templating. Mustache helps with doing that, and this is an example I did. I've been doing a lot of experiments around where could WordPress go code-wise, and this is an example of one of the admin pages. Those of you who've done WordPress core development or ever looked under the hood of WordPress, there are some PHP handlers that are a giant mix of code variables, templating, output, just all kinds of crazy stuff, but when you get to, if you actually use a templating language, it gets very simple to describe your UI, and then somewhere else you can actually really strictly define what your data is that you want to use. Another piece we used, WordPress really, you don't have to rely on WordPress to give you the best version of every tool you might need, so WordPress a lot of times is just going to give you the tools that it needs to do its thing, and it's not gonna actually try to give you a full-featured version of everything. So we use Guzzle to do HTTP stuff, and Guzzle was written by the guy who wrote the Amazon SDK for PHP, and so it's very modern and does things like pipelining, and does promises, async, all kinds of nice stuff. So when we look at PHP projects, we already have an example of symphony, which provides best-in-class PHP components. So if you're doing your own PHP project, there's something stopping you from also using stuff from symphony. Symphony is actually built a nice way to where you can use the parts you want, and you don't have to take all of it. It's not an all-or-nothing approach. WordPress, in a lot of ways, is an all-or-nothing approach unless you kind of know how to massage things in and out of it. We use HTTP Foundation. One of the things in modern PHP projects that's suggested is to not use Superglobals everywhere, which is like the capital get or post or server variables. HTTP Foundation allows you to do that. It gives you a whole API to access that stuff in an immutable way without having to touch all those things. Another piece is that WordPress provides kind of this big, huge database object, but one of the things it does not do is give you an API to generate select statements in SQL. There were some custom database tables we needed to add, and that's something too. In the WordPress paradigm, we tend to issue doing complicated things with the database because we kind of allow WordPress to do all of that. But when you get into the state where you need something global in a multi-side instance, you may need data that is accessed by everything. It doesn't make sense to be a custom post-type. When you need to interact with the database, Doctrine is kind of like a best-in-class tool to do that. The thing I really like about Doctrine is that when you start doing a complicated project, you're going to definitely want unit testing and you're going to definitely want a lot of your use cases. You're going to want an expressive tool set to take care of a lot of your use cases, and you're going to want caching to be taken care of for you. And with Doctrine, it's so much better than writing your own. In WordPress, there's a lot of code that's kind of ad hoc for getting stuff from the database that isn't a post or a user. When you do that and you don't have 100% unit test coverage, there's going to be a lot of holes and there's going to be a lot of weird things that could happen with the use cases that maybe weren't thought of when that code was written. With Doctrine, you get kind of a very solid platform to run on to do that stuff. And then Pimple is the... There's this concept called dependency injection. And what happens is that instead of maintaining a bunch of data in global state, and WordPress has global state everywhere, you have a container that contains all that stuff and you pass that container around to read your data or to use single tensor or methods. So Pimple kind of looks like this. And this is super complicated to maybe look at, but if you see I have app up here, which I'll use the pointer, here's app. And then you see down here, I'm saying like db-host, db-user, db-password. Rather than having a concrete implementation or having something hard coded like a string, I'm saying give me whatever this represents. Give me whatever this is, whatever this is. And then these can kind of be encapsulated too so that if I needed to mock stuff to do unit testing I needed to encapsulate a piece of functionality. As I'm defining pieces of functionality here, I can also get passed in app, which will have other definitions. Yeah, and here's an example in the object cache we did for the New York Times. We're in the constructor. Here we go. This is an app to the constructor. So rather than reaching out in the global state to do anything, and there's a lot of examples in the WordPress ecosystem and in the WordPress object caches where it's actually reaching out into global state to pull out some instance of an object, this you're actually passing in all that together. And then also, what can happen too in a lot of these big projects is that you don't have strong typing everywhere and you don't have a way of enforcing kind of implementation. So this is our cache interface that we wrote so that when we were writing our own version of the WP object cache, we make it implement this interface so that we know it has to be all these methods and it has to be all these parameters. Anyways, Sylex, if you want to take a look, is a good implementation of a micro framework using symphony components. And here's an example of how Sylex works. So a PHP application can be this simple. You include your autoloader and then you run a couple things and you already have a pretty powerful API here. This looks actually very similar to Express in JavaScript if you've ever seen it. Also, for modern PHP projects, there's something stopping you from looking at stuff like Hack and HHVM which come from Facebook. And Facebook, because it needed to scale the billions of users, implementation of, you know, hip-hop is the server that serves Hack and it allows PHP to be transpiled into intermediate bytecode and it actually runs as like C++. It's extremely fast. Hack has a lot of different types that PHP doesn't have. So PHP, you're really using arrays everywhere or you're using standard class everywhere to describe data. Hack makes that a lot more strict and we have collections and shapes. So the scope for errors when you strongly type are significantly reduced. So is WordPress a PHP project? Maybe not. WordPress is really a consumer product and it's not meant to be a tool chain that gives you all these crazy awesome features of PHP. It gives you enough PHP to do what you need to do, but it's not necessarily a PHP project from the ground up. Okay, so real quick, the New York Times, so I talk about all these things we were doing and how we're switching to Google Cloud Platform. Well, we're also switching everything over to JavaScript. So pretty soon, within a year or two, the New York Times will run on Node.js and will run using React and Relay and GraphQL. So the past month or so, I have switched teams to the Web Frameworks team and I've had to learn a ton of things about JavaScript. It's a whole new universe that we're moving to. So number one, if you use JavaScript in your projects, there's a tool Facebook made called Yarn, which is great. I'm gonna post these slides too, so if I go through fast, you can catch up later on. Yarn is like the next generation of NPM. I think it's great. Flow is a tool that Facebook wrote to strongly type JavaScript so that you can actually catch a lot more bugs in your IDE ahead of actually deploying your code. A lot of people, I think, have heard of React, and React is the Facebook's tool for... Facebook's kind of like language for building UIs. Redux is for kind of managing global state within your application. There's Immutable.js, which is a way of passing down immutable objects so you have predictable state and JavaScript. There's Relay, which is a framework for data-driven applications. There's GraphQL, which is what Relay kind of talks to. It's an open-source project Facebook has given us recently that is completely their universe of the way they build apps, but it's actually been pretty interesting to learn, and The New York Times is gonna be using GraphQL as well. All of this is... You can use all this kind of latest, freshest, newest JavaScript type stuff with the Atom Editor. There's plugins for all this stuff, and I've actually switched... I was a NetBeans user for years. I was hardcore NetBeans, and I switched to Atom recently, and it feels nice to be in the modern world. And the latest trend, too, is isomorphic apps, meaning you're going to have Node.js, and you're gonna have it render on the server, and you're gonna have it render on the front end. And this is kind of something Airbnb was one of the first pioneers of to where, yeah, we have all this Node.js stuff, and we have all this... apps are becoming more JS-driven, but how do we go from an infrastructure to where we have a server language here, to where we have our client app, and make it more like this, to where we have one JavaScript code base that's running on both sides. That's something we're exploring at The New York Times. That's something that is very complicated, and it's kind of this new universe that's crazy to be a part of. The New York Times has already open-sourced a tool that makes this a lot easier, and if anybody's interested in isomorphic apps or Node, and wants to talk more about it, we can, open-source project called KIT, which makes it a lot easier to start these kind of projects. Starting a Node.js project can be so frustrating and baffling that you may just want to give up. KIT makes this a lot easier, the initial setup, so it's a lot more approachable. Yeah, and then kind of the last piece, CSS modules is, you know, this is really the future of web development kind of encapsulated in a lot of ways. This is a ES6, you know, transpiled using Babel JavaScript file. It has a React component, and it's also loading SAS in here, and using CSS modules. Like, this is the future of kind of like where a lot of stuff is going. And I don't think anybody needs to be an expert at this to be, obviously, you don't even know any of this to be a WordPress developer or to do WordPress sites. I think being exposed to this stuff is cool and interesting because a lot of big companies are going here faster, you know, sooner than later. And for me, who was really kind of an enterprise-level PHP developer, all of a sudden I'm now an enterprise-level Node.js developer, and where does that even mean? You know, it's like I'm learning this stuff as fast as anybody else, and I'm like, you know, it's a whole new world of things to be aware of. And I don't think anybody needs to become an expert at it tomorrow, but just know that companies like Facebook are having to think about these gigantic problems and think about these gigantic websites with huge teams of developers, and what's the best experience for building these apps and for maintaining these code bases, and there's a lot we can get from them just by being exposed to this stuff. Anyways, so let's do some Q&A if we have time. Oh, thanks. Thank you. Thank you, Scott. Yeah, we have about eight minutes for questions, so if anyone has questions, feel free to come up. Cool. Hi there. I've got two questions and a kudos. First, kudos for adopting yarn. It's amazing. Oh, yeah. Way, way faster than NPM. So two questions, the simple one first. Why did you go with handlebars as opposed to using something like Twig that has a little bit of logic in it? Okay, it's mustache. Oh, mustache, sorry. I actually wanted even less tools than handlebars. I had forced me to separate all of my data layer and actually all of my logic layer. I wanted the most terse set of templating tools possible, so that way we wouldn't be tempted to do anything that was too complex in the templating itself. It's just a personal preference. Oh, absolutely. Okay, great. And then the other question, you mentioned switching to some JavaScript frameworks for the front end, like using React and that you have Scoop on the back end where a lot of the data is managed. Does WordPress sit in the middle and how does it fit into this new ecosystem that you're moving to? I was a little bit, I didn't follow along. So if you look at it like this, take Scoop and WordPress and make them kind of things that can publish data. In our new ecosystem, believe it or not, those are actually going to post into a log that's gonna be Apache Kafka. That's going to get read by a service that's called Bodega, which is going to be like a materialized view of that stuff, which will actually get read by a service that posts it through GraphQL. So right now, all these systems are kind of ad hoc. So if you want data, so there's actually an API that sits in front of Scoop, which is an HTTP API that gives you JSON, right? There may be data that our real estate app is getting that does its own kind of random thing. There's WordPress, and God knows how you're getting that data. Is it from the REST API? Is it from wherever? A lot of this stuff too has to be highly available, so you can't just be hitting, we're not going to hit Scoop directly, we're not going to hit WordPress directly, right? We may hit a WordPress read-only endpoint for REST API that's behind Varnish and behind Fastly or whatever, but most of the time, we're actually putting those files in S3 or something. So like our mobile apps, there's no way they're going to hit us directly because we can't have a single point of failure for the data, so we're actually going to push our feeds into S3, and then they're going to read a service that reads S3, something like that. But WordPress and Scoop are like the lowest level possible, and only because WordPress is the back-end and the front-end, there are times when you're hitting a page and it is hitting WordPress, but the Scoop piece, it's really kind of hidden back here. Okay, so WordPress, the front-end of WordPress, is still going to be represented and out there and accessible by unique visitors? Yeah, so if you go to the Spanish site, you're hitting WordPress, but you're also hitting Fastly, which is hitting Varnish, which is hitting, you know, it's like... but you're never hitting something, it's directly hitting Scoop. Okay, so where does React fit into this ecosystem? My impression, most people, whenever they go to React, they use that to replace the front-end. Right, so... So, look at the New York Times Proper. The New York Times Proper is run on a framework called MYT5, which is internal. That is web service-driven, which means that it's going to parse the URL, make a web service request to get JSON back, and then it's going to render out articles on the home page and that kind of stuff. So, in the new React universe, that front-end, the whole application is going to be React and Relay. It's going to hit GraphQL. GraphQL is kind of replacing that API layer. That API layer may be behind GraphQL. The GraphQL is going to be the one place you get data from. I don't know if you've ever mess with GraphQL very much, but the discoverability of data is amazing. So, hopefully, all these different pieces of the site that need to get data will be in one place. So, any team that wants to build a Relay app will have access to all of the data. Excellent. All right, thank you very much. Thanks. I just had a quick question about... I've worked on projects where you're handling internationalization and translations and stuff, and one of the things I ran into was if there's a site out there in a language that you personally don't understand and people are making change requests and stuff, we would often have to pull it from production back to a staging site, flip it back to English, kind of figure out what they're talking about, make a change, flip it back to their language on staging, get approval, and then ship, and it really just kind of drew out the development process and was hard to sprint. Do you talk about maybe sort of that experience working in a language you don't understand and maybe if you have a better way to solve that problem? Well, I think the challenge is with different languages. We kind of have so much lead time for when we do a thing that there's lots of QA involved with... Because when you're internationalizing, there's really two pieces to it. One is the code base. So, the New York Times has a lot of projects that are built with the shell, which means that they have the furniture on it and the middle is, you know, whatever the app is. So, if we were going to start a Japanese site or an Arabic site, we would spend a lot of time looking at making sure when we're doing stuff like buttons or navigation or all that that it works correctly, kind of for every language we're doing. And then, yeah, there can be things on an ongoing basis to where when you're creating content, things can arise where you're like, oh, you know what, in Spanish this is weird. But because we have such an elaborate editorial process at the Times, we're never doing things fast enough to where that becomes a broken problem. One of the big things, too, is interactive. So, you may have an article that has a ton of imagery and graphics, and we may say, oh, you know what, let's translate that into Spanish, and it requires a ton of work with graphics to change out the text themselves and these images to... You know, it can be like a challenge for each little piece to figure out, oh, you know what, this is weird in Spanish. How do we make it? So it's kind of a case-by-case basis, but it's an ongoing workflow to where... You know, the way a Spanish site works, too, is that it's not the exact same as the New York Times. It's like there's a whole team of people that are doing, I think, 10 or 20 articles a day, and each one has to really be curated to be like, all right, how does this work in Spanish? So, yeah, it can be a challenge, but as you go and as you learn things, you try to be as flexible as possible to be like, all right, let me solve this problem for Spanish, but let me also make sure it's solved for Arabic or whatever. Yep. Hi, thanks for the presentation. Thanks. A question about internationalization, too. You kind of tricked us. You talked about it only for 5, 10 minutes. Yeah. I just wanted to know a little bit more about business editorial requirements. For example, the content itself in Spanish, is it written in Spanish by Spanish journalists that you have on site, or is it translated from the English site, adapted, how does this work? Yes, so the Spanish, the people who are producing the site in Spanish, they're in Mexico City, and they are Spanish-speaking editors, and so the translations they're doing, you know, a lot of the coverage we're doing for the Spanish site is for Latin America, and so the people who are doing it are picking stuff that's newsworthy for the region, and the people who are translating it are native speakers and are from like Columbia and Venezuela, and yeah, I think it's a subset of content that people think will be relevant to that area. So I think for the New York Times global strategy, it's really trying to figure out in different regions of the world what do they want from the New York Times, and there are a lot of people who don't have access to something as good as the New York Times as far as journalism goes. They don't have journalism that's as free, but yeah, it's native speakers and native translators that are doing that content. Thanks. Thank you. So we're out of time for this discussion, but if Scott has a couple of minutes, it looks like there's a couple more questions that you might be able to answer one-on-one. Sure. We have to prep for the next speaker. Thanks.