 the directory on your file system. When you import a file manually, that's going there too. So basically what you can do with that contributed module that's possible to write is you just pick whatever file was uploaded by mistake, you delete that file, and then you just drop all the transitions, and then you report every pure file that's there. And in that case, we just restore it through the state. But if you also manually change things on a user interface, we do not write that out into pure files, those changes. So there is no direct solution to that. That's also possible to write a module for that, but we don't have that. So if you don't use that interface at all, and you accidentally import a pure file, it's much easier to recover from. Because all the pure files are in the file system that you used to import some time earlier, they're sitting there, and you can only report those. Yes. In the future, the system is possible to fix that. OK, I think I'm running out of time anyway. So if people have questions, please come over. I will be around. I will be at the sprint. So I would love to work with you if you could come over and interested in solving some of the remaining problems that are very interesting. Thanks for coming. Hope you enjoyed it. Totally battery to go forward, at least to the top of the room or something, because the front around the front might not be the problem you had enough. Mm-hmm. Are there sessions that willing to see me next? Is this what I can remember from the behind the scenes? Is that what you were talking about? I think we'll be in one in a minute for those who write late. So I'm Yara Rouchi, and the session is Sukkuch Drupal Eidrim Bahapashi. I do know the steps, right? Practice a lot, which is that everything multilingual in Drupal Eidrim English, the rest of the session is going to be in English. So I am Yara Rouchi, and I have kind of a tendency to test the system of conferences. So this one is from a Drupal Khan. This one is from another Drupal Khan. This one is from Program Drupal Eidrim. And this one is from here. So the problem that we've seen at some events, which is kind of ironic for Drupal Khan Asia, is that full multilingual support is sometimes an afterthought. And here I'm stretching the problem of it's already a multilingual page. But there is always someone else to improve. So we decided in Drupal Eidrim to kind of look at this and see if we can make the system understand that everything may be multilingual, including wings, and try to solve that in a systematic way. And this talk is about the Drupal Eidrim multilingual system only, and we'll have plenty to talk about. It will probably go too fast for some of you. But there is a lot of other things in Drupal Eidrim to be proud about. So there's web services that are not multilingual to some degree as well. There's views that are multilingual as well. There's authoring experience improvements, configuration system. There's mobile improvements, a whole lot of things. But this is just about multilingual. The good news is, however, is that a lot of the other subsystems that have been improved actually added a lot of additional power to what we do in the multilingual system. So you'll see, for example, with views, that views and multilingual, where they intersect, gives you very powerful tools. The other thing that I wanted to leave with is I'm the person doing this session. But obviously, there's a lot more people who work on this. So there is a Drupal Eidrim multilingual initiative, and this is a list of people who worked on the initiative. The bigger names contributed more, the bolder names contributed more recently. And it's not in fact the whole list, that would be the whole list. So it's a result of a whole lot of people working on this. So I think we put in a lot of effort, and across 1,300 of us, we also had a lot of fun building this up for you. So we went to all kinds of events, and sat down and worked with each other, and monitored each other on different issues, and just figured out how to make things happen. We also just sat down alone and worked very hard. And that also had a lot of fun, and celebrated a lot when we figured out our solutions. We also worked on a lot of issues. So if you try to count the issues that we tagged with the Eidrim, Drupal Eidrim multilingual initiative, there's over 1,700 of them. We did not resolve all of the issues. There's got to be Drupal Eidrim 1, Eidrim 2, Eidrim 3, and Drupal Eidrim 9, hopefully sometime. So there's stuff to improve, and we also see that we did a whole lot of things. And the question is, why did all these people come together and do all these crazy improvements on these issues? The reason is, we've had experience with how to build these things, and we've had our own struggles. We've seen that people use Drupal in all kinds of environments. Like for example, Berlin uses it on their city marketing site in Berlin. Also, Canada uses it on keep exploring. There's Canada marketing site, Magic the Gathering uses it if you've been role-playing ever before. There are makers of fun games. There's the banking sector uses it. This time from Lithuania. The public transport sector uses it. And Montreal, the UT sector uses it. These are all multi-lingual triple sites. Interests use it for their business sites, in this case in Japanese. The World Health Organization uses Drupal multi-lingual. UNESCO uses Drupal multi-lingual. If you want to register a domain name in India, you would go by multi-lingual triple sites. If you want to connect with the government in India like after the IM, it's a multi-lingual triple site. If you're interested in some TV, on Sony TV, that's also multi-lingual triple site. So it's kind of hard not to bump into multi-lingual triple sites. So a lot of people already do this. Anybody in the room who had pain doing this? Struggle with issues. Anybody? Okay, a lot of you, yes. So it is possible, but we wanted to make it a lot simpler. And these organizations, they probably have a lot of resources and there's the facts. But what I'm really proud of is the small sites, like this one from Stanford. They have a site in English, Portuguese, and... Okay? So they have a site in three languages and just for a small program for kids to make them learn technology. So it's a site that does not have resources to put in developers and solve all their problems. So they need a system where they can just fire off the multi-lingual site and be happy with that in no time. The problem is we are not really delivering that with Drupal 7. So Drupal 7, you have Drupal Core, then you're able to look how module is great. You can have languages configured on the site. It's kind of nice. You can translate in a face. But then it's all manual. You need to enter everything manually. If you download transitions from the community, you need to manually download them and localize to Drupal.org, import into the site, have them on the site, manual update views module and panel module. There are transitions that are updated. You need to manually go out again, download again, import again. It's very painful. So you would obviously install localization of the module, which automates all of them for you. It downloads all of those translations. When you have these modules, when you operate modules, it's very nice. But that's it for interface translation. You still cannot do any multi-lingual content. You enable the content translation module. That's nice. So now you can have multiple copies of the same content piece on the site, different languages, have relations between them. But now you put them in menus. Menus are translatable. Sorry. So you install the I-89 module. That's nice. It enables you to translate menus. It also enables you to translate a few other things like field labels and block titles and stuff like that. But now you're scratching your head. You want to translate the e-mails that are sent out to users. E-mails are being sent out. They are not translatable at all. None of these modules like to translate the e-mails that are sent out to users. So now you enable the variable modules. That's a whole set of modules. So that's a variable module. The variable I-89 module, there's connecting modules between the two. So it actually enables you to translate those e-mail tests. Okay, now that's fine. Now you have an e-commerce shop on the set. You want to sell stuff. Anything would enable you to translate that? No. So you grab the empty translation module. Okay, empty translation module that allows you to translate whatever entity you want. It also allows you to translate taxonomy terms. But you already installed the I-89 module which does allow you to translate taxonomy terms as well. The content translation module you also have which you use before to translate nodes. So now you have two ways to translate nodes, empty translation and content transitions. Very nice. So even trying to figure out at this point what tool to use for what, like I had a taxonomy term, how do I translate it, where I have a new category to translate it. So I salute you for figuring it out. On Drupal 7. Congrats. Good job. So Drupal 8, we wanted to make this simple. We wanted to have one solution for everything and so that that solution actually works with the other module you've added. If you have rules, if you have e-commerce, if you have whatever like workbench or something else. So, we added a system for managing languages. Those about your languages and that's it. It decides how a language is picked, et cetera and that's a base choice. Again, we have a system for translating the interface of Drupal and that works across everything on the interface. You can translate views without you can translate content types or anything that are built into your code. We have a content translation system that allows you to translate whatever content, content meaning all kinds of things. We'll define that later on. And we have finally a solution for translating all configuration. So these four pieces cover everything in Drupal Core and they are extendable and they allow you to translate every configuration you can fit. Every code that shifts with modules and every base configuration. So let's go through these and see what's in each part. So let's start with language. So language is a separate module now in Drupal Core. It's called the language module. We wanted to really highlight this feature out of the get go from the start. So when you install Drupal, the first screen you see is a language selector. So you go there, it already selects you the language based on your browser preference in my case and here it is. But you can pick whatever else from the 100 or so languages we have. In this case I'm just going to pick a target point up. And then you hit save and continue and it downloads the transitions right away automatically when you install it. The next screen is going to be Arabic. It's a bar that is not right to left. It's going to be right to left soon. So you pick your install profile, you give it your database credentials and it's all Arabic except where it's not translated because it's not on fault. So you hit that and now from that on it's RTL as well and it's working with installation. So basically the first thing you choose when you install Drupal is one of your languages and beyond that you don't need to know anything about English. It's all going to be in your language. And it's all working however you want. So that's the first thing that the language, the new language system does. The second thing is language assignment. So the problem with translating stuff is we can only translate stuff if we know what language is in. Otherwise to make assumptions may or may not be true. Drupal 7 makes a lot of assumptions about language and it makes a lot of mistakes based on those assumptions. So the problem in Drupal 7 is it only supports saying what language a node is in, what language a user is in and what language a path alias is in. If you set up a view in Drupal 7 we have no idea if you set that view up in Hindi or if you set that view up in Spanish or whatever other language we don't know. We need to assume that you probably created that view inside default language. May or may not be true. We don't know what your user emails are set up. What language they are in. We have no idea. So that's kind of a problem. So in 8 we decided to extend this basically infinitely. So in Drupal 8 we know the language of a taxonomy term. We know that taxonomy term was in this language. We know the language of views. So when you create a view you can create a view in Hindi. And then if you need a view that's only available in the English part of the site you can create that view in English. And then later on if you decide to like translate the English one to Hindi and the Hindi one to English is totally fine. It's going to work. So we know the language of views. We know the language of your site information like you know what language your site name is, your emails, etc. All of them. And that's basically infinitely extensible. So we can go on and assign language to whatever. We know the language of your menus. We know the language of your menu items. We know the language of the blocks that display your menus with your menu items. And then we need to figure out which language to use. So we have this content language screen for a content language assignment. And by default that's not what I meant. So we have a content language screen for assigning what language to use for a content. Because now we know the language for everything. But it could be very tedious to set up language all the time. Like when you create a view, we kind of hide that language setting behind a separate screen because we make an assumption that you can configure it however you want. When you create a forum post on a site, on a random site, it would be kind of jarring to see the language selected. It's very confusing. So we decided to give you an option to configure language defaults for a content. And the way we do that is by default we create all content in the site default language. And you can set up diversions from that. So you can say you want to create content in a different language and custom blocks in different languages as well. And then you can say, okay, there's articles and basic pages and forum topics. So maybe I want to create forum topics in English all the time. I don't want to multilingual forum. I don't show the language to lecture on forum topics, but for articles, I want to default them to English, but I want to show the language to lecture on them. So basic pages is fine to default to the site default language. Don't show the language to lecture. And then for basic blocks I want to create them in English again and show the language to lecture. So basically it's very flexible in terms of how you want to set up interactions for language assignment for these things. So you can say you can always assume the site default language in which it deals on a check. Or you can diverge from that and say I want to specify the language dynamically whenever I create that type or you can say I want to fix that thing to a specific language. So if you have a single language forum it's very easy to set up. So that's about setting up language defaults for content. And that, I'm not sure you've noticed but it has dynamic defaults like the current pages selected language or the user's preferred language or the site's default language. So like if you take reviews on products then the user would probably submit a review in the language of the page because they always send the rest of the page so you can default the review to the language of the page and you're not sure what I would select to review it. That makes you can get multiple reviews depending on the page it can be in any language but the user is not bothered with specifying the language at all. So you know the data but the user is not bothered with the interaction. Then we brought language to blocks as well. So once you have information about language of content, you have information about language of views, etc. You probably also want to have language for your page building elements. And Drupalite comes with blocks for that still but we don't have a fancy resolution yet. So we put language visibility into core for blocks and that means that when you have language module enabled there's this language selector on blocks and it allows you to select which languages will this block show up on. If you don't check anything it will show up on all the pages. So it's very easy to set up pages for different languages, height, certain things. This can be used to set up multiple menus for example with entirely different menus. Every menu is displayed with a block. So you can say I want a different menu on my Hindi site from a English site so you can set up a menu in Hindi in English and then show them in their block and then show their language visibility based on which menu you want to see on which page. So that's also available with blocks. And now we have all those languages how we decide what's actually used on the page is based on our language selection criteria and this was available in Drupalite as well but we improved this a whole lot. So one of the things is in Drupalite 7 you enable local module and it adds a few languages and nothing happens because there's no defaults there's no sensible defaults for language selection. In Drupalite we have this URL language selection feature enabled by default and then when you go in and configure that the prefix and domain configuration is right in there on one page so you can review all the prefixes and domains for language so you don't need to go to every language and figure out what's set up and how. So it's very easy to set it up here the prefixes and domains the session selection is pretty much the same as before the user configuration is the same for user preferences. The browser set up is very different because now we allow you to map external language codes to internal language codes so Drupalite does not all the language codes are the same across the globe so like Chinese has all kinds of language codes used that we map to our internal language code and you can add whatever mapping you want so that when browser language preferences come in we can map it to internal languages and then we have administration page user preferences so you can browse the administration experience in the prep and input language and we have a selected language fallback which you can configure either to the site default or to some specific language. This solves one of the biggest problems in Drupalite because in Drupalite 7 people change the default language of the site and Drupalite 7 makes a lot of assumptions about the default language as I've said before everything you created assumes to be the default language so when you change that it just breaks everything so here this is totally separate from the site default language you can configure it to however you want and just set it's going to use that so you can build the site in whatever language you want and when you hand it over to the client you just change the language fallback and they can use their favorite language as a default. Then we have a name transliteration so if you type in a name Drupal generates a machine name but that was usually difficult with all kinds of foreign languages so in this case this string contains all the Hungarian special characters it turns out to be a readable English string and that happens to work with so we have a library built in to do transliteration for machine names we don't have transliteration for file uploads, for past releases or for anything else in port at this point I would love if you would come on Sunday and help us build out those things for 8.1 8.2 because that's a very often requested feature but we haven't been able to get around we have this resolved though one thing that at least in Europe is very popular is English can be deleted from the site so in Drupal 7 English is always there you can disable it but then I18N tends to show disabled languages and places it's going to be very confusing to see English all the place where you don't need to have English so in Drupal 8 you can just delete English and the way it works for all the things that are in English like the text in the source code is obviously going to work because it's hard coded in English so there's no way to remove that but the English itself is not going to be and the system is not going to be show up in language selectors or anywhere for the user is very convenient if you actually don't need English so in summary you can delete English there's a very flexible system for selecting language it has sensible defaults now so URL selection is enabled by default there's browser mappings etc we have block visibility for a language so you can hide and show blocks for a language you can place a block multiple times on the page I haven't even talked about that but that allows you to place something at different places for different languages so if you have a special special if you're running for a certain region you can put that up for that specific region and then you can hide it for everything else or you can put it up down on the page for some other region or some other language it's very easy to show the same thing so this place is based on language it's very cool we have flexible configuration for language defaults on content we know language of a lot of things and it's a first-in installer so who's liking all these new things cool so this was one fourth of the improvements in Drupal 8 somebody asked if it's going to be easier in Drupal 8 I hope so next one interface translation so as I said the problem with Drupal 7 interface translation is it's manual a lot of manual work Drupal 8 everything's automated so in the installer you pick the language it downloads right before the next screen appears if you later add languages it downloads translations right away at that point if you install new modules it downloads translations in the installation progress bar it downloads the translations and applies it on the site so by the time it says done it's already translated and downloaded and if the community updates your translations it downloads the updated translations as well automatically now you may be all freaked out because you're going to deploy a site and then it's automatically downloaded things in the background not very good however what we did is we centralized this download stuff into one directory and what you can do is you can use this ultimately download system in your staging or development environment where this just happens then you do the quality assurance and then you push this directory to the live site and you disable the automated updates there and as part of the deployment process you can just import those files in the deployment process and you are done with your updates to the live site so it's very easy to use this on the staging site of course if you don't have the complicated staging you can just run it on the live site on my blog I'm using it on my live site it's not mission critical so for anybody that wants to take care of what words are used then it's very easy to do the other thing where you want to take care of what words are used is you make modifications to those translations because not everybody is happy with the translations that the community does so what we did in 8 was we customized those translations on the site and we know which strings you customized so we track every string that you customize and by default we do not overwrite those customizations from the community so even if the community updates translations to those strings we keep your customizations on the site you can obviously set it up to overwrite it from the community but by default this makes the most sense and because all those strings are marked you can export customized strings and take the same customizations to the next client and then take those customizations to the next client so you can reuse your same favorite translations or you can use these translation files across different markets that you serve or whatever you want so it's very easy to customize and use those customizations across different systems we made it very easy to touch up on translations so who knows this user interface translation search interface from Drupal 7 not a lot of you so probably the reason for that is this is impossible to use in Drupal 7 because you search for something and then you get a table with a summary of languages cross that out where a translation is available then you click in and you have 20 languages on the site and now you have 20 input fields for one string to translate one string to 20 languages at once and you've probably done the whole 20 languages on the site so what you would likely do is you would want to search and then get results and then translate them right away so that's what we do in Drupal 8 so we have a table it supports singular plural pairs we obviously support plurals in many numbers this example is Hungarian we have the same number of plurals in English but it works with whatever number of plurals you have in your language and it marks stuff that you changed in a special color so if you come back from CHI see what you changed and it saves them as customized translations so if I search for only translated strings customized then I will be able to see that those things I customized on the site so these are now protected from community updates they are not going to be overwritten by anything else it's very easy to do on the site another thing that people really want and they use the string overwrite module for that to change the English text on the site so let's make what we say sign in it's not possible in 8 not possible in 7 some people take the string overwrite module other people set up English custom language both have their own problems so what you can do to create is translate to English sci-fi so by default English is not applicable as a translation language but you can go edit English it's a very easy edit form and it has a checkbox at the bottom that says enable translation to English and now English is the translation target and I can say ok I want to search for login in English and I want to change that to sign in and save that save that and then from now on my login button we'll say sign in so if I go to my anonymous content we'll say sign in from the bottom at the bottom so very easy to touch up on interface text no need to set up any other models no need to set up a special English language this is very useful because if you set up a special English language you're going to get confused you have a custom English in English and some content is in this I mean some content is in the other one is a mess so that's interface translation you can translate to English as in change the English interface text we have a whole new interface for an insight translation of your interface we tried your customized translation so you can leverage from the community if you want however we also collect translations from the community automatically download them and update them even for contributed modules using your deployment system and disable this feature on the website and it's a totally separate module so if you don't need interface translation you just want to track languages on files you don't need to enable this module you just use the language model you have here with that one anybody found useful things in there? yeah cool so that's half of what we changed the second half is still left so our next one up so as I said the problem in Drupal 7 with content translation is we have this module in core called content translation it only allows you to translate nodes it also makes copies of nodes that are separate copies we also had this very fancy empty translation module in control that allows you to translate all kinds of entities but it does not allow you to translate the titles of some of the entities you need to have the title module as well the two of them are not directly compatible so you may either use one or the other it's hard to migrate from one to the other and it's even harder to choose between them and the worst part is contributing modules may or may not be compatible with one or the other I think that's the biggest pinpoint so we wanted to have a system where all content entities are supported and all the contributing modules work with that system so that's a huge benefit of having this in core because we can have a solution for everyone so the question is what's a content entity I use this in a pretty broad sense so Drupal 8 has entities which means basically things that have instances of them have multiples of them and there are two types of things that can have multiple items there are content entities which usually take fields but not all of them take fields so for example nodes there are comments that sign in terms contact messages, menu items, etc are content entities so we have language support for them as shown before we can configure language defaults for them and use the interface of how the language is applied but you can also translate all of them into different languages and that's very powerful so we base this on the entity transition module from Drupal 7 to configure it on the same screen where you use to configure language defaults for content and now it's the time to pay special attention so it's the same screen, it's now called content language and translation since I enabled translation it still has a summary of the same content types but now there's a translatable checkbox for every content type so I want articles translatable now I have all the fields for articles one by one all the author is track per language or the publishing status is different per language and for images I can even say I want to have the same file but I want to have a different alt text than the title text and I can decide if I want to have text automators separate or not same for blocks, same for basic pages same for format topics so basically all the fields that are supported on an entity type are exposed here and you can say which fields are in different states so you can say I want to track the author per language I want to publish things per language so I may be publishing the Hindi version of this but not the English version or you can track you can have the same file but different text like if you're selling a product you probably have the same product photo on different languages but you want to have different text on them for alt text and title text but you probably have different language illustrations because they have text on them on the image as well so you can make your own choices here for every field so this is very similar to how entity translation works in 7 it's field-based but if you really like the content translation modeling core in 7 you just check all the checkboxes every single checkbox and that is practically the same thing because now you have a copy of every field and you have a copy of the content in every language so it's easy to reproduce both approaches from 7 and it's possible to reproduce anything in between it matters on what you choose and you don't need to do any migrations because it just happens in the configuration system there's no migrations between the configuration so I think that's kind of powerful it really brings all of these together the translation interface for content the same thing there's a translate tab that was in group 7 you go to translate tab it has a list of languages that are available you pick a language you want to add that translation into two columns a node form in this case for a node and then you can just enter that translation and be happy with the results so that's content translation so now you have that content in all the languages how do you get that content out to people so Drupal 8 includes views and it not just includes views as if you install views on Drupal 7 no it includes views and it makes views the fundamental part of the system so when you go to the front page of Drupal 8 it's a view you can customize the front page and change whatever you want about it what's how it's filtered if it's a table or a list if you go to the recent comments block it's a view so you can customize how many comments are displayed if it has a page or not where does it go if it has a next button whatever if you go to the node admin page the content listing page is a view so you can customize what filters are available in the page you can customize what columns are displayed for your content administration you can clone the page and create a different view for your workflows you can clone the page and create a different view for your translators it's very powerful so if you master views you can do a lot of things views is basically two things it's a query builder so you can tell it what to how to produce results for you it's a query builder so you can tell it how to display those results it's a query builder and a display builder and it has support for language in both areas so in the query builder which is in the first column in views we have a filter criteria for content language and this is the default front page by the way in Drupal 8 it's set up to filter to the translational language or the page so when you switch language on the front page from English to Hindi it's got a filter to only the Hindi translations or only the English translations by default but you can set this up to be filtering to the user's default or not filtering at all or showing multiple languages or showing only translations that were translated more than a month ago and may need to be updated whatever so it's very easy to build up filters there's a rendering site which is in the second column here there's a rendering language setting which decides on how the result is actually going to be rendered so that default front page is content language of view row which is the language that the result was found in so basically render whatever we found but you can configure this to render the original language version of that so you can filter for whatever is not translated to Hindi yet in the language that it's only translated in and then you can translate Hindi from there so it's very easy to build a query and then decide how it's displayed in views and both of them have flexible configurations for language and then of course views the output of views is a block that you put on the page and the block has language visibility so you can use language visibility there to ensure things for the language if you master views you're going to have a very good time the only unfortunate thing here is the migration path for translated content is still pretty much in the works it's not easy to figure out how to migrate from both ways to the new way we have proof of concept patches that need testing and need more help so if you want to help in that area that's the right time Sunday is going to be a sprint we would love to see you there and see you have, the good news however is we've also built a language support to the core search module itself and the search API so it knows about the languages of stuff and whatever language you tried to search in and whatever language the content was in and indexes these translations as separate things so if you use core search you'll find them as separate items access and generally entity access is language support as well so if you use translation you can sell access to the Hindi version separate from the English version because we have access support for language too so that was the third pillar of multilingual support we have now an entity access support for language we are indexing content separate for language search APIs languages the migration path is still in the works thanks to anyone going to help with that it's all views integrated and because a lot of things are views if you want to customize how your load ending page handles language if you want to put a tab on your load ending page for translators just clone that display put on the tab do whatever with the filters with the display it's very easy to do there's no module writing and you can export that into configuration and share that with other sites no coding required it supports all content entities in core and in contrived so if you use rules if you use e-commerce if you use workbench whatever they will work with the system and it has a perv on no field and sometimes a subfield level setting so content types, taxonomy more categories that's the bundle level and then the field level is titled author, publishing status etc and the subfield level is for some of the fields like files where their subfield retails to that's content and we are not done yet so who found this interesting for their work who's going to use this very good finally configuration transitions so the good news for this is it's a totally green field project interblade because 7 had no support for configuration transitions so what people complained about is we actually did our configuration but it was a copy of the transition at the time when you installed something so when you install Drupal in German you would create the content types in kind of German at the time of the installation in the state of the language available at the time and we didn't know what was actually translated and what was not and then later on we never updated that and if you change the site default language from German to Hindi we would never have any idea if it was in German so Drupal 8 we solved that problem all of those problems one by one so let's see what's configuration in the first place I talked about these entities that are the thingies, the items in Drupal 8 and we talked about content entities that are usually created on the front end and they usually have fields on them but not always true and there is configuration as well and some of those are entities like views, vocabularies contact categories, fields menus, etc and some of them are global configuration like the site information user emails, etc so all of these we know the language of so site information and user emails we globally know their language I mean for all the user emails and for all the site information at once and for views, vocabularies, etc each single one we know their language so each view we know which language you created that in each vocabularies, each contact category each field, each menu each block block placement so all those things there is one area that's kind of left over that we did not get around to is half aliases is kind of another circle but the main point here is we have a general solution that's extensible to contributed modules for content and configuration if you have a contributed module you are not in the green or the blue circle you are not using the content API, the entity API and you are not using the configuration API you are doing something like half aliases you are doing your own custom tables your own custom data storage whatever you are on your own ok we have support for you for content we have support for you for configuration if you do something else you are not following the Drupal framework you gotta resolve your own problems so we resolve problems in these areas and finally we solve the problem for configuration because we track language on each config file each view each menu, each block and we store language over writes so anybody heard about the configuration system how it works, how it's deployed not many so the configuration system in Drupal 8 is totally separated from the content system in Drupal 8 and it stores configuration in a way that's easy to deploy to other environments so you can export all of your configuration from your site work on it in your development environment see the changes deploy that to live, review that your changes are fine and deploy those changes to live so very easy to do the way translation works is that our language over writes to configuration so we always store the things that you translated so it works very well with the deployment system for configuration in Drupal 8 and it's also very easy to translate so for everything that is shipped with Drupal Core or a module we have a solution built in the interface translation module so for example this is the website feedback contact category is the category that's shipped with Drupal Core so I'm going to translate that by going to interface translation so user interface translation website feedback was shipped with Drupal Core I'm going there I'm entering my translation saving that there is actually going to be an English on an English site in the case of Hungarian the language I know most is going to be Hungarian so this is a configuration that was already shipped with Drupal Core so I can use the interface translation system for that that's true for all the blocks and all the things all the emails, the views everything that was shipped with Drupal Core the good news about this that's integrated with interface translation is it has built in support for our translation downloads and updates from the community so when you install Drupal every single view that's included every single field, every single permission every single content type that came with Drupal will be translatable by the community we'll get the translations downloaded and later on the translations will also be updated from there so there's no problem like for Drupal 7 where we've installed it in the state of uncertainty and we had no idea later on etc so we keep track of all these things and we update all those translations that works with the built-in features so that we can put up or localize Drupal because we know that everybody has those features because we downloaded Drupal for all the best of the configuration that you make on your site like your site name or your blocks we don't know about so you need to translate it yourself we have a module for that too very easy to use so that's a block it has a translated block tab on it I can just go in there and translate the block label to my own language I can save the block label go back to the page and now that block is translated to Hungarian so it's easily doable with these in place tabs site information, same thing translate site information, there's a tab list of languages it translates, now there's a table of things I can translate I can enter my translations for all the things that are in the same information site name and slogan, save that go back now my site name is translated to Hungarian, the slogan, the block title the compact category all in Hungarian and if I switch back to English it's gonna be in Michigan so everything is translatable with the built-in configuration translation module you can go in and translate all the views that you created, you can translate all the countertypes all the vocabularies, the menus everything is accessible to contribute so this works with standard translation tabs so go to views, there's a translated operation in the list, go to menus translated operation, go to site information translate tab, etc etc it works with configuration overrides, well integrated with the deployment system and configuration it works for anything in configuration in core, in contribute and all the ship configuration that came with Drupal, annual modules, annual themes annual distribution, all those things is already translatable, localized Drupal will be translated for you so who liked this area so in summary, we have four areas where we improved in Drupal in terms of multilingual we have a language subsystem which allows you to assign language to whatever you want on the system including block visibility