 So welcome to Drupalcon. This is the multi-lingual module Madness, and if you're not in the right room, you know where the door is. So hi everyone, and hopefully you're having a lot of fun in wonderful LA. My name is Kristin, and I have been doing Drupal for a long time. April was my 11th anniversary, and I work at Hook 42, which is a Drupal shop in the Bay Area of California. Some contact information if you want to send any questions later. So before we start, I'd like to get an idea of who's in the room. So first off, who would here consider themselves a Drupal veteran? Maybe you've been doing Drupal for maybe at least five years-ish? Oh, alright. So of those, who have you have done multi-lingual before? Okay, why are you here? Maybe you'll catch something. Alright, who's a newbie? Oh, quite a few. Awesome. Who would consider themselves a site builder? More on the clicky click side? Alright, awesome. And who's on the theming side? Just a project manager. A few there. Who in the room actually speaks another language? Wow, awesome. Well, I'm American, so I speak American, and that's about it. And then who kind of does everything? Like you're in charge of the whole website, you do everything front to back and everything. Oh, a lot of you. Alright. Okay. So we're going to talk about a site that you've put together, and customers are super happy, and so you're just feeling great. And then all of a sudden they say they want Spanish. And I don't know if you noticed there, but there's a little bit of stuff going on. Alright, so if you've never done it before, and someone says they want multi-lingual, first off, you might think, oh, piece of cake. No big deal, right? It's Rupal, you just add a module, and it's all good. Or you might have heard that it's not so easy and be a little bit concerned. But that's okay. We're here to walk through how to deal with it, so don't get too freaked out. But unfortunately, it probably won't be simple. This talk is about Drupal 7. If you're going to be doing Drupal 8, multi-lingual, world of difference. If you're still on Drupal 6, which I have heard actually quite a few people in the halls talking about Drupal 6, most of what I talk about today still applies to Drupal 6. So, you know, 85% of it. So people wonder if they're going to add multi-lingual to the site, how long might that take? And it really just depends on the size of the site. So if you have a super simple site, maybe it's going to take you a day or two to just, you know, throw some stuff together, assuming you know what modules and all that. If you have something more, you know, complex, it could take months. So we've had projects adding multi-lingual and, you know, literally took two, three months in order to get everything in place that was just really the multi-lingual part of it. So part of the multi-lingual madness is, okay, well, what modules do we use? And unfortunately, it really depends on your site. So there are some standard ones that pretty much all sites will use for multi-lingual, but then a lot of it also depends on your functionality. So first off, you need to go off and find these modules. If you haven't gone to this session or looked up some tutorial or whatever. And if you go to Drupal.org, there's a module page for looking up modules, and you can go and choose that, decide what sort of version you're running and that sort of thing. So I did this talk two years ago at Drupal Comp Portland, and, you know, I did the search there, I did a screenshot, and then I revisited it just a few days ago, and it's kind of gotten crazy. So at Drupal Comp Portland, there were about 105 modules marked multi-lingual. Now, two years later, we've got more than 180 marked multi-lingual. So it can be a little bit daunting. Here are some of the more popular ones and sized roughly based on popularity. So we'll talk about the more popular ones in this little bucket. So first we're going to talk about the anatomy of a Drupal site so that we can try to pull pieces apart and figure out how we're going to do our translations. And in this case, we're looking at a very, very simple site. This is a Stanford site, I didn't build a site, but it just seemed like it was nice and simple and pretty typical. I actually gave this talk first at a Stanford camp, so stuck with that. So, you know, it's got all the typical things, logo, menus, blocks, nodes, you know, just your typical Drupal site, right? So those are the types of things that you have to deal with, you know, views, and if you're using panels or, you know, God forbid you're using field collection, that kind of stuff, then, you know, these are the types of things that you're going to run into. So the important thing when you're doing multi-lingual in Drupal 7, particularly also in Drupal 8, but is you need to really understand your site and where content's coming from and you have to chunk things out. So the way that the multi-lingual modules work is they tend to be focused around three different buckets. We have a UI bucket, a content bucket, and a config bucket. And I'm going to go into each of these buckets and kind of what modules apply to each of them. In reality, that config bucket should be, you know, way bigger than all the other ones because that's kind of the dumping ground of everything that's not UI and content. So first we're going to talk about the UI bucket. And most people know what a UI is, but when we're talking about UI and multi-lingual, it's a very specific thing. So in this case, we're talking about text or sometimes called strings coming from modules and themes. It might be coming from core or contributed or community modules. It might be coming from your own custom modules or themes. So what happens is when you're writing code and if you're aware of how multi-lingual works in Drupal, what you're going to do is you're going to wrap your text with a T function. T stands for translate. And what that does is it makes your text available to the translation system. So if you don't wrap your text when you're writing a module or theme or any of that stuff and you have text that you're going to show in the UI somewhere, if you don't wrap that text with a T function, then Drupal doesn't know it exists in terms of being able to translate it. So that's very important and we find that when we are called in to do multi-lingual work, this is a very common issue that people didn't wrap their stuff in T functions. So you just kind of have to get in the habit of doing that. So as far as where that shows up on your Drupal site, here's a very simple example of a user login page and the title, the tabs, the text on the labels and the descriptions and the buttons. Those are all typical UI text in terms of Drupal and those things are going to have T functions in the code and then therefore we can go in and translate it later. So as far as how you translate that kind of text, it's done a certain way. You're given a translation page. It's pretty simple. It's not too exciting. The main thing with this is it's case sensitive and that's very, very, very important to remember because if you type in the wrong case, it's not going to find it. It has to be exact. So best thing is really copy paste, copy paste exactly in or even you could do a sub string of it and that's okay. You don't have to have the full string. But then it will show you what's been translated, what hasn't been, you can go in and edit it and it's very simple. As far as the modules involved, there's the locale module, which is Drupal core and that is the one that you enable in order to add different languages. There's a localization update module, which makes life much, much easier and what that one does is you enable that and the system, your site will go to localize.drupal.org, which is another website and it's going to say, oh, I have Spanish and French on my site. Can you go and get me any strings that are available for my website in those languages? So if you have the views module installed, it'll know that you have that and it's going to go, oh, I'm going to go find the strings for the views UI and pull those over in those languages. So that's super handy. You can also configure it if you want to pull things over weekly, monthly, that kind of thing. Localization Client is a handy module that is great for if you're doing on-site translation and you have a person who does that so they would go to a specific page on the website and there's strings on the page and it's just a little bar at the bottom and it'll show the text on that page that needs to be translated and they can just do it right there. So it's a nice little in-place contextual editor. So instead of having to go to this general place and search for stuff and not knowing what's going on, then it'll show up. Kavya on that is if you have like an error message or something like that it's not going to show up unless it's actually on the page. So it'll only show you things to translate that are actually showing up on the page. String Overrides is a great module. It is not specific to multilingual but it supports multilingual. So if you ever wanted to change certain text on your Drupal site where you have a login but you want to call it sign-in then you can use the String Overrides module even if you're not using multilingual. So it's great because sometimes clients want things named a certain way and maybe you're not a coder, you don't know how to go in and add that to your settings file or whatever. So String Overrides is a great module for that. And just for reference I have my own domain where I have a whole laundry list of these modules that you can go grab them from too. Okay, so that was the UI bucket. Sure. So that was the UI bucket. So we've got the UI bucket, the content bucket, and the config bucket. So next we're going to go over and these slides will be available. We're going to go over the content bucket. Now this one is a lot more interesting because in previous versions of Drupal translation was done one way. In Drupal 8 translation is done one way. It's different but it's done one way. In Drupal 7 you can do things two ways. And this has caused a lot of confusion. And so really Drupal 7 is the most confusing version of Drupal to do multilingual for. So that's why you have some madness. All right. So what is content in Drupal 7? In Drupal 6 we had nodes and whatever. We didn't have entities. In Drupal 7 they introduced entities and so all of a sudden this kind of idea of content exploded. And you can actually think of users as content which is a little bit odd. You probably wouldn't translate users. Maybe you'd translate their profiles. Probably not. So here are some things including custom entities like commerce where we're going to be able to translate these things. And taxonomy terms has a little star next to it because it's kind of a weird fish. You can translate it in this way that I'm going to talk about which is content. But you can also translate it in a different way which is really lumped more in the config bucket. And it depends on what works for you and how are you using taxonomy. So we'll talk a little bit about that. All right. So this is a very typical Drupal page, node page, not very exciting. There's a title, an image, and a body. Can't get much simpler than that. So how do you translate something like that? Once you have the right modules installed it's pretty simple. You'll have a tab on your page. You click on it's going to show all the languages that you have enabled. Whether you've already made the translation or not you can add the translation edit. So it's pretty simple. Once you're actually editing the translation you can actually see the language on the page. In this case it's German. So it's got the language selector. It'll select it for you because you've said I want to add a translation for whichever language. So the tricky bit is to know which module to use especially for node when you're translating nodes. So before we talk about nodes, if you're translating other entities, comments, users, if you wanted to do that for some reason, you can do this for taxonomy terms, that sort of thing, you're going to use the field translation modules which we'll talk about. But if you're doing nodes and you want to translate that content which is going to be most of what you want to translate as far as content, we have these two buckets or two methods of being able to translate and this is where the confusion arises. So I'll talk a little bit about these two different methods. The first one is called node translation or content translation. And this is the way it was done in Drupal 6 and before. So this has been the way it's been done since Drupal 4. Pretty standard way, it's core translation, you don't need any extra modules for this and you have your source node, you decide to translate it, it makes copies. So okay, now in this case, I've got a German source node, I translate it, I've got a Polish one and I've got an English one and in the little one by itself, I haven't translated that in the source language as English. So that's the idea, if you want to translate something, you end up making a copy of it. So the alternative is called field translation and that is different. You have one node and then you decide which of the fields you want to translate. So in this case, it starts off as a German source node and then we decide, okay, we want to translate the title and we want to translate the body. But in this case, we're not going to translate the photo and the reason why is it doesn't have any text on it, so we don't need to translate it. You can if you want or you can translate just the alt text or that sort of thing. So it's very flexible what you choose to translate. Okay, so for node translation, we've got the core module which is called content translation and the other one that you really should have with it is called synchronized translations and when I have the i18n in parentheses, that is a whole suite of modules called internationalization and it comes with, I don't know, like 20 different modules, it's crazy just by itself. So it's a whole package. So whenever you see i18n in parentheses, I mean you're downloading that project, that whole package and then there's a bunch of modules in there and you're going to enable the right one. So in this case, we've got synchronized translations there. So what that one does is if you decide there are some fields you do not want to translate, you configure synchronized translations to say, okay, that image field, I don't want to translate between my different nodes. So you have my different nodes but I'm going to synchronize this particular field in the image or whatever, tagging or something like that. So for field translation, we have the entity translation module and that one is actually, for the newbies, you'll hear this term contrived module. It's a community module. It means that someone decided to spend their time outside and contribute back to the community and we call it contrived or community module. So the entity translation one was interesting because they wanted to get entity translation into core but it didn't make the cutoff for Drupal 7. So it's kind of a weird module where a lot of core people actually work on it but it's not officially core. It is the basis of what's going on in Drupal 8, that type of method. So for field translation, you use entity translation and a very strange thing is you have to use a module called title which is very odd that you have to use another module and what is this module? So the title module, what it does is because in Drupal 7, titles are not fields. There's two things for entities, you've got fields and you've got properties. So titles are actually a property and because of that, if you do entity translation by itself, you cannot actually translate the title which is kind of crazy. So someone decided, okay, we're going to have a title module and that module will basically make a title field and it's going to keep that property, the title property in the title field synced up and then hide things so that you're only seeing one and whatever. It's doing a little magic behind the scenes but as a result, you get to be able to translate your titles using the entity translation module. You actually have to go to the content type for every single one you want to replace the title for. So if you have five content types, you're going to, you know, do each one of those, do the managed fields, say replace title and then it's going to, it'll go and do some magic for you. Okay, so I've got these two different ways of doing things. Which one should I use, right? I mean, I don't know. Why are there two and why would you use one versus the other? And there are lots of reasons why you might choose one versus the other. You know, you might have some compelling reason that you want your nodes to be separate. For example, the flag module. Maybe you actually want to flag, for some reason, individual languages rather than the whole, you know, the whole node itself, right, that whole concept of the page that you might want to do that or maybe you really want them all together. So there are reasons for choosing one versus another. One of the most compelling reasons, and I'm going to quote someone on here. I just found this quote last week which I thought was pretty good. This is Caitlin Fogarty. She's at AQUIA and she wrote this article a couple years ago. She said, we decided to initially go with entity translation but for AQUIA.com but we decided to migrate to node translation because of issues with several contrib modules. We are actually now using a mix of node translation and entity translation. And as of two years ago, this was spot on because what would happen would be you try entity translation, you realize it didn't work with something and you abandoned it and then you would do node translation. So this was very, very typical as of two years ago. What I have found is actually there have been a lot of bug fixes and a lot of stuff going on and so you can actually use entity translation and not use node translation probably now. So do a lot of testing, test on your local, but you need to try it out and it really just depends on what other modules you're using. So that's the content buckets. We did UI bucket, the content bucket. So now we're going to talk about the config bucket, which is kind of crazy because it's anything that's not what I just talked about. So it's not the text strings and it's not the entities. But there's a lot in Truple, right? There's menus and URLs and panels and variables and there's all sorts of stuff going on, right? So anything that is not field collections, anything that's not those things, we consider the config bucket. So a very typical thing is to have a view, right? Almost every site's going to have use views and here's a very simple one. It's got just a simple grid, it's got the image and the title. Coming from the nodes, pretty simple. So this is one example where it's a config thing. We're going to use a special module just to be able to make this multilingual. So if you install the module, then you all of a sudden have this option when you're editing your views, different language options. You can choose to have it show up in a specific language or whatever language they've chosen to navigate the site in. There's another part of views which is interesting because there's actually, you have to be able to maybe translate the title of the view, right? Which is that's done, that's not the content coming in, that's actually done through the configuration when you're creating the view. That's the site builder's job to do. So you actually have to do kind of two different things. So for translating that, like if you want to translate the title, you'll end up with a translate link in your contextual menu. And then you'll have your languages like for other places and you can go in and translate that and change your title, more text and some other things. So that's just one of the various things that you'll have to deal with when you're dealing with config translation. So here are some of the modules you can use when you're doing config translation. Transliteration is one that you can use even if you're not doing multilingual and it's highly recommended because if you upload a file, right, and you've got someone who likes to use spaces in their filename, they like to use punctuation in their filename for whatever reason, what it'll do is you upload a file, it's going to take that text of the filename and it's going to sanitize it and decide, okay, replace the spaces with dashes, let's get rid of the punctuation, let's make everything lowercase, nice and clean. So you definitely want to use a transliteration module even if you're not doing multilingual. Now, most of these other modules come with the I18N package, so you'll see them noted as such. So if you want to translate menus, use the menu translation module. If you want to do the contact, you have the contact form from core and you want to make that multilingual, so it's pretty self-explanatory when you go and you grab that package and have all this laundry list of modules in there, you know, a lot of it's pretty straightforward. Some of them not as straightforward, so like variable translation module. Modules in general will save settings to something called the variable table and it has, you know, they can put whatever they want in there. So for example, if you go to the site information page on your site, you'll have like a site slogan and I don't know, some things like that, like the home page, right, and that kind of thing. So if you wanted to be able to translate any of those, those are actually stored in the variable table. So you would go and you would use the variable translation module and then you'd go to your site information page and all of a sudden you have some tabs and you can go in and translate and say, okay, for French, we're going to do this home page and for, you know, German, we're going to do this home page. So that's, you know, not so straightforward why use it, but the last one on the list is internationalization views. That used to be part of this big package of internationalization and they split it out because they wanted to be able to track the versions of that module with the views module, so they split it out so that they didn't have to tie it in with the versioning of the other modules. And this is just a short, very, very short list of things that you might need. If you're doing panels and you decide you want to add text within the panel, which I don't recommend, but there are modules to help you, you know, deal with that. So, or if you're doing, yeah, field collection. Anyway, so the list goes on. So another part of translation is just managing that whole process, right? So you're going to need someone that's actually doing translations and you might have someone in-house or third-party or whatever, but you need to be able to manage all that stuff that's going on. So I have a few modules here, which are for more on the admin side of things. Administration language is a great module. It's a little, not buggy, sort of what happens is it's a caching issue. If you use the admin menu module, which gives you that little bar on the top, which I always install, and you've got the nested dropdowns, which is awesome. The problem is if you're using admin language, you can set and say, okay, for me, I always want to see stuff in English when I'm editing the site, because I don't know any other language. So you can say, okay, set the admin language to English, which is great. The problem is it's with the admin menu, sometimes you'll go and you'll navigate and you're trying to look and see what it looks like, and then it remembers some of the things in the menu and you'll see a mixture of languages and stuff. So I did look at the issue queue. There did seem like there might be a patch, or there's certainly talking about it, so maybe it'll get fixed. Translation table is kind of a shortcut to go in and edit a few things like menus and taxonomy terms. So it's just kind of a different interface to be able to do that. And that is a bit simpler. Translation overview is an overview of what has been translated. So you go to a page and it's just this big grid. If you have a few languages, I think it's handy. If you've got 30 languages, you're not going to be able to see what's going on, because it's just basically a big grid and it shows for each language if something's been translated or not. And translation management tool is more of a workflow tool, and it also lets you plug into other third-party systems. So that is a more sophisticated thing if you want to be able to have different translators. Maybe they're only allowed to translate certain types of content, or maybe certain languages, and you want to be able to send content out to a third-party and then get it back again, and it helps you deal with that whole workflow. So here are some of the third-party modules for dealing with translation. And so we've got... So the translation management tool, the way that works is they're basically plugins or some modules that you can add on in order to take advantage of different third-party vendors. Then there are some standalone modules provided by Lingotech, Cloudwords, and Smartling, and those are all translation companies. And so if you wanted to use those services, then you could go and download their modules and be able to work with them. The Lingotech guys are here if you want to go talk to... They have really nice shirts, actually, if you want to go talk to them. And then there's a Smartling guy who's walking around, but I don't think has a booth. So there are more, right? There's 180 modules, so I'll just... I'll note a few extra, which are kind of interesting, domain access. If you have a site that has different domains, so you have foobar.fr and foobar.de and so forth, then you can use the domain access module to be able to deal with that. There was a buff yesterday and someone was like, ah, don't use it, don't use it. It's too complex or whatever. So he actually recommended something which I haven't tried called context access, which was to not be confused with access context. So anyway, so there's another one which you might want to try out if you're having that situation where you have the different domains per language. Multilink module is pretty cool and highly recommended as an editor tool or to dealing with the content editing experience. So what happens is if you have content in five languages and then you go and you add English of something and you want to link off to something else or maybe you add the English and then you're doing the German and you want to link off to an article but it hasn't been translated yet. You're like, well, it's German, but I don't know what to do because I want to point off to an article that's still in English. It's going to be translated at some point. What do I do? I go to the source one, English, and once the translation's available, it's just going to show up. Now when you edit it, you're pointing to the original node, but as you're viewing it, then it's going to run it through a filter and it's going to show you the most appropriate link available. So that one's really great. I actually wrote a blog post recently about that one. I think it is just a great tool for being able to search for different content on your site. That is not a multilingual specific module, but what it does is if you're searching for content, then it'll grab the node, the node slash number for you and that's important because you want to use those in your content rather than some hard-coded path alias that might change or that sort of thing. Language icons I have up here only because it's super popular, but I have a star next to it because it kind of doesn't make sense to me because English is not British. There are lots of countries that speak English, so the idea of having a flag next to a specific language doesn't make a lot of sense to me, but it's super popular, so I put that up there. The switcher dropdown is just a little handy thing if you have got 10 languages, you're not going to want to have a block that's out of the box and core, it just puts a bunch of links for the language switcher and if you want to put them in a dropdown, that's super handy. The last couple are more configuration sort of things for dealing with path auto and also if you're using Apache Solar. Our company does a lot of multilingual stuff. Here's a recent example of a company that is going to launch soon. They've been working on multilingual for over a year along with all their other stuff and in the end, they're about to launch, they're using 22 community or contrib multilingual modules. They wrote three custom modules to deal with multilingual because they're actually pulling content from other feeds and things and they're using four patches. Sometimes to make multilingual work, you have to go out and find patches. Four patches, actually amazingly small. Two years ago, I was on another project, we probably had 25 patches that were for multilingual. That's why I'm saying, it's definitely getting a lot cleaner. We've had Drupal 7 for a long time now. Just a rundown of the kind of modules they're using for their project. Lots of the translation management tool stuff, so there's a variety of those. They're using just entity translation. Now we've come to the point where you probably can do it. You probably can't just use entity translation instead of having to use the core. The advantage of that, too, is going to Drupal 8, that's the model. You have one node, so you might as well try to think that way going forward. What's going on in Drupal 8? Probably some of you have heard there's a Drupal 8 multilingual initiative that's going on for a few years now. The idea was to, instead of just bolt on multilingual, which is what's happened in the past, to really do it from the ground up. Things are just, everything is language aware. If you add a new module, it's just everything is built in to understand language. A lot of great things. Amy, who's in the back here, she's going to be doing a bof on Drupal 8 at room 410 right after this. It's actually a two-part, but you're welcome to come to both or either. Every Wednesday we have an IRC meeting. If you want to help contribute and make things better, you don't have to know how to code. You don't need to know PHP anything. You can help out, if you know another language, a lot of you did, you can help out with translations. If you want to test stuff, you can help out with that, see if a patch works. There's very easy ways to do that where you don't have to install anything on your own system. You click a button, simply test me, there's also a site that's dedicated just to Drupal 8 Multilingual, and that has, you can actually go and find novice issues and find specific things that need to happen that are based on your skill level, so maybe you just want to do some testing. You've got an hour and you want to go help out, so it's a great site. Some other resources, they'll be in the slides. IRC channel I mentioned, there's a translations group if you can help translate things. I actually wrote a book on multilingual Drupal 7, that's available, actually I didn't put it up there, and some various sites. So the main thing for Drupal 7 Multilingual is have patience, don't give up, and help out if you can. So at that point, we've got a bit of time, I'll open up for questions, and they ask that you go to the mic, because this is being recorded. The mic's in the mail-in room. Hi. I actually have two questions. Not to take up too much time, but have you done any testing on the amount of bloat any of the modules have added? Bloat? You said? Yeah, because I've noticed, especially the I-18 one, it's just so big of things. So that's an awesome question. In general, just adding more modules, period, no matter what, you want to try not to do it if you can. You just want to keep the number of modules as lean as possible. The more you add, just the more overhead, the slower things are going to become. It's just the way it is. One interesting thing we talked about yesterday at the that they're doing revisioning and in terms of bloat, it was interesting because they had so many revisions and they couldn't delete the revisions because it was tied to multilingual. So, if you're going to be editing and editing and editing and saving all those revisions and you've got hundreds or thousands of revisions for one node, you can imagine that, yeah, you might get some bloat. So, I mean, typically, if you're just using the regular stuff, it's going to be a big deal. If you're worried about it, then I would go, if you're able to use the entity translation instead of node translation, just because then you've got less nodes, right? So, if you've got a million nodes and you need to translate them, try entity translation because otherwise you're going to have, you know, if you've got five languages, you're going to have five million nodes, right? So, definitely, it's a consideration. It's more the techniques you're going to use in order to do your translation, I think. Okay, yeah, and not take up more time, but for some of the sites that I've done multilingual, my pre-process pages are just like crazy long. Do you have any recommendation for organizing them? Can you elaborate on what you mean by pre-process page? Yeah, maybe this isn't the best to talk about it, but when I need to do... I haven't used the title translation module that you were looking at. I normally do most of that in a HTML or pre-process function. Okay, like in your template.php file? Yeah. Okay, got it. Yeah... I mean, I personally would go with the title module even though it's another module, but at least it's tidy, it's understood, so people try to make sure it works and whatever. If there's a known solution, I try to go the Drupal way and whatever, but if you have to go custom, sometimes you do. To be honest, I haven't had to do a lot of pre-process stuff for most of mine. I mean, it depends on your theme, right? If you're interjecting a bunch of things into your page in a dynamic way and you need to pull in dynamic content based on language, then obviously I'm more of a back-end person than a front-end person. But, yeah, I haven't seen a lot of issues with having to pre-process a bunch of multilingual stuff, but we can talk after more detail. Hi. Is it possible to have a specific field in a node just hidden completely in a certain language site, or just have an entire node hidden completely if it's not relevant for that language site? So you want to hide specific language so if you have a node, certain fields on it, or the entire node itself. Yeah. And is there a special module to do that with? Right. Well, you just want to hide them. I mean, you can unpublish them. You can unpublish in a special module. Yeah, so what you could do is you could use entity translation, and then you can choose to the status, you know, so the published status. You can make that translatable, and then you can, yeah, just unpublish the things that you don't. I mean, if it's a whole node, if it's specific fields, I don't know if, like, field permissions works with multilingual. My guess is probably not. I don't think you, yeah, you could do it that way. I would probably just write some little bit of custom code to do that. That might be a good preprocess use right there. Like, if it's an optional field, and then you translate it, but you just delete the string from the field, then it may just stop. Oh, well, if it's empty, yeah, you can have it so it doesn't show up, because it's empty. Okay. Yeah, maybe that's a simple solution. Yeah. Thanks. Okay. So have you, do you have any recommendations on the best way of having the languages be chosen, whether it's like a different path, or an HTTP header, or sub-domain? Yeah, I mean... How that affects the different... Yeah, so the language detection is obviously a big choice you need to make when you're doing a multilingual site. And you have a variety of options. You can go by it based on the URL. You can go based on the domain. You can go based on the browser, language, you know, whatever they chose. You could add a cookie. You know, there's all these different things. The tried and true and the most popular is to go with either the domain or the path prefix where you have foobar.com slash en slash fr. You know, that is the most popular method. And I think it's the least confusing because if you're coming in and your browser is set for English, but you decide you want to go look at French, like you don't have that option, right? If it's a browser detection one, you're like, oh, I want to look at the French. And you're like, whoa, I can't even do it, right? So I typically always go with URL detection as my, you know, the method of language detection. And with the modules that you were mentioning for are there particular gotchas with that method in terms of rewriting? No, I think they've ironed out all the bugs for that. It used to be that there were some issues with path auto because of the prefix being there or not, but that suspend ironed out a long time ago. So you should be safe. Hi. What recommendations do you have when you translate interface because, well, two years ago translation wasn't that it has some bugs and, well, one time I had to develop well, I had to make a fix on a website that has two languages, English and Spanish. But I think that they did wrong in some stuff and when I was going to translate interface, there were some strings that were in Spanish, but it believes, but Drupal believed that those strings were English and expecting to translate it in Spanish. So Oh, you know what? You may have touched on something which really deserves its own slide. Beware of the default language of the site. Okay, there's something called a default language of the site. So if you install in English, install in Spanish, whatever, once you set that default language, never, ever, ever, ever change that and you may, the symptoms sound interesting because it sounds like maybe that default language got changed at some point, like you had translated some stuff and then someone decided to switch that default language because what happens is if you have a default language of English you translate some stuff to Spanish and at some point you're like, why is my default English? I'm going to change it to Spanish. It thinks those original English strings that you translated are now Spanish but they're not, right? It's just going with the default. It's like, okay, whatever was there first, I'm going to tie it with the default language. So that sounds a little bit like maybe what was going on but it's hard to say for sure. Okay, thanks. Hey, thanks, Christine. Great talk. And I had a couple of questions that are already being addressed. However, I have one that has not. When I was looking at the summary of this talk that you have a link in there to a Google Drive doc where you specify sprints related to the multilingual and in the columns you say that in the days, like to sprints after and before Drupal console, like on Monday and Friday. And I see something happening today and tomorrow but it's all tagged as maybe. Is there any update? People that want to help sprint this week? Yes. On Friday is probably the best day to help out. There will be sprints this weekend but a lot of people are probably taking off. But if you're going to be around Friday and volunteering, there will be a whole bunch of mentors so they can help you do the sprint. So you go in and if you're first time doing it, there's going to be a room dedicated to that, you go in, you'll learn the ropes, you'll make sure you have whatever tools that you need installed if you want to do stuff locally or they'll show you how to simply test me, which is super simple. And then once you graduate from that, if you want to go out and do some sprinting, you can do some sprinting and other sprints if you're interested in front-end, twigs, stuff, whatever. So that's a great day to come and help out is on Friday. Great. One last thing. What was the website that had DrupalA resources? It was DrupalAMigration.com or what was the name thing? There we go. DrupalAMultilingual.org. It's a great site. We're over at UCSF. We have a pretty intricate system, but part of it is that we're using domain access. Ah, yeah. Just dozens of sites growing very fast, but just a few of them want multilingual and I'm wondering if it's overkill to consider some of this for that situation and maybe we should just create the nodes that are translated manually or something. So you have only some content that needs to be translated in some languages. Yeah, currently right now just one site. One site. And it's one domain? Or you want to go to multiple? It's currently a domain access situation where... You have several. Yeah. Well, I would be interested in seeing... I hadn't heard about this context access module because we did have this discussion yesterday in the kind of multilingual therapy bof and yeah, that could be an option. It was much more of that toted as like a lighter weight simple solution if you just want to keep things simple. So... So are you saying instead of domain access? Instead of domain access. I mean you're already using domain access though, so why throw in another module at that point? I guess the question I'm asking is... Are there any guidelines as far as when you should not use these modules or throw this direction? It's kind of tested and see if anything breaks. That's pretty much multilingual. It's a little bit of a cowboy-cowgirl kind of attitude of like, okay, try this module. Click, click, click, click. Okay, it looks like the site's all working. Okay, I'm safe. All right, now things break less now. If you're using field collections, watch out. But most other things, I mean panels is better. Any translation's better. Everything's just better. So it's been years, right? Drupal 7's been out for a long time. We're getting lots of patches and stuff. So it's pretty safe to do most things. Domain access is kind of its own beast. It's got a whole bunch of sub modules you can use with that. We know people that are using it. We have it on one client's using it. You could do it. I'll try it next week. Sounds good. Hi, Kristen. Thank you for your presentation. One thing I wanted to mention is besides multilingual, you might want to think when you go down that path, you'll get multicultural too. Because we ran into this one where everything's fine and handy. It's just that you can't use a person's name unless you know them and you're familiar. Of course that's them Americans. Hey, I like it to say welcome. Right. And actually something we brought up yesterday in the bof was beware of idioms whenever you're writing. You want to try to avoid idioms if you can. Or even just some of it's hard because there'll be a word. If we say we're going on vacation and in England it's like what are you talking about? It's holiday. That's a very simple example of you think they would understand we're talking about but they might not. I wanted to ask about in D8 how much of it is done and are we still going to be reliant on tons of modules even though a lot of stuff is going to be baked into D8 are we still going to? No, it's a great question. If you are able to come to the D8 bof right after this in room 410 and Amy is going to give you the whole demo of the whole thing but just a little bit of the thunder she's going to do a bunch of stuff core only no contrib modules four modules. It's a world of difference something that would take as you saw 22 or more modules in D7 you can do with four. Definitely a good thing to come and see. I think we're good any other questions? One more? All right. Come on down. You're the next contestant. This is a ridiculously simple question but I'm wondering what are the best practices in terms of URL construction for different languages? We've been playing around with subdomains or using .fr slash fr is there a better way to do it? That's a great question and in the past there was actually an SEO benefit from having your own domain in that particular language .fr.de that's not so much the case anymore and it's often kind of expensive and also just a bit messy to have to deal with all these different domains the typical method is you're just going to have your domain slash fr sometimes people use the en but that's not that if that's your source language that's common. Is there a problem with duplicate content from an SEO standpoint though? Having multiple pages which share many of the same elements but maybe just vary a little bit. It's going to know that it's a different site and as long as the language is set in the headers basically you have the meta area and if you view source you'll see that there's actually a language that's set so Google knows they won't ding you as long as you have a tag. Just check your tags and make sure they're showing up properly and you should be good. I think that's it and we're on time five minutes early, awesome. Thank you very much and I'd appreciate it even if you have negative feedback come and fill out the evaluation because this is useful for the Drupal Association to know how things are going what things can be improved and I do get to read them but they're anonymized so I don't know what you're saying so say whatever you like and have a great DrupalCon.