Home / Resources / Recorded Webinars / Drupal 8 Preview: Multilingual Improvements [August 15, 2013]

Drupal 8 Preview: Multilingual Improvements [August 15, 2013]

Drupal 8 Preview: Multilingual Improvements [August 15, 2013]

Want to learn more about Acquia’s products, services, and happenings in the Drupal Community? Visit our site: http://bit.ly/yLaHO5.

Drupal 7 has multilingual features in itself, but building a multilingual website with several contributed modules can be very complex.

The process of building a multilingual website has been substantially improved in Drupal 8. It has become easier to maintain languages, translate different parts of the website and site settings. Drupal 8 will have standard multilingual solutions out of the box.

In this webinar, you will learn about:
• How Drupal 8 unifies language support across content & configuration
• New features for translating the interface
• The build-in content/field translation solution
• Translating views, site settings and more!

This webinar focuses on a site builder audience familiar with Drupal 7. It is presented by Gábor Hojtsy, Drupal 8 Multilingual Initiative lead. Gábor celebrates his 10 years of contributions to Drupal this year.

Category: 
Publish on date: 
Thursday, August 15, 2013
Rating: 
Click to see video transcript


Hannah Corey: ...webinar is Multilingual Improvements for Drupal 8 with my colleague, Gábor Hojtsy who is a senior software engineer at Acquia.
Gábor Hojtsy: So, I’m Gábor Hojtsy. I'm working in the Office of the CTO with Dries and my day job is I'm working on this product team for offering experience improvement for Drupal 8, and my night job is I'm very interested in multilingual for Drupal 8 so I’m also leading the multilingual initiative for Drupal 8. Although I'm presenting all this information to you, the reality is our multilingual initiative is probably the biggest initiative in Drupal 8.
We have a lot of people. This is the list of them - sites by activity. So we obviously have a few of them who are very active and a lot of them who are sometimes available, but in total, we have over 800 people working on this initiative, which I think is amazing. This is probably one of the biggest, if not the biggest in Drupal 8.
We’ve also had a lot of fun. We’ve had sprints in Barcelona and Berkeley, California. We’ve been to Munich. We've been to Dublin. We are trying to couple sprints with DrupalCons. We have a sprint right now happening in Chicago where several other Drupal 8 sprints are happening as well, and we also have a sprint coming up in Prague. I will put in links to those.
So we are actively working on this. We already resolved almost 500 issues in Drupal 8 related to multilingual, but we still have over 300 outstanding. So, we made huge progress. I think Drupal 8 is leaps and bounds ahead of Drupal 7 in terms of multilingual functionality, but we still have a lot to do. We may not get to all of these issues. Of course not all of them are critical for the release. There are a lot of things that would be nice to have but we’ll not get to that, but there’s something for Drupal 9 always, right?
Where we started is how Drupal 7 treats multilingual and that’s not the best situation that we’ve seen. So for Drupal 7, there is a core module that’s called Locale that handles the basic language functionality essentially and it provides you with a list of languages to configure and it also lets you have a foreign-language website UI which presents your website in those languages and that's about what Locale module provides you. However, if you want to actually translate your site into those languages, you need to download those translation files from the community, manually import them to your site, and it's very painful that you have 100 modules and you want to separate three languages then you need to identify version numbers for 100 modules and manually download 300 files, one file for each language and each module. So we’ve built a contributed module called Localization update. That’s called l10n_update that lets you automate that and download all those things, but it's not in Drupal 7 core. A lot of people are not aware that this is available but it's a huge, huge timesaver.
Then there's also another core module called Content Translation which essentially allows you to translate nodes on your site. It does not allow you to translate anything else. So, it’s only there for nodes. There is no other content that’s supported in core to be translated, so we need to have other modules that step in there.
The i18n module suite is a set of modules that steps in and helps with all the other things in core that are not translatable especially menus, taxonomy terms, field labels, and other things but once you get to Views, for example, you need to install the i18n module, enable several modules under there and then install the i18n_views module and that’s a bridge module between i18n and Views and then have Views. So there are a lot of extra modules that you need to add, same for Webform because there’s a module called webform_localization that you need to add to make Webform language anywhere. So there are a lot of extra things that you need to put on top to support all those things. Even then, the site settings are not translatable. There's another module suite called Variable which allows you to translate site settings. It lets you do you things like site names, slogans, and other things like user email text and that’s a set of modules. Again, it’s not just one module.
Then once you get to things like e-commerce, you want to add a commerce area to your site, none of these modules let you have translations for commerce because commerce uses its own entity system. Obviously that’s not supported by these and that’s where Entity Translation module comes in that lets you actually translate fields on any kind of entity and that’s overlapping with the Content Translation module and also overlapping with some of the i18n module features like taxonomy translation, and that also requires another module called Title module to be effective for translating all of the pieces.
So essentially, the summary from Drupal 7 is it’s not really a multilingual system and it needs a lot of modules to work around that it's not really a multilingual system and to make it behave as a multilingual system and that's not really good and there are also overlapping features in Content Translation, Entity Translation, and i18n that needs to be reconciled.
So what we planned for Drupal 8 is essentially four pillars that cover the basics and then serve as an extended base for everything to work out fast in the contributed modules space as well. So we wanted to build a Language pillar that provides base services for all modules dealing with data not just multilingual sites, even for monolingual, foreign-language sites. We wanted to have a separate layer for Interface Translation. These two were mixed up in the Locale module in Drupal 7 that handles interface translation, built-in update features, and improved usability. We wanted to have a general solution for Content Translation that works with fields and any entity type not just node types so it’s extendable for contributed space as well. We wanted to have a general solution for configuration, and thanks to the Configuration Management Initiative, we’ve got a general system in Drupal 8 to handle that so we can build on top of that one. This presentation is basically going through these four pillars and seeing what we’ve done and how we’ve improved your life from Drupal 7. So I think you will best enjoy this if you looked at Drupal 7 or 6 and try to build a multilingual site because we’ve been focusing on fixing the pain points that existed there and building an extendable system, also an extended system that’s useful for Drupal 8 going forward with improvement possibilities and contributed modules.
So the first pillar is Language and we did a lot of things there. It sounds like the basic underlying layer, but we did a lot of changes there. The first thing is we made language selection step one in the installer and we automatically detect your language from the browser. So in this case, it detected I’m Hungarian, but there are 100 languages available that you can pick from. In Drupal 7, you need to manually download a file and only then these languages become available. We also made everything after this step available in that language. We downloaded translation life from the community and this even works for RTL languages like Arabic in this case, and you can just go through all the installations in Arabic in right-to-left and just do all the things. The pieces that are not translated here are just not translated because they are new in Drupal 8 or have not been translatable in Drupal 7 so these are just temporary issues. So, we’ve made the installer fully translatable from step one and we automated all of the download and future-enable steps so you don’t need to manually do anything to get a foreign-language site up.
One of the most important things that we did I think is we’ve expanded on language assignment features. So what we’ve inherited from Drupal 7 is you can assign language to nodes, users, and past aliases and we kept all those in Drupal 8. In fact, you can now assign three different languages to a user based on different needs, but those are actually just details. What we made possible though is to have language assignments basically to anything. So we've expanded language assignments to other types of content like taxonomy terms. We’ve made language assignment available across everything in the configuration system like Views and even your site information like your site name or slogan. We now know what the language of your site name is so we can work with that. Not all of these UIs have language selectors on them so you can change language of a view, but you can’t actually change the language of your site name at the moment. This is more of a UX question than a technology question and this is extendable infinitely. So we thought it’s very important to know language on the most basic levels because if we know the language of data then we can work with that information and use that information to do all kinds of interesting things like double Views out of the data.
So this is along language assignments and we also added very flexible settings inspired by the i18n module but brought further and generalized and made much nicer to default languages for certain things. We have a full set of settings for content languages, content language defaults under Regional Language Settings. So you can customize the default language settings for any content type either common custom block menu and taxonomy terms, et cetera, and you can default certain things to languages. For example, if you have a monolingual English form, you can say all your forms are in English and you don’t show a language selector on them. If you multilingual articles, you want to publish them in English by default, not show the language selector on them so you can publish an article originally in German or any other language. You can do the same for basic blocks or anything else. So this is a very flexible and extended system that you can use to set up defaults for languages. So the UI for language selection shows up on content creation if you need it to show up, but otherwise, it will just not bother you. I think it’s very useful. There are also dynamic default languages here like the site default language or the current user’s language or the language negotiated for the page, language selected for the page so it’s very flexible and extensible.
We’ve also added language visibility to blocks which are very good for site building. So you expose certain blocks for only certain languages. You can use this to hide and display menu blocks for example or use blocks, and there is also language filtering built into Views. Now, that’s not a new thing. Views have language filtering in Drupal 7. What’s new in Drupal 8 is a lot of the pages in Drupal 8 are views. The front page in Drupal 8 is a view. Even the nodes administration page, the nodes administration listing page is a view. So, you can add language filtering to these. You can add exposed filters for language or have language selection criteria configured for these pages so there is no need to override them or use the i18n module to filter for foreign language or anything else. You can just use Views and the language selection capability is built in.
We’ve also expanded and made the language detection much simpler. Here is that. So we’ve already had URL language selection in 7 but we’ve built in all the settings to be here instead of with the languages so it’s all in place configurable essentially for path prefixes and domain. We have the session as before. We have an account preference per site and we’ve expanded the browser language settings so we can now map external languages to internal languages. So we now understand that the Drupal language probes may not be universally understandable in the whole universe. We can map external language codes to internal ones. We have account preferences for administration pages and now, the best thing I think here is now you can change the fallback language at the end. So in Drupal 7, all the fallback language at the end will essentially decide default language and a lot of people built sites and then they wanted to change the default language and they went in and changed the site default language and it caused a lot problems because then Drupal’s assumptions changed about what’s in what language. Another issue has emerged and we resolved this in two ways: we made language assignments available for almost everything so we rely less on what the side default language is; and we’ve also made this detection setting configurable so you can change the language here and that will made site by default in a different language and you don’t need to change the site default language for that. I think it’s very useful.
Then we’ve added Name Transliteration that was a content module in 8. So of course, if you type in a name for content type, in this case, it will have a machine name generated, but if you type in the name in Hungarian in this case, it will transliterate it to English characters automatically so it will have a machine name that’s readable. It works for Russian, as shown in this example, and it also works for Czech or a lot of other languages.
Well, we have a built-in transliteration system now in Drupal 8. We’ve applied this to machine names and not only for content types but all kinds of other machine names so when you create a view or anything else, the machine name will be generated like this, but it’s extendable so it can be used for file name transliteration or for other fun things. There’s one more interesting development in the language area. I think that European people will – especially LICO I’ve heard that English can be deleted so you don’t need to keep English as a language or bound on your site like in Drupal 7. English can now be deleted. Drupal will still fall back on English interface language, but it will not have English surrounding language selectors in other areas on the site if you remove it. So, if you have a foreign-language site and you don’t need English, you only need Finnish you don’t need anything else, then it will be a Finnish-only site and there will be no English on the site. If you install Drupal in a foreign language, it will automatically be in this state so it will not have English by default.
So in summary, the Language pillar, you can delete English from the site. We’ve made it flexible. We made the language selection configuration very flexible and much more user-friendly. We’ve added block visibility per language. We now have Views inquire which is very useful for data filtering by language. We have flexible configuration for content default languages. We have a much wider language assignment capability, and we are first in the installer with the language – and automatically installed in that language. That was only the first pillar. We still have three pillars to go in terms of what the changes are in Drupal 8.
The second is interface translation and the biggest pain point, as I’ve said in Drupal 7 is with a lot manual work. So what we did in Drupal 8 is we’ve added automated downloads. So, we enabled it automatically if you install in a foreign language and then we automatically download all the translation and this works for any distribution and any module you add later on the site because it will just identify the names and versions and download the right language translations. It’s very cool.
We’ve also centralized the translation file location to one directory. Before Drupal 8, it was multiple directories that run in your file system. Why this is useful is it’s very friendly for deployment. So you can take all those files, put them into version control and you can run updates on your desk site or your stay-in site, commit the changes after you quality-assured the site and then you can push all those translations to the server and you can disable the automated updates on the live server. So, by putting this all in one place and making it configurable, you can use GIS or any another deployment mechanism that you want to take control of what strings are on your site and you can push only those strings that have been quality-assured.
We also track customizations to translations. So we download everything from the community that’s available but you can deviate from the community’s translation and we keep track of where you deviated on a string-by-string basis, expected basis. So when you change something that was downloaded from the community, we keep track of that and we protect it. So while on the update runs it will not be overwritten by the update, and you can also import full translation files that are only your custom translations and you can also export your custom translations and you can reuse those custom translations on other client projects or similar sites that you’re running. I think it’s very useful for keeping string changes from the community when you’re unhappy with the community translation, but you don’t want to fight the fight or you don’t have the time or something like that.
We’ve also built a whole new translation interface. In Drupal 7 this was pretty hard to work with but in Drupal 8, it’s all two count tables where you can just enter translations as you go. You can filter for different translations and you can translate singular, plural paths in place. This obviously of course supports plural forms where there are multiple – like four or five carry-ons that are all built in as before but now the user interface supports that as well and then you can filter to only translate these strings and only do the customize translations that you’ve just entered. So it’s very easy to translate and fill in all the things that are not translated by the community. In Drupal 7, this was pretty hard and you can go in to edit a string translation but then it was for all languages and not for a specific language, so we’ve improved in this area a lot I believe.
One final thing that I think a lot of people who want to do English websites will be happy is that now you can translate to English. So the Drupal 8 understands that English is not one language. You can go and edit English and enable interface translation to English and then English will be made available as a target language for translation. Then you can go in and translate to English much like to any other language and one popular thing here for example is translate or replace login with sign in. So you can do that replacement. You can go to the site and you will see the login text has now changed to sign in.
So, now Drupal core can do text replacement for English as much as translation for any other language and you don’t need to add a custom English language or do any other hacks like you may have done in Drupal 7 to add English translation. It’s pretty hard to do it in 7 because you need to add a custom English and then the base English is not deletable and you need to keep that around and then language selectors will show both of them possibly. So there are some issues there, but all of them are resolved in Drupal 8.
So in summary, the Interface Translation pillar I think is pretty powerful. Now you can translate to English. We have a whole new translation interface built into the site which is now actually useful. You probably haven't even seen the previous one because it was not useful. We track custom translations where you deviated from the community and we protect them for you. We centralized the file directory to one place so you can push - and version control, even your translations if you want to. We added automatic download features so we identify your modules, version numbers, themes, download all the translations and import them automatically. It’s not a separate module so if you don't need all these features, you just want a site where you assign language information to data and you want to have an English user interface then you don't need to enable this module ever and it will not be running on your site. That was the second pillar.
Now, let's move on to the third pillar about Content Translation. I think this has a lot of potential especially because we support all content entities now. So the module name is the same as in Drupal 7. The module name did not change and this is an entirely different module. It has nothing to do with the old one and it now works on entity and field level. So how you configure this is also I believe very comfy. It uses the same UI that you used for configuring default languages but when you enable the Content Translation module, it will have check boxes for translatability. What that makes appear is making all your entity bundles basically or entity subtypes available for translation. So what you can do is if you enable articles for translation for example, it will default to translations configured for a certain set of fields and it makes sense hopefully by default. So what it does now is it makes body translatable, the image field, and the tags field and then it also works on the subfield level. So it does not make the file itself translatable but makes the Alt text and title text translatable. So the image file is kept synced across your translation but the Alt text and the title text will be translatable. So it’s very flexible. It goes on the entity type level and then the subtype level and then the field level and then subfield level. As you go through here, this is probably easy to configure. Once you have a configured site, when you come back, it’s probably pretty tedious and maybe a bit overwhelming, but it’s also a very good overview of what you have configured. You can do the same for basic blocks with the block body, et cetera. As you add more fields, those fields are also configurable for translatability and you can also come back here and configure them for translatability later. So this is all integrated with the default language setup configuration that you’ve already seen. This just makes all the entities and their subtypes translatable. So, it’s very fine-grain and very dynamic.
The translation interface is surprisingly the same as in the previous version which is basically for usability because we found that people already understood that. So, you have a Translation tab on all kinds of entities that this supports. This includes user’s taxonomy terms and all kinds of entities that can have fields in them, and it shows a list of languages that is possible to translate to and then you can go and edit translation and it will use the same form that is used for creating the entity. In this case, the node form that is new to Drupal 8 is used for creating the translation for the node.
Now what you may have noticed that is missing is translating property on these. For example, the node title wasn’t configurable to be translatable on the screen. The reason for that is we only have that half-done. So we are still working on making the node properties translatable and we may not get to making all the other properties. We will probably not get to making all the other properties translatable for menu items, taxonomy terms, and other things, but we are working on a solution that would allow us to have one or two contributed modules at most to cover the properties on those entities and we are still working on the node properties to be available in core. Now, Drupal 8 is not ready yet obviously so I think it’s totally fine that we are still working on this one. The other important note here is that the upgrade path from the previous translation system to this one will be in a contributed module because there are a lot of intricacies involved in how this is done. We need to have redirect from the old URLs to the new ones and possibly have them send you other interesting things so it’s not a very trivial thing and it needs support features essentially which we will not have opportunity to having core. However, we’ve added some more bells and whistles to this area especially around the core search and the search API that’s built into core. Both of them support language now. What that means is that all of these translations that are now stored under the entity are indexed as separate contents per search. So when you search, you will find each language version and if you filter it to a specific language then it will filter only to the variants of entities in that language. It’s also built into the API so if you use Apache filter or some other under contributed module to help you out with your search needs then it will get all the language information that we have for the entities and from the search operation itself and it will be able to use that. We’ve also extended the node access API to have language support so you can have different access control levels per language per node. This may have implications that we haven’t yet explored, but there are a lot of possibilities there especially for contrib. That was the Contents pillar.
In summary, we have node access API supported for language. We indexed in the core search all those translations as separate content. We have search API fully built up with language support which works for all content entities and I think this is the most important part - most important message is that this works for all content entities in core and it also works for all content entities in contrib in the future to come, and it has configurability per bundle which is the top text for entities and fields and field levels and we are still working on the property support for nodes and will likely need contributed modules for menu items and taxonomy terms to be able to translate the title of them and that the upgrade path is still being worked on for this. So then it’s very exciting because it provides a future-proof solution for translating data on entities and it works for all the contents in core.
Now, the final pillar is Configuration Translation which I’m also very excited about not unlike any of the other pillars. For this, I would like to give you a short summary of what configuration content is in Drupal 8. There may not be a correct answer to what’s configuration and what’s content. There is a lot of debate but how it’s implemented currently is that there are entities in Drupal 8 that are things that can have instances essentially and there are content entities that can have instances. Everything that I listed here are content entities, nodes, comments, contact messages, menu items, terms, even users and it’s a bit confusing that users are contents but implementation-wise, they use the same APIs and the same technology that all the other content entities do and they can take fields like nodes. There is also configuration which is a whole new subsystem in Drupal 8. There is a base general configuration system and it works for one-off situations like site information and user email text configuration, but it also has things that are itemized that can have instances, but use vocabularies, contact categories, fields, node types, menus themselves, et cetera. It’s all the configuration that you use to demonstrate or display content. It is essentially governed by the configuration system. Then there are other things like path aliases in core that are neither configuration nor content and we have language support for them in core, but generally we focus on the content and the configuration system because we have general solutions for the content and the configuration system. If you have custom in-house code or you built something for contributed module, I would very strongly suggest that you decide whether you want to make it a content entity or a configuration in some way and use the configuration API or the content entity API because if you don’t do this then you will not have any help for language support and the APIs so you will be all on your own and you’ll need to implement it for yourself and that can be painful. So, I would suggest to you to either embrace the configuration system or the content entity system for all your contributed needs and all your custom code for your clients if you need multilingual at all.
So this area for the configuration support is about the blue circle, the configuration system. It works for Views as well as your site name or user email text or your field configuration the same way. What we do there, as I’ve said before, is we track language in a very fine-grain way. So we track language on every configuration file. We know what the language of each view is. We know what the language of your site name and slogan is or what language your menu is associated with. So, we know language in a detailed way.
There is also a language override system so it can store configuration override in other languages than they’ve been originally created and this is stored with the configuration system so it’s very deployment-friendly and it works very similarly to how the rest of the configuration works. It just overrides four languages for each language that is possible to do. So let’s see an easy example for shipped configuration like this contact category that’s called Website Feedback. Everything is built into Drupal core so I can go and translate it. Let’s place a language selector block first so I can show you it actually works. So I place a language switcher block first here. So it’s available in English and Hungarian and I haven’t imported any translation in this system so when I switch to Hungarian it will still be English. However, the category is available for translation as part of your user interface because it’s shipped with Drupal core. So if I filter for website feedback, I can translate it to – in this case Hungarian, save that translation, and it saves back to the configuration system from here so when I go and reload the page, the category will be retitled. When I switch back to English, it will be English again.
So we know all the shipped configuration that’s available with Drupal core. We know those are in English, we start getting information so we can translate that from English to other languages, and there is a built-in feature for the user interface translation to integrate with that. It can translate any data, any configuration that’s shipped with Drupal core with the user interface translation.
So that is all text that should be available for translators on localize.drupal.org where I’ve been working on making those available for translators and localize.drupal.org because extracting that data from configuration is not the easiest part of our work for Drupal 8, but once that’s available for the translators, it will also be downloaded and imported to your site automatically and be available. So when you install Drupal 8, if you install a foreign language, once we work out the localize.drupal.org integration, all your views and your content types and your user will also input from it and all those things that are in the configuration system will be translated from the community automatically for you which I think is pretty powerful and very much unlike Drupal 7.
Now if you want to work with other types of configuration that’s not built-in, we built a module for that as well that provides you in-place translatability to - in this case go to a block, hit the Translate tab and translate the block title to something else or do the same for your site name and your slogan. You can go to your site information, have the site name and slogan in English, hit Translate, and you want to add Hungarian translation and you have a two-column translation all the way out here. You can enter your Hungarian translation - in this case, I picked Hungarian because I am Hungarian and then basically your site name, your slogan, and your block title will be available in Hungarian. So, it all works the same way. We built this module; it’s called the Config Translation module. It’s now available for Drupal 8 on Drupal.org. It’s called config_translation. We also would like to have this shipped with the Drupal 8 core. We are chasing ahead and trying to make it work. It sometimes breaks due to the changes in core and we are also fixing core bugs as we develop this module that we find. So it’s a lot of fun to do and it’s a very nice, intuitive experience. So you can translate your site name as a tab on your site name settings or you can translate the block as a tab on your block settings. The same works for Views and the same works for menus and all kinds of other things. It’s a very unified and integrated solution and it works very similarly on the UI and appears very similar to how the Content Translation system works as well.
So, this may or may not get into core at the end of this module. If it does not get into core then it will be available right away in contrib under the name config_translation.
So, the Configuration Translation pillar essentially has a full translation module that’s currently in contrib and maybe included in Drupal 8 core. We have standard translation paths there that work very much like content translation. This works with the configuration system overrides, that’s a built-in feature in Drupal core. It works for any configuration and there is a core UI for only your shipped configuration so you can translate your config categories, your shipped views, a number of things into the core UI.
So, that was the last pillar. So in summary, we have four great areas in Drupal 8 and I think we’ve improved tremendously in all four areas. We have a Language pillar which provides base services for all modules, and not just multilingual modules, it provides extended language assignments, much simplified language selection, very flexible configuration for defaults. I think it’s very powerful.
We have an Interface Translation pillar that now has updates from the community. It can track your custom translations now and can protect those, and it has improved usability on the front end as well.
We had a Content Translation pillar that’s now not only for nodes but for any kind of entity. It’s future-proof for content entities as well and it works with fields and is configurable in a very detailed way, and we have the Configuration Translation pillar which is again contrib-proof, future-proof, a funny thing that uses the Configuration Management API in Drupal 8 and it works with all different configuration system that’s in core. It has a core solution for translating shipped configuration and it may have a nice core solution as well for translating anything in a very usable way, but if not then we’ll have the module ready in time for Drupal 8 because we already have it almost ready.
So those are the Drupal 8 improvements in summary and if you found all these interesting, I would encourage you to get involved in this initiative. We have a lot of people but we need a lot more people. There are a lot of tasks. We have tasks on all levels. We have our own website on drupal8multilingual.org where we have news about this initiative. We have events posted. We have a page so you can see who’s working on things. We have videos about the initiative, what we do, how we do it, and we have a Twitter feed that’s available on Twitter.com/d8mi. If you want to be involved in translating Drupal 8 itself, it’s already available for translation on localize.drupal.org at least as far as the last offer really was available. We also have in-person possibilities to work together. There is a sprint in Chicago right now, so if you are around the area you may want to join them. That’s the website for that event, and there is also a sprint coming up on Prague. That’s at the end of September, and the day turned out wrong [Laughter]. It’s actually eight days or more, probably nine days. It’s actually nine days. There are two weekend days and then some sprints over Drupal Commons then two more weekend days as well. So there are a lot of places that you can get involved. There is also an article series that I am posting about this initiative that has even more details of the specific areas and that’s available in the News section on the Drupal8multilingual.org site as well.
If you want to get hands-on with this, I would really encourage you to try it yourselves. Since everything is built into Drupal 8 except the configuration translation module that I’ve shown, the easiest thing is to try out the configuration module itself. So we put a button on the project page. Try it out with Drupal 8. If you press that button, it will go to simplytest.me and that allows you to install a new Drupal 8 instance with this module from your browser so you don’t need to have anything on your computer to try this out and you can try out Drupal 8, a fresh copy of Drupal 8 with this module and see how it works and play around with that.
So, that’s it for me. I wanted to give a shout out again to everyone who’s been involved in this work. I think we did a lot of great things. We still have some ways to go but I think Drupal 8 will be redefining multilingual for Drupal. That’s it for this session. Thank you.
Hannah Corey: Thank you so much. We had a couple of questions come in and if anybody else has any other questions, please ask them in the Q&A tab. So the first question we had was, “Is Scottish Gaelic one of the supported languages?”
Gábor Hojtsy: I think it is. So, the criteria for getting in as a supported language is to have translations available from localize.drupal.org. If you have translations available on localize.drupal.org for Drupal then we can make it available in the installer. If you don’t then if we make that language in the installer available then you pick a language, then it will not work because you don’t actually have anything to download and translate Drupal to. So, that’s essentially the criteria. I can’t tell right now but you can see on localize.drupal.org.
Hannah Corey: A follow-up to that, where can they find the list of languages supported?
Gábor Hojtsy: Sure. So, the localize.drupal.org front page actually has a very nice summary of all the languages that we have teams for and it also has a page for asking for new teams to be submitted. If you look at the top menu, there is a link to ask to add even more teams, but we have over 100 languages on localize.drupal.org. Now I think it’s pretty extensive so it’s a very good chance that whatever language you are looking for will be there.
Hannah Corey: Awesome. The last question is will it be possible to have the actual file assets translatable as well, so have individual file attachments per language?
Gábor Hojtsy: Yes, absolutely. So I have in the – and I think the base configuration for the image field that I’ve shown that by default it's not configured to be translatable so the file will stay the same, but I’ve checked the suggestion from the base system. So I think the assumption there is if you want to have a gallery with – I don’t know - scenic pictures of nice things and that’s probably not something you want to translate, but if you want to have a field where the asset itself is translatable then you can make that field translatable for the file as well and then you can upload different files for different languages absolutely.
Hannah Corey: Great. Thanks. I think that’s it for questions. Thanks, everyone, for attending and thank you so much, Gábor, for that wonderful presentation. Oh, we might have another question come back in. Yes, we had one more question come back in. “Is the edit access mechanism plan for translatable fields?”
Gábor Hojtsy: Is it edit access mechanism? Yes. So we’ve been looking at how to restrict the access to the translation forms in the specific fields and what we ended up with is if - so what we displayed for the translation form are all the fields on the entity if you have access to accessing all the fields. If you only have access to translate the entity then you will not be shown all fields that are global to the whole entity because you could accidentally edit the original entity data, but if you have access to the whole entity to edit then you will see all the fields on the translation form. So we have this level of access. So the form API itself that the form is built with allows any contributed module to provide any further access restrictions on top of this, but that wouldn’t fit into how core modules permissions on user roles.
Hannah Corey: Alright, great. Thanks, everyone, so much and the slides and recording of the webinar would be posted in the next 48 hours. Gábor, do you want to end with anything?
Gábor Hojtsy: I’m looking forward to working with any of you if you’re available to help out. You can see we have a lot of fun. So getting involved now in Drupal 8 development I think is the best time because you can learn Drupal 8 is not changing that much anymore so you can learn a lot about Drupal 8 early and you will be the expert on Drupal 8 sooner than others. I think it’s the best time to get involved. We’re looking forward to working with some of you.
Hannah Corey: Awesome, thanks. Alright, everyone, have a great afternoon.
Gábor Hojtsy: Thank you.