 Bueno, es bueno. Alright. Thank you very much. Bueno, yo he visto algunas que sí o otras que no. La verdad que eso... pero sí lo habí... He visto... ¿Tú tienes agua aquí? No, pero tampoco pasa nada. Bueno, pero ¿tú coge vas o sí? No tengo aquí, me gustó ahí, después allá. ¿Y tú? ¿Tú tienes el mismo sentimiento que tú? ¿Tú tienes una canción favorita? ¿Tú tienes una canción favorita? ¿Qué? ¿El ayno o el catálogo? ¿El ayno o el catálogo? ¿El ayno o el catálogo? No, no, no. No es mi catálogo. Bueno, ¿tú tienes el... Bueno, mía, ¿eso no funciona? No, no, esto no. Lo que funciona es el puntito rojo. Sí, pero eso de cambio de los slides... No, pues eso no... Bueno, todo es nada. ¡Tú me pones pa' ti! No tuvies el tiempo ahí arriba, ¿no? ¿Preguntas así? ¿Se envían alguna ahí? ¿Puedes preguntar? ¿Es servísis? No, ¿cómo hemos hecho antes? ¿Cómo he hecho antes? Ah, bueno. Eso será el entorno de un par de años. Sí, no. A mí gusta hacerlas, ¿no sabía? Sí. Sí. Eso suele hacer... La luz no era... Me gustaba la idea de que me hiciera el turo padre, y que iba a estar ahí, y que me llevaba el cuello... Ah, esto está ahí. ¡Ay! Ah, so far we are fine. Thank you so much. I think lots of people are still coming, because we had a picture in the toilet. Yeah, no worries. We have time. Just let us know when it's a good time to start. A few minutes also. Ah, so five minutes or something. I came straight here, but most of course. All right, yes. Make some things. Parece karate kid. Just in case anyone comes. All right, should we start? So hello everybody, thank you for coming. Today we are presenting regarding our managing a worldwide master about based on regional multi-market, multi-language portals in Drupal 9. Your speakers are on one hand José Luis Peído, our lead Drupal developer, and then there's me, Eno. I'm the director for solution architecture at Cocomor. We both work at Cocomor. Cocomor is a digital agency originally based in Germany, but now it's offices all over Europe. We have in our time done more than 50 successful Drupal projects. We currently have 10 client platforms for which we are responsible and maintenance, and as an agency we have more than 15 years of Drupal expertise. By the way, if I'm too loud or not loud enough, you just let me now and I'll get closer to the microphone, right? Then, for this presentation, our client who gave us permission to name them Nestle Professional. Nestle Professional, they're responsible for selling Nestle products to business customers all over the world. So for example, if you're managing a hospital, a university or an office space you might need one to get to them for a coffee machine or food ingredients for your commercial kitchen. Right? And then they are the place of everything that you need for your business environment. They have a very difficult task to present on their website and sell a very diverse variety of products. And there could be anything, so literally from a KitKat to a very expensive complex coffee machine. Nestle Professional, they operate all over the world. So it doesn't even make sense to call as a country seat because they everywhere, right? But they don't always basically act independently in each country. Some regions are grouped together as regional markets. So to give you an idea I've put here the flags where they operate all over the world. Each flag represents a market portal that has been set up in the past in Drupal 7 and that we are now responsible to migrating to Drupal 9. For some of the regions, let's say for example South America you will see very few flags that's because they actually all work together. So the flag on the left that's LATAM based in Chile but responsible for all of South and Central America. Similar situation for South Africa who is responsible for various different countries and Southern Europe. Now the situation of the project. We started the whole thing end of 2020 when the professional came to us and asked for our help to migrate their all Drupal 7 platforms to Drupal 9. So in 2021 we did with them together first of all of course analysis and planning we presented a design to them that would make sense for the situation, everything needed to be component based and completely flexible and then we did of course a function then in mid-21 we started to create the master code and as a prototype market the USA were chosen. We therefore started then doing content migration for them in the second half of 2021 and were able to go live as planned at the start of December. Ceretically it was that you already have a finished project and all you need to do is the rollouts which was planned for 2022. When I say all that is left it's actually quite a lot of work because the rollout we're not talking about a simple technical rollout so what we're actually having to do is deployment of the master code which is then more or less an easy part but then of course we need to do content migration from all the old portals to the new one we need to do local adaptions wherever needed and a lot of markets had custom integration and they had developed on their own and they also needed to be migrated to the new environment. On paper this looks pretty easy we divided everything into five waves assigned markets to each wave gradually rolled it up to do more and more markets and that was a plan. However when we then calculated what that actually means and days and what could be done when turns out you need to work highly parallel to actually all work. So between preparations actual content migration and anything technical that we need to do each market several weeks go by and if you want to do more than 30 markets that consists of more than 50 countries it's getting really, really tight. So we needed a plan for that. And this is what I will be talking about here in the presentation today. Let's start with planning. Our key learning here was adapt and attack your challenges as they arise. Because we did have a grand plan at the beginning of 2022 that was let's add all the roadmap features that we planned for and add them basically for the go life of each wave that we had different learnings and conclusions. For the go life of each wave then there might be the occasional market feature requests that we can do as well of course we need to develop the third party integrations and then of course there might be bug fixes and additional theory requests. The year started, we started wave 1 and reality kicks in. We doing the first two markets and turns out having a lot more requests than anticipated. And we did take them on because our theory was right, what they are actually requesting it makes sense, nobody saw it before but now that we know every other market that comes later they will benefit from whatever it's requested so let's make sure to get them in. And there was a tendency that then continued. We came to wave 2, similar situation we now got to bigger markets and they had different requests, more complex. So whenever it makes sense and it was a global solution to benefit everyone we again put it in and on top of that we got additional theory requests and of course we needed to fix our bugs everything that we found on the way. Wave 3 came, wave 3 was the first one where we did more complex market that consisted of multi markets grouped together with different languages and that was quite the complexity to overcome of course they will later be talking about that a little bit more in detail and right now at this state of the year Wave 4 Wave 4 has some of the big markets that needed specific integration because actually they have a lot of content that is not created in Jupal but rather imported from different platforms. So conclusion for planning was it turned out very different from what we had planned at the beginning of the year but it did help that we adapt and reacted to the market requests making sure that we got the change requests in in time because we do have a sensible situation where if you wait for long there is always a danger that you will never get it in again because there are too many markets that are already live content would need to be adjusted and there is just no time to actually do that. Second area, design So early in planning I talked about a lot of things that we had to adapt this year to make that work design is actually an area where we had learned from earlier projects and made sure to set up things in a certain way so that we wouldn't get in trouble because of how we did things. I'll give different examples for that. So first thing is you absolutely need to make sure that your design process is connected to your development needs specifically for Jupal. What that means is everything that you put in your design tool in this case Figma for example needs to have a clear purpose it needs to be absolutely clear how it works how it behaves. If something is a simple Jupal paragraph you might get away with only the design in Figma and maybe a few sentences of explanation but in a lot of situations you actually need a real functional requirement doc and you need to tell you developer your expectations of how this model is supposed to work. One thing that we did in Kokomo is on major project we introduced the role of solution architect that would actually be someone in the middle between designer, developer and then of course the client as well. So here's one example you're having an article content type but not everything that you see in Figma is part of that content type. So a lot of the things that you show are actually individual components and you need to make sure that you communicate that to your developer accordingly there might be a simple component like let's say a text component a video component and in your team you have it figure out pretty quickly how you want to do things and how you make sure that you have a solution that can grow with the client's requirements but then there might be either component in this case there's last ones that are marked red for example a multiple collium container how do you do that what is the approach that is most flexible so this is one example where we had more detailed discussions of how we would to do that of course they came back to me and said you know I have certain ideas how to do that and it's more flexible than what the client initially requested and he came up with a great solution that we then finally did second example the way that we set up the design in Figma in the first place Figma is one of the tools that gives you an endless canvas but just because it has that ability to use it we try to use Figma in a way that was specific was specifically helpful to Drupal because on one hand you need to do the designs for the pages and typically those need to be best case examples because the client wants to see how beautiful the pages will look like in the future right so you put optimized content there text that has exactly the number of lines that it looks good between the pictures and all the other media however then you have very different needs in the same design tool for your developers so what we did, I'm not sure how well you can see it on the left side in the menu we have a section specifically for components and they are not set up with optimized content they are set up they are shown for edge cases how much text can I actually fit in a certain component right how does it behave and there's too much of it how does it look on either very big or very small screens so we made sure we had those two different areas and we always had it clear how something would behave and together between those two it worked out very well next examples very clear rules for behavior and design variations so Nestle professional is kind of an umbrella brand because Nestle consists of a lot of brands and all of those brands they want to have to say they want to have a say when it comes to the presentation of their products and the brand itself so what the brands demanded is for the brand pages they actually wanted to have their own color variations that should represent the colors of the brand what you're seeing here on the screen is an example of garden gourmet right our challenge was how do you express that in a way that you can cover the needs of all brands tell them clearly what they are allowed to do and on the other hand making sure that you have instructions for your developer then what should be done later so we came up with a thing of it's basically a mini style guide so we have a generic concept of variables that need to be defined for each brand to represent their own colors and all we have in there is literally everything complete that needs to be changed for a brand to be adapted the code will be encapsulated later so at any point in time I can add new brands without affecting on any of the existing sites keeping with the topic of brands but something different how do you tackle change requests especially in design the brands relatively quickly but after our initial code development they weren't actually happy if their brand colors were only applied to the brand corner pages they would please like to have their colors on a lot of different content types recipes, products articles anything that might be relevant to them so what we did is we had to come up with a roadmap of how to gradually adapt to their needs making sure none of the live portals would be negatively affected in the meantime how to create any problems for the portals that are already live so what you can see is basically four steps to get from a very simple solution where you only have a branded brand page to a situation where we come to various different content types which are then branded which was a brand request and then the markets came and said oh actually what we need on top of that is if you have a normal neutral page we do need to be able to set a simple section in brand colors but only for that one component so we integrated that as well and plans for the future are actually to allow for completely custom designs when they want for example to run a special campaign but still make sure we are running it all on the same components so back end never needs to be touched next area development and I will pass on to my colleague who can explain a lot better than I I will try at least ok so let's dive in a little bit more on the technical aspects of the project so can you can you please so I would like to cover four aspects for my side where the key for this project so let's talk about the project architecture of it so we had clear at the beginning of the project that we wanted to to make sure that all the markets receive the benefits from the request from other markets so if one market from Germany had a specific request we can easily apply to all others but at the same time we have the handicap of each of the sites are independent from one to another so at the end what we did is a distribution but it is not as simple as it sounds let's see why so the roots of everything is Drupal core plus contribute modules contribute themes in a usual project with Drupal plus your custom modules you would finish with that but our client lastly created a distribution named Linest which is great because you can standard all the approaches for usual user cases for instance how do you face when you create landing pages how do you do it with layout builder, with another strategy so you can normalize all the approaches all the projects inside the organization are done with the same strategy but not only that also security configuration everything so at the end when you have hundreds and hundreds of sites this is a huge difference for you having your own distribution then so we created we extended the Linest distribution with our own one professional and this distribution is used to create the different sites that we have on live at the end good thing is that we are able to have the same code base for all of them we are able to manage the releases for each of them but we don't have all of them in the same server like you had on a multi site or whatever so another good thing about it and for me it was really yeah really good we are able to also contribute back not only to other countries in Nestle professional but also to the base distribution in this case Linest so in case that we find any functionality that could be really interesting for all the markets out of Nestle professional they could get the benefits of it so if you structure your project you make a difference also of course to Drupal core and to the country modules since we have been doing for GS in Kokomo can you right so next step and for me it's the biggest challenge of the project as we mentioned before we have several waves with different countries but each country each country has their own specific requirements so one of them is multiple markets on the same Drupal instance and at the same time having different languages I think this is one case scenario that I think a lot of people here have faced it so let's divide it on different scenarios we have the first single scenario and the easiest one which is you have your Drupal instance with one market and with one single language in order to cover that you only need to have enabled config translation and strings translation because we are committing all the PO files with the translation for the fixed strings so when you install the site the strings, the translation are already in there same with configuration the distribution so if we instance, for instance a new site which uses French we have already the French translation ready for them it applies only to the new config for new views everything that we have created specifically for our distribution second we have one single market and multiple languages under this scenario there are various new challenges the first one was to how we how we could make the life easier for content editors when their mother tongue is different than the language that is used on the site for instance on the case of Indonesia the content editor team was in place was localized on Indonesia so for then it's easier to manage the site in English and then translate to Indonesian but we don't want to have English available for anonymous users for the end user that is visiting us so that's why we used language access module with that module you are able to specify what roles are able to access to what languages and it worked perfectly well for us then we had another another specific request how we face it those custom languages for instance if we think about the Latin America regional portal you have several countries with all of them speak Spanish yes but they have localized version of Spanish so it's third chain words that are different from one to another country so at the end you have custom languages but you don't want to translate over and over for all those custom languages the whole config strings or fixed strings you want to have a tree of languages and then only touch those ones that make sense for you so for that we came out using language hierarchy with this module you are able to specify a tree of languages and when a user visits your site the system tries to test the translation of the language that you are seeing at that moment and if the it doesn't exist it tries with the parent language so in that way we have neutral Spanish and then under that we have the localized version for Spanish or Argentinian version from Peru, for Venezuela any so in that way you only need the amount of work that you need to do is really small and flexible enough let's go to the third and the most complex one multi market so you have one Drupal site with multiple markets and multiple language per market this is again the situation of Latin America we have our original portal South America and then we have several countries Peru, Venezuela Argentina then you need accessibly control for the content for instance one product could be available on Argentina only but not on Peru or not on Chile so you need to control what content is available where and at the same time you need to provide different configuration for each of the markets for instance you need to customize your sitemap, XML, you need to customize the name of the site that kind of stuff so for that we use extensively the main module probably you may know it but not only that because we have another requirement you need to detect each of the markets by two kinds of detection let's say one by domain each of the markets have their own domain or by country prefix so in the URL with the same domain you have different country prefixes one for Argentina, one for Peru etc. so for that we use domain country path with that module you are able to define each of the domain records with a country prefix and it is put at the at the beginning of the URL and then the language let's face the last part of it no, no so the last part is languages you have to restrict what language is on what market because not all the countries speak all the languages so for that we use domain language negotiation you are able to with all the languages that you have define your site, you can map them to each of the domain records that you have and also specify the default language for each of them now about the deep workflow we followed a slightly different version of deep flow workflow because as I mentioned before we had different rollouts different waves each of them with different specific features so we didn't want to mix them all of them and we wanted to be able at any time to deploy a new version of the project so we work on releases they start from develop branch which is the blue line big features link to one specific release tickets on our Jira are also related to each version so we know at any moment what feature need to be added to whatever release good thing about this is that as I said before you can create new releases and they don't collide with each other so we can create a new one with backfist for instance only and go to life and then apply the update to the already existing ongoing releases now to finish let's talk a little bit about the whole tool set that we have used so for us was critical to have a local environment that is the same for every single developer on the team there is something easier to maintain easier to to run everything so we started one year ago one year and a half using DDEF and for us it made the total difference for us now all the team members you don't need to know about docker about docker compose you don't need to know the commands for docker compose you just need to run DDEF start and you have the system running on your local with the same versions that are on life with everything so for us it's a huge point same with we wanted to make sure that we are delivering good good quality at any time so instead of running the code checks with phpstan or whatever on when you run when you do the pull request sooner than that so with grand php you are able to orchestrate different tools like as I said phpstan and also you are even you are allowed to specify what commit message pattern should be done in your commit messages and to finish security thanks to our IT partners we were able to use fortify so we are scanning our site just before we go live and also we have recurrent scans but the point I think that we have two types of security scan one static with the code only and other dynamic on which you need a live an existing life site no sorry an existing site to trigger the security scan against so and also you can imagine when you have this amount of site you need to deploy them with trust and for that we have Azure pipelines and we are using it extensively I'm putting it here because of time duration if you like we can talk more about it out of this thank you thank you Jose and with that we come to our fourth topic client migration content migration it turned out it was a very important topic for Nestle professional so you have to imagine there are all these worldwide Drupal 7 portals that had been handled individually for different markets by different agencies adapted over time extended with custom integrations so you literally had pages all over the world that would need to be migrated to the new system and the question was how do you actually do that best there was a sale agency a global partner from Nestle professional and they made it clear to us you can't miss a single content everything that exists before need to exist in the future system unless the client specifically says no they don't want to migrate and then you need to provide a redirect so nothing ever gets lost when you're in front of such a big decision first question is how do you do that content migration two basic ways there manual versus automated scripts right and so we had to make this decision at the beginning of the year and very important criteria to take into account content had changed a lot over time some markets had integrated their own custom HTML content type had actually been diverted from the original intent to do something different because the system, the old system was so fixed that they had to basically get creative to make new requirements work and then we had the situations that a lot of markets with a chance of getting to Drupal 9 and now having a component based system they wanted to take the chance to actually restructure, update their content and create new things all of that combined together was the situations where we say there's no way we can do that with automated scripts and get it right we would miss too many things it would need to be adapted for every single market let's better do that manually turned out it was a great decision we found a great content migration team that we worked with that together greetings to Moher and they helped us to literally migrate thousands of pages and still do right and there were some positive side effects that came with that because it turns out once you go to the markets and explain to them how you will do the content migration they have a lot of extra demands of seeing that they actually would have needed to do in the past, never did but now that there's a chance that we're migrating content can we please do that on the fly and they normally said yes we can so on the screen you have for examples of quotes given to us from our side there was one strict rule whatever you want from us it needs to be expressible as a generic rule that we can follow without having to make an own business decision if you can't decide on something in a generic way if you need to decide content by content then you will have to do that yourself right and with that we were able to help a lot and we were making the content with the migration even better comply with new rules and the markets were very happy about that now let's talk about how we organized all of that it was how you actually do a manual migration in Drupal especially if all your contents are crosslinked between each other right, so if you're on the product page you have related recipes you might have related articles you have a related brand so the way we did that is we had at least two phases for some more complex markets it would be three in the first phase the only thing that we migrated from the old side to the new side are basically empty content containers so every single page that existed on the old page that was supposed to be migrated would appear on the new side with that you have created your URLs and you can crosslink contents to each other at that we would also set up then of course the side structure, the menus and as well prepare any custom integrations that we would need then phase 2 would start content migration team would concentrate on migrating the individual contents so everything that is inside the container every single component all the text, all the media and of course the metadata and the market in parallel already at the same time do the market access test making sure that all the standard functionality works with their content and if they had anything to create on their own site they could do that as well we gave them an onboarding of how to do that and the editor start creating their own content once you have done all that sale agency would come in do an internal audit making sure that everything is actually sale optimized because the assumption was we can't trust the old content let's have a run a test making sure that it's nicer than it was before in Google's view and after that phase 3 would start market would then do the sale optimization and corrections that they had to do on our side this was for us it was a phase when we do the translations we do the audit before the translations so you don't have double work when you need to correct something right so if they find something you only have to correct it on the original language in the case of a portal like South America you translate to all the other language versions afterwards so you already do that on optimized content one more thing I would like to talk about the positive benefits of basically as an agency being responsible for development and content migration and rollouts it doesn't matter how well you prepare how many decision makers you involve upfront planning is always theoretical and there are so many things that are only discovered once the markets actually look at their own content discover what they actually need and then come with additional requests the kind of change request that we got the sheer amount and the potential to make the system better simply because we did content migration for them they were able to look at the results and say oh here are ideas what we actually need and then whenever we could we did it for them in the time available that was a huge benefit for the client and it made the system overall so much better benefits for us we got very happy markets because we complied with the request as much as we could so these are photos that are actually not forced that are the markets themselves publishing basically when they go live unlinked in last but not least so I have been talking about the focus of the rollouts and everything we did of course if you do such a big project there are a lot more technical things that you need to take an account from the very start making sure that your project does not fall over so let me quickly note them here on this one slide worldwide rollout means accessibility it needs to work everywhere in some countries like US you can be sued if your site is not accessible so make sure that's like a basic requirement and should be checked by someone like for example your frontend developer when generally accessibility specialist strategy for optimizing your page load time especially the media make sure the images are optimized as much automatically as it can be done helping the editors to not have to do that themselves never allow any technical depth to creep up on you if in a situation where requests are coming in but you're already going live with markets there's at certain point when you have a certain number of live markets there's only so much you can still without negatively affecting all the markets that are already live and do not want to have their system changed content disappearing or strange side effects so make sure you do everything in time and adjust accordingly of course worldwide rollout also means left to right right to left languages make sure you have that in Figma so you discover things that might look funny when it comes to Hebrew or Arab suddenly a right to left layout structured metadata today is a must if you don't do it your agency will basically send you away and you need to start from scratch also for the editors if you have a process of separating content creation from structuring the layout either with a Drupal module or with something custom you did this is very helpful for them it makes life so much easier and another thing that helps the editors is if you take into account the editor workflows a lot of times markets might not be able to express very well how they actually work together they will however tell you as soon as they start creating their own contents so make sure you have things incorporated like revisions and publishing on demand making sure that you comply with the requirements last but not least the whole thing at all times treated as a living project don't see it as something that needs to be abandoned at the moment that something goes live this is actually when the real work starts and being able to monitor how it goes how well it works for them and then to adjust based on the needs helps a lot to make things better and with that we end our presentation thank you so much for your attention we are happy to take any questions that you might have we have seven minutes questions so there are two from live I don't know if you want to read them yourself so just at the end there you mentioned separating content from the layout do you have any more details about how you did that technically did you mention a custom module yes so nowadays there's actually a trooper module it's layout paragraphs right Jesus the trooper module layout paragraphs right making sure at the time that we started it wasn't far enough to actually incorporate already so we did have a custom module that we developed together with a partner agency that pretty much does the same job thank you it's interesting are you using any multi side or multi domain approach Jesus for Jose could you repeat please are you using any multi side or multi domain approach will have every market his own trooper container each of the markets they are independent from one to another so they are we are not doing a multi side what we did is to have a distribution which is the one we use when we instance the new market the new region that we want to deliver and then if that market has that region has multiple multiple markets we use domain to difference each other but each of them are independent each of the regions that we are for example, America is one Drupal Drupal instance created from this distribution and then we have for instance I don't know France Spain they are independent from one to another there was no need for shared content no only on those shared content is only needed for those regions that has multiple markets for instance Latin America they are sharing content for instance the same product it can be found on Argentina or Chile but they don't share products between the French version and the Latin America version they are independent sites maybe let me add to that because it's a really interesting situation at Nestle theoretically there would be a need for shared content but in the past the market were working really autonomously and they never did that Nestle is right now thinking about techniques to make more shared content possible and to integrate in the structure y en ese sentido vamos a pensar sobre todos estos aspectos Hola, una pregunta sobre parágrimas y translaciones parece que tienes todos estos países y toda esta complicación en nuestra experiencia una cosa que siempre es muy trica con parágrimas y translaciones ha sido discutida por mucho tiempo es que al menos en algunas patches normalmente no puedes tener parágrimas no pueden ser transladas y en nuestra experiencia esto ha sido muy trícita quiero preguntar a vosotros si lo hiciste y si lo hiciste de una forma peligrosa de la patch o si lo hiciste algo mejor sí, lo hicimos no aplicó la patch para ser honesto porque nuestra decisión es un poco diferente como si fuese bien hay only a few examples where they had different parágrimas from one translation to another we are lucky on that but we have a few examples where they are different so it is exactly for those scenarios where we have multiple markets so we have independent notes from one to another they are linked so we are not applying but I know what you are suffering thank you for a nice presentation I have a question around the domain module and country path and language is there time to show it maybe I would really like to see how you do this in different South American countries changing language and having localized versions I am not ready but what I can tell you is basically the functionality when you create the domain record you can define it in that form that you have I meant on the front end we use it ourselves I would just like to see how it is in action we can show you afterwards but I am not really here to ok I will come by then quick question did you have any instance in China and if yes what was the process and technical challenges over there sorry could you repeat please did we have any instances in China in China China was intentionally left out so we were told they will be doing their own thing legally it is a nightmare it is very problematic so we didn't do China sometimes you have markets with conflicting interests or with different perspectives how do you manage that those markets are happy and how do you decide on the features you are going to release that's a very good question as you might have seen on the world map most for example most of the markets in Europe they have their own portals because they couldn't align on a common approach they are all far enough to say we have our own vision of what we need how we should do that we want to use your base components and everything before we put everything together on what we focus and do that and then you are left only with regional portals where you have more markets typically with less money and they have to work together so they align because there is no other choice if they want to do their own thing they need to be their own portal there are a couple of questions in the app from Lev and Niki I don't know if you want to read your question just a quick question about the development part you said you choose DDEF instead of Lando why did you have some comparison because before we used DDEF we were using docker compose with our own list so for us it was easier we knew DDEF from other previous experience so we decided to adapt it because for us it was easier to learn I didn't check Lando or anything just because for us it worked and we knew it already try it for sure another question what it was did you try groups groups groups groups if we consider groups instead of domain actors no because the domain thing the detection of each of the markets was harder to do it on groups last time I checked groups que fue en el desarrollo. No lo revisé de nuevo, pero conocí el domenio. Así que para mí no era en la foto usando grupos. Probablemente no hay grupos que han cambiado mucho y probablemente podríamos usarlo. Pero para mí, cuando vimos los necesarios en términos de diferentes mercados y todas las capacidades que tuvimos para cumplir, para mí fue claro usar el domenio y el ecosistema domenio. Bueno, muchas gracias por la atención y un gran día.