 So this is Drupal 8's multilingual APIs. This is a coding and development track session, so we're gonna talk about code. We've had several sessions around multilingual at different Drupal cons, and we focused a lot on site building experience, and we even built a whole workshop around building a multilingual Drupal 8 site. So if you're interested in figuring out all the site building goodness, then Drupal 8 multilingual.org has a page with hand out text, has a lot of video content, a simple distribution that you can install and try out a pre-created version of a multilingual site and just walk through the steps. So that's, if you're looking at the site building things, we are here for looking at the coding part of multilingual in Drupal 8. So I am Gabor Hoishi, and if you've been to the keynote in the morning, there's people who have problems with their names being incompatible with systems, and I have the same problem. So this is a batch from Batcamp. This is my profile at DrupalConMunic, I think. This is a schedule at DrupalConMunic, and Twitter sent me this exciting email a couple of weeks ago. So the problem we've been starting from in Drupal 8 is multilingual wasn't afterthought in Drupal 7. So there's a lot of multilingual modules, and you can set them up in the right order with the right settings and they work, but it's an afterthought. The system does not know about multilingual, it's not aware of multilingual in many ways, and it may or may not work. So that's the problem in 7, and we wanted to solve that in 8. And I'm presenting this here, but this is the work of around 1,300 contributors. So this is the start of the list, and it continues on until here. So they contributed reviews, feedback, user testing, screenshots, UIs, tests, whatever, all kinds of other feedback that made this possible. So where we started from in Drupal 7, and this is a very short summary of the side building aspects of what we have, and I think it's also useful for just seeing what kind of development approach we did, is that you have Drupal Core, which is in itself not really aware of language. So we have a locale module, which you enable, then you can manage the list of languages on the site, and also translate the user interface to some languages. But locale module works with PO files that you need to manually upload to Drupal 7 through the user interface. So if you have 100 modules and 10 languages, then you need to manually identify the versions of your modules, manually download 100 times 10, so 1,000 PO files, manually download from localize.drupal.org to your desktop, and then manually upload 1,000 files through the Drupal user interface, that doesn't really work. So we built a module for that localization update that automates identifying the version number, downloading the files, importing the files, et cetera. So that automates the user interface translation, and when you want to deal with translating your content, we have the content translation module that creates copies of your content. Now when you create content in Drupal 7, you can also edit the menu items for that content, and the taxonomy terms for that content, but content translation does not allow you to translate menu items or taxonomy terms, so you install the IATN module suite. That allows you to translate menu items and taxonomy terms, and then you are like, well, okay, but I still cannot translate the emails that are sent out to my users, or the site name even, so then you install the variable module suite, which comes with several modules. So now you have the possibility to translate the emails that are sent out to users as well as menu items, taxonomy terms, and then you have views, and none of these will allow you to translate views, so then you download the IATN and views module and install that as well, and then you have web form, and none of these will allow you to translate web forms, so you download the web form localization module, which has a totally different name than everything else. It's not IATN and web form, or web form IATN, it's web form localization, and then you have an e-commerce store, and none of these allow you to translate e-commerce stores. So now you download the entity translation module, which is great because that allows you to translate your store, but you already have the content translation module for translating other things, and entity translation actually could translate all the things that you translated with content translation, so now you have two ways to translate nodes, entity translation, and content translation, and some of your content types may actually be using content translation while other content types may be using entity translation. And then entity translation also supports translating taxonomy terms, so now you have IATN to translate taxonomy terms and entity translation to translate taxonomy terms, so the features overlap in some ways, and I actually run into this with a support request that somebody was trying to translate their taxonomy terms with IATN and it didn't work, and then we looked at the user interface and it turns out that they are using entity translation for translating the taxonomy term, but they used to use IATN to translate the taxonomy term, so it was in the database, and it had the user interface in IATN to translate it, but it was not used anymore, so they've had working in user interface that did not actually have an effect on the systems, so very frustrating, and then if you try to use entity translation for translating your nodes, it's not really possible because node titles are impossible to translate, so you also download the title module and enable the title module, and now you can translate your titles of your nodes, so Drupal 7, as it can be seen, multilingual is an afterthought, and still a lot of people use Drupal 7 to build multilingual sites, and they are very successful with that, but we wanted to lower the barrier significantly here and just make this easier, so in Drupal 8 the idea is there's only four things and they are very extensible and they apply to everything in the system, so the first thing is language, so the problem in Drupal 7 is we don't know the language of most things, we have no idea, so we need to make assumptions, so instead in Drupal 8 we wanted to know the language of everything, so we know the language of your menus, we know the language of your menu items, one by one, we know the language of your views, each view one by one, we know the language of every user, we know the language of every node, we know the language of your user email settings and everything basically, so we wanted to track language and everything because then we can translate to other languages and we can track what's in what language we can translate from the community all the things that are included in the software, so that allows us to do fun things and we need to track language even before you think about translating anything because you set up a site, you install 100 modules and then in two years you decide to add the second language and now we need to know language of everything you've done so far, so Drupal keeps track of language even if you don't actively enable the language feature and then there's several other improvements here on how languages selected et cetera, but we're not going into that here and then the second thing that we did in Drupal 8 is a separate interface translation module, so it's now separate from language management and here we've included the localization update feature by default so that when you install Drupal, the first screen is gonna be a language selector and then from there it downloads the translations, imports them and everything is translated, so it's built into the core of the system and then every module you enable, update, do whatever, they're gonna download the translation updates, they're gonna download the new translations, if you add a new language, it's gonna download the translations for that language so it's very integrated and we've improved the user interface of the interface translation itself to make it easier to touch up on that, we made English customizable as user interface text, we protect those customizations so when you update from the community they are not overwritten so we've made a lot of improvements in this area and for content language, so the problem I've explained is we've had too many solutions for content translation in Drupal 7 and they were competing and overlapping and have all kinds of other problems so what we did instead is we have one unified content translation solution in 8, it's called content translation but it's not the content translation solution that was in Drupal 7, so we threw out that solution and instead brought in the entity translation module and improved it in ways to make it as flexible as possible so now everything is translatable, every field is translatable on your content, there's no need for a title module or any other special modules and so basically you can set up your content translation anywhere between having every field translated which is practically the same as it was in Drupal 7 with the core module or some of the fields translated which is the same as it was with entity translation so it's one model but it supports whatever you need and it applies to everything in the system from e-commerce to user profiles to taxonomy terms, menu items, all kinds of things and then we have a new configuration system in Drupal 8 that applies to everything that is in configuration so it applies to views, it applies to menus, it applies to user email settings, site name, rules, field settings, all those things and we have a unified translation solution for that too so whatever is in configuration your translation solution will apply to that so one caveat here if you are building a module for Drupal 8 and you need to track your own data you need to store your own data with your module if you do not use the content translation system or the content system or the configuration system you have your own database you have your own data storage system we do not have a translation solution for you okay, so if you use your own data storage and not content or config then you're on your own okay, you need to solve your own problems we did solve problems for our content identity and configuration systems so let's start with language so the way language works on the API level is we have a language manager that is used to manage the list of languages on your site and as I've said, even if you do not have any language features enabled on the site you don't have the language module enabled there is still a language manager on your site the built-in language manager is called language manager and once you enable the language module then it's replaced with the configurable language manager so the reason for this is when you don't have language features enabled on the site we still want to track language data on everything you do so we need to have a system that acts as supporting language even if you don't specifically want multiple languages so we have this language manager that assumes that you wanted to use English and provides English as the page language provides English as the language that you save content in et cetera et cetera so until you enable the language module Drupal assumes you are English, your site is English and is doing, maintaining everything in English and keeping track of every configuration and content and everything in English and once you enable the language module then the language manager becomes the configurable language manager and there you can enable multiple languages and then you can have those languages assigned to things so this language manager is a service that has methods that you can call so get languages is the method to get all the languages on the site and if you do not have configurable languages then these are the three languages that are available so even if you do not have language module enabled Drupal knows about three languages one is UND not specified the other is ZXX not applicable so we have these two languages because people were confused about UND so we duplicated it so you are more confused now twice as confused so yeah so not specified is supposed to be used for cases when the thing may have language but you don't know what the language is so if you have a word document that has text in there and you've uploaded it and you want to assign a language to the word document but you don't know then you would assign UND if you have a photograph of you have a selfie with Dries that does not have language it doesn't make sense to assign a language to a selfie with Dries so that's not applicable so it's not applicable to assign language to that thing okay so that's the difference so now we can make a difference of this may have language but I don't know and it doesn't make sense for this to have language and then we have English built-in if you enable language module then you get the configurable language manager and then you can drop English if you want English is not required in the system anymore unlike Drupal 7 and then you can configure whatever you want so in this case I configured Hungarian and Italian and these are stored the configurable languages as well as the built-in languages that are stored in the configuration system itself so if you export your configuration these will be found under language.entity.thelanguagecode.yeml so all of these will be there and the built-in ones are locked so you don't get to see them on the user interface when you are editing the list of languages but they're still there and the other ones are not locked so you can get to see them and delete them and edit their names and do other fun things so if you have a project that you need to have other special languages then you can ship with other special languages as default configuration in your project as language.entity.whatever the language code is and mark them as locked if you want to ship with configurable languages then you would ship with them the same way just mark them locked you can also create languages very easily in code so the configurable language is the class for configurable languages you can say create from language code fr and save and then you get to have the file for language.entity.fr.yeml so this works off of metadata from Drupal already knows about predefined languages so it's just gonna fill in the data the language name, the direction of the language et cetera from the predefined data and then you can do the same delete the language and get rid of it so languages are objects in Drupal 8 very easy to handle there's language manager that deals with listing them and very easy to create and delete them and then language manager also deals with selecting the language for the page or for the request or for whatever occasion you need and that's the other important method of language managers get current language by default this is gonna tell you about the interface language selected for the request so whatever based on the configuration that the administrator set up is gonna tell you about the language selected for the page so if you wanna do something based on this like one of our client projects they needed to custom translate some things in a system based on this language it's very easy to get this language and then use it in whatever third party system to get the data you need. This could also be used to get other languages like the content language negotiated for the page et cetera so that's for language so in summary languages are objects that can be created and deleted very easily they are stored in the configuration system if you have configurable languages or just happen to be predefined if you don't have language module enabled and we track language on everything which we'll see one by one in the other systems so you get to see how that works. Second thing is interface language so interface translation you may get to know the T function in Drupal 7 and this still totally works fine in Drupal 8 there's a T function it works it didn't change now we'll see that it totally changed entirely but this actually works and it's gonna mostly get you the expected result that you wanted so yeah but it's not really suggested to be used like this so the problem of using the global T function is you are assuming that your environment is able to translate something is an assumption about what Drupal has globally in the system for you and it's not a best practice to just call out to the global system and ask for things so this is logically what the T function does so you have your logic and you would call out to your environment so you would say I wanna do this translation through this string and please global environment give me the translation and it's not very good because you make these assumptions about your environment that may or may not be true and also it's hard to make your logic self-contained if you depend on all of that environment it's hard to get it tested so what Drupal 8 moved to very heavily is dependency injection where it sounds very scary but these errors are just moved backwards and instead of we calling out to the external environment we get all of the services that we need and then we use the service references as if they were available locally that's the simplest version of dependency injection explanation that I can do so instead of calling out to the global environment and say please global environment do this for me we have the services that we need injected we have the dependencies that we need referenced so we can call them and ask them to do stuff for us so most of the places in Drupal 8 you would not do English text but you would do this T English text so it would be in a class that has a T method that you can use to translate things and it would work the same way as the global T so the way we do these is there's the string translation trait that provides the T method and the translation manager service and everything encapsulated so if you have your own class then you can just use the string translation trait if you are writing a form or you're writing a block or whatever other thing the form base, the block base and a lot of other base classes already include string translation trait so you have your string translation features at your fingertips so no reason to worry about that so what this allows us is to make this testing much easier and have dependencies explicit in the system so I've also said that the T function works the same way as before so the same way as before would be that you get a string that's the translation of the string that you provided but that's not the case in Drupal 8 so you can also do this so you say translate this English text to me and then you call a method on the translation so what actually happens in Drupal 8 is the T method returns an object instance so it's a translatable markup and if you print it out or use it in some string context then it is translated at the time when you use it as a string okay so it's not translated when you call the T function it creates an object that's like this string needs to be translated into this language with these options and it's translated later when it needs to be translated so that's very cool for a lot of reasons for one it allows Drupal code to use the T method way before even the system is available to translate those things because the actual usage of the string happens much later it also optimizes a lot of these translations because Drupal uses the T function all kinds of places and the actual string that is the output of the T function may not actually be used at the end in the output so it may be altered out somehow or it may be not even appear on the UI or something so this actually as a speed optimization as well as allows us to use the T method more than before so you get a translatable markup instance that you can call fun methods like getOption or getOriginalString and all kinds of other things so later on you can inspect what's actually in there you can create other T instances of that, et cetera so but if you don't wanna do that whatever the T function returns is safe to use in form arrays and all kinds of other things because it's cast to a string at the right time later on so you don't need to worry about this if you don't want to worry about this, okay and then form a plural same thing there's not even a global form a plural function anymore so it's hard to not use something else the T function is still there globally but the form a plural is removed so you need to use this form a plural which is also included with the string translation trait and in JavaScript not much change Drupal T, Drupal form a plural this didn't change much then Drupal 7 had all of these special places that have special translation needs on their own so in Drupal 7 if you go to hook menu the title and description keys never took a T because if you translate them there then Drupal cannot cache them in the original language and then it cannot translate them later on into whatever language needed, et cetera so it's a whole set of pain there and Drupal 8 is not any different except in fact in Drupal 8 we now have these YAML files so it's not even possible to like put in code to translate this for me so in Drupal 8 for menu links for example we have these YAML files locale.links.medu.yaml which is the user interface translation page by the way and we have the title and description keys there that take text so these are special keys the POTX module that does the string extraction knows about these keys and Drupal in PHP logic translated these translate these strings later on so you don't actually need to care about using the T function here or anything like that so this works for menu links for route titles and all kinds of other things that are defined in the plugin YAML files and if you write your own module and you need to use your own plugin and that needs to have its own YAML files for settings then you need to implement the POTX YAML parsing format so it understands these keys as well so your strings will end up on localize.drupal.org if you don't implement your own plugins with your own YAML files then you don't need to care about that because these are all predefined and these just work and are translatable out of the gate so one thing that is still kept as is for interface translation is this is English to some other language so interface translation is always from English to something else so if you use I18N module in 7 I18N reuses string translation for taxonomy terms, menu items and all kinds of other things and there it allows you to translate from other languages to whatever Drupal 8 does not do that at all so the configuration translation is totally separate from interface translation so interface translation is only for things that you hard-vire in your code in PHP, YAML files, these things and it's always English to something else so Drupal deals with that that way so for content language so Drupal 8 uses content entities for a lot of things so nodes are content entities menu items are content entities user profiles are content entities taxonomy terms are content entities contact forms are our content entities so we needed a way to specify which content entities could be made translatable so content entities have configuration for you to make them either translatable or not but US developers need to be able to tell if your content entity makes sense to be translatable at all so content entities are defined with their own classes and they have annotations which include a way for you to specify if this content entity could even be translated at all so you can say translatable true and you should include a language code entity key for your content entity and you should have at least one field that could be translated in some way and then your content entity may be translatable so this just says that the site configuration may configure this content entity to be translatable this does not mean that it is translatable it means that it may be configured to be translatable so you have your entity type in this case nodes and then there are fields on entity types and what I said is you don't need title module anymore because there's all the fields that all the fields are managed with the same system and they may be translatable and that's true but there's still two types of fields in Drupal there are base fields and configurable fields and they are a little bit different for translatability base fields they have a they you define base fields hard coded in your class for your entity type in the base field definitions method and each field has a set translatable method where you can say this base field is translatable again this says that this base field may be configurable to be translatable so if you set it to be not translatable it means that nobody ever will be able to set it to be translatable but saying set translatable true does not mean that it will actually end up being always translatable because this is configurable for per site okay so this just says that I opt in to the possibility of translation so that's for base fields and for configurable fields you don't need to do anything special about them because the system supports the configurability of fields to be translatable configurable fields to be translatable so you can opt out of your entity type being translatable you can opt out of your base field being translatable but you cannot opt out your configurable field being translatable although your configurable field will not be translatable if the parent entity type is not translatable and finally there is one more complicated case if you have a multi-column field type that may have uniquely separatable values in this case an image field then you can use annotations on that field type to further divide your field to translation options so in this case the image field says that I have multiple columns and my target ID width and height columns belong to one group that I call the file and I have a column called alt that I call the alt so this makes it possible for Drupal to individually make your file and your alt text configurable to be translatable but these are just defaults for translatability or not because configurable fields are always always could always be configured to be translatable so you can set up column groups that allow Drupal to go on the subfield level and say I wanna only translate part of this field in this case you wanna translate maybe the alt text but you wanna keep the same file is a good use case for stores so if you sell the same product but you wanna have separate text on them per language then you would use the same image field and this is how it's coded on the field definition okay so that's the how you define what will be translatable and then there's entity language API is the same entity API that we've seen for configurable languages you have the node class that can load a node for you in this case node 42 and the node knows about their translations very fancy so you can say node get translation Hungarian and it gets you a Hungarian translation and it's the same node up the same behavior for the node translation as it was for the node object so now you have a translation object that you can do the same with you can treat it as the same node as before if you wanna do the language negotiation on your translation so you don't know what language you want but you want to have the same language that was negotiated for your page then the entity repository has to get translation from context method that you can use it's pretty much in the weeds but it's very useful if you don't know the concrete language you can go in and ask for a negotiated language for this node that will actually pick a language that's available on the node and get you that language and then it's overall very nice so you can get back the untranslated entity from the translated entity which gets you the original language for this entity you can ask for the language of the current translation of the entity or get the list of translation languages or ask if it has a Hungarian translation or add a new Hungarian translation or remove a Hungarian translation so it's an intelligent object that you can deal with and add and remove translations and deal with translations it's very easy to use it's much more powerful than Drupal 7 where it was just like this anonymous array that you need to navigate somehow with obscure methods it's very hard to do there and then if you don't actually so this API is I think is very great but you may not even use this API for some of your simpler tasks because now in Drupal 8 we've included the views module and that allows you to build out lists and tables and galleries and filters and all kinds of fun things with just the views so you don't actually need to sit down and code anything and that's very easy to do because you build this out and then you can export it as configuration and ship with your module and you don't need to write a single line of code so it's very easy to do language things and views because in views we support language on both of the responsibilities of views so with the query building part on the first column we support language filtering for example so you can say I want to filter the language in this view for things that are translated in the language of the page and this is the default front page by the way as a view in Drupal 8 and then on the rendering side which is the second column we support language rendering as well so that whatever the query found you can configure independently what the rendering language is gonna be and by default the rendering language is whatever was found but you can also render in some other language like you can render the original language version of the thing that was found or you can render some specific translation or render it in the user's preferred language or all kinds of other things so it's very easy to do blocks and lists and galleries and tables and all kinds of other things with this and a lot of the admin pages are views so the note admin pages of you for example it's very easily cloned that page and created a translation dashboard for your translators with that writing a line of code I think that's pretty powerful so that's for a content translation so what you can see there is content translation tracks the language of your content so what I, how I summarize that is this translation X to Y so you can translate from whatever language to whatever other language that you want it does not need to be in a specific source language or need to be a specific target language and it's intelligent objects so just load the object and then you can ask it about its translations and then load the translation and the translation, remove the translation it's very fancy so this applies to nodes, menu items, taxonomy terms, user profiles, blah blah blah a lot of things in core and it also applies to all kinds of country things like rules and e-commerce and all the things that are using the content NAD API so there's one API to use for everything it supports translation of base fields and configurable fields it supports subfield translatability for cases where you need that and you have full control as a developer over all those things as well so finally let's look into config translation so config translation we did a similar thing so in Drupal 8 configuration files that are shipped with projects are in their config slash install slash whatever.yaml in this case system maintenance.yaml is the default maintenance message setting in Drupal core and each configuration file individually has a length code key it's a reserved key in the configuration system so this key specifies the language of this file the whole file so in this case this file is only a message setting for maintenance messages which in this case we say is English because it is English by default so that's in the configuration file and now we need to be able to translate the message so the question is how do we know that the message is even translatable because the same configuration system is used for views if you look at a view it's not going to fit on this slide ever so even with like two point fonts or I don't know so there's a lot of stuff in views and you can only translate a limited number of them so we have a system to explain what's translatable in this configuration and the system is actually used for all kinds of other things as well in Drupal including your deployment of your configuration so it's much more useful than just translation but it was introduced for translation so that's the configuration schema system and it has some base types like text says or it has some base types like string and it has some extended types like text where it says text is a string that is translatable and then it has some more complex types like associative mappings like config object which is an associative mapping that has a language code key so the previous slide system maintenance YAML is a configuration object it's an associative array with the language code key so that's defined as a config object and then we'll use the text type to identify the message so this is defined in the system modules configuration schema and that says that system maintenance is a configuration object so it's an associative array that has a language code key predefined for me and by the way I also have a message key that is text so it's a translatable string so we have the configuration schema that's used to explain the structure of your configuration and this allows the translation system to go in and parse this and tell which keys are translatable this is also used to typecast the configuration to the right type so your deployments are nice and it's also used for testing whether your configuration is actually whether like the test produced the actual configuration expected so it's used for a lot of things but it's very useful for translation so the way this works is the configuration system has the system maintenance YAML file in the active storage in configuration and then we have a Hungarian translation override that says the message in Hungarian is this and this and then we have an Italian override that says the message in Italian is this and this so the config system works with translation overwrites that are stored in these files so all of these are in the active configuration system so these are deployed to your live site with your configuration but they only store keys that are required for the translation so what happens when this is used in the system is Drupal loads the translation that's needed at the time and it merges the files together and then you have a translation okay so for example you use the configuration API very simply like this you load the system maintenance message from the config system and then you get the message key in this case the config system will use the interface language negotiated for the page load the override for the interface language maybe Hungarian merge the Hungarian on top of the original configuration and now you get a Hungarian message you have no way to tell if Hungarian was applied or not okay because the configuration system supports whatever overwrites okay so in this case overwrites apply in from whatever system you may be using domain module you may be using organic groups you may have global settings overwrites all of those will apply okay so this configuration system has a priority list for overwrites in terms of which applies first and which applies last so if you have a translation override it may still be overwritten by a domain override or by an organic group override depending on their priorities so you can configure that priority to configure your site as needed but we don't really like it's hard to know whether you get the translated object or not and you may get a half translated object that also has organic group overwrites and then domain overwrites so it's a lot of fun if you don't want to have or if you want to have a specific language override then what you can do is very convoluted is not really how Drupal H should be but unfortunately we didn't get to anywhere better than this is you need to change global state which I just explained that it's not good so there's the language manager that maintains the configuration override language as well so you can say please give me the config override language so I can remember it for later and then you say set the config override language to whatever I want and then do stuff with configuration in that language because now you get that language overwrites applied all the time and then you set it back to what it was before so this is not nice but this is what we have the reason it's not nice is because the config system needs to be agnostic of overwrites because it may have any kinds of overwrites all kinds of things so you cannot really go into the config system and say I want to have this language override it's not even aware that there may be language overwrites the generic system however the language manager is aware that there are language overwrites and it maintains this for you so that's what you can do if you don't want to have overwrites at all or you want to access a specific override we have APIs for that so config jupo config applies all overwrites everything global overwrites, domain overwrites, everything if you don't want any overwrites to apply then the config factory has a get editable method that you get the original raw unmodified whatever was in your active storage configuration and there's no overwrites so this is useful because if you actually want to make changes to your configuration you need to get this because if you get the other one and then you change something and then you save it back then you may leak some stuff from your organic groups or for your domains or for your translations into your original configuration and that's bad, that's unpredictable anything could happen so what happens actually in Drupal 8 if you do the first line and then try to save it is you get an exception and you are told that no no no no no no no you don't do that so it's not possible to save back things from Drupal config it is possible to save back things from get editable because that gets you original configuration so because you want to save back to original that's what you use and finally if you want to access the actual language override as I've said the language manager knows about language overwrites so you say language manager get me the language override in Hungarian for system maintenance and then I can set whatever I want the message to something else and then save it and it works so you can access specific overwrites one by one you can access the original configuration and you can just load the configuration in whatever overwrites apply at that point in time so those are the separate ways to access configuration so the difference between configuration and content is or the similarity is that you can create configuration and content in whatever language you want originally and you can translate it to whatever language you want okay so config you can create in Italian and translate to French and then create another one in Hungarian and translate to English doesn't matter the main difference is content is intelligent objects that know about their translations they only support language variants so they know about their translations and they can support them and configuration the use case was not possible to support because there may be domains and organic groups and all kinds of other things so it's more like dump areas that are merged in together and then put into an object for you so we don't really know what's actually applied there and what happened so you need to live with that unfortunately so that's the summary of all the APIs and once again I'd like to thank all of these people who worked out these solutions for you and wanted to call your attention to Drupal 8's possibilities because although some of these APIs may not be so nice Drupal 8 now allows us to add new APIs and make backwards compatible changes to APIs so we can add a totally new much nicer whatever API we want and can introduce that and modules can start using that and we can deprecate the old API later on so it's possible to improve this however much we want in Drupal 8 and we don't need to wait for Drupal 9 so if you didn't like something then please come to the sprint on Friday and on the weekend and there's people working on these things to make them better and finally I'd like to thank Christian personally for some of these slides and some of these examples so I used his previous session for some of the content identity stuff and that's it so if you have any questions I'm happy to answer one thing that I was not quite clear was if you install and you have the language selection in the first slide it will install and set the language selector to that language and all the content and all the everything will be stored in that language and not in English like it used to be or undefined so that's true yes so when you install in Italian then all the configuration that you have in the system will be langcode it and they may contain English text so a lot of the configuration Drupal 8 has a lot of things in configuration your user roles, your input formats, your views, field settings, content types all of them and Drupal 8 has magic so what it does is it updates the configuration files to langcode it and then the locale module comes in and it looks at it and it's like okay it's it's langcode it but it's still the English text so I go I go in and I look at my interface translations if there's something translations for the default configurations and then it puts in the translation for the translatable keys so all the default configuration that ships with core and contributed modules is originally in English and what happens is when you install them we we override the langcode to the site language and then we put in the put in the translation from localize.drupal.org so if you have an Italian site and you go I go into views you're gonna edit the view in Italian as it's originally on your as it as it is now on your system because the locale module translated it from localize.drupal.org yeah but you know the big question was actually in order if you install it and you don't if you configure it right away it won't like in D7 it will store every sorry everything in English and but you really have an Italian site so you know it will be hard when you then decide okay I need to make my site multilingual so I will enable all the modules but all my content my Italian content is actually marked as English yeah here no it's marked as Italian so if you install an Italian there's no English installed on the system English is not even added so like it's not even an option to create English things because you didn't want to have English so you wanted to tell it thank you for that sure thank you for people who made it happen okay the question is if you install Italian and and the content you just write English and you save it and it's gonna be translated to Italian or not you type in English but how the system knows okay this ABC is English or is Italian so you type a sentence in English you save your note is gonna be translated in Italian or not yeah so I think the question was you enter your content and you save it in English and how is it going to be Italian at the end so you so as on a site you can configure your content to be translatable so first off well so first off you can configure your content to be able to track separate languages so you say I want note one the one the page note type to support multiple languages you can configure that and then it will have a language selector on the note type so you can say this is English or Italian and then it's saved in English originally as you explained for this example but it could be saved in whatever other language and then you can also configure that note type page in this example to support translation so you also configure it to support translation which will enable the translation tab on the node and then if you go to the translation tab it lists all the languages that are configured on the site and then you can manually translate to those languages Drupal 8 does not come with automated support for translating your English to Italian so if you are looking at automating that or integrating with the system that automates that then people sitting behind there are working for a lingo tech that they are in that business okay and they're gonna do this magically for you you just add Italian and everything no so that means it's gonna be a tab and you type it in yes and you save it so that is okay thank you so it's a tab that says translations it lists all your languages and you can add the Italian there you say add Italian translation it loads up the same form that same visual form that you created the node with and you can translate it to Italian there thank you sure any problems with exporting so the question was are there any problems exporting overrides from local environment to dev environment that's a better question that's a different question so the question was if there are any problems with exporting overrides from a dev environment to a live environment I'm not aware so all the overrides are stored within the configuration system so when you export your configuration you get all the original configuration as well as the overrides in one package there's a sub directory for overrides called languages and then the language name and so this one so this is basically the directory structure in the export that you have so you have the filename and then you have a languages directory slash language code slash the same filename as the other one so you get this and then the same thing could be imported to your other environment and just used like that so I'm not aware of problems but if anybody are aware then I'm happy to hear about it okay thanks for coming and enjoy Drupal 8