 Hi, I guess we start now I am as a track chair at traction on site building. I'm excited to have Susan Kennedy here today Who will be speaking on multi lingual content in Drupal seven and eight? Susan has been a co-founder of evolving web in Canada and has plenty of experience with enterprise-level Drupal implementations She is also presented at numerous life web conferences on Drupal topics several Drupal topics including multi lingual content and At the moment. She is cooperating with aquia to set up the first full-day training on multi lingual and Well come her To speak on that topic today here. Thanks for the content management system So when we talk about making a multi lingual Drupal site one of the first things we have to think about is Translating content and some Drupal websites have so much content that it becomes a Really a really important thing to consider when you're setting up a multi lingual site That's what we'll be talking about today I guess Daniel already introduced me so I this is all covered if you're interested in our multi lingual training course You can find out more at evolving web.ca so today we'll be talking a little bit about multi lingual sites and What that means in Drupal and then we'll be focusing on Translating content and the new Translation method of field-level translation that's available in Drupal 7. That's really exciting on that scanning momentum to become really More a part of Drupal 8 and the standard way to translate content in Drupal We'll also be touching a bit on Translation workflows for content. There's a new module out for that called the translation management tool. That's really exciting and And I'll I'll be covering a bit about Which aspects of content translation are changing for Drupal 8 and what that means for you as a site builder so one of the reasons that multi-lingual features are so Difficult to deal with in Drupal is that every website seems to have a different set of multi-lingual requirements There's so many reasons these days to build a multi-lingual platform You might want to reach a wider audience or expand to new markets So you might be looking to add languages to your site for that reason you might be looking to improve usability for for multi-lingual users for search engine optimization if people are searching for For information in a different language, of course, they're not going to find your site unless your site's been translated and in some places there's government regulations or maybe a company policy that Forcing you to to translate your site. So sometimes it's not really the choice of the site builder So well, there's all kinds of reasons to make your site multi-lingual There's also a lot of resources that you're going to need to put together a multi-lingual project. So there's Translators user interface translators as well as content translators. You're gonna have to QA the site in in multiple languages and you might even need a translation manager to Manage all the translation workflows for the content that you set up That can be quite a bit of overhead And then you might be relying on resources like translations from localize.drupal.org or Machine translations from Google Translate to get your your content translated initially So just to understand a bit better the terminology before we get started Internationalization as a site builder is your responsibility. So you're enabling Translation and localization to take place. So you're separating out elements in the site like text date formats things like that that need to be localized so that Translators or site maintainers can come along and specify those for each language and Then localization includes translation of text, but it can also include things like translating currencies time zones Sometimes there's different legal requirements in different places. So the content needs to be different So before you get started, it's really important to understand What the requirements are how many languages you're adding to the site? Does the user interface need to be fully translated? Does the content need to be fully translated? Sometimes you have a different content set in each language and getting these Getting these requirements down is is really important. Another thing we'll talk about is untranslated content almost every multilingual site is going to have some Content that's untranslated and whether you show untranslated content in other languages or not can be a tricky issue But you need to figure out before you start building views and deciding What the language fallback should be So for it For cases where you have a multilingual audience users who speak more than one language that might impact your your choices there So that's a bit of an overview of what multilingual Site-building means, but what does that mean for us with Drupal? How does that translate into Drupal the Drupal world? So with Drupal you can build a foreign language site. You can install a language other than English When you're installing Drupal and you need the locale module to do that and your content and your user interface And things like menus you'll set up in in another language You can also have a multilingual site So a site where the user interface is in available in more than one language Where things like menus and blocks and things are are translated with the I-18n module and then The locale module also lets you choose a language for each piece of content. You're creating each each node you're creating So you can flag nodes in different languages But things got a little bit trickier when you introduce translation. So when you introduce content translation You are not just flagging nodes as being in a certain language and targeting them at users in that language. You're actually putting translations of content You're relating them together mapping them together in a set of translations So that when a user hits the language switcher They're switching from say the about us page in French to the about us page in English. So that ability to translate content is sort of an extra layer and we can we can do this with Drupal core using node level translation Just like in Drupal 6 And we can also do this using field level translation if you enable the if you install the contributed entity translation module and that choice of which method to use is is going to be a Main focus of the of this presentation So how many out there have used the entity translation module? Oh, wow. There's a lot of you. Okay Great so types of text in Drupal There's all kinds of of text in Drupal that needs to get translated user interface text and code user interface text that you specify as the site administrator site builder There's I-18 n-strings, which are things like blocks and menus There's variables that need to get translated like the site title And then there's content. So a lot of what you have to translate is is content And there's different translation interfaces for this in Drupal, which is part of what makes Multilingual websites seem so difficult, especially to site Administrators authors translators. There's all these ways of translating text and the really exciting thing about entity translation and Drupal 7 is that more and more things are falling into the category of content Because in Drupal 6 content just meant nodes But now in Drupal 7 content means nodes and taxonomy terms and users And if you're installing contributed modules that provide additional entities then those are content as well And we'll see with Drupal 8 Which things are entities and which things aren't I know there's still a lot of conversations going on about that But hopefully more and more things will be able to turn will be able to translate as entities So when you start off planning how content is going to get translated in your site One of the first things you need to think about is what kind of language experience you're building for your users Are you building a fully symmetric experience where everything is translated? This is a site I built for Travelocity and every single node had to get translated before it was published So we didn't have any untranslated fields or if we did it was a bug And then other sites you go to them and you switch the language and the whole structure of the content changes So you have a very asymmetric experience And along with this you have to think about untranslated content and whether that's going to show up or not And you need to remember that untranslated content Can be very valuable because some fields are kind of language independent So just because a node hasn't been translated it doesn't mean it's not valuable to the user if you're looking at a list of Comments or reviews and there's star ratings that users have given to a restaurant. It's useful to see that 20 users gave this restaurant a five-star rating even if you don't understand what their comment is so starting to think about content and whether it's Translatable whether it's language independent or language specific is a really important part of planning out your your multilingual content Other sites you want to hide untranslated content So that that can be a matter of the policy of your organization or politics or or whatnot So content translation methods There's two methods of translating content in Drupal 7 Which means extra work for site builders who have to make sense of this and decide which option to choose We have more options now than ever so building a multilingual site is even harder than in Drupal 6 in certain ways We have node level translation, which means that Every time you translate a piece of content or every time you translate a node You're creating a new node and those all live together in a translation set But they're separate nodes and then field level translation is When you have one node and you're just translating the fields on the node So there's a lot of shared properties or you can have shared fields on that node where Certain fields don't get translated, but there's only one node. So that's the main difference you have node level translation and field level translation So node level translation is provided by the content translation module You're creating a new node for each translation and you're mapping them together and They're all referring back to the original node that was translated. So they all have a translation node ID but you can see here that if I'm creating three nodes and The image is the same for each of those nodes if I'm creating three articles, let's say Then I have to upload the article the image three times and it saved three times in Drupal and that seems a little bit wasteful but those benefits to the system too because Because these nodes are independent you can set all the properties for them separately You can have menu systems that are asymmetric because you have nodes that You're setting the menu setting for each node individually rather than for one node that applies to all the translations You can also do things like content curation per language and node translation is sort of what Drupal Expects in a way. I mean, that's what everybody used in Drupal 6 so things like Built-in functionality like search is just gonna work you search for a node You're gonna find the node, you know in in the original language or in one of the other languages It'll return a node and it'll display the fields to you in in the language That the node is in There's also some features like there's a built-in flag saying that content the content needs to be Updated or the translation needs to be updated and that's built in with node level translation But there's also a lot of drawbacks because With node level translation everything is language specific like I said that image that's gonna be the same for all three nodes is Set to be language specific You can synchronize data between nodes if you use the synchronized translations module, but this still ends up You're still storing the data for each node And you can't synchronize everything with node level translation You can only synchronize fields and certain properties. You can't synchronize things like a user bookmarking a Node it's not built in you'd have to figure out a work around yourself And also node level translation only works for nodes So if you're adding another type of entity this method of translation isn't going to work So the UI for translating a node with node level translation it adds a translate tab You click add translation and it adds a new node And then you have all the the properties of the node are there when you're adding a translation You have the full UI for creating a node which means that you're setting all of these these properties are done So things like the author and the post-date those are all set individually for each Translation so menu settings published a all those properties that aren't That are attached to nodes that are often the same across languages So what's our alternative field level translation? Field level translation is actually provided by a module called entity translation so it can be a little confusing the terminology The field translation Mechanism itself is in core and the entity translation module gives us the UI for translating for translating fields So it feels level translation like I said you have one node and you select which fields are translatable So let's say I want the title and body to be translatable I can specify that those are the translatable things and everything else by default will be the same in all languages and That everything else applies to things like properties of nodes, which you can't translate using field level translation But it also applies to all kinds of other Features that you might add to a node when you think about building a Drupal site. It's more than just core Drupal There's all kinds of functionality that gets added to nodes nodes are kind of these these Dynamic things that we turn into events and groups and That we put in calendars and and so these are all kind of language independent features that You can't synchronize across translation. So if you have more than one node You have to figure out how to get your sign-up list to be synchronized across the French node and the English node if you have an event or something in Two languages it doesn't mean that there's two events It doesn't mean that you want users to sign up to two separate things You just want them to sign up to one thing and you just probably want to translate the title and description Maybe a couple other fields So there's a lot of benefits to field level translation Again, no need to sync properties. You only have one node ID to deal with and it works for all kinds of entities So I'm talking mostly about nodes here comparing it to node level translation But of course it also works for taxonomy turns users and other entities that you can add to your site There are some drawbacks, you know entity translation is new so things like core search unfortunately doesn't work with field level translation The core search is only going to display content in the original language of the node also things like revisions if you if you translate a node and you make changes to the Translation that those aren't going to show up in the list of revisions for the node There's a lot of built-in functionality that we take for granted as site builders that just isn't going to be there It's also a slightly different UI for translators to learn so that's something to take into account it's easy enough for us to figure it out, but for translators that can be difficult especially if you have these two methods living together on the same site And then there's some features of the IETNN module that are meant for node level translation like like node options choosing the the default language of nodes Multilingual select doesn't work things like that And you can't translate properties so everything is assumed to be the same across languages In Drupal 8 properties are supposed to be translatable There's work being done on that as we speak so that'll be kind of fixed for Drupal 8 But for Drupal 7 it's still something you have to consider so if you want to include Content in different menus depending on the language or if you want to include Different author depending on the language you can't do that with field level translation At least not usually So setting up field translation for a content type the great thing is that we can choose Which method we want to use per content type? We don't have to make a choice for our whole Drupal site Once you have chosen with that you want to use field level translation you go in and specify Which fields you want to make translatable so you you edit the field and it's just part of the settings To enable translation for the field Now like I said, you can't translate properties and the title of the node Happens to be a property and it also happens to be something like you'll definitely want to translate So you'll need if you're using entity translation. You'll need the title module To make the title into a field. So you're converting the title to a field so that it can be translatable So once you have translatable fields You're adding a translation just like you would for node level translation Except that you're not adding a new node when you hit trans add translation And the actual interface for adding a translation only gives you access to the translatable fields So all of those language independent fields and all the properties for the node like the menu settings That you're used to seeing at the bottom of the node creation page. Those are only editable on the original node So that's why the interface can be a little confusing for translators because they're not used to seeing this You know only the translatable fields UI So how do you choose field versus node level translation? You just want to go through a few examples So something like a session at a conference or an event has things like a date and time Location These are things that you want to be the same across nodes So these are fields that you could synchronize but with field translation It's nice because you just choose not to translate them things like an item in a carousel so for building a carousel you usually have an order that items appear in and you might be using something like node queue or Dragable views module to set up this ordering system and if you have a node for each language You probably want the order to be the same across languages But there's you know the the node queue only expects one node per item in the carousel So using field level translation for this is is really nice There are some things that there are some types of content where the Language-specific features are Really important like for a web form if you want to translate components You have to have separate components for each web form There is a web form localization module that you can use but if you're not using that you'll want your You'll want your web forms to use node level translation and be separate nodes so making this decision for your content types is part of the site building process and it's something that You know, it's it provides us a lot of opportunities as site builders, but as I mentioned it is a challenge and another important thing to consider When you're making this choice is the workflow that a node goes through so the lifecycle of a node I mean this is could just be a basic node node starts out in the CSB and you import it into the site and Then you someone comes along and publishes it and a user likes it and someone updates it And it is kind of a pain node level translation having to do this for Multiple nodes at each stage you're importing many nodes. You're publishing them So although many workflow modules expect Not not to use field level translation If you're building your own workflow, it's it's really nice just to be dealing with one node per piece of content on your site and This is kind of liberating Especially as we move forward and field level translation is better supported So I think field level translation is the best Data model for most use cases, but it might not always be practical. So because of the limitations things like Not not support nada. They're not being support for core search It might not be practical for you to to use this method for every site you're building that it is the future and and It's really exciting. I think So also it works for other types of entities so we've been talking mostly about nodes and content types and and things but it works for Users comments taxonomy terms and especially when we're talking about taxonomy terms I think this is a really great a method to use for translating them So when you're translating users for example that translate tab is there It's the same mechanism where you're setting up which fields should be translatable selecting those One thing to keep in mind is that there's only one permission for translating User entities in Drupal. So if you if you need to have users translating their own profiles This isn't gonna work because you can't give everybody access to edit everybody's User profile. It's probably not a good idea And also because of the UI being a little bit different than standard Drupal Users might find it kind of confusing But for translating taxonomy terms, I think it's a really great Model to use so you have a translate tab on each taxonomy term you can replace the taxonomy term name and description and make those fields again with the title module and There is only one permission, but that's probably something you can give to your site administrators And if you really want to you can translate comments. I don't know a lot of good use cases for this I was trying to come up with some Maybe maybe for machine translation. It makes sense, but it's it's something to consider And then of course you can translate other entities. So a lot of the modules that you probably use They provide entities and if an entity is fieldable If it has fields and if it has translation support in the hook entity info then Then you can translate it So things like the commerce product entity. I think this is fantastic for anyone who's tried to build a multilingual e-commerce Door before it. It's a real pain to try and figure out how to make products that are translated But that are only one product And a lot of people end up using workarounds like having one node and adding a Title field for all the other languages things like that. So it's really great that we can use Entity translation for this So all the all the views that the commerce modules providing really assumes that there's only one no one Product entity for each product in your store So things like the number of products left that you have in your inventory. That's only kept track of For each node. So if you're doing translations It can it can be really difficult to implement Using node level translation So content translation workflows I've had a lot of people ask me You know, I just downloaded Drupal and I made a multilingual site and None of the none of the site is translated. What's going on? People expect that Drupal is just gonna translate their site for them when they install a new language Which is which is you know? That would be nice Translation is really expensive, especially when you're adding a lot of languages I did a site with eight languages that had thousands of nodes and their translation budget was Had to be pretty high and they were definitely taking advantage of machine translation It also takes a long time sometimes to send a translation off to a translation service And translators sometimes aren't used to working with Tools like Drupal so it can be expensive to have to train translators To come in and translate all your content or your UI people think or I shouldn't say people some people think that Translation workflows should be really simple, you know You add a new node and then someone comes along and translate it translates it But as we saw earlier, you know the lifecycle of the node nodes get published and updated and and deleted and Every time a node gets updated, of course the translator has to come along and do an update as well so you can do a Translation workflow from scratch just setting up the permissions for your translators using rules to trigger emails when translations are required Creating views for translators, so they know what what's left what needs to be translated But there's limitations in Drupal for things like translation permissions And you have to give your translators permission to do a lot in order for them to effectively translate your site You can use the it and access module to give more granular permissions But it's still in depth for Drupal 7 and I'm not quite sure how stable it is yet So there's there's a lot of challenges to setting this up. So that's why the translation Management tool module the TM GMT module is so exciting because The module tries to address a lot of these issues with Content translation workflows and how it works is It's a it's a module you install in Drupal and then you can add plugins to Pull in translations from other services So Google and Bing are machine translation services There's also human translation services that it plugs into as well So you can you add these translators to your site? You usually have to sign up for an account So if you want Microsoft machine translation, you have to sign up for a Microsoft account And the same goes for the human translation services as well But once you've once you've set that up you can request Translation for any of your types of content So the translate tab is still there and you can use this with node level translation or field level translation And you can still add a translation right in Drupal that that UI is still there It's still working just the same way as before But you have this extra Action that you can do requesting a translation for the content And then you can choose which whichever translator you want to use so you can choose your machine translation service or the other service and Once the translation back in Drupal you can review it. You have this nice UI showing me the original content and the And the translation that was pulled in So if you're using machine translation as instant, I'm not sure how long the human translation services take but Once it's in Drupal you You have you have a message that appears and you can review the content before it gets published to the site So doesn't automatically get published you can set up workflows for Someone to review it in Drupal and you can also do translation in bulk so you can do it on the node level or you can actually Translate a set of nodes at once And this works for nodes it works for other entities too if you're using field level translation And there's work being done. I think to make it work for all other kinds of strings so other text groups in Drupal like Blocks and menus and whatnot So really exciting it's really easy to set up so I recommend giving it a try and If you want to use another translation service like translations calm or something you can write your own plug-in It's it's totally pluggable, so It gives you that It takes care a lot of a lot of the Drupal work for you And then it's just integrating it with other APIs, but that you would have to do oh And I wanted to do I think I have time to do a demo which I know they tell you you're not supposed to do in a Drupal con presentation, but It's gonna be short. So I have this node here in English Sir. Oh This is why they tell you not to do it, right? Okay, so I have this node in English ice machine in the Arctic and I hit translate and like I was saying I can add a translation. This is using field level translation here But I also have this nice Checkbox over here for oh great. I already I already translated this one. Okay Great not translated ice climbing in southern Ontario really fun extreme sport, okay So as you see there is no translation here. I Can request a translation and it's gonna take me to this UI that I was showing you before Where I can choose which translator I want to use and I think I want to use Google translator You know, you have to pay like a very minor amount It's worth it. This one works. So I'm gonna choose that and hit submit to translator And it's right back like instantly because it's Google translate, right? So and I only translated one sentence. So I can review my translations and then hit accept and The translation is gonna appear Yay, okay, there's special character in the title, but we can make a bug about it So there's still a lot of challenges for multilingual in Drupal 8 like I mentioned choosing translation method for content is something more to think about permissions for translators aren't ideal and Choosing which contributed modules you can use that are not gonna break your multilingual setup that can still be very challenging Translating custom elements. So things like web form. There's a web form localization module, but it's not perfect yet There's still a lot of a lot of things that Make make it difficult but but I think I Think the level translation is exciting and and makes up for a lot of these challenges So looking forward to Drupal 8 translation Translatable properties are hopefully gonna make it so that we can just use field level translation and node level translation won't be necessary Maybe more things with the entities so we'll have more things that we can translate with field level translation Hopefully we'll have a better UI for adding and configuring languages I know there's a lot of work already being done on that for the Drupal 8 multilingual initiative and If you want to know more about what's coming up Gabor is doing a core conversation tomorrow at 1 o'clock So you should come and find out what's going on with the code sprint to Contributed modules for entity translation that I just wanted to throw it there So if you're writing down a list of modules to try when you get home dot these ones down Entity translation fees allows you to import Import entities with translated fields and I mentioned that the entity Entity translation doesn't work with core search that if you're using search API you can try out the search API entity translation module It's still in development, but it might make it possible for you to add search to your for your field translated content There's a lot more coming up this week in terms of Multilingual sessions and buffs so tomorrow if you want to come and complain about all the problems You've been having with multi-lingual Drupal. We're gonna get together at 10 15 and do a bop and Hopefully get some answers to some of your questions if you have any after after the session today, there's a Multilingual Apache solar buff today at 5 p.m. So I guess coming up soon and Localized at Drupal.org buff for those of you not using Localization update yet for your multilingual site. You should come on out and learn about it or if you want to contribute translations to localize that Drupal.org Find out more about that There's a TM GMT buff on Thursday. That's the translation management tool module that I just demoed So if you want to come do some bug reports for the bugs that we uncovered in this demo Then come help out with that And then there's a multilingual code sprint for the Drupal 8 multilingual initiative That's going Friday to Sunday So if you want to contribute make field translation work better than coming out to that Well, so that's it. I didn't add you're supposed to fill out a survey So you should do that. Are you supposed to add a slide and if you have any questions? We have lots of time so Mm-hmm if you're using are you talking about no translation or oh, I see okay So he's asking if you are using Field level translation. Is it possible to have a default image? That the is set in the original language that a translator can override Not not currently not yes Okay Okay, yeah, so that's a good Okay, so if you're if you're displaying your content in a view With the entity translation module there's a setting for whether content uses the language fallback or not So if you have if you have it using the language fallback that means that if a field hasn't been translated But it'll it'll show up in the original language So if you're showing a list of articles and you want the image to show up in the original language If it hasn't been added for the translation, then you can do that. Does that sort of help? So you should you should always use views when you're displaying content in any form Yeah, yeah, that's true So we I always use image as this great example of something that is language neutral But of course if you have an alt text attached to the image that needs to get translated as well So the only way to deal with that is to add an extra field for your alt text That you can translate so that's a that's a nice workaround, but it's not It's not ideal Yeah, so menus you because because a menu setting is a property You can't translate it with field level translation in Drupal 7 so if you want to include a node in more in a Different menu or a different place in the menu for a different for each language Then you have to Then you have to use node level translation So if you are using field level translation and you add The node to a menu in the original language It's going to show up in all languages in that place the menu Yeah, and then if you're using menu translation you can translate the menu link because That's Translatable with the menu translation module just like if you're adding of you to your menu that is only in one language But you want though meant that you want the menu link itself to be translated So it works using the it and menu translation module Yeah, the body. Oh the pop is is translatable It's a special Yeah, it's there you can translate it for sure. That's yeah the URL of The of the node if you're using field level translation is translatable I think that that would be a huge reason not to use the module. It's very key. Yeah. Okay, so it's a question about the default language and You can change the default language in your site to be something other than English Yeah, yeah, so he's like so it's sometimes a problem is that you have users who speak a certain language like Portuguese or Brazilian Portuguese and you don't want the language fall back to the English. You want it to be Portuguese Because it's way more similar to Brazilian Portuguese than English. I don't Believe there's any plans Sorry Yeah, so the the the answer from flash Who's who wrote the entity translation module here? Is that you can you can it's extensible so you can code that yourself in Drupal 8? It's more much more flexible Oh also in Drupal 7 the whole detection and selection and language negotiation system in Drupal 7 Is a lot more flexible so Sorry, I'm having trouble hearing Yeah, so the I-89 module you still need to use it for translating menus and blocks and all those other things that aren't Yeah, you still you need to use that no matter whether you're using field level translation or node level translation I don't believe The question is about translation of When you're translating content What to do if the translator forgets to translate certain fields That and and if there's a way to treat them treat those treat that content differently in views when you're displaying it Is that correct? I'm not sure. I don't know. Does anyone know how to answer this question. I Don't know it sounds like it sounds like you know, you'd have to look at the specific case There's no there's not going to be flat there's Like adding a flag to a field Okay Well, there is a setting for whether The language fallback is used with entity translation. So but that's but that's just one Setting for the whole site. So it's a setting. It's a setting for whether You know if you if you have certain fields that aren't translated whether or not to show that content in the original language or not But that's I mean you could use that but it's not Probably, I mean, it's the one setting for the whole site. So you'd kind of have to make that decision Are there any other so the question is about translating strings and whether you can export Only strings for certain parts of Drupal like certain modules or things That's more a question about the user interface than about content. I guess So there's I mean you can create PO files for each You have PO files for each module that you can import from localize.drupal.org If you want to override those Then You know, it's gonna Sorry, I don't have it. I don't think I have a good answer Does that did anyone have another question over here or is that yeah? Yeah, well strings when you pass the string. Oh Yeah, sorry the question is about when you have strings in in your Drupal code and you're passing it through the t-function Sometimes in English the the string will be exactly the same but in another language because there's a different Context the translation will be different. So there is a Context That you can associate with a string, right? In the t-function Yeah Yeah, so there's if you look there should be documentation on that somewhere any other questions Yeah, okay. I don't know how to answer that question Yeah Okay, so just to summarize if you didn't hear that patch was just saying that a lot of the issues that I brought up as drawbacks and and also issues with views handling of Field translations are gonna be fixed in a new release So you should all go and download entity translation now and then in a month You should look back for the new release and see how much it's even it's even better That's really that's really exciting thing I think that's all the time we have so it's If anyone has more questions My company's booth evolving web is just out the door So I'll be hanging out there for a while and over the next couple days, too So feel free to come and ask more questions or come tomorrow at 1115 to the boss and Thanks so much for coming