 So I think we're ready to start. So thanks for everyone for being here. This is my first DrupalCon. I'm Tina Williams. I'm from IBM. And I'm going to share a little bit about our story with globalization using Drupal. My colleague Ann Marie Shepard is not able to be with us, but I have a demo partway through the presentation that you'll hear from her. And also the end of the presentation, she's our engineering lead. We'll be more of the slides that she would have covered. But I'll just cover those today. We have a lot of material. We've broken every rule of conference by having way too much information on each of the slides. But hopefully it'll be a good reference for any of you that are pursuing globalization with Drupal. So let me get started. So we're going to cover today the four keys of success. And for us, that was really about first developing a geo-focused strategy. With IBM, we have 137 locations on our website around the world. Then we also wanted to transform our processes, and that was to become more efficient. Finally, we wanted to redefine our roles so we could have more ownership in our geo sites. Our geos are responsible for their revenue targets, so we wanted to give them full control of their digital presence. And then finally, we wanted to have a CMS platform that supported our globalization strategy. So what were our problems? We had, from a user experience standpoint, we had inconsistent languages being deployed across all of our business units. IBM has many different business units, and they were all operating independently and making choices themselves about which languages to deploy and where to deploy. So we also had a content issue in our geos where some geographies would have all of our portfolio, some other geographies, some other countries and regions would only have portions of our IBM portfolio, so we needed more consistency there. We also didn't have a good model for delivery of content into the geography, so we could have our local market teams running campaigns, and then all of a sudden they'd get a new page into their market or their page that they were using for their campaign would be overwritten by our worldwide teams, so we wanted to address that issue and give them more power and to the content that was coming into the market. We also were having extreme delays in our globalization effort. It could take up to 12 weeks for us to translate pages and get them deployed into our local market, so we knew we needed to have a better way to do this much faster and address the issues. And one of the primary problems we were having was we were using in-market marketing resources to validate our content, and that was where we were really running into time because Joe, the marketing guy, didn't really have time to validate the translation, or if he did do it, he would completely rewrite it, and so we didn't wanna have that rewriting of our messaging in the local markets, and we just really didn't wanna be using a volunteer resource for that activity, so we made a change there. And then finally, the platform, at the time that we started, we had, I'd say, five different legacy systems with marketing page content, and we wanted to move to a single consistent CMS for all of our pages, and we first moved to all of our worldwide pages over, and that was in 2017 and 2018, and there's a talk from Seattle from the team that did that migration. I'm gonna focus on, now that we have the content, our worldwide content in Drupal, how did we globalize that content? So this is just another picture to show you just how complex our sites were. This is actually from 2016, where we were looking across all of the different sites, and for our homepage, we had 140 countries in 37 different languages. We had some of our product catalogs and our software catalogs weren't even synced up. They were going to different languages in different countries. Our legacy product lines, like our mainframes, were going out to a much larger number of languages and locales, but then our new product lines, like our cloud, IBM cloud, were going to fewer markets and fewer languages, really targeted on the new market opportunity. So the result was really a disjointed user experience. So in Uzbekistan, we had deployed an IBM.com homepage in 2015 and half of the content on that page was in Russian and Uzbek and other languages and then the content itself was so out of date it was promoting a conference in 2015 in Las Vegas. So we don't even run that conference anymore. So we had an issue with even keeping content maintained in these markets. And then you'd see Tom and Croatian might be able to find the homepage in our legacy systems sites. Someone in Germany, almost all of our sites were being kept up to date for Germany and for the US market. Everybody there was happy and could find everything. But then as you started to go to some of our more minor markets like Aruba, we had our whole product catalog, did we really need it there. So we really were looking at where do we need content? Who are the, who are our, is our audience in these markets and how can we best serve them? So we developed a strategy where we wanted to look at what consistent languages could be set up. So we have a market development insights research team within IBM and we asked them to go look at all of the different markets, understand the proficiency in the different languages for our specific audience. So for someone that's buying IT related services. And then also looking at where do we have marketing resources and what is their language proficiency and also our sales resources. So we wanted to align all of this to make sure that we came up with a set of standard languages that were sufficient for our markets but also, and also aligned to the resources that we had. So we didn't just decide this, we got the research from our team. Then we went out to each of the geography leads and we talked to them about the languages because we are, of course, we're gonna take away some languages that we were supporting. We got their agreement and then we turned around and went to each of the business units in IBM and talked to them about making this change as well. So we really took the time to socialize the research, get the buy in, and then we said, okay, this is gonna be the standard. So we didn't dictate it, we worked together with all of the organizations to make sure everyone was in agreement. The next thing we did was, we decided on the locales that we wanted to focus on. So the countries and regions that were important. And again, we went out to the geographies and talked to them about, let's look at your traffic, let's look at the revenue coming in. Where do you see your emerging markets? Where do you see your declining markets? Where do we really need to have content and where do we just really need a brand presence? The next thing we did after we knew the languages, the countries we wanted to support, we set up the staffing model to support that, followed by a whole new set of processes and process improvement to make globalization run much quicker. And at the end, we gave the ownership to the pages going into the market to the new resources that we put in place. And then finally, and this is intentionally the last thing, we worked with our engineering team to customize our Drupal implementation to support all of our needs. So these are the standard languages that we agreed to. We actually added Arabic, so that was a challenge because we have to be able to support the Arabic language within the system and rendering. But we'll be going back and revisiting this over time. So I do get calls from different geo leaders and they say, can we please add this language? And my first question is, okay, what sellers do you have in place? What marketing resources do you have in place to support this new language if we enable it within the system? We do allow our local markets to still create and publish pages in their local language if they have a need, but they have to totally own those pages. They have to own the maintenance of the pages and the content for those pages. And that's pretty much to support local campaigns, local events, and they can also have local case studies. So part of our content strategy was to really think, how could we model our content in a simple way that we could be really efficient in the way that we're deploying out to the markets? So one of our areas, our security business unit said, you know what, in some markets we only need marketing pages in other markets, it's sufficient enough if I have my product pages. So if you think about the different types of pages you might have on your site, those are two of our primary types of pages on our marketing sites. So for our worldwide site, we have all of the content. We have the homepage, we have our legal pages, we have all of our worldwide marketing pages, our product catalog that's full of our product pages. But as we started to think about the geo markets, we said, okay, let's define some tiers. So the first tier is really about replicating the worldwide site with just a less amount of content. So maybe we have 100 pages for a business unit on our worldwide site, we don't need all of those 100 pages on our geo sites, on our tier one sites. So some subset, maybe 20%, 30% of those pages would be deployed to the tier one market but not out to our tier two or tier three. In the tier two, we decided it would be sufficient enough just to have the product pages. And then in the minor markets we really just have our IBM.com homepage and a little bit of other minimal content just to keep the content fresh on a quarterly basis. So we went out to the geographies and asked them also to classify which market fit into which model. So we defined the model centrally but then we went out to the geographies and got them to decide on their own which markets they wanted to classify as tier one, tier two and minor based on their revenue targets. And then after we defined all that, we again went back to all the business unit leaders and met with them one by one and shared this new model and got their buy-in. So there was a lot of socializing around the content model as well. So the next thing we did down that we had a content model, we were trying to think how is the most efficient way to manage IBM.com in 137 locales. So we said what if we would set up some of our locales to be parents of other locales so that we would really only have to maintain the parent but the child locale would inherit any changes that we make to the parent. So we again went out to our geography leads and said if we set up this structure who would be the parent, who would be the child in your markets? And so each one of them defined how they would wanna be set up. So for in our MIA market, we have UAE is the parent for both Saudi Arabia and Libya but South Africa comes directly off of our English master because that part of Africa, their messaging, their graphics, everything would be much different than it would be in UAE and Saudi Arabia and Libya. So we set up these inheritance models and Drupal does a really great job of supporting us with this. So I would say that's probably, that's one of the many benefits we have from Drupal but this is very significant because it allows us to be very efficient in our management of the websites. Okay, sorry. I was hitting the wrong button. So we also are doing the same thing for other languages. So the other, the previous slide was about the English language locales. We start with our worldwide site and create our English master kind of as our snapshot in time that we globalize. And then we create our other language masters. So like our German language master and our French language master. And again, we set up those parent-child relationships. Again, working back with the geography teams. So that was our content model. So the next thing we did was really focused around our process and roles and how could we make the globalization process much more efficient. So if we considered the steps, the one through nine steps of preparing for globalization, initiating it, going through translation, validating your translation, approving your translation, and then moving on with creating locale pages, publishing those locale pages and then doing optimization and localization around the pages in the local market. So the places in our older process that we updated were that during our initiate phase, instead of having the worldwide teams just shove out new pages and no one knows about it, we now require our worldwide teams to brief our geo teams on any changes that are coming through the globalization process. And our geo teams have a week to raise their hand and say, hey, that's not enough pages or that's way too many pages or ask questions about the content that's coming to them. So that's worked out really well. It's a very structured package that we've put together that they have to complete. It's a lot of work, but the feedback we've also gotten from our worldwide teams is that it's a nice package for them that they've never really thought of having all of that information together at the same time. And it includes information about really thinking about what are the assets on the page that are being linked to, what redirects need to happen as the pages are being deployed and a lot of other detailed information that really helps our geo teams prepare. The next thing that we did different was we moved away from translation validation and using our in-market resources, marketing resources to do that work. We knew they were rewriting the content, they were slow, it just wasn't their job. So instead we now pay our translation service to do what we call translation QA and we use new capabilities in Drupal to allow for side-by-side comparison but also a preview of the content in context. So they can look for grammar and syntax issues that aren't caught during normal translation. So that's the space where I'll be sharing with you a little bit about where we did some customization around the TMG MT module to support that. And then the last part that we changed was the approval and publish. So like I said before, we wanted to give ownership to our geo teams so we now have web managers in each of our geographies and they're the ones that receive the briefing materials and prepare and then they know that the content is coming but they have the right to publish. They're the only ones that have content approval to publish the new pages live. They're also the only ones that as an update is coming into the local market, they are the only ones that can accept that update. We call it an unlocalized function. So again, we use Drupal during that for the inheritance capabilities too to make it much more efficient. So we don't have to have a web manager assigned for all 137 locales. We have about 42 web managers. So success, through our process, we just recently were able to complete globalization in five days for our Red Hat announcement. So think about 12 weeks down to five days and I know we can even do this much faster. There were a few reasons why we didn't make it even faster that we're working on now. And the goal is to actually be able to just queue everything up so we can launch on a single day in all markets and we have the capability to do that. We just haven't tested it yet. So now I'm gonna talk a little bit more about Drupal and how Drupal helps us. So for the developers, you're probably familiar and we're on Drupal 8. A page itself, so this is a page with all of the different lead space and bands, our IBM implementation of Drupal is, it's not layout builder, we call it page builder and it's our own implementation, but it's really made up of the lead space and the bands. So if you think of a page as lead space and bands. So that aligns then to within Drupal when we're looking at the different bands within Drupal. So every band, every lead space is an entity and then the elements within the band are also entities. And then every page is a node and then a lead space is a node and a band is a node. So you're probably all familiar with that. So if we have our English master, then we move into, we create an English master from our US site. So the reason we do that is we wanna allow our worldwide teams to continue iterating on content, but we wanna know what we're globalizing is approved for globalization. Like they already know that it's performing well, it's the content that they want the geo markets to have and the geo markets are ready to have it. So when we create our English master, we create a complete copy of every node from the worldwide site and this actually cuts the inheritance. So we can make changes on the worldwide site without it affecting our English master. Then as we build our locale pages, so from the English master, we would create our UKEN page. We would, when we create the locale, the only thing that actually gets copied is the page wrapper and none of, not the lead space, not the bands, but when our web manager or one of our content editors in the local markets changes a band, then it creates a version of that band in that local market. So Drupal knows when they're going to the UKEN site, to look and see for each element of the page, the lead space and all the bands, is there a UKEN version? If it is, if there is, it renders that. If not, it'll fall back to the English master. So this is how we use the inheritance capabilities. This is another part of Drupal that we enhanced is the TMG module, the translation module and we set it up so that we can send content off for translation to our IBM in-house translation service provider and it comes back in. We put in, we send it, we were able to send an X lift and it also includes a JSON file with our operations data and this is really an important element because that's the information that's used to build. So every time we send a translation to our service provider, we have to pay for it. So it wasn't a matter of just figuring out how to send the page. We also had to figure out how to send the financial information so that we could be billed on the backend. So that's all sent over. It comes back into the module. We then have two APIs and one API sends out information to get segments so that we can have then our reviewers look side by side in Drupal to see the segments and then also we can look at a whole preview of a page and then when we decide to approve the page, we use this other API that sends out, looks at the whole, is able to assemble all the content back into a whole translation unit. So a translation unit is putting the segments back together that have been taken apart in the process of translation and this allows our translation QA specialist to look at all the content in context. So the next slide will start video. It is gonna be a pretty long demo. It's about 14 minutes, so I'll warn you, but it's Anne-Marie walking through the whole globalization process so you can see how it works. I'm going to start at our master English language of the Cloud Red Hat page and request a translation into our master German and step through the workflow. So here we're looking at the master English version of the IBM Red Hat page. Looking on the translate tab opens our list of languages that are available for translation and localization. I'm going to locate the master German translation and select the request translation. So selecting the language with our TMGMT and trip module enables, we can click request translation. Clicking request translation will take us to the checkout form where we're going to look at our custom IBM translation service provider and the operational data and checkout setting is that required. Sometimes it's a little slow. This is a development server. On the checkout form, I'll enter a label and select our translation provider. This is the pre-production environment. On the right hand side, based on our content model, all of the entity references are included as additional job items to send in the same request translation packet. As part of our checkout settings, I'm required to submit a domain, charging agent, charging code and business unit. This is all operational data that's required to submit from the IBM Drupal instance through to our translation service provider. I'll select cloud, are keeping our Drupal 8 as the charging agent, enter in my test charge code in the business unit and the translation contact is pre-populated with my ID and click submit to provider. As part of this process, we're now submitting the translation XLIF outbound as well as a JSON with the operational data. Taking a look at the operational data, we can see that the raw JSON submits the job ID, the job title, the domain business unit, charging agent, charging code and the contact email as part of the JSON as posted to the endpoint. As well as the outbound JSON, we also have our outbound XLIF file that has all of the translatable units as part of the content model and the content type defined as our source language BN and all of the translatable strings sent to the translation provider. I have as part of this demo previously submitted a translation to both master Italian and master French and have processed them through various stages of the workflow. Once the translation job has been processed by the service provider, it's returned into Drupal and coming in with a workflow status of needs review. Clicking on manage the job, it opens up our managed job form showing us all of the job items that were included in that package and our content editors for this master language can click on edit translation which opens our side-by-side comparison form. A quick scan of this shows us all of the segmentation, JSON and its source on the left and our translations on the right. As a translation QA specialist for this master language, they can review side-by-side each of the translations and validate for correctness. If there's any additional updates, they can be made here and be resubmitted back to the translation provider. We can also do a preview of the translation. Clicking on preview will save a draft of any edits that are made as part of the side-by-side editing experience and will be available in context in rendering. So here we can see this is now the Italian translation for the IBM Red Hat page. And we can see if there's any corrections, errors or omissions or any updates that need to be made to get prior to approving the translation. Once the translation has been reviewed, any corrections made, we can submit for review. From the comparison form, the translation QA specialist can submit this translation through to the approver for this master language. I have as part of a previous translation processed the master French into the status. So the status changes from needs review to needs approval. From this point, we can manage the translation job for the approval state. The difference on our overview form is that it's no longer an edit translation but a review translation. Clicking on review translation opens our comparison form in a read-only state for our translation approvals. We can also preview the translation and see again in context prior to approving the translation. Our translation editors in the contextual rendering of the preview can see the job information and we have this moderation bar that's available to allow them to approve the translation while they're previewing it in context. They can also from the comparison form approve the translation. Both will publish and move all of the job items into an accepted state and publish the master language translation. Any corrections that will have been made will be submitted through to our translation service provider and will update and validate those translations in memory. Doing so will mean that a second translation request for the same segment will come back as a validated translation and will not need to go back through the translation QA process again. So now that we have approved our translations we can have our locale editors use our master languages to create localized versions of the IBM Red Hat page. I'm going to start with our master English and create one of our tier one locales for the IBM Cloud Red Hat page and I'll create the UK version of the page. From the translate tab again we see a list of all of the available locales. I'm going to choose the United Kingdom and instead of a request translation I'm going to do an ad for a locale. Looking on ad will open up the edit form for this page. The first choice that our locale content editors make is what is the parent source language that they want to use and inherit the content from. This is a list of all the published languages and locales. For E and UK I'm going to choose the English master and click on confirm. At this point all of the content fields are read only until they confirm which language they want to source those fields from. I can now see that my source language has been set to English master. The locale of this node entity is UKEN and all of my entity references as part of the content model are sourced from my parent source language which is E and UK master English. So lead space and band are all sourced for master English. Click save and preview will show that my rendering logic is going to check for the current entity in its language code. And if it doesn't find a revision for that translation language it will fall back to the parent source language master English and render its revision. So here I have my lead space and I also have my band which is inheriting from master English. If a locale wants to localize one of its content items. So if I want to do an override of my inheritance I can click edit and I will edit the lead space and create a localization. We now we can see that the source is still inheriting from master English and I will simply add UK as part of my headline and we see we have the option to localize this lead space. Once I've clicked localize this lead space we now have a localized language variant of this lead space entity reference in the source language of E and UK. Save and preview picks up on my rendering logic where it will check do I have an E and UK revision for this translation effect it? Yes, then let's render it instead of inheriting the master English. This process works for all of our languages and their locales so even our translated languages. So if I choose to create a localized version of my Spanish from you'll see that it's inherited from my master Spanish and you can see that this locale for Spain is inheriting all of its master language from the translation of BS. Should this locale want to create a localization? This process would be the same and here we see the source is master Spanish. Great, edit and in this case I'm also going to remove the call to actions in the lead space. So in addition to making content edits they can also add or remove custom content entity references on the page. And I'll click localize this lead space and save and preview. So while this translated locale is taking advantage of the QAID and approved master Spanish translation they also have the flexibility of being able to add and remove custom blocks from their page as well as localize any of the content for their locale. So with the use of a custom translation provider with our side-by-side translation QA process storing translated memory or segmentation of our translatable units of our content models as well as the ability to reuse master languages translation at the locales. This all gives us the benefit of faster time to market for creating localized versions of our content for Drupal. Thank you. So now I'm just gonna take you really quickly through some of the updates, the customizations that have been done for our Drupal system. And again, these are Anne-Marie's charts so I'm gonna do the best to represent them for her but we also have contact information at the end of the presentation if you wanna reach out to her and I'm sure she will be glad to go into more detail with you. So we really looked at several different things to enable the core and the supporting contrib modules and I'll go into each of these on detailed slides. So the first one is that it's really important to get your content ready for globalization. So for each content model, our development teams for each of our different page types have to define which, let me turn this down, sorry. Which, what the English link of the content is what the translated length can be if the content can be localized and also if it's a required field. So this has actually been one of our issues during globalization that has gotten us into trouble. If the development teams aren't defining these sometimes we've had failures when we send our content out to translation and back because the content coming back is too big for the field. So that's a really important thing for developers to focus on. So we've written, she's written a whole module around this to help with that. And this again is about the character length as well making sure this is the actual module that checks the link before it goes out. She's also developed her and her team modules to support the localization. So since we need to know whether a published version in the CMS is a language master which will not render versus a locale version there's code that actually sets that. So if it's a master language it results in a false and then if it's a locale it renders a true. So for any places where we need that information we're able to have that coded within the system to pick up to know how to render. Also the content inheritance. So having a way with our translation helper to know all those inheritance. So when I said we asked the geo teams to define the parent and the children that's all defined within the system and there's a module that goes knows to go look for that as far as the rendering. Our outbound translation request. So this is in that TMGMT. So this is the extra customization module that was created to send the content to our internal translation service provider and bring it back in the format that we need within the module. And then this is the piece that pulls the pieces the segments back together and helps us do, make sure at the end of the process we update our translation cache. And I didn't talk as much about that as I wanted to but we wanna make sure every time we do a translation and the reason we're using translation QA team members we don't wanna change the messaging we wanna have an exact translation and we wanna optimize that during this process so that over time our translation memories are being optimized overall driving down our translation costs. So we won't as we see the same term will it'll be handled by machine learning versus having to have a human involved. And this is the side by side module capability that was built in to allow our translation QA team members to do that side by side validation. This is the assembling back API. Again, this will be all there for you to reference. And finally I just wanna say so the key steps to success are really first understanding what your business problems are with globalization that you're trying to resolve and then developing a strategy to solve for that including KPIs. So we knew we wanna get to two weeks as for every one of our globalization projects as a maximum. So we've got our eye on that goal and everything we're doing is trying to get to that goal. We then aligned our processes to the strategy. We aligned our roles and responsibilities and our staffing to our processes. And then we implemented functionality within the platform to support all of our needs. So that's what I have to share. And we've got some connection information if you wanna get in touch. And don't forget to go to contribution tomorrow. And we'd love to have your feedback on the session. So thank you. And I can take questions if anyone has questions. I can't tell if there's... Okay, I'll let you. No, I can hear you, I think. So we actually have divested of our content management system. And so when we were looking at choosing a CMS, I think we knew that was happening. And we probably had about 50 people across our marketing organizations and our engineering teams involved in reviewing input from several different vendors. AQUIA was the one who presented Drupal and AQUIA was ultimately the vendor we chose to get started with for our implementation. And if you wanna learn more about that, the Seattle recording for DrupalCon, there's how to get big blue to dance, I think is the topic title. So you can learn a little bit more about that. But we also were looking for an open source solution. Our engineers wanted a solution that they could customize and they can contribute back to the community. And so we just wanted something that would address our needs. And the inheritance capabilities of Drupal, I don't know if any other system has that, but that's really been important for us as far as our marketing efficiency goals. Any other questions up from here? Web sphere, so there's probably more irony now in this than I can even comprehend. Things are always changing, yes. Absolutely, yes. So I think we made the right choice back then. So we've had a long journey now with Drupal already and we're actually now going through a similar exercise where we are changing our approach from having almost 60 so-called full sites into these kind of tiers. So I'm interested to learn more about how you made the decisions and got the buy-in because my experience is that if you ask, people have a strong inclination towards let's keep the status quo, we want to have the full site. So how you were able to get the buy-in and able to move into these tiers? I think data is the key. Like data was our source and our friend. We had our research team really look, do a deep analysis and come back with data so we could go to the marketing teams and wherever there was any kind of pushback, we said, okay, well, let's look at your data. Let's look at your traffic. Let's look at your revenue. Let's look at your resources. Let's look at the numbers. And so just focusing on data, it took all the emotion out of it. Like it was the best approach. Okay, great. So that's our plan, so hopefully. Sounds like we're doing the right thing, so thanks. Great. Any other questions? Great, well, thank you all. And thank you for going through the video and thanks for a great DrupalCon. This is my first one, like I said before, it's been great. Thanks.