 So, this is our session, Multilingual in Drupal 8, featuring visit the USA.com and Habitat.org. My name is Jay. I've worked with Media Current for the last eight years or so. My title is currently Director of Development, and you can follow me at Drupal Ninja on Twitter. This is my co-worker, Dan. Hi, I'm Dan. I've been doing Drupal for about eight years, and I got to work on Habitat.org, including the multilingual setup there. Awesome. Thanks, Dan. Just a little bit about Media Current. Media Current helps organizations build highly impactful, elegantly designed Drupal websites that achieve the strategic results they need. Okay, let's talk through today's outline. We tried to keep it pretty close to the original outline that we submitted for this session. Now, we'll be showing you a lot of annotated screen grabs just in the interest of time, and most of our examples are, of course, coming from visit the USA and Habitat. Many of you might be like me and Dan. Maybe you've done multilingual in Drupal, but either you don't do it all the time, or maybe you just haven't done it yet in Drupal 8. It had been a while since I had done a big translation like this, so it really felt like I was doing it from scratch. I think Dan and me, both around the same time, were working with our respective projects and talking with each other about different things. Our goal today is to hopefully save you a lot of time just walking through everything step-by-step. When we were working on this project originally, there wasn't a ton of comprehensive information out there, so I hope this really helps get you going. The great news about this is that you can do all of this setup without any coding knowledge required. It is a lot to take in and understand, but you can be a site builder and get it working. Please, if you have a burning question, you're confused about something, raise your hand, shout it out. You can wait till the Q&A if you want to, but I don't want anybody leaving here confused about anything, so please don't hesitate, raise your hand, or just come talk to us later. First, let's talk about the modules we're going to need to configure a multilingual Drupal site. So here we'll talk about the core modules you're going to need to enable to get going. You're pretty much going to need just about every multilingual core module enabled. So there's four main modules here. Configuration, translation. This allows you to configure things like blocks, menus, et cetera. Content, translation. This lets you translate nodes, taxonomy terms. Interface translation. We'll walk you through how to use this tool later. This lets you translate all of the hard-coded text you might have around the site. And then language, the language module allows you to add new languages. So notice, I didn't mention any contrib dependencies. The great thing in Drupal 8 is that you don't need a ton of contrib modules like you did in the past. And so this is awesome news. We got everything in core that we need. Okay, let's talk about setting up languages. We'll see this page a lot. First, go to slash admin slash configure. You're probably familiar with that page. There's this little section called regional and language. And we'll be walking through several of these items today. And so the first one is languages. By default, you will have English enabled or whichever language you install the site with. But you can add any kind of language you want. Now, many of the languages do have language packs. And they include things for interface translations for many of the core and contrib modules. And that's great if that's important for you. In our experience with our clients, the admin interface translation is more or less a non-issue just because a lot of the administrators are using the English interface. So the language pack piece isn't as relevant for us, but it could be different for you. Okay, so going to the configure languages page. It's not visible on this screen, but you can add your own custom languages. And this can be useful. This was useful for us on VisitUSA because we had our own language prefixes that were used on the old site course site. And so we were able to map it one to one. It made things less confusing. So that's an option. Okay. And now I'm going to hand it off to Dan to talk about translating fields. All right. So in Drupal, there's always been this question of whether you're translating your content at the entity or node level or at the field level. And going back to Drupal 6, it was always at the entity level. And what this meant was you would have, let's say you had a Spanish content and some English content, you would have a node for each. And they would each have an NID. And that worked out okay. But then in Drupal 7, they introduced entity translation, which made things a little bit easier because you were able to have a single node with multiple translations. And then you could translate each field individually. So each field would have its own content per translation. And this is the way that's been kind of driven forward in Drupal 8. And I think this is really good because it's, you know, very simply it's easier to manage fewer nodes than it is to manage, you know, a ton of different nodes, you know, one per language. It gets kind of unwieldy, especially when you might have incoming entity or node references. So most of this tutorial is going to go over how to configure translation at the field level. So the first, you know, step when you're trying to figure out how to structure your site for translation is you have to decide which content types you want to translate. In Habitat for Humanity, these were our country landing pages. So the first thing you want to do is edit your content type. And you'll see in the language settings, you'll see there's an enable translation checkbox. This is the one you want. It's pretty well labeled. Those other ones in there are there to confuse you a little bit, but if you're doing entity or field level translation, you don't need to worry about them because they'll be overridden, you know, just because you set the enable translation checkbox. So once you have a translatable content type, you can create a node of that content type. In our case, you know, Mexico is a good example of this. There's a country landing page that had different content depending on the language context that was detected. So, you know, you'll create the node. You'll fill in, you know, any default values. It won't be of much use until you have translatable fields, which we'll see in a minute. And then you'll have access to this translate tab, which is, you know, a sibling of the view and, you know, edit and all those revisions. And this is kind of, you know, mission control for a single node, really entity. It's the same across all entity types as you'll see. And you'll see which translations have been created, which, you know, are yet to be created. And this is where you can add those translations and populate the fields. Which brings us to, you know, the kind of the meat of this, which is how do you configure the fields for translation since we are doing translation at the field level rather than by using duplicate nodes. So this, again, was made pretty simple to figure out, I think, since it's all in core, that's really been great. You know, all this stuff is pretty well documented and, you know, evident, really. So to make a field translatable, you simply edit the field and click the users may translate this field. There's no trickery here. That's pretty much all you need to do. And what this will do is this will make it so that when you have some content that has this field, so in our case, you know, country node, you can enter a value for this field per language. So, you know, again, it's one node, one node ID, but multiple values for every field that you've indicated you want to be translatable. There's another way to look at all of this. You can go to the configuration screen in the region and language section and the one I've highlighted. And that gives you a really nice kind of bird's-eye view of all the translation settings for your pull sites, so for all entity types. At the top, you can choose which entity types you want to have translatable. And at the bottom, you have each entity type and then each bundle of that entity type to say what fields within that you want to make translatable. So, again, all of this interface exists kind of segmented in other places, but here's a nice way you can, you know, do it all at once. It's kind of big and ugly, but you can click a lot of things and get a lot done in one fell swoop, as it were. So, you know, we saw a pretty simple example of a field that you probably want to translate. You know, it was a WYSIWYG field, long text formatted as Drupal calls it, but Drupal has a lot of other field types and some of them are more, you know, a little bit trickier and, you know, when you're thinking about translation. So, you know, we encountered these and scratched our heads a little bit during our projects and, you know, we'll kind of share some of the insights that we gained. So, one of the, like modern sites rely on paragraphs a lot. So, just to give a quick synopsis of what that is, paragraphs is a contrib module that basically, instead of, you know, making the content on your nose and articles and other things be just a big WYSIWYG field with lots of strange markup and short codes and whatnot, you can have your content on nose or any entity be defined by paragraph references. And these, this makes it more structured. You can say, okay, here's a text paragraph, an image paragraph and, you know, any kind of paragraph. They're basically just entities with a, you know, like field collections with a set of fields that you can define. So, how does this, how do they, you know, what comes into play when you try to translate them? Well, it says don't translate. What that means is you don't want to translate the field referencing them. So, the field on your node referencing the paragraphs, you don't want to translate that. And it will remind you that you can't also, so that's helpful. Which, of course, begs the question of how do you translate paragraphs? The key there is that you can make the paragraph entity type translatable, just like you did with nodes. So, this is, you know, illustrating the great part about entity translation is that it's, you know, any entity it works for and in core, you know, the entity UIs are much better standardized than they were in Drupal 7, certainly Drupal 6. So, this is, you know, made pretty standard across all the entity types. So, once you translate the paragraph fields, you'll be able to translate your paragraph content nodes. Taxonomy field references is another kind of interesting one. You certainly can translate them, but, you know, to think about kind of what this implies when you have multiple translations with different taxonomy references, it makes filtering by those tags kind of tricky because you'll have, you know, you won't be sure, you know, what piece of content you're dealing with when you're filtering. And it's far simpler to leave the taxonomy reference field untranslated. But again, like paragraphs, you can actually make the taxonomy term entity itself translatable. So, that way, you know, the use case for that is like if you want to display the name of the term on the node, you don't translate the term reference field, you translate the term, and then language negotiation and language detection will take care of everything else for you. Images, this is probably a yes in terms of translation. Definitely the alt text on an image, you want to be translatable, assuming it's something that, you know, visitors coming in multiple languages might be seeing. Make the alt text translatable because that's important for SEO and accessibility, of course. And then, you know, kind of the more discretionary issues, the file itself, the field translation supports translating the file. And what that amounts to is you provide a different file for different languages. It works the same way as text in a WYSIWYG. And this, you know, there's certainly use cases for this. You know, if your node has like, you know, covering some kind of protest and you have one sign in Spanish, one sign in English, that might be, you know, useful for that. Otherwise, you know, you might be fine with a single image across all translations. Another one is node references or any entity reference. And this is very similar to taxonomy term references because those, the taxonomy term references derive from the entity reference field now. So, in short, you probably don't want to translate the field itself, but you do want to translate whatever's being targeted by that field. In this case, it looks like a node. And now I'm going to hand it off to Jay to talk about the translation interface. All right, thank you, Dan. Okay, so we're back at the regional language area, the configuration page. And now we're going to go to the user interface translation page. This is going to be similar. If you've used this in the past, it's pretty similar. Basically, this is like a search and replace kind of action. So, think about all the button text, all the other miscellaneous text strings you have in template files and things like that. This usually is text you want translated. So, as long as you use the translate function in Drupal, a.k.a. the t function, Drupal will know how to keep track of those strings and they will show up here. There are a couple of gotchas that we'll talk you through in a bit. Assuming your default language is English, you're going to be searching for all of your English text and then you'll need to fill in the translated copy into this interface. Now, what we did on visit is we were able to export everything, send over the files to a translation partner and import those back in in bulk. The import and export files that Drupal generates are human readable, so it's easy enough to work with. So, once we did that, it was easy enough for editors to just use this interface for any one-off strings that they needed to translate. So, any questions on this? Okay, let's look at menus. So, if you remember the page Dan showed you a minute ago where you could see all of your content configuration in one place, there's a little checkbox there for menu links. Then you'll need to check, save that. Once you do that, when you edit your menu links, you're going to see this translate tab and just like on your other content. So, that's pretty easy. Okay, we're getting the hang of this. What about translating taxonomy? Same kind of deal. Go back to the content configuration screen, turn on taxonomy terms, select whatever fields that you want translated and now you have a translate tab. So, that's so fun and easy. Okay, we're on a roll. Let's talk about how to configure language negotiation. So, we're back at the languages screen. This is where we added our languages earlier. So, if you're having trouble remembering where all of these pages are, remember you can access them all from that one area of the configuration page. So, earlier we didn't talk about the detection and selection tab at the top of this page, so let's do that now. This is going to give you a bunch of options on how to determine which language to render to the user. Now, I'll admit that I'm not an expert on all of these options. What I do know is that one of the more popular options that you probably need to know about is the URL detection method. And there's actually two sub-options that we'll want to talk about. So, click configure on your URL and it takes you to this page. So, two options, which unfortunately are mutually exclusive. The prefix option that you see on the left is the easier option. That's my preferred option. This is where you simply have a prefix in the URL that tells you which language to render. All of your links are going to add this prefix for you and so as the user clicks around, unless you mess something up, they'll see the right language, page to page. And usually the way you get to this page initially is by maybe selecting it from the language drop-down. Now, the second option is what we have on visit the USA. It's a little bit trickier. It's there on the right. So, on visit they have top-level domains for almost all of their languages. So, the first disadvantage to this is that it means you're going to have to log into each site to edit a translation. That's kind of a hassle. The URLs do look a little bit nicer and I guess there's maybe a little bit less risk that you could accidentally get to the wrong language that could happen with the prefix. So, the biggest problem is just that it adds more work for editors. Now, if you did subdomains, you could have a shared session across all of your subdomains but we actually had separate top-level domains for almost every geo. So, that's just something to think about. And we actually override this setting locally so that locally we use the prefix thing just to make things easy. So, there's your options there. Okay, now I'm going to hand it back to Dan to talk about a few gotchas. So, by and large the translation functionality that we used worked really well in both of the sites. I think this is really a function of it being baked into core now and it benefits from all the testing that's in core. So, core tests can't really pass if language stuff is broken. Whereas before it was on contrib modules and it was kind of very ad hoc. But nevertheless, there's definitely some tricks to it and hopefully we can save you guys some time by going over that. And just real briefly, we're going to be looking at views. Making sure that it filters correctly. Some tricks with the translation interface and also the path auto and translating that. So, language detection works pretty well in views but it's not quite as smart as the rest of the site. You know, if you go to a page it engages the language negotiation and detection and you instantly know what language things are supposed to be. Views, you have to actually tell it a specific filter to use and you tell it to filter by the language. And the one you want to choose is the content language selected for the page and that just means whatever the language detectors have decided is the correct language. Which should be the same as the interface language that everyone will also work. And by the way, so that will work for search API as well. So if you have a view that's, you know, doing a solar search, you can use that to pipe the correct language into your solar search results, which is nice. The next thing that we had to kind of puzzle over a little bit was making sure that the translation interface, you know, the place where you can enter in the strings that represent the translations. Making sure that that gets fully populated with any, you know, any place in your code, especially custom code, where you've written the t function. Because Drupal's not smart enough to, you know, look through all of your code and see where, you know, every place where something's been passed through the t function, which is what constitutes the interface text. So the trick here is it helps to actually crawl your site to make sure that everything gets loaded into here. That's, you know, probably the surefire way of doing it as long as you, you know, take a little time to write a little recursive crawling tool or something like that. I think WGet might have some useful options for that. But however you end up doing it, make sure that you've actually gone to each page so that the database gets populated. And then you'll be able to use this to enter the string that you want to use for whichever translation. And the last thing to watch out for is the path auto settings. So this is, if you're using it, like a common use case here is you take the node title and whatever that is, you kind of process that and turn it into the slug for the URL. And the only trick here is that you just have to keep in mind that if it's a non-ASCII language, it will be, you know, transliterated into ASCII characters and then piped into path auto and then it'll use that as the URL. So that's probably the functionality that you would want, just something to keep in mind. And Jay's going to tell us a little bit about Lingotech. Thanks, Dan. So the last thing we're going to cover before Q&A are TMSs. A TMS is a translation management system. Lingotech is well known in the Drupal community because they're very involved, but there are other providers as well. So I'll just be covering a couple of examples just so you can get an idea of what it looks like in case you decide to use a translation partner. For a visit, we used a company called SDL, and they're a pretty big company. And so they are leveraging a contributed module called Translation Management Tool. And that module also depends on some other modules. You don't really need to know so much about what it's doing, just that many TMS providers will give you what they call a connector module that uses this contributed module. And the smaller module is just basically the glue between the TMS and the TMT module. So the big benefit for us as users is that it means quite often the interface you have is pretty consistent provider to provider. At Media Current, we've worked with several different partners and it's just nice when there's consistency there because they're leveraging the same tool. So I only have a couple of screen graphs to show you real quick. Most of your translation modules are going to have some concept of like a cart, kind of like a shopping cart. Translations, they go into a cart. You send them over. That creates a job. And then there's lots of reporting around statuses and things like that. So you might have to wait because there's a human element to it. Then you receive the translations back and you're able to review them and then import them into Drupal. And the workflow is pretty easy to work with. So, Lingotech. Lingotech is also another option. What I like about them is they have, so we have an internal demo that will show the prospects and we use a little Lingotech module connector. And it's nice because you can get a developer account and you can configure it and it'll do a machine language translation. And it's pretty fast and easy and it sends it back. It's good for demonstration, right? If you're trying to show this is how TMS works. So Lingotech is good for that. Now it's interesting about Lingotech. I haven't talked to them about this. I'm sure there's some reason. They don't use the same contrib module as some other TMSs use. I'm sure there's some valid reason for that. But the workflow is pretty similar. So same kind of thing. You request translations, create jobs, download them, et cetera. Pretty easy. Yeah. And so that covers about 90% or so what we had to do on Visit the USA in Habitat. So I hope that's helpful for you. And I think that sums up the tutorial part of the presentation. So we'll open up the floor for questions. And if you've got somewhere else to go, feel free. Can you talk a little bit about language fallback in group plate? What happens when you go to content? Isn't translated into your current language? Right. I think what's typical as far as fallback languages, it's usually going to fall back to your default language, which is often English. And so that will happen. Usually it's like some kind of logic error somewhere. Why that's happening? Oh, I forgot to add a filter or whatever. Why is English showing up here? And so then it's basically a bug to fix. Right. So that's a good point. So the comment was sometimes you don't have that content available. So in that case, same kind of thing. It's just going to render your default language. I guess you could add some additional logic around it if you didn't want that to happen. But for the sites that we do, they pretty much want the entire page translated. OK. So I don't know if you guys may not use it anymore, but we used to rely heavily on the path logic module back in the Drupal 7 days. And we used it again in a Drupal 8 site. And we noticed that it was actually having a lot of issues with regards to internal paths when we were trying to go from Spanish back to English. Is that something you guys had to deal with with either of the sites you showed or just any in the past? That's a good question. I haven't run into that myself. And I haven't even used the path logic because I don't know that they have a stable Drupal 8 module path logic. I don't think they do. I think they may have a dev module. We might be using the dev version. I'm not sure. Right. So the problem being when you need to switch back and forth between languages. Yeah, sometimes we'll have a Spanish node that has a link in the content that links back to another English page that may be somewhere related. On purpose, it's trying to link from Spanish to English. OK. Yeah, I just haven't run into that issue myself. I don't know, Dan, if you've run into that. Because with us, it's pretty much they're using the dropdown or whatever coming in from Search Engine. So they're pretty much wanting to stay on the same site with Visit. I think if you pass it through the API URL forming functions, it will decide if the URL exists that you're trying to go to. And if it does, and that's good, and if it doesn't, it will go to the fallback. But if you try to link to a translation that doesn't exist, just put in the wrong prefix if you haven't translated, it will 404 at that point. OK. Yeah, this was just something one of my developers wanted me to ask. OK. I mean, it might be, I guess, it could be a bug in Pathologic if Pathologic's not enough. It's not aware enough of... We didn't use that. Right. We may not actually need it. We'll go back and re-evaluate. But figure it out. Thank you. Yeah, that's a good question. Yeah. Thanks for the session. I'm from East Africa, like in a small country called Rwanda. And then like every time that you list the languages, you will not find Kenya Rwanda. I mean, the language that you're using. Maybe it may be beyond like this session, but can you please tell us like a little bit on the process of adding that language and translating the strings, like not necessarily like the content you're putting in. Because sometimes it's awkward, like you have the content that you have translated. But when there is an error, it comes in English till the user doesn't know what to do. I guess I understand part of the question. I don't know. So I know adding a custom language that isn't there, that isn't available. So you don't have the language packs. But you can add, it's kind of arbitrary in some sense. You can add, as long as the valid prefix or whatever, you can add your own custom language. It's just, it's not going to have the language pack stuff. So it won't have the interface translations. But I'm not sure I understood the rest of the... Yes. You answering part of it, but I'm doing it for myself. But if I want to contribute, so that other person comes and finds it there. You want to contribute a language? Yeah. Translation? You can do it for yourself, but if someone also comes, I can find Kinya Randa. I was asking the process to make available that core content. Is it like contributing back translations? Yeah. Yeah. There's definitely a Drupal initiative to basically cover the interface translations in every language. I forget what the name of that project is. But it's localizing Drupal. So there's, and I think if you search for it, there's a way to, a concerted effort to do that. Yeah. I'll get it for you. Yeah, sure. Yeah, I'm sure we can find that. Hi. I work on a team of about 10 content developers maintaining a site of nearly 12,000 nodes. And we localized some of them into about 10 to 12 target languages. So a bug I noticed maybe about a month ago, two days before we launched our Drupal site, actually, was whenever I added a new paragraph type to a node that had been translated into another language and added English content to it, it was showing up in English on the other nodes, on the translated nodes. Okay, yeah. I realize this is probably a special case and fault of our configuration or something like that. So I was curious if you had ever encountered an issue like that, because we have a lot of different paragraph types to like leave each other like notes saying like this content is reused in this place. Please don't add a link or something like that. Yeah, I think I could see how that would happen. If you, I think the key is you, if you added in the English translation, because the thing with paragraphs is tricky, because every translation references the same set of paragraphs. So as soon as you do that, it'll appear in all the other translations. I think the key is you just have to translate it there. Did you try that? We have a localization vendor that we do periodic exports and re-imports of the translated content so it's not like automatic or very quick. Well, yeah, so that's the issue. It's that there's a delay. So if the page, if the page is unpublished, then it's not an issue, but a lot of times the page is published and then you need to add a paragraph. But as soon as you add a new paragraph, it's, and you just add English, then that it's gonna show up. I wonder, it's not really a bug, it's just kind of an unfortunate feature. Like I don't know if content moderation helps you with that, if you could save it as a draft and send it through to your partner or whatever. So, because ideally, if you could save the English as a draft, it's not yet ready to publish, then send it off, whether it's using one of these connector modules or they just have a login and they translate it however your process is, then that might be a way around it. I don't know how well the, yet the whole content moderation workflow works well with translation. Yeah, that's something we're setting up and it's a help site for a software company that's doing continuous delivery releases, but unfortunately, we're not on continuous delivery for localization yet, so we have to publish content that won't be localized for a few more months. So we've just told people to edit the existing paragraphs. Right. I mean, the other thing is you could try to work around the problem as far as adding additional logic somewhere that says don't show it if it's in a different language or something, I don't know. I'm sure there's some way to, with a code fix or something, work around the issue, but it is kind of unfortunate just the way it works. And someday, I think the paragraphs module will support actually translating that field reference so you can have a different set of paragraphs per node, or yeah, per node. So, you know, I haven't checked on that in a few months. I think it's on the roadmap, definitely, because it really should, because it is a, it's a problem, because you don't want all of your translations sharing the same paragraphs, because what if you wanted to have an extra paragraph? Right. So. Okay, so another work around with the issue, and we actually set it up on visit, we added an extra language field to the paragraph so that they could, it's kind of a work around. I don't know if it's a perfect architecture or not, but we added a language field on some paragraphs so that they could specify that this paragraph only shows up, and so we had to add a little bit of logic around it, so we check it in a conditional, say, well, if the language matches the detected language and show it, if not, don't show it, and so that's another way to work around the issue, so you could have, let's say it's a hero slider that's using, that's powered by a paragraph, you could have one that only shows for English, you know, only one that shows for Spanish or whatever, and then in your kind of a situation, you could initially set it only for English until it's translated, and then you either, you know, add more languages to that or just unset it so that it, again, applies. That's another kind of a work around, you know, that kind of issue. Cool, thank you. Okay, yeah. Kind of following on from that last question, do you know if it's possible to configure the fallbacks so that you can say, if there is no content in my language, just don't display it, don't give me English, just give me nothing, and then even to go a step deeper, is it possible to configure the order of fallbacks so that if a user says, I prefer Spanish but I also know French, that they can, they'll get content in Spanish, and then if there is no Spanish, go to the French, and then, like, is there how much granularity is for those? That's a good question, as far as fallbacks, because I know on the detection page you have fallbacks and things for the detection, but then as far as, like, setting language, you know, a certain language order, I don't know if that's possible or not. I don't know if you've seen that. Yeah, maybe a custom language detection plug-in that kind of looks at, you know, lots of user-specified two preferences, and then it would be a custom plug-in, though, I think, but it would be similar to the one that exists if you would just, you know, ask for multiple languages. Give it an array instead of just a single? Yeah. Thank you. Yeah, I mean, that problem makes sense. I haven't run into that, but yeah, I could see. Hi, how are you? I wonder if you had any experience with a domain module and the languages using them together, and specifically the problem, for example, if you have, say, for example, you know, a European site with, you know, 10 subdomains for each country, you know, each country, like a Spain, for example, you'd run it off SP.you know, some example.com, and then you want that to default to a Spanish language with the possibility of having it also in English, right? So that's the problem. How would you, you know, if you have any ideas on how to use both domain and language at the same time, given the tools that Drupal offers? So question is, we aren't using the domain module, so I don't have a great answer for that, unfortunately. I've only briefly looked at it before I know some other guys at Media Current have used it. Yeah, Habitat didn't use it either. So are you wondering about language fallback as well, or just not? Yeah, I think it's the same problem, sort of, but it's per subdomain, right? Probably with multi-site, you could probably solve it and, you know, you just use the default, you know, the default language. Right. Yeah, okay. Yeah. All right. Okay, sorry. Sorry. Yeah, unfortunately, we haven't run into every problem. These are good questions. Hi, I apologize if this is a question that was already asked. Yeah, no problem. That was a bit late, but I've been having an issue with, it concerns the paragraph module, we'll familiar with that, and the fact that it doesn't translate, you have a content type, and then you have a paragraph type that, you know, has five of the subsets of it, but the main parts of that content type can't be translated because you're using the paragraph module. Does that make sense, or is that something you're running through? Yeah, that is something we've covered. I think that's probably a very common thing. We have mentioned it a couple of times, so you can't translate the paragraph as a whole, the field at least, you can translate the fields on the paragraph, and like Dan was mentioning earlier, there is an effort to make the whole thing translatable like some other entities like taxonomy field. You can translate the actual field reference, but then paragraphs right now, you can't do that, so it's just kind of a limitation, but you can kind of work around it. It's got a few quirks to it as we've discussed, but you're kind of just working around it, so. Thank you. Okay. When you selected the languages at the beginning, if a language is not listed there, are you just not able to use it? Does it have to go back to like when he was talking about doing the translations? Right. So like Uzbek and Kuali are not there. Right, so you can add a custom language. There is a little bit of validation that they put in there that I found. You can't just put like FUBAR as the language code. There is a little bit of caveat. There's like a Wikipedia page that tells you all the valid codes, but as long as it's like a valid language code, you can add your own custom language, and it's kind of arbitrary in the sense of it's a prefix, and that prefix maps to whatever the label of the language is, and you're good to go. It's just like any other language. The only thing you don't have, of course, is all the language packs that are associated with that language that come in core. So if that's important to you, then you might want to start translating your own interface strings or whatever, but a lot of times that's not necessarily a big deal. So it's just a key value pair, basically, is all it is. Okay, thank you. Yeah. For that custom field for paragraph, you're using to hide the content. Is that something custom or it's available as a country? There's a language field type. I can't remember if that just comes. I can't remember if that was a contrib module or not. Is there a language field? Yeah, does that come with one of the language modules, maybe? But yeah, so we added, it's just called a language field. It's not custom or anything. It's a field that's available, either core or whatever. And we just added that to our paragraph type as a workaround so that we could say, this hero paragraph for a slide or whatever, we only wanted to show up for English. And that's, again, that's the workaround where we can kind of have the best of both worlds by default. All of our hero slides show up for every language. Each field is translated, of course, but we do have the option where they could specify one or two for only specific geos. And it's a decent workaround. Now, it just doesn't happen magically. So you have the field, you capture that. And then in a conditional somewhere, maybe it's in your little twig template, you say if language whatever matches up, then show it, else hide it, works pretty well. You would do it in twig in a template. Yeah, just in twig. So you're just looking at that field value. And if it is true, then show it. I mean, it's a pretty easy workaround. I think it's not a bad solution. Another question. If you use Lingatech, for example, they switch in your workflow with translation nodes to their workflow, right? So you cannot go and add translation and manage it there. You have to go through Lingatech. Is it possible to have both? I guess I'm not exactly following the question as far as Lingatech. Let me show you where you translate in the node, right? You can add the translation and edit it there. You physically go in and copy and paste in the translation, right? In Lingatech, it's disabled. That part is not available. You can manage it only through Lingatech. Okay, yeah. I actually didn't even realize that they... So you're saying that they limit you from translating your own content. I guess if the module is configured. Yeah, that would seem like... That doesn't seem right. It seems like you should, from the translate tab, be able to just click edit on specific translation. You're saying if you want to manually translate a node. I mean, that would seem like not great because you wouldn't necessarily want to send every single piece of content through Lingatech if you've got your own translators for some stuff. Or some of it's just not relevant to send to a translation partner. In Lingatech, when it's end up in Lingatech, they usually grab in the piece of content between tags. So it's not one text. It's pieces of it. And if you want to remove or rewrite the whole page. Right. You cannot do that. I guess I don't know if it's just a limitation. One more. You showed us that you have a country type and you have different pages, landing pages you called it for different countries. How do you set it up in Drupal 8? In Drupal 7, I figured it out, but Drupal 8, I cannot see it. So which part have you figured? You switch into language and it displays a home page but specific for the country. So the detection? Yeah, so the pages that we did that way weren't the home pages. It wouldn't have been at the root of the site. The country language pages had their landing pages, had their own URLs that were just for landing pages for that country. And you do it through redirect or there is something. In ITN Drupal 7, there is something like that. You go to site information and you can change it for different languages. Oh, change, yes. We did have to do this. And if I remember there was, so you're talking about different paths to be the home page per language. Right. Okay, yeah. You can do it, but if I remember, there wasn't a UI for it. But what you get into there is translating configuration. And it seemed weird to me because it seemed like there should have been a UI for that. Again, we've been said that it's now everything in ITN in the core, but that piece is missing. Right. So I guess you're talking about maybe special kind of pages. I have a panel pages. Right, panel pages. And we should have brought that up, actually. So that's one of the reasons why I lean towards everything being like a node type. So our home pages on Visio USA are node types. We have a node type called home page, and it makes that kind of a non-issue. All of our landing pages are node pages. And you just translated them, right? Yeah, and so they translate into normal workflow. So that's the downside if you do use panels which are kind of a special thing. They're not a node, right? They're the special thing. And so having had issues with panels in the password translation, when we started this project, I kind of avoided it knowing we could run into issues with it. We do have a couple special pages, like I think maybe the search page or something. We have a couple special pages where we work around it, but I think we're doing custom stuff there. So just as a general approach, if you can make your landing pages a node type, it's going to make your life easier. It's basically my advice. If it's kind of too late for that, you already have a site, then you might have to do something custom to get it figured out. Yeah, because the reason I ran into that issue is because our, the same thing as you, where the landing pages were actually pages that had different paths. So yeah, that was kind of a weird situation. And like Jay said, it's easier if you have one page and you just provide translations for that. But it's weird. Only Drupal 8. Yeah, no, it was definitely, I looked at that. I was like, why isn't there a UI for this? And the way I got that to work was by actually changing the config. Kind of hard to explain right here because it was, you know, what I did was I looked at how some other config was translated and, you know, some of the documentation and kind of put it together so that the front page path was also translated. But there was, yeah, there was definitely something weird, like it didn't have a UI for that. So I feel your pain. Yeah, the advice is to try to, you know, take the different approach. Maybe too late for that. But if you are starting a new site, think about, well, think that there's big advantages to most of your pages being actual node types. It's going to make your life easier. They're searchable, translatable, et cetera. So just be careful if you're going, if you have some kind of, you know, special landing page. Just understand you're going to have more limited experience if it needs to get translated. So. Thank you. All right. And so we're done. If you have any other questions you want to talk to us about, feel free to approach us up here. And yeah, thank you all for coming. Yeah. So even if you use something like Lingotech, they, you know, they, you tell them to, you send off for a translation and they send it back and it gets like saved in the database the same way it would if you, you know, clicked.