 Negotiation support at the bottom. And we already started that with moving out the language handling support from locale module to a module named the language module. So Drupal 8 does already have a module called language module. And all it does right now is that it lets you maintain the list of languages you have on your site. And that's what it does. And it will also get the negotiation code from the locale module. And with the language module enabled, what it means basically you can have a list of languages configured. And you will be able to assign language to stuff like entities and like configuration. So this basically allows you to tag stuff with language and to specify what languages you have on your site. And then we have three different silos in Drupal 4 language support that we consider. First is the interface language, which is kind of interesting for us or which is special for us because it always starts from English and it's built in the software. And it ships with the software. And we can pre-translate that for you and we can ship that to you. And there is a standard format for shipping that language information to you, et cetera. So it's a very well explored field that we have a lot of solutions for. The second silo is content, which is basically synonymous for entities in Drupal 8 for our plan, which in Drupal 7 already has two models of language support, which we'll get into later. And we want to make that simpler and make it a single model for everyone to be able to use. And then we have configuration, which is a separate silo for us. And that's a whole new system in Drupal 8 that was never in core before. And that's a whole new approach to how we store configuration and stage configuration and deploy configuration. And it's entirely different from the system in core for handling content language and translation and for handling interface translation. So on one side, this looks like a very nice model because we have a lot of previous experience with interface language. We have a lot of previous experience with constant language and we want to scale back on that area, in fact, mostly. And we want to move forward a bit, but we also want to scale back a lot. And for configuration, we need to explore the area a lot. But it's also scary because we have three silos to implement language support for. So it's three very different systems for interface. We start with English and we can pre-translate it and we have formats to ship it with. For content, we have fields and entities and that system. And for configuration, we don't have fields and entities and nothing like that. We have those file-based API-driven configuration areas. So these are three very different areas that we are planning to tackle one by one. And then we do not plan to provide any unified interface to here you can translate at the same time your interface and configuration content. We'll leave that for contrib. It would be, it's definitely not hard to unify these, but we need to implement that level of support for each of them for contrib to be able to unify. And then based on top of all these, we want to have a more capable display system than we have right now which can pick different content language and different configuration language. So there's a lot of stuff to do there. So let's start with the language list management. So as I've said, we already get started with that in Drupal 8. We removed the language management from locale module and created a new module called language module. And now all language management is right there. And we greatly simplified the user interface for that area. So you only need to specify a few properties of your languages. And we are adding a few special languages to Drupal 8 for you to be able to more granularly tell what your content is about or what your configuration is about. So in Drupal 7, we've had by default built in Drupal Core. We've had English and none. So when you created content, you could assign English and none after you've been able to locale module. And if you've added more languages, then more languages became available. And you could not get rid of English and you could not get rid of none. And there was IATN module that let you work around this problem. So in Drupal 8, we've already made English optional. So you can delete English. You can remove English from your website. That is not possible to assign to any content anymore. It will not remove the built-in user interface. We've added a new language called System Language. That is the built-in user interface language. Part of the reason we don't call that English is because English is like German. It can be any number of different versions of it. So another feature we built into Drupal Core is that now you can translate from the system language to English, your user interface. So you can translate Drupal to English, to your English that you want to use on your website. And it's built into Drupal 8 already. You're not obligated to do so. It's an option. It's not turned on by default. So there's no performance penalties with that. And we've added, or we are adding, three special languages, not specified, not applicable, and multiple. And these three basically replace what was in Drupal 7 none, because none can mean different things. And we used it for different things in Drupal 7. So if you save a path alias in Drupal 7 and you say it applies to language none, then it actually applies to all languages, multiple languages at once. If you save a field as language none, then it can either mean you don't know the language or it means it does not have any linguistic content. So we're adding three versions of special languages that you will be able to assign. These are already added in code. And we are working on a user interface on the workflows so you can assign these languages to your content. So if you don't know the language of the content, you can say not specified. If you know that the content does not have any linguistic information, it's a picture of a cat, or it's a number that's the price of a hockey ball, I don't know, then it's not applicable. And if it's a PDF file that contains a user manual for your MP3 player and it's in five languages, then it's multiple. Yes. So the question was whether it applies on the entity level or the field level or it's just theoretical. The level that we've added these right now is just that we made these available as constants and we are working on how you can apply these. And we are discussing two different approaches. One is to actually add these as languages on your system so you can enable them, disable them, remove them if you don't want to see them, et cetera. And the other is to add them as like special language additions that are added by alter hooks and other fun stuff whenever applicable. And then how granularly you make that configurable, we have a different issue for that that would allow you for saying that this type of node can never be submitted without a language assigned and then you would not be allowed to submit it with not applicable or not specified. So these are like more granular special cases for what we have none in Drupal 7.4. And I realize we do need some heavy documentation for this, so it's clear for everybody. I hope the three examples I provided you are kind of understandable. If not, then feel free to ask at the end or just shout. So we are adding some more special languages and we are making English optional so you can remove it and we are making English a translatable language so you can translate Drupal to English. And we are adding system language so we can maintain the built-in language as something of an information. So for interface translation, so far our working model is that we want to keep the system that we use in locale model in Drupal 7. So we want to keep using the get-text system for exchange of translation information. We want to keep using the t-function for languages. The main, so there's a lot of ideas and debate on improving that and moving forward in the area. The main reason for this is that we have a working system for this all around and we don't have working systems for content in different aspects and we don't have a working system at all for configuration. So we have much bigger problems in the other areas and we have kind of ready tools for this. So how we approach this right now is that we keep with the assumptions that we had that English comes from source code, it's always English that comes from source code from the software and it can be pre-translated and deployed from the pre-translation to the websites and what we want to build into Drupal Core is this system that's already available for Drupal 7 with the localization updates module. So that we provide a system on localize.drupal.org for translating Drupal the software. It's already happening and we can pull that we should be able to pull down eventually the available languages from localize.drupal.org to your site. So you can pick a language from localize.drupal.org on your site when you install Drupal and we can pull down the translations from localize.drupal.org when you install your site and when you update your modules, et cetera, et cetera. So if you want to enjoy this feature right now in Drupal 6 or Drupal 7, look for the localization updates module, L10 and underscore updates in Drupal Contrib. What we are doing is we are building this functionality in piece by piece to Drupal 8. What we have already of this is that we centralize the translation files to one directory. So the translation files will not be looked under translation folders of every module everywhere. We centralize that to one directory. So we can feed that directory with our module from localize.drupal.org in the future and we can import from there in the future. So we centralize that and we are working on the rest of the problems here. What we are actively working on from these problems is tracking local overwrites. So when you pull down translations from the community, it quite often happened that you want something different from the community translations but you also want to keep your site updated with the community translations for all other stuff. That's also built into the localization update module and we have a fairly well-working patch for Drupal 8 of this to be built in and it's gonna have much nicer features for the important export functionality as well. So if you wanna help out, you can find this issue on the DE8MI website. We also want to make pure parsing fully Bosward compliant. Which means all the PSR0 and OOP and PHP 5.3 and every Bosward that you can imagine in Drupal 8. We started working on that. We are looking at other systems whether we have a reusable library like Drupal 8 found Symphony for request handling and routing and other stuff. We are looking at all kinds of libraries for this so that we maybe don't need to do it ourselves. We have not yet found a good library that we could use in Drupal Core. So our working version for now is that we wanna rebuild our own code with a more modern architecture. And we are working on the user interface for translating interface in your website which I think most people don't use because it's crap. And we are taking ideas from localizeDrupal.org for this so we unify the experience and you can just seamlessly move between contributing to the community and working on your own website and you don't need to learn to screens. So it's basically a table of source string on the left and then a copy button that copies your source string value to the translation and then a reset button that clears it out to the original value, very simple. And we also already fixed the problem that we never had support for translating plural strings in Drupal Core on the user interface. We did support it if you imported or exported it but we never had a user interface for it. We already fixed that in Drupal Core and we are working on making the user interface simpler question. I was gonna say, is this view ready for seven or is this a screenshot of any? This is a mockup for Drupal 8. It's not yet built for Drupal 8. This is not at all hard to build this for Drupal 7 either. It's just a different UI on top of the existing built-in user interface translation system. So this is another thing that we are discussing right now and likely work on this week. So this is interface translation. In short, again, we wanna keep the existing backend system because it's done and it works and we have bigger problems elsewhere. We wanna modernize and make it fully password compliant in the backend. We wanna modernize the interface and we want to build in the localization updates so you can pull in from the community and we can simplify this area as much as possible for you. In fact, this system was the first that Drupal ever had external formats imported and exported in core. There was no others. Maybe except, yeah, maybe except RSS. Yeah, so RSS and GetText import, export are the only ones that are supported by Drupal Core. So next up is content language and translation that's our second silo. And what we have there is we have a problem with two models of translation. So in Drupal 7 we have two models of translation to work with. One is node translation that has a built in UI and the built in API in Drupal Core. It's called the content translation model and it works this way. You have a node, you mark it German and you wanna translate it to English and you wanna translate it to Italian and it builds two new nodes and it builds a relation between those nodes and you wanna have an Italian node as well. And we have a parallel system to this for field translation that looks like this. You have a German node and you don't make copies of the German node for translation but you make copies of the fields of the node for translation so you have the body in German, English and Italian and you have the title in German, English and Italian and for the data that you don't wanna translate like price of this, if it's a product node or photo of this, you don't wanna make translatable because it's the same across every language then you just don't make different copies of them for different languages. So Drupal 7 already has these two models supported and you always need to choose which one to use so both of them are supported. The interface for field translation is in contrib called entity translation module. So if you have that module in your site and the title module to support title translation then you basically have both systems and you can pick on a content type level and entity level to use either. Problem with that is that even those who understand these two models have struggles with selecting one or the other and then the customer comes back and it turns out that you actually should have selected the other one and it's kinda hard to migrate from one to the other and then there's all those modules like sign up and organic groups and all the other models that work with these entities and nodes and they either know one model or the other or neither. So the problem with this is that we have too much stuff going on. So we wanna simplify this and unify this in one system so it's easier to explain for people and it's easier to implement for module developers. So what we arrived at after a lot of debates and discussion is to kill the node translation model altogether, remove it, no more node translation model and extend the field translation model so you can reproduce the node translation model with field translation. So if you can translate any field and any property in a node, so if you can translate the publication status, the author name, the assigned menu items, the node relationships, whatever, if you can translate all of that in field translation then you could basically reproduce node translation one to one, you just have the same node ID but you load it or display it in different languages and there you have your different node and we can support that in workflows, we can support that in permissions and we can move that forward and modules that don't wanna deal with language can support it by default, they just don't care about that it has different languages supported, it just works with the entity as one and text to the entity as one, yes. Yeah, so the idea is that you have your workflow status fields so fields are translatable. Basically the problem for us, the biggest problem for us here is properties like title, like the published flag, the author name, et cetera and we have a buff tomorrow, lunchtime to discuss property translation so we can make that translatable. So if we solve translating properties in some way then you can basically replicate anything for any language and then you can just say that this language version of that so the node ID becomes a number and a language instead of just a number, right? So if you wanna support multilingual then your node IDs are a number and a language. If you don't wanna support multilingual then your node ID is a number, that's it. And you don't need to support two models and you can scale however you want so if you wanna have a few translatable fields you can set that up and later it turns out you wanna translate more fields then you can set those up too and just move forward and you don't need to migrate between two different models and models don't need to support both models at once, yes. Yes, the question was, do we plan to load all languages at the same time still? I don't have an answer for that. We don't, I don't think we made any plans to change them but. I'm Plach, actually I'm one of the people that designed the field translation API. I was saying when we designed it, catch the current D8 core maintainer which is deeply involved in performance issues stressed on the fact that we should always have all the languages loaded at one time because this makes easier to cache everything and it actually helps to deal with multiple languages because when you load an entity and you have multiple languages at the same time it's easier to support fallback and choose that maybe one field is available in one language, another field is not available in that language so you can pick up fields and mix them from different languages if you need to and so, yes, basically there is no, at the moment there is no plan for removing this support for loading multiple languages at one time. Which concern do you have about this? Let's keep that in mind. I feel for you to stay here, feel for you to stay here. No one's still my podium. So I think we can get back to that discussion certainly especially with catch involved as well if he's insisting on keeping it all the same. I don't remember discussing it recently so we can certainly revisit that. So we wanna move to this direction. What we've done already here is we've added languages assignment API support to more entity types. So in Drupal 7 you cannot assign language to terms or vocabulary entities and you kind of have a mixed language support for user entities and what we've already accomplished in Drupal 8 is that we have API and data storage level support for assigning language to entity to taxonomy terms, vocabularies. We have users are can now in Drupal 8 have a separate preferred language for email and site display and the language for their user entity content which we do not expose in the UI but if you so wanna be that detailed then you can do that. So we've added support for more entity types and I think we covered every entity type that we have in Drupal core. So that's kind of nice. We did not add UI for the new things that we added on the API level. So you cannot assign language to taxonomy yet on the UI. We are working to unify that UI and then get that in through a general entity system. We'll see how that pans out but we're working on a very good patch for defaulting the language on entities and how to configure that for different entity types. As I've said our biggest question I think our biggest risk in this area is the properties to be made translatable. So properties in Drupal 7 really are title status author are really just like single data entries in a coloring database and they are like very lightweight and they are lightweight because a lot of things are dependent on them so permissions are dependent on whether it's published and who authored it and the menu item placement is good for performance when you need to load that node, et cetera. So there's going to be a lot of debate there to solve it in a performance way and we are having a buff tomorrow if I have not yet told you about that. Lunchtime about this topic. So look at the buff schedule and if you want to get involved lunchtime is the right time. We are also working on language assignment and translation UI for this. The language assignment issue is already very hot and it's being worked on and the translation UI we just had a buff lunchtime so you already missed that to discuss the translation UX for Drupal 8 and to improve the Drupal 7 translation UX in the entity translation model for this. So there's a lot of discussions on how to improve this and get a better solution. And we do have a solution for a migration path from the node set solution in the Drupal 7 entity translation model. We of course need to solve it for the rest of the entity types where language might be assigned somehow and for the properties and all those things that are not yet supported. So that was content. Again, the content language silo is basically our problem is we have too much in there. We have two models of translation and we want to have one model which works by default. If you don't care about language, it works right away. You don't need to care about language if you don't want to. And if you do care about language, then it's just one system to develop for and it's just one system for the site builder to granularly get into. So that was content. And then we have configuration language and translation and this is a big open question. And I've had this session in London and what I've said there is that this is a big open question. So we did not make a lot of progress in this area. We do have some discussions and plans laid out on this node on Drupal.org. And we do have a buff about this on Thursday at the same time as the keynote. So we are not being too polite for the keynote but we want to solve this for you and I want all of you to be there to solve it with us. So we are having a buff Thursday at the keynote time to discuss the configuration language and translation support. That's gonna be very interesting. And finally, the higher layer was display. So we do have some support for picking a language for your interface depending on user preferences and all kinds of other things and that's pretty nice. What Drupal Core lacks is display support for content. So like the number one request maybe I get is I enabled multilingual support and my front page still shows nodes in every language but I enabled multilingual support. And I'm like, yes, well Drupal does not really do that in its listings. There's no multilingual support in listings. So grab views and then you'll be able to configure it there. So Drupal Core doesn't have display language filtering support for lists and other things. And we need to solve this in a more generic way and there's multiple discussions going on in here but this is not a well explored area yet. So we need to expand on here a lot. So if you wanna get involved in all these things then this is again the sprint. We are holding on Friday in this venue and then we are holding on Saturday and Sunday at an offsite venue. Actually the Saturday sprint venue is different from the Sunday sprint venue as well. So it's gonna be a lot of fun. So this is where you can sign up for the weekend sprints. If you are coming for Friday just come along. If you wanna come for Saturday Sunday you need to sign up. And this is the URL to track the progress of the initiative and we should be open for questions now if there are any left. Yes, please walk up to the mic. Can you walk up to the mic? That would be best. Is it on? I hope so. Thanks. One of the things you meant, I got two questions. Number one, you mentioned language of multiple. Yep. Kind of, I don't know, keyed something for me. Is this just gonna be a generic multiple or when you say multiple will you specify the languages that it's in? Like you mentioned English, German and Spanish I think. I don't want it to show up in other languages but I wanted to show up in those three. Yeah, so this multiple that we were introducing is you cannot act so it's like, it's not for specifying a list of languages. So what we have for a language assignment in any place in Drupal is you can assign one language to one thing and a thing can be granular. So if you have a thing that's an entity and that's in relation to something else and then there's multiple entities that are related in different languages then you can basically achieve that or there's multiple, or you assign multiple languages to the relation you can do that but not this multiple is not for that. This is for, this is a generic multiple of, I cannot specify one language because it's multiples. Okay. I'll have to read more about that. The second one was you mentioned the PO files and how you were looking for, I think you said something like you were looking for a way to do this to work with PO files and have a, I don't know, maybe a standard method with working for them. Have you looked at XLIF and all that's going on there? I know that all the translation vendors, the commercial vendors are supporting XLIF and they're open source tools to do translations using XLIF. Yes, I do build the first version of the XLIF module for Drupal Core. It was taken over from me some time after that but yes, I did look at XLIF and the tools I've looked at usually supported either cross migration or cross conversion from XLIF to POs if the data structure is simple enough or supported PO as well as XLIF. As I've said, we do have a lot more problems on architectural issues around the configuration and the content area. So we don't want to rebuild this distribution system and translation infrastructure for interface translation so we want to leave that kind of alone. But XLIF could be used all across for a lack of generic translation distribution method for content and for interface on top of this layer. But there's the translation management module that basically unifies this into one workflow system and then it connects you with, it can connect you with outside translation providers and workflows and rules and all those things so you can build in, you can build all these into a workflow. And it does have XLIF support as well, yes. So what we are building is we basically have, so the problem that we are trying to solve in Drupal 8 is we want to build a multiple support on the layers of Drupal Core so that everybody else needs to build on top of that. What we have in Drupal 7 is that IATNN tries to inject stuff from the outside and entity translation tries to inject stuff from the outside. It tries to support you to have your German version published but not your English version and that kind of thing but the rest of the system does not understand that or oftentimes does not understand that. And IATNN does the same, it tries to inject configuration translation somehow into the system but a lot of places the system does not understand that's going on. So instead of like injecting it from the outside what we are trying is to build stuff in and if we have this layer built then these advanced tools can build on top of that. But we are not looking at interbuilding advanced tools yet because we don't have a good solution for the underlying system. Hopefully this is not too involved a question. This is an ambitious project, an ambitious initiative for Drupal 8 as many of them are. Are there ways that you have in mind already that the community can, or paths for joining the effort and contributing and taking some of the load and to put that a little bit in context full disclosure. I'm also part of the learndrupal.org initiative of the Boston initiatives as you've been invited to as well. Just to put that out there. Yes, that was a good prompt. So actually I'm also involved with a buff for the Boston initiative that is I think tomorrow. It is tomorrow. So the Boston initiative is about building a leather of tasks that people can come in green like whole new to the community and then start with some simple tasks and then learn and then improve with working on more and more complex tasks. And we're going to have a buff tomorrow to try and map this work to the Boston initiative letter. So to build out these tasks and build out some tasks and help get people on board. And I also have, so the D8MI tool that I have on my site which is not in Drupal.org because it required a whole system of building content. So this is the D8MI link that I provided you twice. It has a current top priority tasks page. If you go to, it basically displays what we consider current top priority to work on. And this has things that I mentioned is like provide more flexible settings for initial language on content types, may get expo parsing, its own abstract functionality. This is the buzzword compliance thing at generate field property getters setters. This is property translation related. Let users assign language, not applicable language multiple. That's what I've said right now. So the things that I'm talking about are broken down to issues and are being worked on by fine people. And all of them need more people to work on, right? So most of them are to do in the to do column. And there's a lot of things in focus right now. Of course, and if you look at all the tasks that we have tagged for D8MI, it's like, well it's kind of, that was all the stuff we had and this is all the stuff we've already accomplished. And these are all the people who helped accomplish that. So be part of them. If you are a big name in this list then you get jobs better. I can tell you. Yeah. Hi. So I had a question around not just translation but the locales themselves. So a site like Wikipedia, it makes sense for each article to be translated into multiple languages. But what about content that's really only relevant? Not to a particular language but to a country or a region. And then when you have say in Canada you have French and English. It's really Canadian content that can be translated twice. I know you could probably hack it by creating separate languages for each region. So Argentinian, Spanish and Chilean, right? That's not really about the language, it's more about the region. Is that a separate module or is that what locales for? Yes, we do not currently work on that problem. So the question was there's languages and there's locales. Like if you wanna post something in French you might wanna target that at France or you wanna target that at Canada or somewhere else, French. And we do not currently work on that problem. There is an issue among the Sea of Issues here that has numerous people interested in that. I will not be able to find it for you but where I might. Yeah, no, that's not the one. So you can likely find it somehow. Yeah, separate language and locale proper language for kind of no, that's the one. I don't know. There's at least one issue here to work on that. It did not get a lot of developer momentum, unfortunately. So I think what a lot of people do is they hack languages right now for this. What you can also do is use fields for location and then build views to filter by fields. So you can have like French content and then the field tells you that it's for France and then the combination of the field for location and the data for language provides you the information to target it proper. I have a question about translation project maintainers. What does this mean for them? Translation. Like project, translation project maintainers on L.do, what does it mean for those people? What do you mean translation project maintainers, where, how? Like people that manage like specific language translations. Does it mean anything for them? On localize.truple.org or in your projects for your clients or where? No, localize. Okay, I don't think it means anything for them. So what we are. So pretty much we can ignore it until we're ready. Yeah, looks like it, yeah. Okay. So for translation project maintainers on localize.truple.org, basically this is the Drupal 7 thing and this is the Drupal 8 thing. So what we are trying is basically to separate the interface translation to its own thing and built in the localization update module so that people will be fed with your work from localize.truple.org. But we do not plan to like blow up this area because of our work in these other two areas that we are very much lagging behind. Hi, could you expand a little bit more upon what would be going on in the usage of .po files? And maybe also as a side question just what the motivation is for that format as opposed to. Like I know in symphony 2, they don't use .po files, they use YAML and I think two other type of file types that they allow for with their translator, I think it's a translator component or translation component. So I was just sort of wondering what's the motivation there and how are we talking about implementing this for Drupal? Yeah, I've been thinking about that a lot and I wanted to talk about that with Greg today but I did not manage to do that. So a lot of the momentum behind Drupal right now is to try and get standard solutions for things like PSR0 for placing classes and like symphony for a request handling system and et cetera, et cetera. And what's fun about our initiative is that we, for years we have a standard solution because get text is a standard unlike YAML is used for translation. So I think in this case symphony goes its own way and we are going the standard way with tools available for editing those .po files and spell checking them and merging them and making stats of them, et cetera. So there's a lot of tools built there that we can leverage in the market as a whole, not in Drupal but in the market as a whole. And we also built a lot of tools in Drupal, that's true. So I think in this case it makes a lot of sense to keep this however, if you've been to Greg's session he also said that Drupal 8 will either have entities which are content or CMI data which is configuration. So question is where's actually this interface translation stored in Drupal? So it kind of would look awkward if you take a PO file from localizeDrupal.org you import it to a CMI XML representation and you deploy that to your site and maintain that in the XML thing and then you can export it to PO file again. So that would look awkward. So if we wanna go the whole way then we might actually drop PO files altogether and use the CMI XML thing and just use that for deployment and distribution and everything. But the whole push for Drupal 8 is to use standardized components and things that prove themselves in the world and things that have tools already. And for us this is the area where we already have that. So I don't see a good reason to move forward although I see the problem with this internal representation. So it kind of comes back to having the getText editors available for people writing content and translating? So we are not doing getText for content. If you use the translation management and I think it integrates with Axlif it will not export your content in getText. I don't think, of course it's possible so you can write a getText import export tool but Axlif is the absolute acceptance standard in the area. We're talking about translation all the time but localization is sometimes a problem for us. If you have fields like amounts, prices and so on the displaying of amounts is in US different from Germany separated, are there any plans for Drupal 8? We don't have any plans in court. I've seen an announcement recently of a module for that in Drupal 7 though. I don't recall the exact name of that but I don't recall the name of the person working on it either, sorry. But it's being worked on definitely for Drupal 7. Locale dependent display of prices and those kind of things, yes. Cool. If there are no other questions, then thank you.