 First, thank you for being here. I know it's already past five so I really appreciate all the people that are in the room and I would like to start with a confession. This is my first time as a speaker at Drupalcom. So and then please be harsh in the comments. I want to get better for the next time. So About me, I am Lubo. I have been part of the IT industry for the last 15 years and I have a specialization in leadership and management from Harvard University and also, I am a professional scrum master and professional job leadership certified. Why I'm telling you this because for the last five years I'm trying to be a branch between the business and the tech and I'm doing this as my job as group architect and deputy program manager at FFW. So why I joined FFW is actually described in this quote. I wanted to move enterprises and people forward. I wanted to work on stuff that I could see the result every day so I could see it on the TV or I could see people that are using the thing that we are delivering and if you don't know about the company company is already on the market for the last 20 years. We are more than 800 people. We are located in various locations. I'm coming from Bulgaria. So and one of the things that I'm proud is 100% of our clients want to have a second project with us. If you are more interested in the company, please visit us at the boot. Tomorrow I'm on boot duty. And that's for the company. What will be the agenda for today? First we'll go down a tour down memory lane, not the song, and then I'll give you some information about multilingual then guidance for the business, how we managed to optimize the process and last but not least the lessons that we learned. So a tour down memory lane. It all started in Amsterdam. Again a Drupal con. It was in a room similar to this one. We were just releasing a first website on a new platform. So it's like I have a dream. I want to make a new platform. It has to be awesome and let's be honest we deployed some of the stuff in front of the room. Some of the guys here were with me and they did that. But once we managed to deliver the first website, then we got the second question like hey let's make it multilingual. Because the business wanted to have a quick win to show that this is possible and then the business decided, okay, let's make this platform multilingual. And my personal opinion is always choose to start with the multilingual stuff. Don't do it after that because when you do it after that you have way more issues. That's why you could see in this diagram that the first multilingual website was released one year later and once we delivered the first multilingual stuff, then over the next three years we managed to deliver 50 more brands on that platform. And we are coming to this day, which is Drupal com.lil and what we did was during those three years we were optimizing the process when it comes to translation and I will show you what we worked. So you could have a better picture. I need to give you more details on the platform. You have Drupal multisite, multibrand and in there we are actually generating a static version of the website. By the way, the person who was working on this is still in this room. So you could ask him questions after that and then as you could imagine we have static HTML pages. All the dynamic stuff is handled by microservices and those are written in Node.js. I guess you already know where I'm going. We had the translation in Drupal. Then we had to have translations in all the microservices and those microservices had some of them frontend which was in React and now this frontend is in next.js. So we had to support translations in Drupal and then support the translations in the frontend microservices. This is the architecture in short. So with having this problem we had to solve the multilingual for the business and the first thing that anyone should do is make sure that the client understands what the translation means because for some of them it's translation of content and by translation of content imagine that you have a page. In that page you have three different paragraphs and then when you click translate for that note they say on the other language I want to have five paragraphs which are different than the original ones. So make sure that the business understands how translation works. Make sure that you understand what are their needs when it comes to translations and also make sure that the different content in different language is something that they want, they understand and they will receive. Another thing is that sometimes they misuse the translation. So what does it mean misuse at least in my eyes? Misuse is we do have multilingual countries. I'm coming from Bulgaria. In Bulgaria we have only one language, national language which is Bulgarian and for us you might have another language on the website which is English but if you are coming from a country where you officially have several languages like let's say Belgium, you have Dutch, you have French usually you have English as well. For a person from a multilingual country it's okay to have the content in all these three languages which is odd for me, but for them it's okay. So we had a case where the business said I want to have a list of items and it's not a problem for me if the first item is in Dutch, the second item is in French, the third item is in English. I want to have a language switcher on the top and through that language switcher I want to be able to change the user interface but changing the user interface won't change those entities, won't change those items. This is something that's okay for them because they could read through those languages and this is something that you might have to accept and understand if this is not a commenting for your country. Another thing that you could face with multilingual countries is they could misuse the translation with the functionality. So I will give an example specific to France. Thanks to that I know that in French language you have masculine form of the word, then you have a feminine form of the word, then there was one search functionality where the business said if I have added the masculine form of the word I want to see results which include the feminine form of the word. Also, I would like to see results which include all the synonyms related to those and also I would like to see words that has the same root in them which is specific for the language. Yes, this is the grammar. It might be normal for people that are living that country, but it's not directly related to translation. It is related to how you make a multilingual website and the functionality, but this is not translation. By the way, if someone is interested in this case, you could catch me later and I could give you details. So now we have the different behavior. We have the understanding of the translation and the next thing is reuse translations. One of the things that we learned was Canadian French is different than Belgian French is different than the French language that you use in France. It's obvious for you guys. It's not obvious for people who don't know. So we said let's reuse what we have and at the end you have 80% things changed. Still it's better to give them options than start from scratch. And now I'll try to give some guidance for the business. So the guidance is you see this image. It's Google Sheets. We have two columns. One of them is like components. The other one is the actual text and in there we have the like a context saying validation, message required and the other one is filters required. So it's pretty obvious what this is about. Why I'm showing this to you? Well, there are a couple of things that we need to make sure that our clients understand. For example, choose the design language. Most of the clients have their own UX UI guys and most of the time the design is in English, okay? But if you have a solution like we want to have a main navigation, that main navigation should consist of only five items and that main navigation shouldn't go in two rows. But then next to the main navigation, we want to have some fancy component and they did that in English. I guarantee you that probably there is a more than 70% chance that when they translate this to German, it will go to two rows. So always ask them in which countries are you planning to release that? What and how that design should behave if it's translated to another language and I'm not touching Chinese, Japanese, etc. I'm not touching Arabic as well. So always ask that. Another thing is consider the wording curve. So I showed you the Google Sheets image because if there is a new person that is going to use Drupal, at first they have a big wording curve. They need to learn how to use translation interface in Drupal and this might slow you down if you have a limited time to the market. So it might be beneficial for the first launch or just to speed the things up to use stuff like Google Sheets and just give them the Google Sheets because most of the time the business might have a person responsible for that, that person might be an intern and that intern will have to learn Drupal as well. So consider the wording curve. Another thing is this responsible person for the translations. It's always a good idea to have someone from the business responsible for the translations. When we start working on a project, at some point we are that good in their matter that we could help them. But at the beginning we still don't know the business. We don't know the specifics. That's why it's a good idea to have a person from the business that is responsible for the translations and that person is responsible for making sure that gathers all the stuff and that person could say, hey, I know that Canadian French is different than the French used in France, but we start with these. These are the most common things that people change. And also that person will extremely help you when he or she has to update them. So another thing, provide guidance. I said that there is a wording curve and it's always a good idea to have different videos or screenshots just to point to the people where does those translations live. Because it's obvious for you, but it's not obvious for a person that is starting to use the platform. And what we did was we added different videos. We added screenshots. Next to each component inside Drupal, there was a video when you click it and it shows you this is used like that. So you could easily find out what is the translation. A colleague is here. He had a good idea that we could upload those videos in YouTube as a private channel so everything could be searchable. So this is extremely good because if you have those videos, there is no point to have them in a conference page and then no one updates them. So don't forget, if you have videos and screenshots, always plan time to update those. Otherwise, at some point, you don't need them. The last thing, you could always consider an external service. There are a lot of services that you could use to make those translations, but think from legal perspective. Is this okay for all your branches across the world? Also, is this okay for you as a pricing model? Usually, the mistake that is made is like, okay, we have 10 accounts, we will use them, but we have to deploy to 50 countries and 100 people should have access. So we have an issue with the pricing model. Always make sure that you make the math. How we optimize the process? Well, we reinvented the wheel. Like what we did was, that's why we had Drupal on steroids. We have service one, service two and mobile app that have their own translations. We know that Drupal is great with translations and Drupal is the user interface for the editors. What we did was each time when you push a change to any of the services, we are listening for that change. And then inside those services, we have the translations. Those translations are stored inside a translation bucket. That translation bucket, you could see it's not only horizontal, but it is vertical because if it's horizontal, you could have multiple instances and it could be vertical depending on the brand because different brands for the same client might have different naming conventions for specific stuff. Also, Drupal is reading all those and giving you a user interface so you could actually update everything from one place. And last but not least, Drupal is extremely good because it could export the translations for you in a PO file which you could give to any person and that person could make the translations and then you could import them back. In more details, how does it work? Each service has a default text. We need that because if the service doesn't have a default text and for some reasons it could not get the translations, you don't want to break the interface. So always make sure that you have the default text in the service. Then data is added to a common place. In this case, the common place might be in the image registry bucket. I always joke with clients like if S3 is down, we will have way more issues in our wife, but who knows. Then Drupal will import all the translations and how will Drupal know which is coming from which place? Well, if I have the naming convention like a warehouse, if you work in a warehouse, you need to know where a specific parcel is, how you know that. Each parcel has a unique code and there is a convention for that. A context might be we have login page dot login form dot login button dot label. It seems that I know where this is. I know this is on the login page. This is the login form. This is the label of the login button and I could add on the left on this like this is service one or this is the mobile app or this is something else. Then I make sure that everyone knows this. Most of the people forget to inform the rest of the people that are working on the project, how this work. If you don't inform all parties included, you're not doing anything. If only the developers know this, this won't work. Everyone should know how this is done. Then Drupal will export the translations and the translations will be consumed by the services. Those services might be written in any language. It's not a problem. The main thing is make sure that we use the context. What we did was we actually enhanced the context that we have in Drupal by including data from external service. Drupal was okay with that and it actually served really well because now if you need to make any translation, anyone from the editors could do whatever they want. One thing that I didn't mention, cache, always make sure that once any of the services is reading the updated translations, you have a cache in clear. This means that when the service displays that, there is enough time that you are okay. There might be a discrepancy between what has been translated lately and what you're showing to the end user. Also, you don't want to abuse the service. This is the technical part. There won't be any more technical stuff. So what were the lessons that we learned? Well, the first one is be careful with design systems. Now it's extremely trendy that everyone has a design system or it's using a design system. Okay, but one of the main issues with the design system is that those are built usually by teams that are located either in one location or are driven by a person in a location. Why I'm saying that? The dates. The date format. This is extremely simple example that most of the design systems have issues because people said, okay, I will deploy this in France. I will deploy this in Central Europe. But if there is a specific country with a specific requirement, the design system won't let me do that. What is the cure? Make sure that you have international teams. Do your homework and check are there any specifics in the businesses that you want to deploy that so you could make this configurable. Otherwise, you have to use design system and then make adjustments to it. Always that context of the translation. I already explained that with the warehouse so I know where the parcel is. Then the configuration versus translation. You know that in Drupal we could have configurations. Those configurations could be translatable. Okay, but you could also speed up the things. Let's say that you have in the design a error message. That error message doesn't have any placeholders. So instead of making a configuration for the error message, you could make it a translation. And then any editor could make a translation from English to English or from the source language to the same language. Because it's one text, it's not multi one, so it could be used. Another important thing is placeholders. If you have many placeholders, let's say I have five placeholders in the translation, consider seeing five placeholders in Drupal translate interface. It's not really user-friendly. So either you have to think about updating the user interface or you could make this a configuration. The next thing is use as much as possible. That's expected. And be patient. We are working with people. We want Drupal family to be larger and larger. So if you are patient, we will have new family members. And don't forget, you could use a translation manager. The translation manager will make your life easier because there will be a sole person responsible for that. And if someone wonders how could I offer to a client something like this, well, you could have a gatekeeper of the documentation who is responsible for translations and the rest of the documentation that you have in the project. This is, in short, the lessons that we learned. I would like to remind you that if anyone wants, they could contribute. So contribute. The module that I showed you, we are aiming to make it open source and release it. And don't forget to give feedback. Do it in the app. And thank you. There is no question in the app. But if somebody has a question here, raise a hand. And I will come to you with the microphone. Do you think it's an option to, instead of having the default translations stored in the app or the services, to have them as PO files? Yes. Currently, what we have is, you know the situation. So we have them in JSON files, which could easily be translated to PO files. The trick in there would be how you add the context in the PO files. Make sure that you don't lose the context. Thank you. Other questions? Yeah, we're running one minute after the time schedule, but we're good. Thank you very much.