 Good afternoon, everyone. Thanks for coming. My name is Conal O'Reilly, and I'm a solution architect with Smartling. And I'm joined by Kostya Glushak, who's a member of our development team and who's worked specifically on Smartling's Drupal integration. We're going to cover three things in this session. I'm going to talk a little bit about Smartling just by way of background, in case you're not familiar with what Smartling is, a little bit about what we do. Then talk about weather.com, and a little bit of their story and how they're using Smartling today. And then I'm going to turn over to Kostya, and he's going to talk about what we're doing in Drupal 8, so the work that we're actively engaged in now and looking forward. So there for a second, and just to mention as well that Smartling has a booth in there, is a little bit about Smartling. Smartling is a cloud-based software platform for managing the workflow around human translation. For the most part, we do integrate with machine translation, but it's mainly a platform to tackle the challenges that traditionally plague the business of translating content and applications. If any of you have ever been involved in translation projects, you've probably got some horrible memories associated with it, because usually there's copy and pasting involved. There's usually putting stuff into spreadsheets, emailing spreadsheets to translation providers. They, in turn, email them on to translators. The translator has to do their work with a big list of words in no context of where the content will actually live, so they end up making mistakes during poor translations. And the process around fixing those is slow, laborious, error-prone. And it's slow, and it's costly as well, and it's kind of painful for everyone involved. Smartling addresses this traditional mess by providing a single platform that everyone involved in the process logs into and uses. So on the company side, project managers log in to Smartling and manage the content. They can see what's going on. On the translator side, the translator also logs in. We provide great tools to the translator in terms of visual context so that they can see the work that they're doing, where the logic we live allows them to get good translations first time. We manage translation memory. A lot of the things that are the kind of state-of-the-art for translation work, so they're all available in the platform. And in addition to that, and a bit more relevant to the Drupal conversation, is we also provide methods of integrating with places where content comes from, so application development systems, content management systems. So instead of developers having to copy and paste them into spreadsheets, Smartling automatically collects the content and just removes that from the picture. So that's kind of what we do. We have this app base. It's a browser-based interface. Different people log in, see different views, depending on their role, content's coming in automatically. Translators work in this platform as well. Through the same platform we provide. But actually, what I'll do is I've highlighted. I don't want to say this is not about Smartling. It's more about the integration work with Drupal. But a couple of features that I'm just going to quickly go through to give you a better feel for what Smartling is about. And then we'll switch to talking about rather. One of them is, I mentioned this context idea, so that what we try to do in Smartling is in addition to supplying the content to the translator to work on, we also give them the visual context that they'll ultimately live in. So if it's on a web page, they'll see that actual web page. If it's describing a product, they'll see the product. And so can do a high-quality translation first time. In addition to that, as they do their work, they'll see the translation appear in the content above. So if the translation is going to introduce any layout issues, they have a better chance of spotting them right off the bat, as opposed to seeing them in some QA cycle weeks or months later. So that's a little glimpse of the in-context interface in Smartling. They also have in this interface translation memory so that anything that's previously even translated, they'll have access to it in this interface. They'll be prompted that this experience is translated and it allows for faster lower cost. So switching to a completely different thing is another capability that Smartling has is what we call the GDN Global Delivery Network. And this is a proxy-based approach to translating websites or web content. So if you didn't want to do the translations and manage the translations at your site, we can instead, let's say, leave your site in whatever language it's in, let's say your source site is in English. Through this proxy, the way the translation would work is when somebody requests a translated version of your website, the request would actually go through the Smartling proxy. Smartling would go to your English site. So this, for example, is, we've got some very large websites that are using this approach to translation, but it's only one approach. We maybe half our customers do things this way and the other half do the translation at source using approaches like that. Just mentioned one last thing. There's a lot of things really we can, this is just a recent thing, so I picked it out as well. Sometimes when a translator needs context, there's no HTML context available, but there's maybe a screenshot or a design from a designer that exists as an image. And so we also have lots of different approaches to get in context in, but this is a new one we had recently where if you load an image into Smartling, OCR on the image and extract all of it. So switching to the weather story, in 2014, weather.com was based on, you probably know that they're the largest traffic, Drupal-based website in the world. They have over a billion page views a month, I believe. So it's a very, very large site and the way it used to work was it was based on Java framework and all of the content was stored in Java properties files. And the process by which they translated this content into other languages was exactly the one that I was describing at the beginning. They had members of their development team literally going through these property files and copying content and basically into spreadsheets, which then were emailed off to translation agencies. This is how the translation process happened and this is a common process actually, even though it seems so old school. So that's the way they were doing things then. It was very slow. It was expensive, they had a good number, a half a dozen developers that spent a good portion of their time on this type of work, which that's an expensive use of your developers. And so they embarked on a process of changing this. In 2014, they re-architected the weather.com. Oh, one thing I didn't mention as well is that whole copy-paste thing that was repeated multiple times for different environments. So the Angular app, the Windows app, the iPhone app, all of these went through the same process in many times with exactly the same content. So it was redone multiple times, also adding to the cost of the whole thing. So they went through a re-architecture process of their English site, changed it to be based on the Angular mods, so Drupal, and then the Angular mods in Drupal for English. And what you see here is the new version of their site as of, I guess it would have been, came out in late 2014, the English version. And then they said, we want now to, we need to update our internationalization process so the international sites are all still on the old approach with the copy and pasting and everything. And so they went through an evaluation process to choose a translation management platform they ended up choosing Smartling for many of the things I spoke about earlier, but also because we have an integration with Drupal, which they started to use, they had some additional requirements which are shown here because of their particular custom way of using the Angular mods that they, that was not something we initially supported out of the box. So we did some custom development to allow them to translate that type of content from Drupal. They also had a requirement to allow translation submissions to happen from multiple different environments so that a developer's Drupal environment, for example, could be used as a source for content to send for translation. But once the translations were complete, they could be downloaded into other environments. So download into, so that was kind of a new, traditionally in when we're connected with content management systems like that, usually the translations go back to the same system that they originated from. So this was a new requirement from Drupal that we were able to meet with some modifications on our side. This is an example of what that interface looks like in Drupal. We have connectors for platforms. They all look more like the platform so that this should look like a Drupal interface, but the flow, the content flow is largely the same. So you can see on the left, it's been filtered, allows you to search for the content that you want to translate. It's been filtered to this weekend forecast app. You select that, you press the translate button and then you're led to this page where you can choose the languages and you can see where it comes of very large set of languages that they're translating into. But it gives you the option to choose a subset of languages in particular applications, say it's only available in certain countries. So the flow is simple, you find the content, you search for the content, press the translate button and choose your languages and off it goes. And once the translations, and so once it goes into smartling then, translators are notified that content is available for translation. They'll immediately log in and start working on it and you have fast turnaround time on the translations. When the translations are complete, they're automatically downloaded and incorporated into the direction to that type of flow. There's also this kind of a status view that allows you to see at a glance the progress on all of the translations that have been submitted from Drupal into smartling. This particular screenshot happens to show all 100% but more typically you'd see varying percentages along the right here. You can see languages listed as well as the different types of content. Once you have the ability to download translations manually but the more typical flow particularly for a large site is you just let them come back in automatic. So they've been successfully implemented this. They went from a world where it was taking them a long time to translate and they were using half a dozen developers in managing the process and was very error prone to a process where they can simultaneously deploy into more than 35 languages. They don't need any developer resources. So it's just content people can manage this from a Drupal interface. They've got some examples of the particular app on the left in English translated into various languages, Chinese right to left languages represented there as well, Arabic. The other thing that they get from this, the content coming from all of the different applications is they get this very high translation memory leverage. So once they've translated content for their iPhone app, there's a lot of the same content in Android. So that can skip the translation process completely if they choose. There's a configurability around what they wanna do with translation memory matches, but that's something where it makes the whole translation process faster and more consistent and a lot cheaper too because you're reusing translations that have been done before. And they're using this submit from multiple places and download into different environments process as well. So they really, they view it as a great success that they're now able to do translation work in a kind of an agile, it fits into, they were shifting to a more agile development model and this kind of approach to managing their content and translations fits now nicely into that agile development. So that's, I'll stop here and just say, ask if there are any questions at this point. Yeah, actually, and correct me. So the question was content can be created on staging and then it'll be sent to production. So the normal flow with a smart link connector is if it was created on staging, then the translations would go back to staging and you would manage yourself to push it to production in the appropriate way, but this also supports a model where the content is created on staging pushed to production, pushed to smart link and when the translations are complete, they can be downloaded directly into production environment. So at this point then, so that, everything we've spoken about so far is based on Drupal 7. We're also very actively working on Drupal 8 and Kostya's demand doing the work. So he's gonna tell you a little bit about the work we're doing on Drupal 8. For Jainas today, so first about TMGMT and I'd like to say that we decided to go fully with TMGMT as our default Drupal 8 solution for the integration. It was a somewhat hard decision, you know, as we did this decision after Drupal Con New Orleans and some internal discussions, but by that time we already had a release candidate one of our custom plugin integration for Drupal 8. So we already spent quite of efforts for that, but anyway we decided to switch to TMGMT and there were several reasons to do so and let me share those reasons with you. The first reason was that it is a well tested module with a big community and even at this point the core is really well tested. The second one is that after the active development phase it has really nice APIs that allow flexible extension of the TMGMT module and that we could use to implement the needed features. And the third one is that we truly believe that we cannot only successfully use this module for the integration, but we think that we can bring in some new features that everyone can benefit from. And before I continue I'd like to say thanks to all the TMGMT maintainers that put their hard work into this module. You know, having written the module with similar functionality for both Drupal 7 and Drupal 8 we think that we can really imagine what a big and great piece of work it is. And so we would really like to thank the maintainers for all their hard work and that they made this, our decision happen. And now a few words about the state of our own custom TMGMT smart link plugin. So right now it's production ready. It allows you to implement all the basic manipulations with content. You can upload the content to smart link and download the translation back. But right now we're working on a new really cool feature for Drupal 8 which is called translation context and Connell mentioned this featuring his part of the presentation. So soon translators in Drupal 8 will be able to immediately see how their translation looks on the real side. We do this by capturing the actual HTML of the page and sending it to smart link and then showing the actual HTML of the page inside the smart link to the dashboards and that's why how it happens internally and this feature might be really useful for example for German language. This language is known for really long words and sometimes these long words come feeds into certain parts of the page. So instead of going through the whole loop of the test process after you downloaded the translation back then you go like give the site to your testers and they mark a bug that some string doesn't fit. Now they can easily see it right away and translator can try to split his translation into several smaller words and so it would look nice in the UI. So while working on the integration with weather.com and their amount of both content and locales we learned several important languages while working with them and we think that we could bring these important lessons to the TMGMT ecosystem. And in order to do so we started the new project which is called TMGMT extension suit. It's a module on Drupal.org. Right now it's not yet production ready. It's more like work in progress but I think it will be worth checking by the end of this year. It's also worth mentioning that we see this project as a vendor agnostic tool. So hopefully anyone who's using TMGMT may benefit from this project. And now I'll tell you about a story of how would you translate actually the sites using TMGMT and hopefully our new extension. Yeah, so imagine that you've got a customer that you created a site for and these customers called Fantastic and so you created a site for him. He was happy with the site and he noticed that the site started to bring in new business and so the customer decided to go multilingual and try a new locale on the site. In order to fulfill this requirement you install the usual TMGMT module on the site and create all the translation jobs, send it to the translator provider of your choice and in approximately in a week when all the translation happened you expect the content to return to your site. But that doesn't happen. And during the debunk you find out that the reason for that is that you use the dev environment of your site in order to be able to test the translation afterwards. And it appeared that you use the HTTP authentication on your site and thus this site is not available outside and so the default mechanism for pulling the translation back for the site in TMGMT module is the download callback. It doesn't work because the servers of your provider can't reach the site. And you really in this situation you don't have like many options to choose. You would need to go inside each job, the translation job on the site that you have and by one click the download button manually to get the translation back. What we see, we could improve here is to actually improve the integration between the TMGMT module and the VBL modules that could leave together. And essentially we think that the download action and re-upload action would be really helpful in such cases as I've just described. There are also some other actions like the cancel job and like the delete job I believe but we think that the content managing actions are the vital here. And so some time passes and we leave in a rapidly changing the world and some content of your client becomes outdated. So he wants to fix this situation, he goes to the site and changes the content and now you need as a developer to update translation. Right now in order to do so in TMGMT you've got two options to do so. The first one is you can create new jobs and send them again for translation and then download them back and then you will have the translation. And the second option is the pretty much new feature in TMGMT that is called continuous translation. This feature allows you to configure a bundle that will be automatically sent for translation and then download it back. And the issue with such approach as we see it is that you no longer be able to select which nodes or other pieces of content you want to translate inside this bundle and which you don't. So for example, if you got the bundle article, yeah, the note article or the basic page and you want to translate some of those pages and others you want to leave not translated for now you like this is not the option. And what we implemented in Drupal 7 and right now working on in Drupal 8 is the tracking changes on a per node basis. Per job, sorry, per job basis. So if any piece of content inside a job was changed, we will catch the moment when it was changed and re-uploaded again to the translation provider so the translation could be updated immediately. And finally, in some time, if everything goes well with your fantastic customer and his business grows, he may want to go truly multilingual and at, I don't know, six more locales to his site, right? Right now, TMGMT allows only two create jobs on a per one locale basis. So in this case, you would need to go to your administrative interface and create all the jobs that you created for the first language. You would need to recreate them for each new locale and it might be kind of tiresome. There is actually the cart feature in the TMGMT module where you could select multiple locale for your job but after you select them, you would need to click through all the job creation process. So if you got six locale, then you would need to click through six forms for each locale to create a job for each locale. And instead, we will work on making this process more transparent and allow to create all those jobs from a single page. Yeah, so this is our basic roadmap for the nearest future, our top three features and everything else will be prioritized after we implement these ones. It's a matter, as I said, we would expect it to be more or less finished by the end of this year. And maybe after that, we would bring in some cues that we had in Drupal 7 or Ural Rights where inside, for example, your body fields, you've got some URLs that link from one page to another or the images, the links to the images. And the common use case is that when you want to localize those images, so instead of one HTML link inside the body field, you would like to link it to some other place. And this transformation should happen according to some rules. And so in Drupal 7, we provided some APIs that would allow this feature and that is definitely somewhere on our roadmap, but again, somewhere in the... So I think that's it from my side. Thank you for your attention. And if you have any questions, please ask them. I may also mention that we finished a bit early, but we thought that we would have only 30 minutes for this presentation and only recently, we got to know that it will be the whole hour. So questions are really welcome. Thank you for your attention. No, we don't plan to backport it for Drupal 7 as we've gotten. I essentially ceased. So it's like more of the client request base. So if some of our clients want... So we don't have right now the active roadmap for Drupal 7, but we've got some incoming requests from our customers. And if we do so, then we prioritize them and give them some resources to team implement. There are on Drupal 7 and I'm not sure about their plans towards Drupal 8, but as far as you know, the media card framework they see it on was involved lots of work. So maybe they won't be like the early boards for Drupal 8 adoption at least. So basically we've got clients that at least in Drupal 7 use both our plugin and workbench moderation. And essentially we don't influence the state of the workbench. So for us, if you are talking about in the tracking changes, right? Feature, so there we in no way, like with the states of the workbench moderation. For us, the final stage of the original content is the one where the admin of the site or the content editor first uploaded some piece of content to smart. So before it happened, we do not track changes for this piece of content. But after the first upload, we think that we should get to know about the updates on the content as soon as we can. Essentially, if for example, some piece of content was uploaded to smartling and then somewhere or was found in those pieces of content and quickly fixed, and it can happen that translator didn't even start to translate this node. So this way we will be able to fix the typo before the translation and so the client won't need to pay for that translation. Does that answer your question? So the question is, is the translation context something specific to us or is it in the extension suite? So the answer is that it is specific for our connector and the reason for these is that it is not only the Drupal site, so the code on the Drupal site, but these are pretty much specific APIs on the server side and a bunch of the communications between our servers and Drupal before we actually gather the whole page together and so it could be properly displayed for the translator and we've got some doubts that other providers can easily implement the same server APIs, so this could be useful for them. But on the other hand, all of our code is open source. It lives on Drupal.org, so if any LSP thinks that they can implement the same feature on their side, they can easily just fork out our code or grab the needed piece from our code look how we implemented it and use it for their own benefit. So the question is, why did we go with a separate project rather than kind of prison to TMGMT? And the answer is that we wanted to stay more agile here and I think you can think of this module as the experimental modules for Drupal core. So the TMGMT module has lots of stakeholders and people that are dependent on it and so there might be even some argue on how should it better implement the integration between VBO and TMGMT and it can take some time. So we decided that it might be better for everyone for us to implement it more or less quickly and then share it with everyone else and then discuss the existing implementation rather than some theoretical maybe approaches on how to do it better in which one. So yes, so the question is how will a smart thing influence the TMGMT module? I think that the answer here is that, well first of all, a TMGMT module has, I think really, really strong stakeholders by the empty systems company which is really huge. And like the second contributor. Yeah, there's a second contributor. They have a really nice view of where they're going and I think their opinion is definitely not easy to influence in some way. We can only in a way help and add something that we think is important. So from what we see, maybe we could add a little bit in terms of improving the UI and helping to translate the big sites with a lot of content as we usually deal with that type of customers and usually the companies that use smart link with Drupal usually Drupal is only one source of content in their platform. So usually it's something else and as we have such type of customers, I think this is where you might expect our help and involvement in developing and TMGMT, I think that's the answer here. Sure, I mean, single source or limited source. And I think another nice thing in the current situation is that right now, before the smart link connector in Drupal 7, it was our custom solution that we only were responsible for. But right now, if some of our customers, for example, want some new feature, we can ask them if it's appropriate maybe to spend some resources as now it's like, not only our custom solution, but everyone can benefit from and if they are willing to, we can propose them to contribute to actual open source that others may benefit from. Not sure how well will it go as we are only at the start of our path here, but that's at least an option. Okay, thank you, everyone, for your attention.