 I think it's time to start. So since you're all here on time, we shouldn't hold this down waiting for more people to come. I think this is the biggest ever Drupal 8 initiative status update that I've had, which is amazing. There's a lot of interest. I hope you'll get a lot out of it and I hope I will get a lot out of it. I'm working on this since I'm a Gabor Hoichi. I'm working for Acquia, and Acquia is paying a tiny part of the work that I'm doing here. Acquia is sponsoring a tiny part. Most of it I'm doing in my free time because I love making Drupal more multilingual. I started with Drupal in 2003. That was nine years ago, and the reason I started with Drupal was because I found it a great system, but I needed to contribute to Drupal. I was required to contribute to Drupal because I've had issues with translating Drupal to Hungarian, and I have issues ever since. So it's either a hard problem to solve to translation and language support in general, or I'm not good at it. We'll see. I wanted to start this off with a live demo of Drupal 8 because I think there's a lot of exciting stuff that we did in Drupal 8, and it might fail at places. I hope it will not fail completely, but there's a lot of stuff that's already in Drupal 8, and the team is working on this, putting a lot of hard hours. We burned out a couple of people on this already. So I hope you will appreciate this, and then we'll talk about the rest of the stuff that might be even more stuff that we still need to do in the remaining three months until feature freeze. So let's get this going. So the first thing when you start to install Drupal 8 is the install screen is not very visually visible, but if you've been installing lots of Drupal sites, you will notice that the first step when installing Drupal 8 is to choose language. That was the second step. So you choose language right away, and we also pre-select your preferred language based on your browser preference. So this is the text that I prefer Hungarian, and it chooses Hungarian for me. Now let's install it in English because that lets me to introduce you to this piece by piece. Otherwise, the installer and user interface in Drupal 8 is not much different than in Drupal 7, so you could be mistaken to say that this is Drupal 7 quite easily. There's a lot of work going on to make this different and better at several places, but that's not the focus of this talk, so I'm just going to do the simple whatever UI installation. So that was our first change, and the second change that we made is that we moved all the language based system functionality into a module of its own. So we now have a module called language, very simply, that when you enable you get all the base language functionality, and we'll see what base language functionality means. And we still have the locale module for all the user interface translation that's disabled by default, and the content translation that we'll talk about later. So now we have a language module which provides base language functionality, and the most important part of page language functionality is you can configure the list of languages on your site. So you have English by default, and now we provide three confusing special languages instead of one confusing special language. So in Drupal 7 there was the, what's the, language neutral language, and people used that for all kinds of different things. So we broke that down to three, not specified, not applicable multiple. So not specified means that this could have a language, but I have no idea. So if you are aggregating content from somewhere else, but you don't know what language it is in, it's all kinds of languages, then you could use this for example. Not applicable means that I know it does not have language. So if it's a picture of a cat that has no text on it, then it's not applicable, because it's not language specific information, it's a picture of a cat. And there's multiple, which is an opt out because we suck at implementing this feature. It's when you would want to apply multiple languages to something, but we don't have that feature, then you could apply this. So if you have like a PDF with user manuals that in Europe at least it's common that you get a user manual for your latest gadget, and it has five languages in there or 10, then you would use multiple. So if you have like a PDF file, people can download it, it has 10 languages in there, then you don't want to pick one, or you are not going to say it's not applicable because it has languages, you would say multiple. So we have these three, and we are still wondering whether to remove one of them or two of them or what to do with this, but they are here. We don't have configuration to remove these from the UI at places yet. We want to make that possible because now you have these showing up all the time. Language configuration is very easy. If you want to edit a language, it has a name and a direction and that's it. So there's no path alias, there's no domain, there's nothing. But we did not remove that feature, we made it more intuitive. So if you go to language detection and selection, what we have, we have URL language detection enabled by default, which is what we suggest people to do is I go there manually enable it, we have it enabled by default for you. And if you go to configure your URL language, what happens, you have your settings there. So you can say what path prefixes English or if you switch to domain, then you can say what domain is English. And it's only one place, so you see all the languages right here, all the languages you have configured, and it's much easier to compare them and fix issues with it. So that's a good usability improvement, I believe. We've also improved browser language detection, we fixed several bugs. We actually back ported that to Drupal 7 as well. It's equally simple to add a new language. So if I want to add German here, then I can just pick this and add language. This was a much more confusing form before. If you want to add a custom language that's possible at the bottom of the list, so if you pick custom, then you get all the custom fields you can put in there. We are not entirely sure that this is the most intuitive solution, but it's very compact and you scan the list anyway if you look for a language, or you might not scan it. So usability feedback, welcome. Yes, we do also have HTML5 language markup in the page. I'm not going to show that, but we converted the XHTML language markup to HTML language markup and HTML5 language markup, and we added some more of that as well. Now base language functionality is not about setting up language. It's also about assigning language to stuff. So if you now go to content types, you have the language module enabled. Now you can assign language to content, and if you just want to create an article, there's nothing happening there. So there's no visible functionality here, but you can configure it. So if you go back to structure, content types, and edit, people might remember in Drupal 7 there is publishing options. You need to go to publishing options to specify how you submit articles for languages. That's not very intuitive. Now we have language settings, and you have a lot more flexibility than before. So you can say what's the default language that this node type is set to by default, and then you can hide the language selector. So this means that these nodes, articles, will always be in the site's default language. You can also say it's in the current interface language, or you can also say it's the author's preferred language. So if you use stuff that people just submit, then they would submit in their own language, then this is a good setting. Also current interface language is a very good default for sites where people just submit something on an interface, and you assume that the content of the language of the content is the language of the interface. And it's going to show up if you unhide the language selector. So if I unhide the language selector and set it to current interface language, and I want to add articles, then I will suddenly have a language selector that defaults to English, because that is my current interface language. And then I can choose whatever else I want. So I can submit an article of this. So it's much more flexible. We've also made this language selector available as a form API element. It falls back to a value field. So if you implement the form API element and language module is not enabled, then it's just going to assign the language to your stuff, to your stuff. If you have language module enabled, then it's going to pop up as a select box and it will allow you to select the language. So it's very easy to add language support to your stuff. We've also added language support to other entities. So if you go to structure taxonomy and edit the vocabulary for tags, then you can say this vocabulary is in English, German, et cetera. And if you go to add a term, then you can also say this term is in English, German, et cetera. We have also added language support to files and that does not have a UI to edit. So it's not possible to show you. And we've also extended language support in users. So users can now have two different languages assigned to them. One is their user entity language, which is the language that their user profile is in. And they also have a preferred language that is the language that they get emails in and that the site displays them, et cetera. In Drupal Core, we unified that, we collapse that to one select field and we don't show two. So the user interface is the same as in seven. But if you do have that crazy use case that the user entity language is different from the user's preferred language, you can just unhide the form element that we have in Core and then you have it done. We've also added entity translation support to search module that is not in Drupal Seven. So if you translate content with the entity translation functionality with translating fields, then the search module in Core will index those translations as separate pieces and they will come back from the results as separate pieces of content. I cannot show you that because there is no UI currently for translating nodes with the entity translation functionality, there are API improvements to the entity form system. So that entity forms are now much more flexible and can be displayed in different languages and there's a lot more API improvements in that area. But it's not done yet to all the way to the front end. I still have language module enabled. So one more thing I can do here is I can assign language to blocks. I know blocks will be reworked and they will be fancy and all that, but we can assign language to blocks right now. So when you add a custom block and you want to have something, then you can assign language to blocks. And that means language visibility. So you can say this block shows in English and in German and whatever else. These three options does not make sense here. I know we should have a feature to remove these where they don't make sense. So then you can specify your visibility for your custom block and you can place it somewhere and be done with that. Now if I have a language switcher block enabled, I will be able to show that it actually works. So then I will be able to switch between English and German. So I've just put my custom block here and I'm on English and if I switch to German, that is still there because I kind of selected German, right? So if I don't select, it's not the custom block. It's the language selector block. So if I... Oh, it did work. Oh, sorry. It did work, but I'm going too fast and you can't even follow that. So there is a custom block there in English. If I switch to German, there's no custom block. So there's language-based visibility. And that's currently about the base language support. So we move that one layer down so it serves all the other subsystems. And one of the subsystems that it serves is a user interface translation that's currently in the locale module. So if you enable the locale module, then you'll get more functionality. So you go to enable the locale module, save for preparation. I just did multilingual training on Monday and one thing I've absurd people do when I said translate your stuff is that they went to the language list and they wanted to click on something to translate their site. Now that's totally possible. So when you go to the language list, there's a summary of your interface translation status and you can click here and you are instantly translating stuff to German. So there's interconnection between the translation screen and the language overview. Yes, so it's connected all together. It's also possible... Yeah, so there's also another problem that people face that when you have a multilingual site and you want to make changes to the English text on the site, like Americans like to change logout to sign out, that's not really possible. So you need to add the custom English and then you change that and then you already have nodes in English and then your site is a mess. What we have in Drupal 8 is you can go edit English and you say enable interface translation to English. You save English and you can translate to English and there's no need to add the custom language. Also, if you don't want to use English on the site, you want to use German, you have German, now you can delete English and English is not there at all. It's not in the language switchers, it's never in the world. So you can totally remove English. Yes, we've also improved the language translation user interface itself. So when you click on English or German, now this will direct you to the English translation UI and if you click German, it will track you to the German translation UI and it's all on one screen. So it's built into one screen. If you've used this screen before, it's one column your English text and then the summary of translation status for all the languages you have on your site, then you need to click in and then you have a translation form that you have all the languages there and then you can translate this text to five languages. Now it's the 80% use case is that people don't know five languages in a one language. They want to translate everything to one language so you have a UI for this. So you can enter your translations here. It shows you that you changed the translations if you go to drink some coffee or eat some dessert and you come back and you see what you changed, then you can save this and it saves into the database. So you can see there and edit it forward. We also have a much improved interface for editing plural information. So if I'm successful enough, there's already data for that. So you can edit the singular and plural forms altogether in the same place. This was not at all possible in Drupal 7. The data storage model in Drupal 7 does not allow for this in the locale modules. It's not possible to backport. It's all in one place so you can edit your singular and plural forms here. We've also made import and export much fancier. So import is a much simplified user interface now. You can just pick a translation file like I want to pick one for German here and then import it to obviously German. And now we take two types of translations. We take custom translations and we take non-custom translations and it means you can take translations from the community, which is files you download from localized Drupal.org and then you can take translations from your internal company stuff that you want to override the community translation with. And this will protect your overrides. So it already knows that you have overrides in the system. So you can treat it as custom or you treat it as non-custom and in that case you can overwrite non-customized or overwrite customized. Okay? So let's say I want to overwrite everything in German because I just submitted some crap there. And if you hit this import, what happened previously, that it uploaded this file and it imported all at once. And this is a big file. And if you have a server that does not have enough resources, this might run out of memory or your browser might disconnect or whatever. What happens here is you import this and it runs in a batch process and it reads the file in a running window and it imports the file in small pieces. So it runs in multiple HTTP requests so it's much better for seeing how it goes. And it's also much better for resource use. So now I imported German. You'll see that it actually works here. What we've also solved is there's also a much nicer UI for oh it's now going to be in German. So we've also have a much nicer UI for when you have more complex things like if you, I think this is Polish. So if you, whoops, now there's a bug. So if you have more complex plural forms and you want to import to that, I have experience importing or working with foreign languages, I know with the UI. So you want to import this to Polish that has more complex plural rules and we totally have the UI covered for that as well. Yes. So you go back to edit your step and you want to switch from German to Polish. That's going to be all Polish. And then they have three plural forms. So we have singular, first plural and second plural and you can edit it all together here as well. So it supports all that stuff. We've also have, let's switch back to English, we've also have some improvements to export. So when you export stuff, what did that did I switch to English even? Oh I imported to English. Oh no, otherwise, yeah, it's language prefix is still in my, yeah. Okay, so I can export stuff as well. So there's some tiny improvements there. It's again a much simpler UI. You just pick the language and you can export non-custom stuff, custom stuff, or untranslated stuff. So you can export all the stuff that you customized for your clients and then import this on other sites as well. So that's also possible. And that's about it for the existing improvements. We've also improved a lot of the APIs. We have a nice clean language API so you can hook into when languages are added, removed. We've improved the JavaScript support for language contexts in Drupal T and Drupal form of plural. We've improved the get text parsing process a lot so it's not just the user interface. It's much nicer. You can visibly see how it works. It's also much improved on the back end. We decoupled a lot of stuff so you can plug any other data source in here and just use the database submission process and take the data from somewhere else or vice versa. That's also possible in contrib. So that's about it for the language improvements we have so far. I think that's pretty exciting what you think. Good. Yeah, so I demoed this but the applause goes to these guys there. There's a lot of people who are helping out. There's a lot of people who help out once or twice. So those are like the small type people, the small type font people. Those who are like with bigger type are helping out more and those who are bold type are helping out recently. So there's up and coming people who don't help as much but they are up and coming and they probably grow out to even better contributors and we already have some of these people who left because they weren't out of all that stuff so we need more people to come and help. Because that's all cool stuff that I've showed is nice but there's a lot of stuff that we have still in the plans and it's not ready at all or is only half ready. So let's talk about that. So our initiative is structured in these four layers basically. We have this base layer which is base language functionality which we migrated out from local module to language module and we migrated all the local specific stuff to node module, comment module, user module, etc. So modules are language aware by themselves if language module is enabled. We also introduced form API language support as I've said. We are introducing, we hopefully introducing language support on forms so you'll be able to know this form is in this language and that will be useful to write your own code for that. And we hope to be introducing sometime later admin UI language selection so you can stick your admin UI to one language even if you have five languages but nobody's working on that so if that's an itch that's important for you then please work on that one. There are a lot of things I could not show in this demo but it's already in Drupal 8. We are building in localization update module to Drupal 8 and we have a lot of those pieces built into Drupal 8. So what we did is we centralized the PO file directory to one single directory. It's not under all the modules scattered all around. It's not that you need to download files to crappy places. There's one directory that's configurable in the files system, the file system UI, and the good reason for that is that we can import stuff from there. You can put it into version control if you want to put it into version control. It's one file it does not interfere with the version control or the stuff with the rest of your site. It's not going to be overwritten or stuff like that. We've also put in file tracking to core so it imports files from that directory automatically if the files are there for your language and we put in tracking to core so they tracks the files when they were less imported and it knows if it was already imported and it will not import it again until it changes or you specifically tell it to. There is no UI for this yet and we are working on right now especially Eric in the middle there raise your hand yeah Eric yes is working. It deserves it. So he's working right now to build in project identification we're using we are reusing some functionality from a bit module so we can identify your projects and version numbers and then download those files automatically that's the main missing piece here so we have it in the installer we have file tracking which is centralized to one directory so the final step is to identify projects and actually download those files and then we can show all the languages in the installer everything and you pick a language and it could download the translations from remotely and you can install Drupal even if you didn't download translations at all and it will automatically download all translations from there on so that's the plan we need more people to help with that we have pieces missing as I've said yes and then there's content language translation and some work is going on there as well and this part needs a lot more help I posted a blog post about this two weeks ago and it had no effect whatsoever in new people helping out but I try to make scary remarks about what's going to be missing and what's going to be hard for you when you're going to try Drupal 8 so I think it's worth it to like get involved now because then it's going to be a nice and shiny system if you're not involved now then you'll be you'll need to use Drupal 8 later unless you leave Drupal of course and then you'll suffer okay so if we solve this then you will not suffer so what we have there is a lot of modules in contrib content translation is in core and then entity translation is a UI in contrib for a core feature and we want to unify this to make this better and I will have some more to say about this later and our other area of work is configuration language and translation which is a totally different area in contrib it's implemented by the variable module that stores different variables and by the IATNN module that stores all all kinds of other language stuff with text groups in core and they use some core functionality in IATN module and there's a lot of modules to enable a lot of different user interfaces so what we are aiming in Drupal 8 is to work with the CMI system to have this done and I will have more to talk about this later so the so we are very good in the language area as you as you've seen the base language area we are very good the interface translation localization area we are pretty far ahead but we need more help and the content and the config area we need a lot more help a lot okay so there's a lot of things there that might not happen if you're not helping out so content language and translation the problem there is there's this nice core module called node translation that works like this it has a node that you say is German node and then if you enable this module then you can enable content types to have translation support and that means that you can assign you can relate other nodes to nodes so you can say the German nodes translation to English is this one and Italians that one and you can have free standing nodes that don't have translations of course so that's a core functionality the problem with this is that a lot of modules don't support it because if you are like selling products then you don't want to sell a German translation version of this product and an Italian translation version of this product or if you are taking signups or you are running organic groups you don't want a German version of this group and an Italian version of this group unless you want language specific groups obviously um or language specific signups or you want to take language specific votes or something so if you really want to have language specific things this is very good if you want to have overarching not language specific solutions this is bad because it's um it's much harder too to use it that way so core has a field translation functionality which uh works around this or work or is the solution for that problem that you have fields and you kind of translate stuff inside the node and you say this node is originally in German and it has fields in German but it also has translations to English and Italian inside there's no different node and you can say some fields are shared between these translations they are language independent um and that's not possible with node translation so it's not possible to do here but it's possible to do there and there's a work around here to copy around data and maintain that data and um and that's painful and that that's problem is solved over there the problem with field translation is that a lot of things are not fields so I've shown title here but title is not a field in core so you need to install a title module that replaces the title property with the title field and then you still have the author and this publication status and all kinds of other things that are not fields and are not translatable so if you want to have direct different authors for different versions because you like want to have translation permissions which is a pretty common requirement then you kind of cannot do this you can't use full translation you need to do this uh so so there is uh there's drawbacks to both systems and the biggest problem is there are two you need to choose you like think up ahead whether this content type uses this system or that system it's not possible to use both for one content type so you need to choose upfront for the content type and what's even worse is that Drupal developers need to learn both and implement both and they do neither so we need something that's that works out of the box they don't need to care about it and then and then we can solve our problems with it so the idea for Drupal 8 that's we are working on is to do property translation and that's just a terminology change everything's going to be based on properties and then fields are going to be extensions of properties so if everything is a property and properties can be translated then we kind of solve this problem of titles publication status etc and also if everything is translatable then you can reproduce this model right so if you set everything to translatable then you have a node id and then the language code and then nothing else is the same in the different language versions so you get the same thing okay so if we extend that area to be more flexible and have more features now you can reproduce both with one system and you only need to learn one system you don't need to choose upfront developers only only need to learn one thing so the idea is this and we get rid of no translation altogether you have one system and you can use it for both and you can use it for anything a bit weaned you can it's a lot more flexible and a lot more simpler the problem with this is that it's also looks like this because because almost nobody's working on this because it's a hard problem so what we wanted to try first is to make everything fields make title of field make author field make created data field and there are very few proponents of this in the Drupal community and a lot a lot of people don't like it for very valid reasons so we are not going that route but we need properties to vary by language so that like our core requirement is every property should be able to have different values per language so we need to do this so what we are doing instead is that we are migrating properties to a different table from entities and we make them vary by language and then you'll be able to vary any property by language they are not going to be filled as in you can remove and add them and rename them and that kind of stuff but we need to have them be stored separate by language and where we started with this is those two issues the first is already committed but you can look at the concept there so that's the test test entity type that we started with that we changed the schema and we migrated the properties to a separate table and the second one is entity field query to be able to query this an entity field query so the problem with this is we change schemas on every entity and we where's where's Dave we slow down core a little bit just because you need to you will have a join there or we will need to maintain copies of data from the original table in the entity property table so we can quickly query it so either we slow it down and insert service slow it down on the fact and and we need to support querying that and there's queries in core that needs to be converted to this so we just got started on this and we only have three months left and we need to convert all core entity types and we need to convert all core queries and we need to have an entity forms for this to make them work so the only way that this can happen is if people rally behind this idea and we make it work so these are the two issues that you can have a better understanding of what's going on the first was already committed so don't like we don't need your reviews anymore unless you're freaked out and you want to express your feelings there the second one is not be not yet committed it's still more work to do it's about entity field query and that of course we'll need to have everybody to embrace this thing so like using core we'll need to work with this new system that's uh we'll we'll I think fight this out whose problem is that one whether we need to convert or they need to convert or we'll work together on converting the system to that um there will be and then we have configuration translation language that's the other big part where we just got the first batch committee yesterday late night or it was maybe this morning even I don't know exact hour that that's a very complex problem and we are not solving the whole problem space but I'm going to explain some of the problems and then we'll see what we are aiming to solve so the the best thing here for us is that core is being converted to this unified configuration system and instead of every place variables and contact forms and I don't know site settings etc using different database tables and queries and all that stuff the cmi is unifying the system to one storage system and one access api so if we the druple a multilingual plugs into that api and supports language then we finally support language to everything that is cmi okay so we are kind of expecting in druple eight that things are either entities or under cmi stuff that is not entities or cmi will not have multilingual support in druple eight things currently in that area are aggregator stuff menu items and menus custom blocks so there are pretty core building blocks in core that nobody's working on to converting to entities or config actually custom blocks are somewhat being worked on at the scotch initiative but they are yeah it's being worked on there so you can help out there the rest I don't know if anybody's working on I'm following the issues and I haven't seen progress so we kind of expect stuff to be cmi or entity if it's neither then it will either keep the existing language support as for path aliases but it will not get language supporting core okay it will not so this is the example for site config let's say you want to translate your site name and your site slogan that's a very natural thing to ask for but there's not just translatable things there's also multilingual things so if you want a site there is a default front page or not it's a terminology thing you don't want to translate the default front page variable the path it's not translation you replace it with a different path for a different language if you're running a site and you have perfect german coverage on the site but your french site is three pages and it just says sorry we are still doing this then your front page for german is probably going to be like a panel or something and your french is going to be a node that says sorry okay so there's two different paths and that's not we don't consider that a translation we consider that multilingual the reason for this separation is for all the stuff that is in configuration and is translatable if we know the items that are translatable one by one and then we can translate them on localizedrupal.org for all the configuration that is shipped with Drupal core and the modules okay so if we identify the translatable pieces then we can translate things and that's going to kill issues like why the hell is my forum vocabulary named forum when i'm in a foreign language i think some of you might remember that problem and then there is this problem of widgets and validation in configuration like the logo image it's a very simple thing but it needs a file upload widget and it needs validation that it's not an evil file it needs to be renamed etc so theoretically for our use case all the configuration forms would be built from from a description that's meta level description much like entities and fields are and we would have this metadata of translatable and multilingual pieces but that's insanely a lot of work to do to convert every single form in Drupal core to this meta-meta system and nobody even built a meta-meta system for this to be converted to so the most likely thing for the forum area is to be solved in contra for Drupal 8 because there's it's just insanely low at work and we did a lot of work and we still have a lot of work to do another example which highlights an interesting problem is field config this could be an interesting example for people who speak English and don't really care about multilingual because it shows the language problem there so you have field configuration has a label description and a lot of values and you want to use multilingual features on that so when you display the administration form for this you likely want to edit the original language version of this because that's how you submitted it and you expect translation to happen somewhere and when you display the note form then you need to display the note form in the interface language it's the interface for submitting content which could be anything so I can set the interface language to German and I originally configured my fields in English so we need to translate to German on the note form and then there's the note display which should use the content language because the notes can be in different languages so when you display the English version of this note or the French version of this note then I need to pick that version from the config so when you pick config from the back end you need to tell the back end what do you need it's not like the back end will magically note that you need a specific language we need the back end to be told that what kind of language do you need so even if you are developer only speaking English and you don't want to care about language if you want to do configuration right we'll need some information from you to tell us what kind of language stuff do you need in this configuration retrieval process and the third one's very interesting is the contact configuration where we also need to have multiple languages supported but it's all in the same http request so you might want to load different language versions of configuration at the same time or almost at the same time so it has contact categories recipients and auto reply text and when you display the contact form it's the interface language that you display the contact form with and when you submit the contact form it's still likely the same interface language but when you submit the contact form we send a bunch of emails so we send an email to the recipient which should be in the recipient's language and we send an email to the copy to the submitter that's a checkbox on the contact form and that should be in the submitter's language so we kind of need to use the contact configuration data in the interface language for when the form submit comes in and for sending emails we need to pick different language versions based on the user's email preference and we already do this right now we kind of pass on this information but core does not support contact configuration translation so i89 tries to sneak in there and overwrites that and ideally we would not sneak in there but we would have a system where we are told the language and we would pick the right language information and storing that with configuration is also pretty useful because then we can store and stage it with the yaml files of configuration and then you can push it to upfront to the to the live server etc so we are going that route we are also going with configuration overwrites that means that there are separate copies of only the values that you have in different languages we need to work out the details of this and we need contexts which is a very overloaded word but i don't know with what we're to choose here for all the stuff that i talked to you before that we need the underlying system to tell us about the language that it needs we can just assume what language it needs so there's a patch that went in a couple of few hours ago to support this api and it has some baked-in assumptions so we have a lot of work to do on this it just went into support this thinking and we need to validate this thinking and we need to convert stuff to this thinking and one good example might be the date format settings that have language support in Drupal 7 already so we don't need to add language support and they are like relatively simple settings and that's also unfortunately a bit unicorny because we still need to work this out so the initial very first patch on this was just committed today that added this support so if you want to get involved there these are these two issues the first one is the i think the one that was just committed and the second one is about the metadata that we would need to be able to identify translatable configuration so the idea is you have views and you have panels and all kinds of other things which ship with configuration in modules if you export them and you build them in a module and you put it out to people and we can pre translate all the text in there or localizedrupal.org or for you and your client process with the metadata if we have metadata we don't currently have that metadata and we don't currently agree on what kind of metadata we need so so basically we have this base language layer that's pretty much worked out we have interface translation where it's pretty far ahead but needs more help and we have content support which is still kind of starting out there's a lot of work that went in there but there is a lot more work to do and there's a config language which also we have an idea of how we want to approach that what it also needs a lot of hands so how we can help is there's a sprint this week we had a sprint starting last saturday sunday and there was some sprinting on monday and we have a sprint on friday saturday sunday so this week so if you're staying around then you can sign up on this form and it has or in this page and it has information on the location and if you come and you sprint with us then that would be very much appreciated if you don't have time now and you already have a flight booked then you can get our irc meetings every second week that we hold on wednesdays and you can come and ask questions and there is a summary board of all the stuff that we are working on in this page that you can go to see this summary that i just did here just a short overview and then all the issues categorized that we are working on and there's a priority board there that you can see all the priority issues that we are working on right now and the current version of the user tech cloud that i showed at the start to thank everybody who helped and i'm totally over the supposed time for my talk part of the session but we should open up now for questions because that was my session yes yes it's already possible in duple seven the the fullback logic is pluggable so you can write your own fullback fullback callbacks so the the language selection fullback logic is pluggable that where you've seen that there's url language session language browser language default language you can add any number of other language fullback items there and you can define that logic however you want because it's php code so you can build in these assumptions of where things should fall back on based on that and then the language fullback system will just use that data and and use the appropriate language based on that selection as the question was what if you have multiple fullbacks and how you how you manage that the question is what you fall back for so if you fall back on content what we plan for duple eight is that all the translations are in one node so the fullback logic can happen when the node is displayed which is much better because then you don't need to pick a different node so it's already all in the same node and that then you already have the node displayed so you can do the logic there which is just one node and then you can pick very quickly from a short list of languages available there or not that well if you just need to pick from 200 that's still short it's relatively short in one node yeah i think we should we should talk about this privately because would be good to take other questions then we'll try it we can figure this out anything else anybody totally scared that we screw up everything or anybody happy that we are fixing everything yes currently we it's we do not touch revisions so we just use the other thing revision system so when you save a revision the api supports saving multiple languages at the same time in a revision so we still do save every language version of the node in the revision at once because it's one node one entity so we save all the language versions at once and the api totally makes it possible to change three language versions at once so if you have translations then you want to fix something in multiple languages in your api you can change multiple at once and it's just one new revision it's revisions of a node it's not revisions of a language i know there's a lot of data miro the treaker has a blog post about this problem the revisioning problem and the locking problem for editing these when you have multiple languages and then write locks and how that how does that work and what happens there so miro has a blog post about this i don't have the url handy but is working for md systems you can look at the blog there and that has interesting insights and that totally needs people to look at yes i agree yes yes we currently do that we currently do that that's the same as we do it in triple seven the reason for that is that's the that's the data about the entity that we load in and then the data we choose to display about that entity turns out much later so we load the whole data and then the data display decides what to display of that data so that happens later we kind of don't don't don't do lazy loading there i'm not fully aware of the intricacies of the new property api that fargo is working on but that might or might not make it possible to do lazy loading and just load the the specific language versions later that you actually want to access so the question i understood is uh if you use node translations right now will there be an upgrade path to field translation if we are burning down node translation altogether the answer to that is we do we did not burn down no translation yet and if we cannot solve the problems remaining for field translation we might not be able to burn it down and then we will have the same confusing thing in triple eight sorry that if you can help to get there then we can have we can get there and then we'll be able to remove that functionality so if we will remove that functionality in that case we will add upgrade path to the field translation system so you can upgrade to this system from Drupal 7 the existing entity translation module in Drupal 7 has an upgrade path coded for this and since we will only have one system we don't need to have any any cross migration tool anymore in Drupal 8 because you'll be able to configure on a property by property basis whether you want it to translate or not and things that you don't want to translate will be same they will be same across languages and things you want it to translate will be different yes yes yes the trick is that triple eight has a system english language that we do not show you but it has a system english language and it uses system english as a source language for all the code-based translations we did not change the process so we can introduce the system english behind and the english that you see on the ui it's just a frontend to that if you don't check the translation thing if you check the translation thing then it becomes all its own thing the reason you need to check it is performance so we didn't want to have any introduce any performance issues in this case for english sites so english sites so sites where you have multiple languages and one of them is english if you do not want to touch any strings in english then it will not go through the local system at all it will skip the local system if you check the checkbox it will go to the local system but if you don't check the checkbox it will not so you will have the same performance as triple seven if you check the checkbox it will not but it will have the same performance you had for your custom english because it's the same essentially but it's a much nicer understandable ui solution for the same problem yes yes hopefully yes it's not so this it's possible to change it but you're going to break your site that's the triple seven status so the question is will it be possible to change the default language hopefully yes so one of our missions is everything has language assigned explicitly so one thing you've seen is that you now can explicitly say that this taxonomy term is in this language and we did not have that information before so the default language on the site in triple seven is used as the assumption for everything that you did not tell the language off like a view if you did not tell that this view is in english then we assume that's in your site default language and if you change your site default language then all the assumptions suddenly change and you break your site because then you can translate from that language to the other language and it's a mess so what we are trying to do is is to assign language to everything that's a problem in all the configuration area that we don't really have a solution right now to solve to like have an assignment of language to every piece of configuration but ideally that would be the case so if you don't have that solved then there is a country module already called fixed language negotiation that you can use which allows you to change the language fallback to a fixed language without changing the default language so if all you want to change the default language for is the language logic fallback thing then you can ignore that and you can install this module and done that's what usually people want to change their language for because it changes how the logic works and it's a country module that works so you can use that we might build that in core if we don't get to the other end and then you'll be able to configure that anything else no so you so if some of you can show up on the Friday sprint we'll be hopefully able to to take tests for any levels i would love to see you there and i would love to see you in issue queues and later on if i don't see you then just assume that a lot of things might not happen of all the shiny things that i've shown that might happen the things that i should have actually already happened are there and they are not going to be rolled back i hope so all the shiny stuff that is there is hopefully it will be in droop later already yes yes the question was whether the study solutions for showing that a note has full translation as a flag that maintains it my answer is your definition of a full translation is your definition of a full translation it's not the same definition of the person sitting next to you and then the one sitting next to them there's different so you can add a flag with a flag module if you want to and then you need to have your own logic of setting that flag whether it's manual or whether it's automatic you can save flags with an api automatically and then you can set up your views based on