 So multilingual is not very easy and I've experienced this a couple times first-hand at Drupal events When I got my badges This is a batch from one of my Drupal events. This is my Account site from one of the last Drupal cons. This is the official program of one of the Drupal cons where I presented multilingual Drupal 8 so So I like to think this as an analogy To where we are coming from where multilingual is an afterthought and we may get it right or we may not get it right And we want to get to a place where multilingual is a very integral part of our system And we support it as much as possible. So this is only one of the many things that happened in Drupal 8 There's be many initiatives and non initiatives in Drupal 8 that improve the system And there's been very excellent work in services, views, mobile configuration management, etc And I would be the first person to admit that I was freaked out There's a lot of change in Drupal 8 and I even wrote angry emails to some of the other initiative leads at the start And I got very embarrassed at the end Because I thought it's gonna fragment our resources and it's gonna be very hard and and we will not achieve either of the goals that we wanted to achieve and I regretted all of that because what we ended up with is we empowered each other a lot more So you will see through this session that all the changes that the views initiative brought in all the changes that the Configuration management initiative brought in a lot of those things That came from other other places really helped a lot you to make better multilingual sites They are they are not the multilingual initiative But they helped a lot for you to make multilingual sites and I'm presenting this session, but reality is There's a lot of people who contribute to this initiative This is the list of all the people who are contributing to our initiative if you are in the room and you contribute Can you please stand up? If you commented on these issues Submitted patches you're not standing up The reason probably for that is there's a quarter lunch right behind these curtains Where those guys are sitting down and working on those patches, so that's why If you count those people we have almost nine hundred people who contributed to this initiative It is not counted the same way that Dries counts the thousand six hundred people in court We count everybody who commented on issues put reviews in or do any of those things who appeared on issues with comments So we we are more liberal in how we how we can't contributions We also had a lot of fun. So we've had a lot of sprints around at different places. We had sprints in Barcelona, Berkeley Munich That's Barcelona again We are sprinting right here right now and as I've said behind the curtains here And we also have been sprinting the previous weekend and we will sprint in the weekend coming this week And we also obviously will sprint on Friday as well. So you're welcome to join us So we work very hard on this and we already resolved about 540 issues a lot of stuff So Obviously we come a long way, but there's a lot more to do We started off with looking at Drupal 7 and what can Drupal 7 really do for you in terms of multilingual and The set state of Drupal 7 multilingual is there are some things that are multilingual, but it's mostly not a multilingual system So there is the locale module in core which can define your languages and it can try and get download try it can Handle translations that you downloaded and manually imported, but that's very painful to manage those translations So in contrib we built a module called localization update Which automates downloading those translations from the community and imports them for you And so you have less hassle if you have a hundred modules and three languages If you don't have this module you need to manually download 300 files To your desktop and then manually upload 300 files through the web interface to Drupal core and then import them It's very painful otherwise We also have content translation in Drupal 7, which is great because it can translate nodes It cannot translate anything else. So if you want to translate user profiles taxonomy terms menus Views whatever else it is no help for you in there. There's nothing. So Jose Ray Ray Ray hero when on and build the IATM module sweet Which has a lot of modules in there and it helps you Actually translate a lot of other things like menus taxonomy terms field configuration Views to some degree etc the problem There is there is a lot of modules to do this stuff because Drupal core is not multilingual in those areas in 7 So it needs to work around Drupal core and try to provide that feature From the outside basically And also there is a generic system that you need to map every functionality to so if you have views module Then you need to have IATM and you need to have IATM views module So it connects views with IATM or if you have web form you have web form and IATM And then you have rep form localization module that connects the two and that quickly becomes a lot of modules Huge maze of modules and this will not even translate your site settings or your configuration So there is a variable module suite that allows you to translate your site name and all of the other fun things That's again a multiple multiples of modules, and then you want to have an e-commerce site And you go and install Drupal commerce and you find that these 30 things that you've installed help you in no way in the process So you install the entity translation module which actually can translate the commerce entities And then it will use field translation, which is very different from content translation And now you have two different solutions on your site for translating taxonomy terms So you can use x entity translation or 18 and then you have two methods to translate nodes You can use content translation or entity translation and it becomes a mess So it really requires a lot of planning to build out a multilingual site on dribble 7. It's possible There's a very great book that you can buy Kristen Paul wrote it and I attack reviewed it so it should be very great and You can buy that and it explains all of these processes But it's a lot of work and a lot of contributed modules And what we really wanted to do is to get from an afterthought to be a base thing in the system And also to have a system where you build something and it's future proof for all the contributed modules And all the things that you build for your site so we decided to approach this and Using for pillars for areas that we wanted to work on so we wanted to have a base language system Where Drupal understand language in every place possible in Drupal core and it would know the language of everything in Drupal core And will not assume things that this menu may be in your site default language or maybe not That's not something we wanted to keep in Drupal. We wanted to know data about your stuff We also wanted to improve The interface translation software translation capabilities Bringing all the stuff that we built in contrib to help you in managing those translations and then do some more fun We wanted to have a content translation system that does not only apply to nodes It applies to everything in content for your site And we wanted to have a configuration translation system that's also in core and would support you in translating any of your configuration be it views or field formats or our field settings or input formats or user roles or Rules or whatever else you you want So let's look at these four pillars and see what we've done in each area And see how useful these improvements will be for you So the language pillar we wanted to make it very evident in Drupal aid that it's a multilingual system So we moved language selection up to the first step in installer and we've included all of the languages that localize Drupal at org supports so you can pick any of those languages that you want and You can hit hit submit on that whatever you like We even pre-select the language for you based on your browser preference So you don't even need to select one and then you can as you select it It downloads the translations live from the from the internet and then applies it to your installer and from the second step It's all in that foreign language It supports right to left and it can download any translations from the community that's available If you don't have an internet connection, it will try for a little while and it will say sorry I can download that please proceed in English So it's all built in there So from here on you can install in your own language. There's no manual steps involved There's no install text 10 step process to download something put in a place renamed the file nothing You just pick the language and we even pre-select for you from your browser preference We also thought it's very important to extend on the language assignment capabilities So what I've said is Drupal core has some language capabilities It can assign language to nodes users and aliases to some degree comments as well But it does in Drupal 7 it cannot assign language to anything else So for all the other data that's in Drupal 7 Drupal needs to assume that it's in some language and in Drupal 7 It assumes it's in the side default language and it's very dangerous to change the side default language on the site that you Already built in Drupal 7 don't do that ever because it changes the assumptions about what language your data is in And we didn't want that pain at all in Drupal 8 So we what we did is we extended this to everything that we could in Drupal 8 core So you can assign language to taxonomy terms you can say this view is in French or Czech You can say your site information is in a specific language So when you install in German, we save your site name and your slogan in German So we know that you've installed in German and this information is in German and it's independently Assigned to that from any other part of the site and this is extendable to anything So we have a generic system for assigning language to content to Configuration and we build this out for every piece of content and configuration. That's in Drupal core So we have all that data. We also have very flexible language UI setup for that So we have this content language settings and the admin interface and we have all the content content entity types there like comments and Users and taxonomy terms etc And then you can select which those types of content which language they will default to and if you want to show a Language selector on them or if you don't want to show a language selector on them So by default all of them will save in the site default language But you can configure forums to always be in English if you have a monolingual forum But your site otherwise is multilingual you can have more multilingual custom blocks And you can show a language selector on them etc etc So it's very easy to configure where you want to expose this selection to the user and where you want to hard Wire specific languages for specific content and you can later change your mind and change the defaults Well, if you want to so we we track that data and we allow you to configure that user interface On how we track that data and once we track that data we can do a lot of exciting things with that So we have block visibility per language which allows you to do site site page builds Based on language conditions so show specific blocks for specific specific language pages and since we have all the language data and we have views in core and We have a lot of pages converted to views even the content admin page and the user administration the user listing administration page It's very easy to customize pages for specific language needs So you can add language filters you can add language conditions and how they fall back on language selection what they display What they filter on etc So we don't need like 18 and magic functions to do this because views is in core pages are converted to views We have all the data about the languages of your things So you can use views and their conditions to build the right Right pages and then you can part of your pages you can use block visibility to hide or show based on language as well So we have all the data and thanks to views we can build off of that as well We also extended a great deal on how we select languages for the page So we used to have some selections here the URL language selection now includes in place configuration for your path prefixes and Domain so you don't need to go to another place. You have an overview of all the settings, which is pretty cool We have session selection as before we have account preference as before we have browser preference And now we understand that there is language codes outside of Drupal that are not the same as inside Drupal So you can add mappings of outside language codes to inside language codes So we can detect languages based on that as well. We have account preference for admin pages as separately and we have a Configurable language fallback so you don't need to change the site default language to change what language your site selection will fall back on which is again improving a lot in in what language Will the page be handled with so we improved the URL configuration a great deal We improved browser detection by supporting language mappings from outside language codes to inside language codes And we added an account preference for admin pages Which is very useful if you don't want if you have a multilingual site But you only know like to two of those languages and you still want to delete spam from the Chinese pages Then those pages when you go to them when you administer them They will not be Chinese They you will get the right language for your own preference And then we have selected language instead of default language so you can configure the fallback language on the site as well We also built in name transliteration and we applied it to content types in course So of course if you add an English content type name it works But then if you add something else like in this case a Hungarian word that that contains all the accents in Hungarian then it will Transliterate it to a meaningful English word and this all this also works for basically any other language So it works for Russian it works for a check all kinds of other things that we have built in so we only apply this to To machine names at this point it is possible to build contributed modules to apply this to file uploads We only get any other thing, but we have the base system in core and we applied it to machine names already It would be great to extend core to support it for files It's not a very easy task to do, but it would be a lot of fun and One more thing that that Europeans would really love I think is English can be deleted now So There's no need to keep around English on your side if you're never gonna use English in fact if you install in a different language Like Arabic that I installed at the start. There's no English added to the system. So everything will be Understood as Arabic and there's no like magic English showing up in different language selectors if you don't want to have that It's easy to add it back if you want it so This these are these were a lot of improvements and this is only one fourth of our initiative one fourth So you this the base language layer you can delete English We have a very flexible language selection system detection and selection system now We have block visibility per language views is in core We have all the data and you can build views out of language conditions We have flexible configuration for a language selectors and language defaults on entities We have much wider assignment for a language so we know much more about your data and language relations And we are first in the installer. So so if you don't recognize that Drupal is multilingual that we can't go anywhere Better than this So that was the first of four areas second area interface translation This is what used to be the main function of of locale module If you want to take yeah, sure. Let's do a question Yeah, so the question is what happens if I delete English and there is no translation Reality is Drupal's the software is still written in English. So the text is already in the code So we can take that text and display that even if you don't have English configured Because the text comes from the code anyway All the things that you create on your site you will create in your own language because you don't want English So you will create it in your own language So that's available in your language and all the stuff that comes from code will be In English if you don't translate them So it works It works the same way T function works the same way as before So interface translation is our second pillar And we built in the automated downloads that that we have in localization update except it's much cooler now Because it's also built into the installer right away as you have seen So it's it identifies all the versions of your projects and it automatically downloads translations for every module that you have in every theme And it's future proof. It works for every distribution works with every module that's on Drupal.org and has this information So, um, I think it's way easier We also centralize the translation file location to one directory And what why is that important? Uh, it's important because it allows you to have deployments with translations So you can have the automated downloads on the staging or the dev site And then you can turn off the automated downloads on the live site because you don't want your live site to magically Have new translations every day that would be kind of confusing So you can have it on dev and stage you can do the quality assurance And then because it's only one directory it can it can actually be put into git if you want So you can version control you can see diffs of what translation has changed in the interface Uh, it's very cool. And then you can push that to live and with the single drosh command You can import all the all the translations there and you are ready to go with your qa translation updates So I think it's it's very powerful We've also put in customization tracking. So how many of you are not entirely happy with the translations in your language for Drupal? Some of you. Oh a lot of you. Okay. So one option is you go and help out the translation team Okay, that's the best option But the translation team will not always like your suggestions, right? You want to have special texts for an audience? You are building a site for teenagers or you're building a site for serious corporate types You need to have different wording. So what we have in Drupal 8 we track customizations That are different from the community translations So you can customize those strings and we will protect those translations from being overwritten from the community Or all those customizations will be kept for you and you can export them and use them in another project and reuse them As you want So I think that's also very powerful and we worked a lot on supporting small sites So the import importing of p.o files, even though we import huge p.o files and Drupal 8 is much bigger than Drupal 7 The import happens in a process that it will never time out your php process We also have a whole new interface For for translating on the site. It's a table of source text and target text and it's for one specific language In Drupal 7 you translate for all of them at once, which is not very likely applicable to you and it supports plural strings and supports any number of plurals unlike the Drupal 7 built in user interface So you've probably never seen the version of this interface in Drupal 7 because it's useless. It can be used So we have a very nice user interface for this in 8 and now since you customize these strings in the translations You can filter for only translated strings and only customized translations and now these are more customized translations So it's very easy to translate and and review what you did and Just move over with these tasks Another good thing that we did to english is now you can translate to english So if you go so by default the translation is not applicable to english But if you edit english there's a checkbox to enable translation to english And then you save that and then now you can translate to english Which means that you can replace english text with a different english text So if you want to replace login with sign in Then you can search for login you can replace that with signing you can save this translation And it will be available on your front end on the login form So there the button that was used to say login now says sign in So you don't need to add my custom english whatever that you needed to have in 7 that's very painful It it breaks your Storage for english content, etc. You just translation enable english The reason we don't have this by default is because it will slow down your english pages Because this is extra database queries and and things like that. So you need to Accept this if you want to have this feature So this is only the second pillar of the triple eight multiplying improvements. We still have two pillars So you can translate to english There's a whole new interface for insight Translations We track your customizations and we protect them from being overwritten from the community We centralized the translations Into one directory So it's very deployment friendly and you can push from a staging dev to live And you can turn off the automation on the live But otherwise we can automatically download your translations And it's a separate module So if you only want to track language on your stuff If you have a search engine and you want and you have data and you just want to track language You don't need to enable this module and and your site will be actually faster So the third pillar that we have is content translation and what I said is the problem in Drupal 7 Is content only really applies to nodes? So we wanted to solve this in Drupal 8 and our goal was to support all content entities In Drupal core. What does that mean? So what are content entities in Drupal core? So first of all there are entities which Store itemized things and some of the entities are content entities This is not a hundred percent true graph, but it's a good generalization for our session So the content entities are like nodes users comments terms contact messages menu items Etc etc Mostly the things that you can put fields on not all of them are fieldable, but most of them are fieldable So we made it so that each of these can store their own language And we also made it so that each of these can have their fields translated So whatever fields you can put on users for profiles or put on taxonomy terms or or even comments Will be translatable And we have a very flexible configuration interface for this So it's the same UI that you've seen for language setup But if you enable the content translation module it will have a checkbox on the side You can mark something translatable the article content type for example And now it can you can configure per field So it has a body field an image field and the image field has a file and alt text the title and it has a text field So the image field even has subfield components that you can configure And you can share the file between different translations, but you can translate the alt text and the label Etc So it's very powerful and there's a lot of a lot of granularity in how you can configure this So if you want to have an e-commerce site and you don't want to translate your product prices Why would you want to translate your product prices? Then you will never enable translation for that field and it will be same across everything and then you can like enable the product image translation But don't enable for the product image itself You can enable for the label on it and the alt text And then you can translate those and the image itself will be the same across languages So it's very powerful and it applies to every content in Drupal core and it applies to every entity content entity in Drupal contrib That's going to be built So it's very Very granular and it's very future-proof In terms of the translation interface There is not much of a news here for you because it's basically very similar to what we've had in Drupal 7 You have a translate tab you go there It's a list of languages and then you can add a translation And then you get the note form at the new note form in Drupal 8 and then you add that translation and then it will be available for you So For the user at the end it's a very similar UI, but the internals are entirely different So the module name is the same But there's no there's no common thing between the two modules This will translate every entity and it will start the translations in the fields And it will have a very similar user interface, but it internally works very different So so we correct the problem of supporting all entities, but Drupal 8 is not yet done So Drupal 8 there's no Drupal 8.0 that you can download right now. So it's not probably not yet done So we are still working on property translatability For example, obviously it would be very useful for you to translate note titles Right, it's kind of useful And we don't have that right now on the user interface So if you go there you try to edit it, you will file a bug report that you can translate it Yes, you cannot at the moment we are working on that one and we are working on solutions for menus and taxonomy terms We may not have a core solution for those two to have properties But any fields you put on them are translatable. We strive to have a solution for properties We may not be able to get there The other bad news for you is the upgrade path will be a content module There's a lot involved in this migration process because we need to take your old nodes And merge them together and put them into one node and then do path redirects And all kinds of fun things So this will probably not be a fitting solution for a course. So we will build it in contrib And we need to Have be very creative about how we migrate i18 and entity translation stuff to this new system because we Bring in all the good stuff from i18 and an entity translation into one system and we need to migrate all your data However, there are a lot of other good news in this area The core search api is we updated to support this system So if you use core search, then all of those things will be indexed as separate things in the search And the search api passes on all the language information For any other module So if you use a patchy solar patchy solar module will get all the language information that we have And then it's up to a patchy solar module what it does with that information Uh, what's especially funky is node access api supports language So you can have separate access per language Which may be very interesting like if you are selling selling access to content Then you can sell access to german, but a separate sign up for french or something Is possible Um So in summary, this is the third pillar of triple core. We have node access api supported Which is great if you want to have granular access or selling stuff based on language We have search index indexing as separate things for these translations search apis know all this data It applies to all content entities. It's future proof. It's distribution proof It applies per bundle entity bundle and then the field level and the subfield level Like you've seen for image fields. You can make part of the image field translatable The property translations we are working on we may not have all of them ready by the droplet release But we would love to have them ready And the upgrade path will be in contrib. It's not yet ready at all The fourth pillar is configuration translation And this is an area where we are really thankful for the configuration initiative Because they did an awesome job of applying a new system to At every configuration part of droplet core. So I've shown this Thing before about entities having con content entities and all those things And there's also a generic configuration system So there's a generic content entity system and there's a generic configuration system Which is very good for the multilingual initiative because we can build generic solutions for content and configuration And all the things we built for configuration will apply to views vocabularies contact categories menus fields input formats user roles Whatever else is on the system basically entity display modes entity form modes, etc, etc So we have we we have a generic solution for that as well And it applies to configuration entities and configuration instances or configuration or standalone configuration as well in general now if you build something for Drupal And you are not in the green circle Or the blue circle and you want to have multilingual You are on your own We don't have any solutions for you so in core We do have path aliases that have a one-off implementation of language It's neither content neither config But if you want if you do something with Drupal 8 and and you are not a content entity or a configuration of some kind Then you are on your own. So Embrace these apis it's a very it's going to be very good for you Because configuration entities have a lot of developer experience back end They automatically store your data. They have list controllers. They have form controllers They have Dragon droppable form controllers that you can just like write a few lines of code and you get a drag and drop list controller that you can do Content has view support all around so there's a lot of power behind these two systems So you should adapt these two systems and work off of them because they are amazing So what we do for our configuration is we track again language on each configuration file So you can create a view only in french And you can create a view only in flemish or dutch or whatever you want And then you can translate it from there through other languages and have all that fun stuff So this is useful if you have Local community areas in your site and you need to do something for that area But you don't you don't want to do it as a general solution You can do a one-off french view for that area or a one-off german view for the other area All the language overrides for configuration all the language for configuration is stored in the configuration system So it's again very deployment friendly. It deploys with your configuration to the to one side to another So it's very very well integrated with how the configuration process works We have a ui in core to translate shipped configuration like this contact category. That's called website feedback You can go to the translation ui that I've shown you a few slides earlier And look for look for that. So let here I enable a language switcher So that I can actually show you that it works because otherwise I could just like hack you or else, but that's not very visible for you So I enable a language switcher and I have uh english and hengarian because I know hengarian best My mother tongue so I switch to hengarian nothing changes because I don't have hengarian translation for this I can go to the translation user interface and just take that website feedback string search for that and Translate it to hengarian right there and because this is part of the software. It's been shipped with triple core It is included in the software translation ui so I can translate it I can save it and from here on it's saved back to the configuration system and voila It's in hengarian So anything that ships with Drupal core you can translate using this built-in user interface in core The little caveat here is we are still working on localized Drupal.org integration So there's going to be modules distributions themes that ship with fields and entity display modes and all kinds of configuration And we want to get all the text from them and make it available for the community to translate for you So when you download Drupal all the views and content types and fields and everything will be translated from the community We don't have all that integration done yet This is again not an easy problem and we need more hands to help with that But we will we should be able to do that because otherwise Drupal it is kind of not fulfilling its promise of being fully multilingual This is for built-in configuration You you also going to build a lot of your own configuration So we built a module that's applicable to any configuration built in or otherwise And it's called a configuration translation module and we are proposing this for core So you can for example translate your block with this. So I go to edit my block I want to translate the block label to hungarian. I translated to hungarian. I tap in the hungarian title I save that And then that's available in hungarian. I can do The same for my site name and my slogan. I have my fantastic site I go to the site information screen. Oh, there's a translate tab who would have thought I can translate the site name in my slogan. I can add a hungarian translation type in my site name translation Type in my slogan translation It will be saved to the configuration system If I come back to the screen it will come back at me And it's available. So if I switch to hungarian my fantastic site changes to fantastic Ushwebalda, which is hungarian And my block title will change and my Uh config label changed, etc And this supplies to configuration in double core like user roll names input formats views fields content types Whatever So this is a generic user interface that puts translate tabs on all the things that are configuration So you go and and there's even contextual links. So you go in a block You can configure block translate block you go into view edit view translate view So you can go in and translate stuff as you go and this is a fully built module It's available right now for Drupal core. You can try it out. It works And we hope to have it committed to Drupal core in a couple weeks. It's not this week Um It's a feature and we are man months after feature freeze But we are still arguing for this It we found a lot of core bugs while we've been building this out because this crosses a lot of core systems from configuration language routing Views and all kinds of areas We are using in this um that um, that it's a very powerful thing that that Not only good for user experience, but also very good for developers So The configuration area we wanted to have a solution that's future proof and it works wherever you want So we built a full translation module that applies to all the content all the configuration All the config entities all the normal configuration on your site We really worked very hard to make the developer experience of this as simple as possible So it's very easy to build uh with this There's very minimal stuff that you need to do to integrate with this module We have standard translation tabs here that are you know from content translation is the same Same UI basically we work with config overrides in the configuration system So it's deployment friendly it works for anything in configuration And we have a core user interface for shift configuration So that's all the things that I think are good about uh droop late multilingual improvements So we have a layer base layer for language We know language of almost everything you have in Drupal core And we have much better language assignment and language detection capabilities We have a software translation system that has a much better user interface It automatically downloads from the community. It tracks your customizations Now it has a lot of fine UI improvements We have a content translation system that applies to every content entity it works off of fields It has you it allows you to configure subfield level translations And it's very powerful for that and it integrates with views as well And we have a configuration translation system that applies to everything in the configuration system Even your contributing modules and it has a has as integration with the software translation system So we can provide you with default translations for views and content types and everything that ships with core And we have a user interface for you to translate any configuration on your site So that's what's in droop late core But But there's one more thing That's not in droop late core. So if anybody like seriously looked at these slides, there's four pillars and there's I could also have set for silos Because there are different systems with different solutions. They try to have a very similar user interface Which is by the way also accessible. We worked on that as well But there are three silos. So there's a silo for software translation. There's a silo for content and there's a silo for Configuration and they are very different systems inside So those are silos. So if you want to really like control your site translations You need to have a system on top of this that sits on top It swoops in all the all the stuff all the content and it pushes it outward So there's two possible solutions for that one is the tmgmt module that's already being ported to droop l8 This is a droop l8 tmgmt screenshot That can take your stuff from these content entities From software translation and eventually from config translation. It's not yet built, but it's coming And it can integrate with outside translation providers Etc. So this is a layer on top of what's available in Drupal core And it integrates all of these silos into one system and can integrate with third parties There's a session about this on thursday 1 p.m. To 2 p.m. In the amazelabs room And there's another solution from the lingo tech guys who are sponsors of this conference and you can talk to them at the Exhibition area and they have a buff about their solution On thursday from 1045 to 1145 Where they showed their integrated solution for this That sits on top of of all these systems. I believe they don't have that ported to droop l8 yet But they will have it eventually. They have a droop l7 version right now So there is a lot of stuff and we as you've seen we still have a lot to do So if you want to get involved there's a sprint friday This week there's a mentoring sprint for those who have not been involved so far And there's a multilingual sprint for those who have been involved or feel confident to Join the team right away. If you don't feel confident to join the team right away There is a mentoring sprint They will let you get started and in the afternoon you can come over and work with us But if you just feel like coming over with us then that's also fine We also have a lot of other ways to get involved We have a website at droopl8multilingual.org If you want to translate droopl8 it's already available and localized at droopl.org for translation We have a twitter feed We have a sprint in prog that as I've said we started last saturday and we are here until sunday Late sunday, I think 2 a.m on monday actually We have a sprint space Booked and there's a sprint in vienna coming up and there's more sprints coming We will sprint in sagat droopl that day's march as well If you want to have your hands on all of this as I've said this already already works and you can try it out The configuration translation stuff is not in core yet So that's a module that we maintain as a contributed module at the moment You go there configuration translation module. It has a nice green button try it with droopl8 You hit that button you get a simply test me site with droopl8 and this module And it has all the things that I talked about working and you can try it out And once again, I'm here to talk about this, but this is a work of almost 900 people 500 issues Most of whom are not most of whom a lot of whom are actually behind these curtains and working on this right now So more of these things get fixed in core and and it will be even better for you at the end So with that I'm open for questions and discussions Any questions? So if you have questions, there's a mic right there as easy as to if you like line up behind the mic Or if you don't want to line up, I will try to hear you and repeat your question So the question is if is it possible to install One general language in different variants like us english or uk english The answer is Is yes, so there is a uk english on localized droopl.org They are not very active in in Replacing in us english texts with uk english, but it is possible. Yes There's a more complex use case there like if you want to have formal german and informal german That's a bit more complex because there you probably want to fall back on a translation or that's already a translation And that is not possible in droopl8 core However, the dependency injection architecture that was built in droopl8 Is supports a contributed module to very easily Swap out the t functions back end And do a fallback system. So the t function is as dependency injected. So the logic inside it is Is replaceable so a contributed module can very easily do language fallbacks across even different language So if you don't have a translation in one language, it could fall back to another one Um This by the way, that's the system we even used to simplify the developer experience of droopl8 Now you can use the t function everywhere Even if you don't yet have a database setup it works because its dependency injector is very powerful Other questions so The translation interface is not very good at the moment And is it possible in droopl8 to define translation groups? So all your translations in the front end would be packed into one group So your client would only be able to see that one group Since we've got like 33 languages they need to translate and it submits So we made our own system So you want to so you want to group by what? Front end or just something Because it's like the context Uh, you can define the context, but you can't sort it in the translation interface or you can't Mark just show this context It's just marked as Context something Yes, so Yes, so uh droopl7 already has a contact context that's possible to assign to strings It is not for front and back end separation though It's more for informing translators about whether like whether the word check Is for a check that you that's a paper check or whether it's checking out something or stuff like that So it's for if defining additional or providing additional information for short strings Unfortunately, how droopl is structured. It's very hard to tell if a string is going to show up on the back end or the front end So like there's a module that comes there's some strings coming from code And there are a lot of usable components that are maybe used on the front end or maybe used on the back end It's very hard to tell so what so I I have an idea So if somebody wants to build a contributed module you can build this out because It's very possible to build a contributed module that gets this information from your site So there's a module called the localization client module That collects all the strings that have been used on the page and it displays it at the bottom And then you can in place translate it. It's not available yet for droopl8. It's for seven The the technology that that module is using collecting all the strings that have been used on the page can be used to run Run logic on your site for a week or two weeks And then it will collect strings that are used on a page and it will store that location information Droopl8 can store much more granular location information for strings now by the way And then after a week or two you have all the information about Which strings are used on which paths on your site? And then you have a much better idea about which strings are front end and back end so Drupal does not know that And and it's really dependent how it shows up on your site So it's possible to build a module that crawls that that crawls That collects that information as time goes on and then you have that information I Discuss this idea and at several conferences and nobody built that module yet. So somebody wants to build that module I think it's a great idea because that's a free country request Yes, but would it be possible just to make it sortable by context? Once you have the context once you have that context. Yes But Drupal cord cannot tell you that context So like a views plugin It has An admin ui part and a front end ui part and some of it will show on the front end Some of it will show on the back end if you don't expose the filter on the ui if you don't expose the views filter It will never show on the front end It will only show on the back end So there's a lot of a lot of dependencies based on how you configure something If you have a field has field configuration, but you hide it on the form mode You don't show it on the front end ever and it's not a front end field. It's a back end field So it's very hard. There there's a lot of flexibility in Drupal core And we can't really know off like out of the code what's going to happen with that string So it's only your site that that through time can have that experience itself of what's appearing on the front end and on the back end Unfortunately, but it's possible to write a module. We have the technology in core to collect that information But nobody has written that module yet I can see one more question coming or two Yeah, quick question. Uh, is a selection of the Translate interface and content translation still separated? Can I have only a french back end and some? Like eight language in front end Yes, so so there's so what I've shown and I enabled the language switcher block But in Drupal seven if you have the entity translation module label You have like two or three language switcher blocks, which is very confusing So in eight we only show one one block by default and one language type But you can enable content language to be separate from interface language That's also a checkbox on the interface on the language selection And then you can configure them separately and then you can configure and can have different blocks for fallback So that flexibility is in there, but it's not shown by default because it was confusing, but it's still possible Okay, and another one is um, you talked about language customization like for informal english or commercial context Will that be uh uploaded to localize or is there some plan to do some I don't know inheritance in language or localize There is a great issue on localized Drupal at arc Which actually has some code to have language inheritance um, so the main so the main issue with localized Drupal at arc is it's running on Drupal six and Now that Drupal eight is hopefully about to be released Then we don't want to build new functionality on Drupal 60 will not be supported anymore So we want to bring that site over to Drupal seven And there is much less people working on localized than on Drupal at arc itself and Drupal at arc itself We've got a long way to update to Drupal seven. So there's an ongoing process to update the site to Drupal seven But it's not done So we need more people to help with that And uh, we actually have a post on localized Drupal at arc to help with that as you probably know Um, so once we port that to Drupal seven, then we can extend that functionality to however Why do we want we have a lot of feature requests from different teams? And we really want to improve the experience of moderating strings and language inheritance And uh activity monitoring and all kinds of other things so that you can be more effective in translations Thanks Thank you I want to know if it's possible to reap the benefits of automatic translation updates for your modules that are Not on Drupal dot org Is it possible? Yes so So, uh, so we so we use the back so the automated translation updates Uses the back end of the update module And the update module has this idea of the project source So by default the project source is updates dot Drupal dot org where it gets all the update data But if the project source is somewhere else Then we get the update data from there the version numbers that whether we need to download something And there's also a localization project url, which can be different per project So if you have a module that you build for your own then it then it then it can very well have its own Its own translation source url and it will get all the updates from there as well. Yeah, it's totally possible. Yes Thank you So the question was if it is possible to block modules When they have wrong translations to get to get downloaded to your site um, so So I think the answer to that is probably no there's no core solution for that You can Like it's possible to write a module to alter the project information and like have a Page where you can check off modules that you never want to get translation updates from But there's no core user interface to like configure by module Whether you want to have this module updates or that module updates It's all it's all applied to all the modules If they have so I think if they have wrong translations you probably want to have English translations instead, I guess So that's also possible to write a module based on the trans the downloaded translations to remove those translations from your site Or so there's different ways to write a module to solve this problem But there's no core solution to to solve this problem The best solution to go and help with those translations and make them better Yeah, submit them and then get them try to get them reviewed. Yeah, I know That's it's sometimes you're getting ignored thank you I have a question about the About the you know when you have Strings that you find and you want to translate Uh, not especially just from the modules, but from for example, if you have a login or or a string like that to have that translated as an inline translation where you have What I am actually trying to reference is from From the magento webcommerce system you can Enable to have inline translations displayed and you will just pick out this one string and Translate it translate that inline when you are working instead of going into the back end and translate the strings there Yeah, so Almost so what we have we have a localization client module That collects all the strings that have been displayed on a page and it has a toolbar at the bottom of the screen That contains all the strings on the page and it has a search feature So you can search for the string and you can translate it there. We don't have in place translation There's a very long standing feature request in that module to have that um That so it may be possible in some cases to do that The problem is well when we translate it We can't really inject any additional markup or any behavior to that to that text Because we have all these security measures that it may be escaped on escape later on in the page display process And then we'll screw up your page displayed All together so we can't really add an additional markup or information about the source string So when you when the page is downloaded we can't really tell which part of the page comes from which source string So we can't really like do Things like click there and translate it It may be possible in some limited cases, but it But it but we so far ahead of hard time imagining how we can do it generically There's a very long-standing issue in the l 10 n underscore client modules issue q to have click clickable Clickable page elements that you can just click and translate in place So you can look there and look at all the discussions and arguments and why And what we tried and where we failed There's there's a lot of things that we looked at and tried and we so far haven't been able to crack that problem Thank you So what if you already have nodes that have been translated but haven't been associated together? I know with i18n there's a way to do that where you get a nice little table and you can select the existing nodes I didn't see that in the screenshots Yes, so in in this case in ruple 8 all entity translations are stored in the same entity So they will not need to be an associated in any way because it's the same entity If you have content from before ruple 8 or In ruple 8 for some reason you create separate pieces of content and you need to later on associate them Uh, then we will need a solution for that We don't have a solution for merging those entities into one s translations But we will need to build that functionality for the migration path We actually have a have code for that in the entity translation ruple 7 version So we have code for that migration, but we need to pour that to ruple 8 And once we have that code we can release a version of that modular We can have a sub module there or something that allows you to do these merges And then they will be Functionally identical to that process where you say this node that node. Please put them up as as translations and put them together Okay, that'll be very helpful for those doing big migrations from yes Juma, for example Indeed So the logic already needs to be in the migration path So i'm not concerned that it will not be written We then need to write it in a way is a very good point that we need to write it in a way that it's available As a generic solution for later on as well when you need to merge things Yeah, great. So, uh, that was it. Thank you