 Good afternoon everyone. I'm going to kick things off a little bit early. I'm Jason Yee. I'm the local community track chair lead here for Drupalcon, Portland. Aside from picking sessions, one of the great things that I get to do is introduce the featured speakers. So, Gabor is actually one of our featured speakers. You may be wondering why the multi-lingual initiative is part of community. One of the things that I've tried to do this year is re-examine what we mean when we talk about community, and that includes contributing code. So, I invited Gabor to come speak, tell us about what's going on in the multi-lingual initiative, and particularly what they've done, what needs to be done, and how you guys can all get involved with that. So, without further ado, I'll turn it over to Gabor. Thank you. So, yeah, so this session is about multi-lingual Drupal 8. It's going to walk you through every goodie that we did in Drupal 8, and it will explain why we did it, and what we are still to do. I would, I'm totally fine if in the middle of it you think it's not for you and you walk out. I would love to be at three other sessions at this moment, but I hope it's going to be very, I'm very excited about this topic. So, I hope it's going to fire you up, because there's a lot of changes. And the way we approached it is as we want to have Drupal 8 finally have language as a core thing, not as an afterthought. So, if you've been, if you've been using language stuff in Drupal 7, a lot of the case is languages and afterthought. And I have two interesting photos to explain that actually at this conference. So, this is my user account on the site. I'm not sure you noticed the extended character is not really in the font that it's supposed to be. And if you look at your printed schedule, it's even better. Yes. So, if we put language as like a core thing and not just as an afterthought that it may work or may not work and we don't really think about it, then we can do stuff better. So, I'm this guy who like always uses his actual name instead of cutting off the X and just to see what happens. And this is not picking on DrupalCon. I've been able to photograph my badge and session prints at multiple conferences so far. So, that's just how it goes. So, although I'm presenting this session, this is a huge, huge, huge, huge team effort. So, this is the list of people who helped out. So, if you think you have no idea how to help out, you can probably notice that we have a lot of people who helped out some. So, this is all the names of people who ever commented on the issues that we worked on and we got into core or we are about to get into core. And there are a few relatively big names, but not many. So, there's a core of a few people who work really hard. And then there's a lot of people who just chip in and do their small thing and then go on with their life. So, you don't need to be involved very much in this if you don't want to, but we very much love you to get involved and help us with tiny, tiny changes to big changes. So, this is a huge team effort. There's actual human bodies working on this. So, this is a sprint we did last summer in Barcelona. We've been mapping out the configuration system there with all kinds of people from core. This is a sprint we did this past weekend and we are continuing to sprint this coming weekend as well. So, we are in town on Friday, Saturday and Sunday to work on jubilee multilingual. So, this is just from this past weekend. This is from bad camp last November. Francesco is working on the NDV translation module right here. And this is also from Barcelona. So, we have a lot of hard work and we also have a lot of amazing fun. So, it's been a great experience. And what we came from is the Drupal 7 multilingual experience where you have Drupal core and if you want to do anything with that you need to add up a lot of things on top. So, first thing you want to have languages on your site and you want to translate your site to those languages. You need to enable this locale module that provides languages and foreign UI for your site. And then if you want to make it useful then you need to have the localization update module because the locale module itself is very painful to maintain with all your translations. If you have 100 modules and 5 languages you need to manually write down on a piece of paper the 100 version numbers for your 100 modules. And then you go to manually localize Drupal.org and download all those files, 500 files manually downloaded to your computer. And then you upload all those 500 files manually to your website. And the localization update module saves you from that hassle. It identifies your versions and downloads everything automatically and imports them. So, that's the kind of modules that show that multilingualism afterthought and we really have these problems that we need to solve with extra things. And then there's the content translation core module which creates copies of your nodes so you can translate them, but it's only working for nodes. So, if you use Drupal commerce or you want to translate taxonomy terms or menus, that's not for that. Then we have, plugging in the whole, we have the IATN module which plugs in a lot of holes. So, it lets you actually translate menus and taxonomy terms and contact forms and do some degree of use, but it depends on a lot of other modules. So, if you want to actually do all the stuff that I mentioned, IATN has like 20 submodules and then it requires other modules like variable module and variable realm module and variable translation module and all kinds of modules. You need to add in your site. So, we are like now 20 modules by at this point. And then that's the variable, yeah, that's required. And then you figure out you want to have Drupal commerce on your site and nothing supports general entity translation from here. So, you also need the entity translation module which translates content in a different way from the core content translation module. And now you have two different solutions for the problem. It's very painful. You don't know which one to use when and it's just a mess. So, there's a lot of things going on that you need to be aware and that's just scratching the surface. So, there's a lot of other things like admin language module or translation redirect or there's a lot of other things that you need to think of. And we wanted to have language as a core feature as much as possible. We will not be able to resolve all the problems obviously that there are not all the problems and all the use cases that there are for multilingual sites. But we wanted to have a solid multilingual base system that provides all the services that Contrip can build on and make that base system as useful in itself as possible. So, we have four pillars in Drupal for multilingual support. The first pillar is language. So, the language pillar lets you set up languages on your site and do all kinds of stuff with language. And we'll go through all the details shortly. And then we have a pillar for interface which is your software translation. So, you can use this to translate your software and use a lot of automations and a lot of cool features there. We have a pillar for content which is generally all kinds of entities in Drupal core that is supported across entities. And then we have a pillar for configuration which was the most lacking thing in Drupal 7 like translating your views or your site name or your slogan or your contact category or user roles or whatever else that you have on the system. So, we wanted to provide native support for language in general and then build three layers on top that are parallel to each other for your software, for your content and for your configuration. Now you might say that this is still very confusing because now you have three different systems depending on where your content is stored and where it's coming from. Yes, it is not the ultimate ideal system for everybody. We are trying to make the user experience of those three solutions unified in a way that users might not even recognize that they are interacting with three different things. But internally the storage and the back-end and everything is very different for these three things. So, we needed to have individual thinking for them and have solutions for them. It's already a huge improvement since Drupal 7 because Drupal 7 for configuration has an unlimited number of custom solutions like views works totally different from user roles and input formats and in Drupal 8 the configuration initiative did a very good job of summarizing all that and distilling that down to one system so we can rely on that. By the way, feel free to come closer. I will have screenshots that might not be visible so feel free to move over here and come closer. I'm sorry that I might not have the biggest fonts possible. So, the first pillar that I want to talk about is language. And that's very exciting for me because that in itself brings in a lot of new features. So, first thing we put language step one in the Drupal installer. So, when you encounter Drupal 8, the first thing you encounter is a drop-down with languages. And that's about 100 languages that you can install Drupal 8 in. And it also automatically pre-selects your language from your browser preference. So, if you have your browser preference to prefer German stuff, then you will have German pre-selected. You just click the button to move forward. And what it does, it downloads the translations live from the almost up-to-date translation from the community and it will import that translation and the next step when you choose your install profile will already be translated. So, if you use an Arabic language, it will also be RTL. I think that's no way to make a language any simpler than that. So, you just pick language, we auto-select your language for you if it's not fine, you pick something else and we just download it and you can use it right away. Now, this works with all distributions and all future modules because it works with a built-in localization update feature that we put in that identifies all the versions of stuff that you're running and pulls down translations for them. So, it's future proof as well. When you have language module, you have language assignment features. So, you can assign language to a lot of things. One of the big problems in Drupal 7 is a lot of things don't have language as an intrinsic property. So, when you want to translate them, we can assume what language that might be in, but we don't really know. So, we assume it's in the site default language and that's a very painful thing that we do that. So, in Drupal 8, you can assign language to nodes, you can assign language to users, you can assign language to path aliases, you can assign language to terms, you can assign language to a view. So, if you have a multilingual website and you create a view only for the Spanish pages, like a view that only makes sense for the Spanish section, then you create the view and put the text in Spanish because it wouldn't make sense to do it in English or anything else. And then you can say, this is a Spanish view. And that's very important for us to know that information. We know the information about, language information about your site configuration. So, like we know what language your site name or your slogan is in. So, when you install Drupal in French, you have the form to fill in your site name and slogan. We save that you input that content in French. So, we will know that your site information is in French there. And then there's a lot of other things. So, we unify language assignment across all kinds of things in Drupal. And our primary goal there is we need to know language for the smallest thing possible so that we don't need to rely on assumptions. And if we know the language, then we can work off of there and we can translate to other things. We can filter by language. We can target by language. We can do all kinds of crazy things, but we need to know the data. So, that's a very core feature that we need to build in. There's also a very flexible language setup. So, of course, if you have language for everything, then you will have language drop-downs everywhere and it's very painful. So, we wanted to simplify that for things like language. So, we have this configuration page, for example, for content types and for all entity types across Drupal Core that lets you configure how they behave in terms of language. So, you can say you want certain content types to be always in certain languages or expose language selector on them and then default to the site default language or the user's current language or the language that the page is in or a certain language. And you can make very flexible settings here. So, for example, if you have a multilingual site but your forum is always in one language, then you can set the forum to always be, for example, in English and do not show the language selector on forums and then it will just be an easy form and there will be no exposure of language because you already know what's going on there. So, you can configure this in a very detailed way. Yes, and we have two special languages here, not specified and not applicable. That's a new thing. We used to have the language neutral and we don't have language neutral. We have not specified and not applicable and that's a fork of language neutral to two things. Not applicable is it doesn't make sense to assign a language. So, if you have a cat photograph that doesn't have any text on it, then it does not have language. There is no meaning of language associated to a photograph of a cat. It may, but yeah, may be okay. So, maybe if I photograph your face, it may not happen. Yeah, it depends on your data model. So, you don't need to pick any of those options. We provide it for you if you want to. And the other option is not specified, which in our model means that it could have language, but you don't know what the language is. So, you can have state where you might feel the language information in later, but you don't know yet. And you can have a state where it doesn't make sense to assign a language. And then you have states where you can assign language. So, we have this set up very detailed and it's possible to add any kind of custom languages and special languages to this system. We have language visibility. So, for each block on the page, and Drupal 8 is making a lot of things, blocks, we have language visibility. So, you can see which languages those blocks are displayed. There's also built-in language support in views. So, you can filter for language in all kinds of views in your Drupal site. And nearly all of the pages in Drupal Core front-facing pages are built with views now, the listing pages. So, you can configure the front page or anything else to filter to language. That was a very common thing that people asked and Drupal never had. That's very easy to do now. There's language selection features highly improved. So, we simplified the language configuration experience. So, now all the language selection is configured in one place, the detection and selection configuration. You don't need to go out to configure a language. And we enabled path language selection by default, which is very painful. Again, in 7, that is not enabled. We have two new features there. We have admin preferred language, which allows people to set a separate preference for the admin pages. So, if they have a multilingual site, but they only know one language and they need to work on the site, they can set a preference for administration only. And we have a selected language option, which again solves the problem of the default language in Drupal 7, that if you set the default language on your site at once, you're never able to change it again ever. Because of the assumptions that I talked about five minutes ago. So, we have that option there, so you can change the language fallback without affecting the default language on the site. So, we made them disconnected, which is very cool. And we improved browser language detection a lot. So, we have much better understanding of languages coming from browsers. And we also have a mapping system of language codes understood by browsers and language codes understood by Drupal. And you can add custom mappings to this system. So, like Drupal has certain language codes for like Chinese languages, but then actual browsers have like 10 different versions of those language codes for Chinese. And we ship with some of those mappings by default, and you can add more of those mappings. So, you can understand language codes coming from the browser in all kinds of ways and map them to internal languages, which is, I think, pretty cool. Yes. Yeah, yeah. We also have transliteration in core. So, for example, machine names here, there's entering, I believe, Russian machine name, and it's transliterated to ASCII characters. So, we have transliteration API in core that's built in and we applied that to machine names. We haven't applied that to anything else yet, but it's in there and it works pretty well. There's a possibility to apply to any other thing like file names or other things in core where you need to transliterate them to meaningful internal identifiers from the outside language. So, I think that's pretty cool as well. And I think the big bombshell is that English can be removed from the site if you don't want that. Anybody happy about that here? No? Yeah, a few, okay. So, at least where I come from in Drupal 7, when you install the site in Italian, you still have English because Drupal has this built-in assumption that Drupal comes from English first. And what Drupal 8 does is you can just get rid of English and have Italian as the only thing and then you don't get bothered with English popping up all the time that you never use. So, that's, I think, pretty cool. So, in summary, this is just enabling one module in core language module. We have all these features. You can remove English from the site. We have a very flexible language selection system with all new options and much more usable like in-place path, prefix editing and all that very easy. We have block visibility per language. We have views, language filtering and all kinds of front-end pages with views. So, you can dynamically do your pages and views. We have flexible configuration for language on content types and entities, what they default to, whether they show language selection. We have wider assignment availability. So, we assign language to all kinds of things across Drupal Core, and language is the first in the installer. Now, we have interface translation for this. So, what we put in there is automated translation downloads. So, when you enable the interface translation module or when you install Drupal Interfering Language, it will go out and automatically download translations for core and all the modules that you have on the site and import them. So, you don't need to do anything manually. You just add the language and it works. Kind of good. So, this is another required module. It's separate now. So, there's language module and interface translation module to separate things. It just works like that. So, it's all magic. And we've improved it a lot more on top of that. So, this is magic, but we also put in a lot of things to help you maintain that thing. So, let's say you are an enterprise site or you just care about the quality of your translations. Maybe you're not an enterprise. And you want to quality assure your translations on diverse staging environment. And you want to push that out and you don't want this automatically downloaded magic thing because it breaks your live site. No problem. What we did is we centralized the translation file location to one directory. You can even put that directory to Git version control or whatever. You can download the translation files to that directory on diverse staging. You can QA the import. And you have the live site configured not to download any translations ever. And when you push up your new release, it pushes up all the files in the directory that may be Git version controlled. And then it's imported on the live site exactly as QA on diverse staging. Very good, right? We have customization tracking. We pull down translations from the community, but of course you are not happy with the translations that the community provides, right? That always happens. So we track your customizations on top of what you downloaded from the community. So when you import a translation file, for example, we ask you if it's from the community or if it's your custom thing. And also when you manually translate stuff on the site, we will track that you customize the translations. And that also works with protecting all your customizations. So when this automatic update runs, we track all the customizations that you did before and it will not update them if you don't want it to update your customizations. Also, we made it better to run on shared hosting, in fact. So if you import a huge file, a huge translation file, it used to time out or have memory problems in Drupal 7. And now we import them in small pieces. We have a running window on the file that we import and it runs much better on shared hosting. We have a whole new interface to translate your site to whatever language. So this used to be a table of source strings with languages crossed over if they were not translated. And you can click there and then you can translate one string to all the languages on the site that you've had. Now that's not the use case that people actually want to have. What they want to have is a source string to one language and translate it as fast as possible. So in Drupal 8, we build this system where we have the source strings and we have the target strings and you can translate right away in place. We also added support for plural strings. That was not there in Drupal 7. It's not backportable because we needed to update the data structure. So you can translate one minute and count minute and the same thing. We also track what you changed. So it's yellow in the table so you can walk away, have a coffee, come back and you still see what you changed. We keep record of what changes made so we keep track of all the customizations and they will not be overwritten by stuff imported from the community. And you can also export all your customizations so you can go to export your translations and you can just export the customizations that you made on top of the community translations and then bring them over to your other sites. I think that's pretty cool. Also, English can be translated too. So in Drupal 7, if you wanted to have a custom English thing, you needed to create a custom English language and then you ended up with two English languages because the built-in English is not removable in 7 and it's not translatable, so you needed to create a custom English. In 7 and 8, you can remove English or if you want to translate to English, which in this case means you want to customize the English interface, like you want to replace login with sign-in and log out with sign-out or whatever, then you go to the English language, you check a checkbox, make it available for translation and you can go and translate to English and you can replace whatever string you want. Easy peasy. So in summary, interface translation. You can translate to English. All new interface that's in place translates your stuff and it saves your customizations. We track all your custom translations. The import will not time out if you're running on shared hosting. We centralized file directory for Enterprise so you can track your translations and curate them and push them live. We automatically download your translations from the community, identify all your modules for all the languages, we download them, import them and it's a separate module, so if you don't need it, you will not enable it. So if you run a data store site and it has an English interface, you can still use language module to assign language to stuff but you don't need to translate the interface and you can still have a site which has a rich language information of data but it doesn't need to have all this baggage of interface translation if you don't use it. Okay, there's content translation which is a same module name that was in Drupal 7 but it's an entirely different thing. So the thing is, it not only supports nodes but it also supports all content entities in Drupal Core. We are working on some of the details of this so that's why the yesterday's gonna scare and I will talk about that briefly. We have an integrated configuration experience for this. So how this looks like is you go to your custom language settings screen, it lists all the entity types that you have on your system. In my case, it's common custom block content, taxonomy term user and we are working on making menu items available here and then if you use Drupal Commerce it will show up here as a checkbox and you can say you wanna have custom language settings for your content. So you go in, you wanna make custom language settings for our content types then you will get this table that you've seen earlier but there's now an even more dynamic table so you can set the default language for things but you can also make things translatable. So you can say you want to make the article a content type translatable, fine and then under the article content type you can make the body field translatable, the image field translatable, the tag field translatable and under the image field you can make the alt text and the title translatable and keep the file synchronized. So it will synchronize the actual file that is uploaded but you can translate all the language specific information on top. So you can have as detailed configuration as you want and you can just like dive in deep into this from the very top, very simple checkboxy form to this very scary big thing where you can configure everything and this is one screen where you can configure content translation across all your site, everything. So you don't need to go to your content type settings and your user settings and your taxonomy settings. This is one screen and you can configure everything in place. So I think that's pretty cool. So we also store all these translations in place under the entity. We want to achieve something similar in Drupal 7. This is the entity translation module concept but we improved on that a lot in how it works and how it's configured. So it's essentially the user interfaces. We have a translate tab on content. You go to the translate tab. We have a list of languages. Then you go to actually add the translation and it will be very similar to the actual note form in Drupal 8 and you can just translate it and save it. If you have permission to edit everything on the node you will be able to edit all the stuff that is not translatable in the translation as well. If you don't have permission you will not be able to do that and there's a lot of possibility for content modules to improve on this user interface obviously. We have a lot of ideas that we will explore on the sprints on Friday and on the weekend. There's a lot of exciting opportunities here and we have a few designs that we want to explore to improve this even more. Now there's a few problems here. So our main problem currently in this system is that properties are not yet translatable which is very painful. So if you go back to the node configuration page I'm not sure if anybody knows this problem but you can't actually translate the title of content in Drupal 8. That's bad. So it's unbelievable, right? So we can't release without that but it's hard to do so we're working on that very hard. And that's the same problem for menu item labels and taxonomy term names and stuff like that that we want to solve for the release. So we want to make them store per language and for you to be able to configure the same translatability configuration on them. So you have it configurable as any other field on your entity. It's very important for us so we are working very hard on this so if you have spare time and you like hard problems then you're very welcome to work on that. And the other interesting problem is we haven't even started working on the migration path from Drupal 7 for this shiny new thing. As a matter of fact we have two content translation modules in core right now. We have this content translation module and we have the content translation legacy module which is hidden. So if you install Drupal 8 fresh you will not see that module at all but if you install Drupal 8 by updating a Drupal 7 site you will see that module and all your previous content using that module will retain its features and functionality. But we don't plan to implement anything new for that and we want to remove that from core and have a migration path for this new thing. Whether it happens by the time of release is to be seen but of course we would love to. We would need to have this feature in for anybody who's updating from Drupal 7. But this is one of the big pain points that we need to resolve. But there's a lot of fun things. So core search API and core search and the API supports language as well. So in Drupal 7 we have a similar feature for entity translation but the search there's no support for this. So for Drupal 8 we index each language version separately in the core search module and we also pass on language information in all the APIs. So when search comes in or when search indexing happens we pass on the language information. So this makes it much much much much easier to integrate content search modules with core. They will get all the language information that we have. So we support access API per language. So now that we store all the translations in one entity we also support access per language for nodes which is pretty exciting. So in summary we support node access API per language. We have search indexing as separate content. We updated search APIs. This applies to all content entities in core including menus, taxonomy terms and regular content and users and all kinds of other things. You can configure translatability in the per bundle as in content type, custom block type, et cetera level and on the field level and on the sub-field level very granular and we are still working on some stuff. So like Drupal 8 is not going to be released on Monday so we need to be working on something for half a year that we have left. So we're working on properties to make them translatable and the migration path needs to be worked on but I think it's a very exciting thing there. And then there is config translation which is especially exciting for me. I had a lot of fun working on this as well as all the other things. And for this I want to explain briefly what config and content is in Drupal 8 because that might not be clear. And the unfortunate truth is that as long as we have these as separate modules and separate UIs we will need to explain this to users as well which is not good. They shouldn't be in the business of trying to understand this but we'll see whether we can improve the UX to the point that it doesn't need to be explained. So I've been talking about a lot about entities and we have entities supported in the content language translation thing. That's true. In Drupal 8 there is two kinds of entities in core. So what I've been talking about so far was content entities. So there's content entities which are notes, comments, contact messages, terms, users, etc. These are content entities and you usually identify them because you can put field by the feature that you can put fields on them. So you can have configurable fields on them. This is not necessarily true for every content entity but it's a generalization that might work to understand the concept. Like you can put fields on notes, users, terms, menu items, no but contact messages and comments yes. So that's content entities. There are also config entities, configuration entities in Drupal 8 and you can think of those as configuration that has pieces that has instances like a view or vocabulary or a contact category or a field or a block type. So that's or a menu in fact. So that could be very confusing because a menu is an entity but it's a configuration entity is an entity but it's a content entity. Now I can't do anything about this I haven't designed this thing. I think it makes sense from an architecture perspective. It's a nice architecture. The things that you configure to do your content are configuration and the things where you do your content are content. But again, I'm not sure that people will necessarily understand this. So we'll need to do a lot of education to understand this. So this translation thing pertains to the configuration thing and there's also a configuration that are not entities where there's not instances of things. So for your site information like your site slogan or your site name, those are not entities. You can't have multiple site names. So those are just configuration and there are just a couple of things that are neither both alias already have language so they are kind of covered. So in Drupal 8 this is essentially the data model of Drupal 8 in general. So this applies regardless of language. So you have entities for most of the things and some of those entities are content and some of those are configuration. And this part of the talk is concerned about configuration translation and the good thing is for this blue thing all the configuration system uses one storage format and one system so that's amazing for language support and why it's amazing is because we can track language on each file for entities and for these configuration pieces. So we can say this view is in this language or this menu is in this language or this contact category is in this language. And then we can do stuff with that as I've said earlier it's very important for us to track language on as granular as possible. And then it's also true that chip configuration is always in English from English to other languages. And we have runtime override support for configuration so we can ship all that configuration for the system and whatever configuration you create will create those configuration files in Drupal 8 and we can override the translatable pieces of configuration with translated text and then we can merge them and have translated versions of your configuration in different languages. So that's a lot of fun to do actually that allows us to do a schema. So we have a configuration schema system that explains the structure of the configuration for us. So we can look at the structure find the pieces that are translatable and override them with translations and have translated versions of the configuration for you. So there's the configuration system unified in Drupal 8 allows overwrites that we can use to provide language variants and it has a schema system that explains the structure of the configuration so we can build those overwrites. And this also supports a lot of other cool things in Drupal 8 like domain module or organic groups so it's not just applying to language the overwrites and the schema is very useful for domain module organic groups and the combination of language domain module and organic groups. Sounds fun. So for ship configuration what we have is we actually integrated this with the interface translation. So all the configuration that is shipped is part of the software. So you can translate your this is a contact category called website feedback that is shipped with Drupal core. You can translate that contact category to a different language in the user interface translation UI. And it's saved back to the configuration override system so it will be available as a translated configuration. It also works with pulling in translations from the community so the community can pre-translate it to a different language. So if you translate your content type, your contact categories or your note types will all be translated to different languages. And it will all be translated from English so you will not have this problem that you have right now in 7 that when you install Drupal 8 it installs in a certain language and then when you add other things that are in another language and there's nothing to keep track of what's going on there. So you can use the interface translation model to look for strings that are in configuration that you translated. But this is a very crappy user interface to translate configuration because it's way out of context from where your contact categories are configured. These are the strings. These are just individual strings that you need to find and translate. So we have a better solution. So the problem is this is only supported for shipped configuration that is shipped with Core. The reason for that is the whole interface translation system is set up so it translates from English to something else and it translates all the stuff that the community can also translate on the community translation server. So it doesn't support translating your own content types and your own views. So we have a solution for making these strings available on localizeDrupal.org. So there's a lot of new APIs in Drupal 8, a lot of new syntax that we need to find all the translatable strings that are present in code for Drupal 8 that we don't yet have solution for finding all the strings. So all the APIs that did not change from 7 are supported but all the new APIs are not supported at all. So we have a solution for this that we propose for Core that would provide a translation UI across everything in configuration and it's very shiny and easy. So it's called a configuration translation module and what it does is it provides a translate tab on everything that is translatable and configuration. How easy is that? So you go to your site configuration, here's your site translation. It will have a list of languages on your site, much like content translation. It will indicate the original language, I installed the site in English, I can translate it to Hungarian and then I hit the add translation thing and I will get a form where I can input the translation for my site name and my slogan which were the translatable things from the previous page. The previous page had a lot of information and then I go and the translated site name and slogan is there. So the best thing about this is this is for the site name but this same system works for translating a menu, a custom block, a contact category, a filter format, a user role, a panel, a rule, whatever. So whatever uses the configuration system as long as they use the schema system and the configuration structure of their configuration that we can identify the translatable things, we can pull them out, we can generate a form, we generate this form for translation. If you have a country module, you just use the configuration system and write a schema for your configuration and we generate the configuration form for you, we save the translation for you and the application can be used. All those goodies are there. So you only use the configuration system and the schemas and you are done. So we are proposing this module for core. It looked not very likely to be committed a week ago but now I'm getting some more positive feedback so maybe we'll have it in core, it would be very nice. I think it's a very crucial component for translatability because there's a lot of configuration in the very shitty UI but I can't translate the other stuff. I don't know. So, yeah, so this is going to be a huge improvement. The big thing to do here is change management so when the module is updated and they have a new plugin structure, a new data structure for their views plugin or their rule plugin or whatever, then we need to manage all that we are not doing yet and we are having a lot of discussions about that this week and we have issues to talk about that and this is a very nice user interface. It has a tab at the right place. It has a form. It only shows the translatables. It works for views, very nice but it's still very tricky because of the structure that I've shown earlier is that you have these data structure is very fragmented now so when you want to translate like a custom block it is a type of block that's a custom block type that is a configuration entity and is translated as configuration and then there's the block itself which is a content entity. It's an instance of the custom block so it translated as a content entity so the body of the block will be translated as the content entity and you can place it on the page which is a block placement configuration entity so to place a custom block in Drupal 8 involves three entities that's the two configuration entities and a content entity and if you want to translate you need to translate all three so there's a huge opportunity there for us to kind of figure out a good UI there and there's a huge business opportunity for these guys to provide us a nice and sane UI on top of this that makes sense and is very fluid and is not exposing all these technical details of Drupal we'll obviously want to work on a general solution so we are not reliant on lingo tech to do it but they will do it probably sooner than we will do so watch out. So the good news around configuration is we have a full interface translation interface in ctrl that we are proposing for core if it will not landing core it will be in ctrl so it works it's a Drupal 8 modular it works already we've been working a lot on actually improving the user experience of that and we'll do even more of that on friday and we'll do accessibility testing on friday so we are working a lot on perfecting this to make it even better we have standard translation tabs we have a system that explains that structure that we can use to generate forms and save translations we have config overrides that are the actual translations saved this works for any configuration across all of Drupal so we don't need to have the i18n underscore views module and the i18n underscore panels module and the i18n underscore path module and the i18n underscore menu module and all of those because this works everywhere we have a core UI for a ship system, string tracking and everything unfortunately we don't really do the change management for this yet which we should and the UI is very tricky and we need to have a layer on top which makes sense so there's also I should mention TMGMT also here which is also a unified UI on top of all kinds of sources of translation that you can push into jobs and then translate them so there's also a very big possibility there that TMGMT for Drupal 8 could plug in this whole and provide you with an integrated solution in Drupal 8 so I would love to I would love to have that out sooner than later for Drupal 8 so we have these four pillars we have language support which adds amazing new features like languages signing across everything and much easier to use we have interface translation which automatically downloads supports enterprise workflows better tracks custom strings lets you translate to English we have content translation which works across every content entity in core and it's very granular very configurable and we have content translation which works across every config in Drupal and is very powerful as well so our goal with Drupal 8 is to really have so as just to go back to my point at the start is to really have language as a core understanding and not just as an afterthought and if you use core APIs and core systems proper then you will have language support in your module so if you have a custom content entity type you will use the entity API that has built in language support if you have custom configuration systems like rules and panels then you will have intrinsic support for language through the configuration system so this is really a base support system that I hope would basically change the game because this is supporting everything if everybody who uses the API right to have language support in their modules which is going to be amazing I believe so if you want to get involved and be part of this and be in that huge list of people we have a website at Drupal 8 multilingual.org where you can see all the people working on this all the events that we have meeting times, sprints news about what we are doing focus issues on what we are doing and what we believe even videos of where we are so when this video is available I will put it there so people can see and always be up to date we have a Twitter feed at the EMI, we will sprint here we already sprinted here on the last Saturday, Sunday and Monday and we will sprint here on Friday, Saturday and Sunday we will sprint in this building on Friday and we will sprint on the weekend in the aquea office there will be whiskey sprints, twig sprints configuration sprints, a lot of sprints and we will sprint in Dublin Drupal Dev Days Dublin is the biggest developer conference in Europe outside of DrupalCon obviously so that's going to happen at the end of June and it's the last week right before feature freeze so it's the last opportunity to not feature freeze, code freeze so it's the last opportunity to get a lot of those things that we still need to do in so we will be there, a lot of us will be there all week to work on those things that are still not ready at that point obviously we would love to have stuff ready as soon as possible so I would wish you are included already on this list if you are not then please get involved come on over on Friday either if you haven't been involved with Core before, you should go to the mentor sprint, there's people who will mentor you to get on board if you want to be involved we have all kinds of lists of tasks so for example, Kristen identified two days ago that the module name for configuration translation is not capitalized properly and we don't even have the issue for that so we have an issue open, we have a patch filed we have somebody to test that and committed so there's things like that we can have issues on any level on any kind of area that you want to be involved so there's people entering you on Friday experienced in Drupal Core development you come to our sprint you will look for me or somebody else on the multilingual table we will have signs up where the multilingual table is we will be there and you can find us there so that should be it I hope you are as excited about Drupal 8 as I am and let's open up for questions I know we haven't solved some of the problems so there should be problems you mentioned that language detection will be browser based will you still support URL based language choosing? so what we have is all the features of Drupal 7 for language configuration with a much better user interface so it's all configured on one UI and we have by default if you install Drupal it will enable path language selection by default so you will not like I just edit a language and I can and I edit a language selector block and it doesn't work so that's the initial experience of someone in Drupal 7 so it will work out of the box in Drupal 8 so we have all that supported and we improved the browser detection a lot we've added a lot more testing coverage we've added mapping for external languages to internal languages and we have a couple more language selection options so yes we support everything that we did so far this morning in Kristen's session she explained that in D6 translation is node based in 7 it's node or entity based in 8 it will be field based in 8 it will be field based only we use a model where for region only content like for China only products for example we source everything in English unpublish it and then translate to Chinese since it's one node how are we going to unpublish the English and have the Chinese only show so I believe there's currently a custom solution in the node implementation for either this translation is published or not and we also working on making the properties themselves multilingual it's very exciting because you can have author tracking per language and status tracking per language and created time tracking per language and stuff like that so you can have all those properties per language then you can just unpublish certain languages that you don't want to see so it will treat it kind of like a meta node so what we found is in Drupal 7 we've created copies of the node and then people didn't really understand that there may be another copy of this node that is kind of the same thing but it's not really the same thing and what we do instead now is we translate it in place and we apply it to every entity type so people that so people who don't want to deal with language they deal with one entity and they don't want to they don't need to deal with language people who want to deal with language can provide the entity identifier and language and then be more granular in what they deal with so has there been any thought given to integration between date and multilingual right now we've had hellish problems translating date doing date formats in Chinese in places where it can't be handled by you know PHP date codes and stuff like that so I don't have a good answer for that I know that the all the date format per language configurability that there was in 7 was ported to 8 and it's in the configuration system it uses the configuration language system I don't think that was improved much but I don't have good details on that unfortunately so certainly the existing feature is certainly there I'm not sure if it was improved in a way that's helpful for you it's probably more of a date problem than an internationalization problem but it is a problem any other questions okay oh wait slightly unrelated but the sprint I think it was around the multilingual table someone left a mouse on Monday I was wondering if anyone's here who's missing a mouse tomorrow yeah what was that I didn't catch that oh you lost a mouse there's somebody left it behind oh you left it I don't know yeah you can you can put it out you can yeah so if that's it then thank you I hope you will enjoy Drupal 8