 Let's see, so we are here for the multi-lingual site set up in management, it's going to be divided into really three parts. The first part is for me, I'm Rob Vandenberg, I'm the CEO of Lingotech, we are a cloud-based translation management system and I'll be doing the shortest part of the presentation which you'll soon find out is a good thing that mines the shortest. But I'll be doing an overview of our solution and what we do. Rob Bailey, core developer for the Lingotech module will be participating and going through the details of what our module does, what it includes. I'm an author from AdJax, we'll go through a real-life discussion as well. So those are the three components and feel free to walk up to the front of the room guys that are just arriving late that there are seats up here in the front of the room. Alright, so let me get started. So Lingotech is an eight-year-old software company based out of Salt Lake City, Utah. What we provide as a software company is really a translation management system. So what does that include? It includes things like project management, the idea of initiating and managing workflows so different content might have a different workflow associated with it, with different language pairs. At the end of the day we really think of the idea of content in your Drupal site having a continuous translation model. The idea that translation is not like a print production model in which you launch a site, the site stays static, you've translated once and it's done. That's not reality. Websites change all the time. Think of your source language changing. New products, new content, how do you synchronize that content out across different languages making sure that's the same message globally? So we really think of it as really a continuous, multilingual content synchronization approach. So we've been active in the Drupal community for a long time. We've been bundled in various distributions, participate at about 60 different camps, have a variety of large and small customers using Lingotech from Intel and Cisco and Atachi and eBay, etc. We're a founding member of the Acquia Digital Alliance Program and have a number of folks that are dedicated to the Drupal development in the module. We just had our latest release, I think it was yesterday on R6.0, not Drupal 6.0. I won't run you through this whole part but basically our idea around content and translation is really enabling customers to take control of that process. So the solution leverages people, process, technology and I'll let some of the subsequent slides speak for themselves. So even though we're here at DrupalCon, the fact is a lot of companies have content in lots of different repositories. The idea here is that we can leverage that content in that translation process across many different platforms. One of the unique aspects of that is having a translation management system is the core or center of that translation hub, if you will, is that you can leverage past translations or translation memories, use them in your knowledge base, use it in your source repository, your Wiki, your marketing automation, so leveraging all the translation you've done, storing them, publishing them out in different channels, so that's a core part of our value proposition. So again, the complete offering is really Lingotech inside, those are the connectors to those different content repositories all connecting up to a translation management system and a variety of translation services that can sort of add to that mix, changing translation or content from a word by word basis to different languages. I think I've mentioned this, I'm going to skip this slide and I'm going to show you one, I think last image here. Again, the idea here is there's a translation management system at its core that's powering it, SaaS based, cloud based, whatever you want to call it, there's a contrib module you can download for free, try that out, it provisions an instance of the translation management system which you can use in a demonstrative type of way, it can take your content from your Drupal site, machine translate it, publish it back, so that's sort of the free instance of our software. If you want a full version of the translation management system using professionals, your own community, your own translators, that's the solution that's a paid for model, so we offer both, both a free version as well as a paid version, the free version is obviously free to try, you can use, it's fully functional, but the idea again is to enable and facilitate a continuous translation model, not a transactional model, meaning your content changes, how do you synchronize that content out across languages. That's a lot of business pitching I know, so we're going to stop with that soon enough and get to the core stuff, and I'm going to hand the microphone over to Rob Bailey, who's a developer for us, and he will be able to take you through that, so. Hey, thanks for coming. I would presume that most of you are developers or maintainers of some kind of sites. Who here is the developer, raise your hand? Okay, nice. And how many by the show of hands have done multi-lingual projects in Drupal, okay? And then have you had to maintain the translations on a continuous basis, or is that something that you're able to, to separate? Okay, well good, well at this point, can everyone hear me? Okay, you know that multi-lingual projects can get pretty messy, you have to really understand the nature of the project before you can really get a handle on it. A lot of the clients that we get actually come to us off of failed projects, it just kind of spirals out of control, they have Uncle Bob and he knows Spanish, and so he's going to start translating, and then it just, well it just buries him. So anyway, you know, you need to know how many languages, what your limitations are, there's a bunch of modules in Drupal 7, and I would presume by the show of hands, you know, are you guys here? I'm going to talk mostly about Drupal 7, you know, Gabor is in another room talking about Drupal 8 and you're not there, so you must be focused on Drupal 7, but anyway, you know, what's your budget, how fast do you need translations, and you know, you need to create a framework that's going to work for you and get some questions answered. And so what I did is kind of put together a packing list, here's the multi-lingual landscape as far as modules for Drupal 7, you can see that the green ones are the modules that are in core, and it's just really a whole bunch of modules, internationalization and all kinds of other stuff, and it's realistic actually for your site, by the time you have a truly multi-lingual site, you're going to have just a big pile of dependencies, and you'll need to decide which ones those are based on what you need. And then, so what I'd like to do is just sort of talk through just a minute of what the manual setup process is and then how Lingotech sort of automates that to one of our goals as part of being a service provider is to just free your hands to let you not really worry about the translation, or yeah, the translation. So if you have a lot of time, this is a great exercise to do a manual setup process, but you just don't have to if you're turning out websites. So after enabling the modules, you need to set up languages, language detection and selection, find a language switcher, and then for your content, usually in our cases we're adding translation onto an existing site, and so there's a whole bunch of content that's language neutral, there's a bunch of blocks and menu items and things that aren't set up for translation, and so you kind of need to peck through and find those and get everything working to figure out why this block's not ready for translation. But with the Lingotech setup process, it's easy. You download the module, you run through the setup wizard, and then you're ready to translate just right out of the gate. So first up, this is the information that we collect just to get an account, your name and your email address, and it automatically provisions for you, like Rob said, an instance of the translation management system on the server side. And then it just gives you an option if you want a language switcher. And then here for content types, instead of trying to step into every content type and every field of every content type to enable that for translation, it's just a one-page thing. You say on these different content types, these are the fields that I want to translate. Click, click, click. I don't want to translate URLs or whatever, and then you step through the next one. The same for other entity types, for comments or whatever, you just enable those entities and the bundles and the fields that you want translated. And then for additional translation, what are the things that you want? Do you want your blocks to be enabled, taxonomies, menus, views? There's also miscellaneous strings. I was just talking to someone today about kind of those straggler strings that custom modules will inject into the local source table. This will actually pick those up and make them candidates for translation. And then you hit finish, it gathers everything up and just kind of auto sets things up based on what you've selected. And so you can see here, you know, configuration options have been saved, 76 blocks are now enabled for translation, you know, you have your taxonomies and menus. And then, you know, it says the links are already set to language neutral. The LingoTech module actually makes some decisions if you don't. It makes some decisions for you and says, you know, for the case of menus, since there's a whole bunch of different ways to translate menus, it says, well, it's easy to automate the translation of them if you stick them in the menu strings. And so we use the localize option. But you can override that and stuff if you want. But like I said, it frees you up so you don't have to make so many decisions if you don't want to. Once that's done, it opens up a translate interface. There's no checkout process. You're not managing, you know, different translation vendors from this interface. From here, the idea is get the content out of Drupal and into an enterprise-grade translation management system so that your translators have the tools available to them. So they can apply formatting tags, they can, you know, use machine translation to autofill, they can just conjugate some verbs and then call it done. And so from here, if I, you know, here's the content types in this case. This is just a default Drupal Commons install and I just, with some demo content and I just put it on here. And so you'll highlight the stuff that you want translated. It uploads them and then it says here, here are the status of the translations. Each of these boxes is a translation of each of the things. And so the idea is, we want to eliminate the human error that's associated with offloading, you know, export files, working with Excel, using a specific Excel file. If you want to do that, you know, the Lingotek system is capable of doing that and a lot of our clients do, but they, you know, most want to just get away from that all together and let machines handle that. So when I, when I just click on the status of it, this is just machine translation and so it's, it just kind of finishes by itself. It says, okay, it's ready for download. And then it, when it downloads the translations, they're there. And so, you know, what I've done here has taken, you know, about 10 minutes, give or take a couple of minutes just to completely configure a site, enable it for translation and download the translations, upload and download the translations. So, okay, so when you're, when you're coping with site changes, I mean the 30 seconds after you're complete with a website and translation, your editor's going to come to you with a change and the changes aren't going to quit coming until you die. So, there's lots of different places that it happens, core modules, upgrades, changes to site content, you have changes to your configuration, a new manager comes in and you're changing your business process, you know, all kinds of different places that changes can happen. And so, there's a subliminal, we focus on letting you see the incremental changes as clearly and easily as possible so that you know, ah, this changed, you can send it up automatically or manually, it just, it completely depends on what you want to do and all the tools are there for you. So, here's some of the specific things that the Lingotech module does. We automate the setup like I talked about. It's enterprise translation software, we handle change management, we integrate with rules and work bench moderation and things like that so that if you have complex document workflows on your Drupal side, it's going to allow you to handle those and manage those and just plug the Lingotech process right into that. And then on the TMS side, you know, as Rob pointed out, you know, the demo version is free, it's free machine translation and then also as you click on one of these, this gives you direct immediate access into the translator workbench, not workbench moderation but on the Lingotech side, it opens up a portal for you to actually get in and view what the translators are viewing so that you can make small changes. So, for example, if there's a translation that you just don't like, you could tweak it just a little bit or you can just redo the whole thing and then when you save it, that translation change is stored in a vault for you and that is part of your translation assets with Lingotech. And then the next time, you know, after you download that node, let's say a block comes up and it has that same phrase in it, it's going to be saved or it's going to pre-fill so that the translators never have to translate that twice. So, some of the other things, you can do content translation, entity translation, you can do actually in the same site content translation and entity translation. We have some clients that like to do that because say for some news feeds that they're doing, they have to use node-based translation for some restriction but then for their other stuff, for their articles and things, they want to use field-based, you can do that under certain circumstances. You can do, you know, it does taxonomies, messages, it will do nested field collections with no patches, it's all there, you know, and so forth. And like Rob pointed out, we integrate with so much more than Drupal. You know, the idea of the Lingotech platform is that when your business gets to a certain point, you're not a Drupal site anymore, you're a business and you have a Drupal site but then you also have so much else in your business process and you want to be able to store your stuff centrally and just keep that as an asset to your organization. So, and you also, you can use any translators, even your own community. Even, you know, on the back side of the translation management system with Lingotech, you can export that to XLIF, you can send it off to other organizations. It's, it really gives you complete flexibility there. So, you know, if there's a business side of the room and a development side of the room, the business side loves that the cost and time savings, there's just no more fiddling with exporting and things and translators don't have to re-translate things and do, you know, there's already enough time that's lost in that, in the process that you want to save as much time as you can, but and then on the development side, it's nice to have a support group. Our team is there, we can answer questions and we can just sort of help you through the process and with Drupal, you know, our team loves Drupal because all of the multilingual plumbing is there and for Drupal 7, it's a hodgepodge of modules, but it works and we just build right on top of that and Drupal 8 is so much nicer because it just gives us just four nice tight pillars to integrate with and so it's actually been a pleasure to work on our Drupal 8 module. Anyway, how are we doing on time? I think we have some time and I wanted to save some time for some questions. I was hoping that you guys would have some, so yes, well, Lingotech is integrated with several distributions. We're like in, this was Drupal Commons and it chips with Drupal Commons, but you can get, you know, the latest version of Drupal Commons has a slightly older version of the Lingotech module and so you can just kind of get the latest and greatest. It's kind of like, you know, with Linux, it comes with a distribution and some of the stuff is older, but there's also commerce kickstart and demo framework and a bunch of others. Well, it depends on where you're coming from. If you're a development shop, is that your role? Where you have a client in your development shop? Development shops usually like to partner with us because then they can build the site and then hand it over to the client, the translation part and the client can work directly with us for the translation part and that frees up the development shop to do more development and focus less on the translation side. And then the client will love it of course because then they actually have enterprise grade translation software that they can use. It's very versatile. There's complete translation workflows. You know, every language and localization is different and so if you have, you know, your French team or your Amsterdam team is just okay with, you know, one translator or a reviewer and then you're out the door, but then you have, you know, a more structured, you know, if your German team wants, you know, four reviews and then a final say by the CEO, you know, you can build that right into the translation workflow process. Excellent. Good question. Others? Yes, absolutely. Lingotech has a software arm and a services arm. If you actually use Lingotech for the services arm, then it's a more structured engagement and we'll match you with a person that has that domain of knowledge in, you know, whatever language you're interested in. And then, you know, there's a vetting process and we make sure that that's going to be a client or a vendor that meets your needs. Or if you have in-house translators that have the experts in the subject matter, then, you know, they can, you can set them up on the system and they can be your translators. Great question. Others? Okay, excellent. Well, I really appreciate the time that you took. I think that we just have a couple of minutes. Rob, do you want to say anything? Okay, thanks very much for coming. We'll now introduce Adyax here. Hello, everyone. My name is Arthur. I'm a project director working at Adyax. It's 100% Drupal shop based in Paris. Today we'll be talking about how we built a multi-language and multi-country e-commerce website with Drupal. So a couple of years ago, we started to work with the LVMH group. It's a luxury group, one of the biggest luxury groups in the world. And over the years, we built several e-commerce multi-country websites for some of their brands. And I will be talking about the one particular brand. It's Makeup Forever. Makeup Forever is there producing the cosmetics for professional makeup artists. It's 50% of the customers. Another 50% of their customers are ordinary users. And actually, they had their website before, but it wasn't e-commerce. And they wanted to have much more rich editorial content. And they were not happy how the website was managed in different countries because they have local offices in many countries of the world. And editors in every country, they do whatever they want. They changed the design of the website. They put some crappy content and so on. It wasn't very good in terms of the brands. So the headquarters, they wanted to centralize the management of the content on the website. So there were lots of requirements for this website. And I will stop just on the most important of them. Well, first of all, it has to be multi-country, multi-lingual website. It's not a classical e-commerce website because a classical e-commerce website is just a catalog of products. And more than e-commerce websites, it's content, which is mixed with products. So we have some articles and there are related products to these articles. So this we call rich editorial content. The client wanted a complex validation workflow so that everything is managed in the central office in France. And everything is approved by France and then they just let the translations to be managed in local countries. And this is the e-commerce website. As there are many countries, it means that there can be different ERPs. And in terms of e-commerce, they wanted to have some complex catalog discounts. This will depend on the role of the user because they have ordinary users, anonymous users, professional users, industry users, many of them. And we split the release into versions, e-commerce ready in version one. It means that the website uses Drupal commerce. There are prices on the website. But there is no checkout. And then when the connection with the ERP will be ready, we will release the checkout section. And this is the website about makeup. So a very important thing is to have lots of high definition and high quality images and the videos. And of course it's full responsive. I think it has to be working well in IE7 because this thing doesn't want to die and fortunately some boss has Internet Explorer on his computer and usually that's how it works. Also we decided that we will use the single Drupal instance for all countries and languages. That release will be progressive. This is the easiest way to manage the delivery of the website because imagine if you have 25 countries, the release is just enormous. There are 25 countries that have to contribute some content. Then you have to package all that release and production. So that's why the release is done country by country. We created a system of experts and imports of SKUs, products, categories, stores, lots of other things in Excel. I will explain why later. Only several countries will be e-commerce. But others can decide if they want to display the price or not because all the products in all countries have the local price. And we had a very complex, quite complex translation and publication workflow with the validation rules and the central admins and so on. So just some basic tools that we used on the project. Obviously Drupal. I think I don't need to explain this one. Drupal commerce. We used feeds to manage all the imports. Imports of products SKUs from ERP as well as imports of products, categories and stores from the Excel files. And Apache Solar for search and some product listings. So this is a very global scheme of different incoming and outgoing information sources on this website. In central we have Drupal. We have ERP. With ERP we synchronize SKUs, inventory, orders and invoices. But ERP doesn't contain all the rich editorial data like images, product descriptions, long titles and so on. It has very basic information. That's why we have in the lower parts of the schema we have editors that contribute all the content in Excel file. They can import, they can export, they can manage translations. Then they put all the media files in the CCD archive. They upload all that to Drupal, they import and they see updates on the website. Countries and languages and how do we manage them? So basically to understand how do we have to manage and why we had these requirements for languages and countries, we need to understand how the company is organized. So at the top there is a headquarters. It's based in Paris, France and they have lots of people. They have a full building of people and they have lots of editors. They have enough resources to train them. So there are no problems to contribute lots of content from the headquarters. But local offices, some of them they have resources, some of them they don't. And what headquarters wanted, they wanted to contribute all the content themselves and then push it to local countries and then local countries can decide whether or not they want to use these contents on their website. And this is what we did. We had a central repository of all contents. It's like a subdomain of the website where local, sorry, global editors they can login, they have a special role. They contribute all the content and then all that content is available in local countries and the local editors they can decide whether or not they want to use these contents or not. In terms of countries and languages, there are some countries that have several languages and not necessarily the French language in France is the same French language as in Belgium or Canada. So there can be some copies of languages as well. We managed the translations with entity translation and localization clients and I will stop on entity translation because that's an interesting topic. So basically what is entity translation? Let's raise the hands. Who knows what is entity translation? Okay, I will explain just quite fast. So the standard Drupal translation system works. We have articles and nodes. It has its own node ID and by default when we create 10 translations in 10 different languages there will be 10 different nodes with different node IDs. And entity translation with it we have only one node and all this translation stuff is done in the field level. So we have just one node ID. It's much easier to manage. Not all fields can be translated. For example, a picture doesn't have to be translated the photo of the product because it's the same across all the countries. So this is easily done with this module as well. And finally it's in Drupal 8 core. There is a great presentation done by Gabor. I invite you to check his slides. He talks about the future of multi-lingual stuff in Drupal 8. The translation interface pretty much standard. We didn't change anything at all except that we installed the localization client module. We just set the small block on the bottom of the page. So the editor when he or she opens the page, for example, the page of the product, you can see all the strings which are translated on nodes of this branch. It's quite handy. So the main three features is where the most important is to have the central country where all original content is first created and then pushed to other countries. To have the possibility of copying all content from one language to another, this is handy when we create a new language. When we create, for example, Belgium-French, we might want to copy all the content from French-French. Notification of countries in case of notification of any content in the central country. For example, we have article one which is published in the United States as well. And then the central admin, he adds some new information in this article. And the local editor in the United States, you will see that, okay, we have some updates for this article made by the central administrator. So I'm talking a lot about the countries, but how do we define the country in Drupal? So each country can be identified by the URL, either by path or by domain. It can have some specific settings and its own admins and editors. And in fact, there is a great module which is called domain access module which is, I see the guys right there know it very well. And basically it does exactly that. Everything we actually did, we just renamed on the admin panel, we just renamed domain with the countries. Here we go. We have countries admin zone. It's very easy to do. We added some features like ability to select the parent country. What it means, it means that when we create a new country, for example, Canada and we select the source country as the United States, we will initialize this country with content. So when the editor opens this new country, Canadian website, he will see the fully featured website with all content, with images, with everything configured, and then he can go and publish some product articles and so on. So in the domain module you can select which languages are enabled, which one are enabled and defaults. The same we added the notion of source language to the language itself to copy translations from the source language. And what it gives, it gives this structure of languages and in the top we have English English. It's like the main source language, all the new content is created in English English and only then it's translated to Canadian English, for example, or to French. We pre-create translations automatically. So when, for example, Canadian admin opens the article, there are values for all the fields from the source language. So if you don't want to change anything you just click on publish and that's it. But if, for example, you are translating to French, you can translate to French and publish. But also, for example, it's not very useful, it's useful for English but it's not very useful for French, that's why any language can be a source language for another one. And everywhere in our dashboards, on our dashboards, we have the flag outdated translation, yes or no. What it means is that if central admin modifies the article which is published in ten other countries and languages, they will see that this article is outdated, the translation for this article is outdated. There are some changes done by the central administrator and they can either contact the editor or just click on the button and copy the original translation to the local copy. A few words about the validation workflow, it's quite standard. We have drafts, we have statutes to validate, validated and then published. I would like to precise that entity translation didn't support revisions when we started to work with them, that's why we had to implement our own revisioning system to enable previews of content for example. So we have a draft version of content and published and there is no history but when we publish something from drafts we just replace the published version and so at any time before we publish the draft we can just preview this version of the content and it's some kind of custom rebuild preview system for entity translation. Some other features, important experts. So yes, important experts is done by Excel, why Excel? Because everyone knows how to use it. So you don't have for example the offices in New York, they can pay some money to train the editors to use the pick office of Drupal to do the translations but the office in China unfortunately they don't have the resources, they have just like five people working on the website, not exactly on the website on marketing of the brands in China. They know how to use Excel, they don't know how to use Drupal, that's why we create these files. The format is strict but everything you have to do is just export the file you send to editors, they change it, then they send it to the headquarters, the headquarters they verify and they import and here we go, we have a translated website. The Excel file with the SKUs and products is quite complex, actually a very huge Excel file because there are many, many different fields and editors they easily can start panicking and saying okay I'm lost in this huge file, help me. That's why we introduce color codes to separate fields from SKUs and products. We highlight optional and required fields and just a small help to our editors. And when the file is ready we just import it through the dashboards and take some time. We also import media files but for this we have to create a special media archive with a special structure and then it's getting uploaded to FTP, to FTP because it's a bit too heavy, it can be several gigabytes and that's it. A few words on security because we have a small problem with it. So all the non-secure traffic, basically our content delivery network provider, they do not support SSL. Why we use this content delivery network provider? It's another question but it just doesn't. Anyway, so we had what we had to do, we had to pass all the non-secure traffic through CDN with the domain, with the subdomain 3W. We had to create another subdomain 3W 2WS secure domain and to pass all secure traffic directly to our servers. So this is a bit tricky to configure and it's not the ideal way to work. For example, Akamai, they support SSL but that's like that. The main take-home message on security is just that if you know that you will support SSL, just configure it in the very beginning with the self-signed certificate because there can be some problems with the Ajax pop-ups posting data from insecure page to secure page and there can be some problems. If you do it two days before the release of the website, you can have some surprises. The front end wasn't the easiest one because we had to support several breakpoints and the main problem was that the website, one of the requirements of the client was the speed of the website, had to be fast on all the devices and it's responsive so if you have on the desktop you have a huge image in the banner on the home page which can be up to one megabytes and if you are browsing these websites on your mobile phone sitting in the subway and you will try to download this one megabyte image, it can take some time. That's why we had to use responsive images. It means that we serve different sizes of the images depending on the resolution of your device. We're not resizing it with the HTML and the CSS and just a few screenshots of the site. The design is really nice. In terms of performance, we use CDN so all the static files are delivered by the CDN with domain sharding. It means that we have subdomains like farm static one, static two, static three. It allows to speed up loading of the static files and browser just a bit. We also have a microcache in CDN and then we have a varnish with the tag-based cache. The tag-based cache is something that we had to build. How does it work? For example, you have a product page. The product page is a node so it has its URL and it's also displayed on the home page, on product listing. It displays as a cross-sell on some other product page and in many, many other places on the website. Then we change the products. What happens? Usually you just flush the cache of this product and that's it. You have short TTL for all other pages and you just wait when these pages will expire and you will see the updated product information. In our case we tag all the pages where this product is included and when this product is updated we can flush all the pages of the website where this product is displayed. It's very handy. It allows us to increase the TTL in varnish to some ridiculous amount of time, like one week or something like that. The main message on performance is if you plan to use varnish, memcache, some other tools, just activate all of them in the beginning of the project because if you start to use memcache just one day before the release, it can lead to some delays in the release of the project. A few words about the organization. So the key numbers we've spent for version 1 10,000 hours, 10 months of development and we had 700 pages of specifications written out of which 500 pages of functionally technical specifications and 200 pages of front-end specifications and the style guides. Just a breakdown of the hours spent by different actors on this project. So the total hours, we started in January and we released the project in October and I just added two other months for stabilization of the project. Developers, front-end, QA and project managers. In terms of timeline, so we usually work with our clients on a fixed-based budget. It means that we are not very agile in terms of scope. We have a budget that is very difficult to change the budget during the project for different reasons. The client just doesn't have enough money or in this year, for example, or they just don't want to pay. There are many reasons. That's why we always do design and specifications. At least we try to in the very beginning of the project and then we validate them with the client and they sign it with the blood. Front-end development, we did it in sprints. We had 21 week sprints, one week for something new to us. But it is quite good because every week we can deliver a new page to the client which is tested and then they can play with it and so basically the client is, every week the client is busy. He doesn't ask you questions. He can see that there are updates every week. It's very interesting. The Drupal development was split in 10 three-week sprints, two weeks of development, one week of Q8. Then we've got code freeze. The code freeze, it's not actually the code freeze because usually we start panicking at this moment and we start to finish everything we didn't finish in the previous 10 sprints. But it's also the bug fixing period. Then there is a UAT. This is a real code freeze because no features are added. It's very particular to this client. They booked this two or three weeks of user acceptance test with real users on some pre-production website. And then live. Just a few tools that we use. Git for source code, RedMind for project management, Catastreno for automatic deployments, and Pingdom to measure the page speed and to send alerts if something happens with the website. And that's it. Just again, I've worked at Adyax. It's one of the largest Drupal shops in Europe and we've worked for many interesting clients like Johnson & Johnson. That's it. Thank you very much. Don't hesitate. We have like five minutes left for questions if someone has them. Yes. We actually do exactly the same. But you mentioned that you copy the translations over. So if I have like the French Belgium, do you copy every node when you install the French Belgium then every time you copy over or do you use language fallbacks? We don't have, we disabled language fallbacks. So when we create a new language and a new country, we copy all the contents. We call it initialization of the country. This is done only because usually when you create a new country and a new language everything is empty. You don't see anything and it's quite ugly. And this is not the client that wants to see his website ugly. We prefer to display the contents like the real website, the copy of the source website. Yeah, we actually had some reasons why we decided to copy. Why did we decide to copy? I don't remember exactly but I think because in some cases they wanted to keep, yes, because the main market was the United States. So they wanted to keep the original language and to change some lines or to add them and it was just a bit more handy for them to have the text already existing in the field like in the body of the term node and then they would just change one line and that's it. Do you use domain accessibility and for the multi-language website? Do you use it or not? It's for this website. Do you use it? Domain access? Yes, we use domain access. It was, actually, I used it one year before and you are using it for multi-language websites. Well, the domain access, we use it for multi-countries websites because the multi-lingual websites, you don't need domain access to do it because you have support for different languages in Drupal. It's not specifically in the Drupal core but if you want to have different countries, like you want this small select box on your website where you select Kale send me to the United States website and then you have two languages in this country and all that is managed by one single Drupal instance with one single database and yes, you have to use something like domain access module. All the specifications at the beginning, did you really like finish every part, all the parts of the website at the beginning and documented it? And didn't you forget about what you decided at the beginning in month 4 or how did you handle the process? Well, over the years we found the format of the specifications that allows us to be pragmatic, not to write just lots of text and understand that this actually doesn't correspond to anything we decided with the client before. So we are quite short on text but we specify content types, taxonomies, main rules, business rules, how everything has to work and yes, we specify everything and that's why we had 500 pages of specifications. Yes, but I would like, just a moment, I would like to say that we try different approaches. With the fixed budget it's very difficult to discuss something with the client when there is no base for discussion. If there is no base for discussion then it's just your word against their words and that's it. You can have the design but there is a button and if it's not written that this button has to, it's red but under some certain magic condition it has to become black for example, just an example of some small functionality. Then how are you going to prove that you didn't discuss it? So the specification is the only way. You can do it spring by sprint but for a big project like this with the fixed deadline first of all we have to provide a date and to respect this date. It's not agile in terms of deadlines as well. We cannot specify spring by spring because we cannot see the size of the project in the beginning. So, yes. Sorry. How about the pricing, shipping, taxation across countries? Yes, so this is done with Drupal commerce. In our case the pricing of the shipping is fixed cost. There are several options. It's like I forgot how it's called. It's like a table based shipping cost. So we just have three different shipping options and the fixed price for them. That's it. And then the second question was about taxation. Taxation in the United States, the taxation is done per state and sometimes per city in the state. That's why, if I'm right of course, and it's just done with Drupal commerce as well. It allows to specify the taxation rules depending on some conditions. Sorry. Yeah. That's a problem with the Ajax to be honest, because we always consider releasing some of the codes that we do, but we just don't have enough resources to do that. Probably we would like to participate in some work for entity translations in Drupal 8. That's why we have our development team who are attending the summit this week, and they're right now listening to the session by Gabor, because there are some interesting things that we could propose. But for Drupal 7, I don't think we will do anything. Next question. Okay then. Thank you very much.