 I'm just gonna do some quick little change here. Alrighty. Okay, so yeah, as was explained, my name is Tom, or Tom was said to be Tom though, and rather than have this beautiful long title, which does explain what I'm talking about, but isn't pretty, I'm calling this briefly in English, and I'll tell you why in a moment. But today I'm gonna talk about more of the fairy side about this whole topic about making multi-regional, multi-lingual websites, and tomorrow in the workshop I'm gonna try and go through the sort of practical side of setting things up, and actually the idea would be to go through with whoever is there, and actually help you decide what sort of setup you need, how you should do it, and you'll see sort of what I mean as I go through this presentation. Oh, that light is bright. So the first thing, what do I know about this, and sort of why the hell am I so interested in this? Well firstly, it probably makes sense to talk a little bit about me. So I come from a system, service, industrial design background, where a big focus of what we do is product development, which means listening a lot to what users say, and looking at how we can make the user experience better. Also, I've been living in a lot of countries over my life so far. I've lived, grew up in New Zealand, living in Argentina, Australia, Uganda, and then I moved here. So I kind of understand what it's like being a foreigner in another country, or going to a website where the content just doesn't work for me, and to a point actually sort of turns me off. Lastly, I am the Creative Director and CEO of Pixels, which means that I'm doing this every day, I'm looking at these sort of big complex websites. Another reason is about two years ago, we had a project where we were working with another agency. I'm not going to say who they were, but we were talking about this with the client, and they had no idea what to do, they had sort of a multi-country setup that they needed to do, they had to have multiple languages in some countries, and not in others, and they had country-specific domain names already, they also had a generic domain name, they had no idea what to do. And I kind of knew a little bit about this, I had prepared for the meeting by looking into this, and the agency who we were working with who were kind of taking the lead on the project, the guy kind of just spurted out a lot of lies, and I just sat there listening to him, going like, no, no, no. And that kind of drove me to sort of be quite interested in this. Unfortunately, I never really got to do much with it because you kind of need a project to sort of really help you get a real grasp on it because it's something that, while you can look into the sort of theory behind it, it's better if you actually have a real-life project to work with. But what I basically identified was that there is a big gap in knowledge. No one kind of has a best practice, no one sort of released information. Google has some stuff about it, but that's really to do with SEO. No one's really come up with sort of guidelines of user experience and what you should do. And that's another big thing today, I'm not really talking so much about the technical side, there's gonna be some things that I'm gonna show and I think people are gonna be like, but you can't really do that at the moment on WordPress, so why are you saying that? But the idea is to really think about the user experience and then I think the development can kind of follow along. Another thing is that recently I finally got that opportunity with a big client of ours. They have a very complex arrangement of companies. They have one which is working with many countries and wants to expand throughout Europe. They have another company which works only within Italy and then they have another company which works in one specific part of Italy. So they really sort of cover the spectrum of different ways that you need to configure a site for different audiences. And then this beautiful thing here is my last reason. I hate this. If you ask foreign, and this isn't just in Finland but it really seems to happen in Finland quite a lot. A lot of websites, even for very big organizations, have this Briefly in English page. I go there, if I see this Briefly in English, I just leave and I'm not the only person that does that. I think one thing that I've noticed is that people underestimate the number of foreigners who are in countries and a lot of foreigners are actually expats who are being pulled in for two years and then get sent out, but they're still customers. They have money, they want to spend it. If they can't find the information they need, you're losing your customers. So by not, and when I say you, I mean your clients. So when your clients don't actually put the effort into building proper sites that actually catered to the users who probably exist in their target markets, you're actually losing money. And, oh, I wasn't quite my last one. Also about getting things right. So I wanna show you through this how you can kind of plan correctly and implement and then using the right structure and also using great content, you can actually create really effective multilingual or multi-regional or both websites. So the first thing is when you're sort of working with the website content, you can either, we have, when you have a website, sorry, you can either look at content that's by region or not by region, you can talk about language. Maybe you have both region and languages. It gets very complex, so the sort of question is, what do I choose? And then it's sort of, why is this important? Well, the reason is that you're ensuring that your user has the best experience by giving them the most accurate content that they need or that you can give them. It also helps SEO because SEO, like these days, Google especially, and I'm sure Bing is doing the same thing and I don't know if anyone still uses Yahoo, but whatever, that's, they're trying to, all these search engines are trying to look at the content that you put there. It's not about keywords so much, don't shoot me for saying that, anyone who's SEO person, but it's not so much about the keywords, it's more about the content and how useful it is. So if you're providing useful content to people in the right markets, you're gonna start ranking higher. So how should you decide this thing? Well, you need to plan this with your client. That's probably the most important thing. You, I, they need to consider target markets and target users. What do these users need? Like what content? Do they need to have everything? Do they need to have some things? Do they need to have content that's specific for different countries or different languages or does it not even matter? Can it be the same content for everyone? Do they just not care? They just say, we're just gonna do this in English and that's it. And kind of the most important thing out of this and this is what I sort of hinted at before, especially when you're looking into a country-specific situation, actually look at what languages your users speak. There was something interesting I heard. I'm not sure if I've got this right, but then in Finland now, the second most commonly spoken language is Arabic. I'm not sure. Does anyone know if that was true? I think I saw something, I don't know. But there was something that was quite surprising, kind of sort of you wouldn't sort of think about it, but then when you actually consider it, you go, ah, if you think about, there's a lot of sort of immigration going on now, that's quite true. So you could almost say that, hey, if you don't have your website in Arabic, you could be missing out 10% part of the population or something like that. Like there's always those little things that you just kind of assume that, okay, well, I live here, this is the language I speak, I don't need to worry about that, but when you actually look into numbers, you might be missing out in a huge demographic, which, again, costs money. So this is my kind of method for working things out. You're either gonna have non-country specific content, so basically content that doesn't adhere or isn't needed for a certain country, but can be used globally. Or you have, funnily enough, country specific content. So in this case, we're gonna take the little Finland. So you might have, let's say you're looking at a huge company, something like Kesko Group, so they're focusing on Finland. For non-specific content, it could be something, I'm not gonna say Google because that's a terrible example. Let's just say Apple. Let's ignore the fact that they do have some regional differences, but they sell the same stuff pretty much everywhere. Then you wanna look at, are you dealing with a single country in terms of what your site has to cover or are you having to deal with multiple countries? That more or less explains itself. This only really adheres to if you're dealing with this situation. Then, lastly, the kind of more obvious one. Are you having to deal with single languages or multiple languages? Now I'm gonna go through sort of the matrix of how to make sense of this. This is a little bit like hypothetical in some ways, so it might be a bit weird to kind of get your head around so hopefully it makes sense. If not, come to the workshop tomorrow because then I can show you and practice how it works. But basically you get this kind of grid and basically by working out the answers, you can then sort of work out what setup you can use which we'll go into later. So the first one is what most websites out of the box are. It's non-specific content for a single language which is basically I have example.com, that's it. That's all. Then you've got non-specific content for multiple languages. So I've got example.com slash em slash fi slash fr. So Finland, English, wherever that may be, or French, wherever that may be. Now that's an important point that the language doesn't necessarily have anything to do with the country. Then if we start going to country-specific content, the first and most easiest is one language. So in this case we might have example.fi, done. Or then we go, well actually in Finland, often you need to put Swedish or we probably need to put English because maybe we're based in Helsinki and we know that we've got a lot of English-speaking potential customers. So then we're looking at example.fi slash fi for Finnish content or slash en for English content. Then we're gonna start looking at when we have to have multiple countries but each of those countries maybe have their own slightly different content and then they have, but then we just have one language for each of those countries. Now this is a slightly weird case that I don't really think makes sense because if you're international enough that you are having to go into different countries and have country-specific content, you're most likely gonna end up in a country where there is more than one official language that you probably have to have content in, I would say. Also if you, it's also not a good example, not a good one to use because people often still assume that the codes, like the language codes, can be country codes, which is not actually correct and so then you've gotta really be careful that you're not actually confusing the user by having country codes when they actually, or by having, yeah, country codes when they think you're having language codes. So if you have example.com slash SV, they sort of understand that it's not the same as slash SE and there's a lot more common examples of sort of screw-ups that come with mixing language and country codes. Sorry, that was a bit nerdy and technical. I'm a little bit obsessed with this. Then country-specific content with multiple countries and multiple languages. So this is like the big kahuna of everything. This is the most complex one. This is the one that Apple has. This is the one that, was the one I saw recently. Finnair has it, yes. Good example. Are you from Frantic? So this is like the most complicated one and it's kind of like the dream case. If you have a company that needs this, go for it because not only from a just general, easily organizing stuff, it makes it easier for the user to make sure that they're in the right place. It also probably helps with SEO quite a bit because you've got realistic content. Duplicated content is not an issue. There's things called hreflang tags. They deal with that. So please don't tell me that. So that's kind of the way about choosing things and which one of those. So you probably want to have one of these situations and that is for you to work out. That is for you to base on the content that your client's telling you that they're going to want to put there, that their users are going to need. That's kind of one thing of it. Then the next part, which is a big, big part of user experience, and this is a bit more sort of practical, how do you help people navigate through your localizations? Now, when I say localization, localization is when you take a piece of content and you localize it, I translate it, to the local language and country that you're actually targeting. The reason we say localization and we don't say translations is because, well, a language doesn't mean a country, a country doesn't mean a language. If you go to Belgium, you have French and you have Flanders. Flanders is the same as Dutch, but don't tell them that. If you go to the Netherlands, you have Dutch and I think there's another weird language they sometimes have. If you're in Finland, you have Swedish and you have Finnish and these days, more and more, you're having English, though it's not an official language. So there's so many different locales and with languages, it doesn't just belong into one little European border. I come from New Zealand, there's a sea, there's nothing beyond that, so it's a bit weird for me to get this concept around into my head, but I'm learning. So, what does this actually mean? The first thing is about helping your users select their language for the first time. So, how does your user get to their preferred language? Let's say you've got a site with different content for Finland, different content for Sweden, different content for Germany, and let's throw Austria in there just for the fun of it, and then you have obviously different languages within those countries. Well, usually you just do language forwarding based on the local codes that are based on your user's browser. Google actually says not to do that, based on the fact that when their bots go there if they get redirected to another site, they don't sort of discover the other part of your websites. That said, they've also said that site maps sort of fix that issue, so they're kind of like going round and round in circles and kind of covering their houses, I don't know, but it depends on your site. If you've got a smaller site where it's not too many options you need to choose from, you can probably just go with the redirection thing. It's gonna be okay, as long as you don't redirect on every single page every time they get there, because then it's gonna start pissing people off. But, if you have a more complex site, then you probably wanna have a landing sort of region selector, or some way that a user can go and select their region's languages, like Finair, whoever said that. Though there is one weird bug on the Finair site, so let's not go into that. If you can come and ask me later, I'll tell you. So, next, the good old language switcher. So, these should always show the language that the user is currently in, so they understand where they are. But if possible, it's also good to somehow show that this is where you actually go to change your language. To, I think it was Mikko, sorry if I got your name wrong, he was talking about usability. This is where you should definitely be using the ARIA labels because that gives people who are using screen readers a hell of a lot of more information about what they're actually doing here. Otherwise, they're just confused. Also, when you, I've seen a weird tendency, and this is available in some of the multi-lingual plugins, that you can, on these things, say that you only want to show the languages that that specific piece of content offers in other ones. So, let's say you have French, German, and Italian, but this content's only in German and Italian, it wouldn't even show French. I get why you do that, but actually it's kind of annoying to the user because they're like, oh, you don't have, if they go to that site from a search engine or from Facebook or something, they go, oh, you don't even have French, why am I even here? I'm gonna leave. Whereas you might have it a whole entire French site, you just don't have that one specific piece of content. So, you're kind of pissing the user off, giving them a bad experience and ultimately losing them. Then, that's, wait, yes, that's it, sorry. My favorite and not favorite. Flags do not equal languages. Please don't do this, it's horrible. I know that all the multi-lingual plugins say, yes, use flags, it's great. Please don't. It's actually kind of offensive for some people. When I see English recognized as the Union Jack or the flag from the USA, I'm from New Zealand, we have a flag too. No one uses New Zealand on their flag, like, what the, use the country codes, use the name of the language, don't use flags, unless you're using flags to indicate country. Lastly, in terms of user experience and helping people navigate the different language versions you have or different localizations you have, this is maybe in the wrong place, but there was a tendency a while ago to on like blog posts or whatever pieces of content have this article is also available in these languages. I think that was originally done to help Google understand that you had this other content these days with hreflang tags and polylang, and I think WPML does it as well, they deal with that now, so you don't have to worry about that, search engines understand it. So you don't need to do that, but at the same time it's not the worst thing if a user especially is trying to navigate between different language information, it's not, yeah, it's not the worst, but you don't need to have it, and you shouldn't put languages here that don't exist, save that for that big menu for languages. So the next thing you need to talk about is, oh, need to hurry up, is content localization strategies. So how much or how little should you localize? A translator will tell you everything, your client will probably say something, your client's boss will probably say nothing. I would say realistically, as my English teacher used to say when, how much should I do? She would say how long is a piece of string? The answer to that question is how much do you need? So it really depends on the content, it depends on who the content's for, what type of content, and this is something that you kinda need to go through, I'm not gonna go into all of it because it's just gonna take forever, but you can come and ask me if you want to, or if you come to the workshop, you can ask me all that tomorrow. So first of all, start with the basics. You should always have your core content translated or localized, that's pretty good rule of thumb. Everything else depends on what information your users need to know, what they want to know, and this should kind of steer your content localization strategy. And of course the big one, which is your cost to benefit ratio of localizing that content, is obviously it's not free, unless you have lots of people who speak different languages in your office. Thank you ours. So what are we working with in terms of content? Now this is getting again a little bit nerdy. So you have kind of two ways of doing this. One is that you have this core static content, so that's like about us, company, team, all that sort of stuff. Then you have this additional static content. So that's sort of, well it's kind of between these two, so it's maybe things like products that don't really change that much, but maybe you don't need to translate them for every market. And then you have dynamic content, which is things like news, events, stuff that really is regularly being updated or added to. This is really expensive to keep translating, especially if you don't have any house translators. This can be all right, can be worth it, also something you can decide when you go into a market and you have the value of actually doing that, that you can do that. But this I think is crucial, because if you don't have this, but you have a language version of, so let's say you go into Norway and you have this briefly in Norwegian page, that's useless, don't even bother setting up your site. But if you have about us, team, whatever, some sort of, the basic pages that explain enough to the user that they get what's going on, that they feel that they've got the same experience than the one they saw in the finished site when they first landed there, let's say, you're gonna give a better user experience. In terms of then how you should localize content based on the countries that the content is sort of targeting, you have this country independent, so again, that might be about us or like about the company and when I say company, it might be the big, big company. Country specific, so again, that might be things like products. Maybe you have slightly different products for slightly different countries. And then language specific, which might be things like events. So if you have an event that let's say is only in Finnish, you might wanna second guess about it or sort of rethink whether or not it's worth translating that event, posting on your website into English, because English speakers might then not understand it. That's debatable, you can choose, but that's an example of one of those. So if you're having one of these non, I've kind of skipped the first website type with no languages because that's not relevant. When you're looking at this non-specific and multiple languages, so like these generic kind of international countries, companies, all the core content should be done, but this additional and sort of other content doesn't really need to be, you can see if it's worth it, if you have the money for it. When you're dealing with this, you don't actually need to deal with any localization, yay. When you're dealing with this, you should be localizing everything ideally. Perhaps if it's obviously a cost factor, then whatever is your sort of secondary language or when the content doesn't apply to other languages, don't worry about it, but in the perfect world, do it for everything. Here, again, all the core contents, additional sort of the static content should be localized, so like these products, let's say, if they're in the country or not. And then dynamic content should be based basically on the country or like the sort of like news and events and things like that. Again, these are just examples, they really depend exactly on how your site's set up and what the needs are. If you're doing the big kahuna, then core content, definitely. Dynamic content, if it applies, sorry, the static content, so products, if it applies, and then the dynamic content should be really thought about if it actually makes sense for that market. So one client we have, who I talked about last year, they have to have their sites in German and Italian and then they have some other sites which are in French and English. And for them, it really depends on, like they have events, for example, and they only translate the events based on where they are, which country, and also which region of the country. So in Italy, they're actually based in the German-speaking part up the North, so if they're having an event there, they don't put it into Italian because there's no point. But if they have an event in the South of Italy, then they do, they probably don't put it in German because no one's gonna care. So the next thing I'm gonna talk about is addresses. So URIs, if you wanna be fancy and use the correct terms, I just learned that this is also a URN, I didn't even know that existed. This is important for UX because it doesn't sort of help the user directly, but it gives users a little bit of an indication about what they're seeing and how your website is structured. Subconsciously, a lot of users take a lot of information when they see the URLs. Unfortunately, Safari is now cutting out everything except the domain name, which kind of sucks, but whatever. So the moment when you're, at least this is sort of using Polylang, I haven't used WPML in ages, so I can't tell you what they do these days. These are the four sort of options that you're given. Well, first of all, I'd wanna cut out parameters because they're crap, bad for everything. Just don't even use them. I'm also not a big fan of subdomains because I feel like they don't actually convey the information properly. Also, with Finnish it's okay, but if it's like English, I don't know if that's supposed to mean like where or like German, like if it's DE. Does that mean German the language, German the country, it's a little bit misleading. And also it's kind of not logical, it's like finishofexample.com, not example.com of the Finnish version, at least for me that's slightly more logical. Directories are good and more and more people are going for these and I think that's great. And if you're doing country specific stuff and you can get hold of your country specific domain, do the beautiful one because it's the pretty one. And a lot of users kind of trust those a bit more. But when you start to add countries and languages, it starts to get messy. If you start using locale codes, you get beautiful stuff like this, like this, which for us maybe makes sense, for people who deal with locale codes makes sense. For most users, that means absolutely nothing. They're like, what is this even? Like I don't even understand, am I in Sweden but with the Finnish one, like I don't know. So there's a lot of kind of like mess everywhere. So then, what's the best structure for these addresses? Well, really quickly I wanna talk about the main names before I go into that bit, which is, you have kind of these two types. You have these generic domain names, which are .coms, .eu, .asia, and there's a bunch of other ones. Or you have these country specific ones. Generic ones are fine if you're doing a anywhere website. Also, if you have it for a specific country, you can go into Google search console or I think the other one, and Bing has a similar thing, and you can say this .com actually is targeted for Finland, please make its rankings better in Finland. But if you're using .fi or whatever, .whatever, then it's going straight to the right sort of, the results coming straight to the right person when they're searching for it. So if I'm searching for Finland and I'm going for a website that's a .fi, Google knows to put me a bit higher, it's really good. So if we look at these sort of situations really quickly, we have this one situation with the non-specific content. So again, this is when it doesn't apply to a specific country, but I just want many languages. Go for something like this. And these are just my sort of best practice that I believe. I'm trying to sort of start a standard of how we do these things. If you're doing country specific content with a single country, single language, if possible, go for these. They're the prettier ones. They're a bit more logical I think for users. But if you have a .com and that's the only one you can get, then go for that, but just make sure in the search tools you actually say that it's supposed to be for a country. When you're doing multiple languages within a country, go for something like this. It's pretty clear, it's a Finnish domain, and then it's the language that's within that country. If you're dealing with multiple countries, you probably, well, I mean, of course, you can use the country-specific domain names, but if you can't, then you can go for a generic domain name because obviously getting all those country-specific domain names can be expensive and sometimes impossible unless you actually have a company in that country. But at the same time, this is a bit weird because then it's a bit confusing like, is this Swedish, it's not so nice. Like I said before, this is the kind of nasty situation you have. And then this is the big kahuna one, and yes, as someone said before, this is how Finnair does their URLs as do some other bigger organizations. And at least in my humble opinion, this is the nicest one. I'm at this website and I'm going to the Finnish country site and I'm in whatever language. In terms of specific country domains, I would then actually redirect all my country-specific domains to here and then be sort of forwarded to the correct situation. The reason I would do that is that it's a lot more scalable. If you expand into new markets and you cannot get the country-specific domain, you don't have to worry about it. You can just tell people in that country to go to example.com slash fi and then they'll go to the right language site. What happens when you don't have more than one language in a certain country? Personally, I would still have the same structure because I think for users it gives consistency. So if they, for some reason, are going between different countries, they kind of get the same understanding of what's going on. Oh, and that was my pretty redirect thing. So just to kind of summarize all of that, I know it's a lot of information and very hypothetical and all that. Pick the right setup. Talk to your client about their needs. Talk about the future, what they want to do, what content and work that out with them. Help your users or their users navigate. So help people on the page find the information correctly by using the right language switches or the right region language switches or whatever. But make sure you make it easy. Don't use flags for languages. Use them for countries, et cetera, et cetera. Don't skimp on content. So if you're gonna launch a new country or language version, put the effort into at least to get a decent amount of content there. One, because your users will love it and two, because SEO, i.e. the God of Google, will also love it. And also use domain or sort of website addresses, URIs, that actually talk to your users about how your content is structured so they understand where they're looking, what they're looking at. Now ask me any questions or thoughts, shut me down. But yeah, thank you very much. Hopefully some of you got some questions. Does anybody have questions? Thank you so much, Thomas. No problem. That was great. I see a hand over there. One. I kinda, I'm not sure. Yes, there was a person. Okay, great. And there are mics going around, so just pick up your hand if you have a question. Hey, so like a WordPress technical question, how do you guys organize this stuff? So if you have multiple countries and multiple languages, are you talking about a WordPress network with Polylang? Yes, there's two ways to do it. It also depends a little bit how you want to, how your client wants to sort of delegate responsibility. If they've got different countries, sites with different languages, but they want each country to kind of manage their own and not be able to kind of interfere, apart from the admin God and whatever home country which has the big head honcho, you probably would be best going with a multi-site and then just having, for example, Polylang on all of those. However, this is something that I've actually been working on a little bit with the guy who makes Polylang. He has just added a hook into it, which means you can create your own URL structures now. So you can actually hook in and do a lot of things with them as you need to. And one of the things that I've been trying to sort of build is actually that you can have a sort of, you can set users to have certain authorization for certain countries. So that's hopefully another option that I will, as soon as I get this plugin actually working, we'll be actually releasing out so people can use it. But yeah, it's a good question. At the moment, I think it's the multi-site that's the easiest thing, especially if you wanna really worry about interference between countries. But with Polylang and with that hook, you can actually build this completely under one site. So you don't have to worry about all the wonderfulness that comes with multi-sites sometimes. Does that answer your question? That's a good answer. Anyone else? Okay, well, if you do have questions, you can go to Thomas's workshop tomorrow. So yep, check it out on the website. Yeah, oh, there is still, no. There's one. Yay, good. Thank you for a nice talk. But language switcher, country codes or native names, country names? That's almost like a design question, but no. If I wanna jump on the UX, sort of, or put the UX on, I would say the full name, because it's nicer, it's clearer for people to understand. At the same time, at least in terms of like if you have, let's see if I can, oh, come back, yeah. So it probably is okay to have just the language code up there, but then actually in your menu, it's probably better to have the full language names. And I would have the language names and their native language, so don't have German, have Deutsch, because otherwise, as an English speaker, I'm probably not looking for German. And we're like, oh, yes, German. Yeah, I'm probably German, I'm looking for Deutsch. So does that, that's your question there. Cool. Any other questions? We have a question in the back over there. Yeah, my question is, can you mention cases where a website doesn't need to translate for other languages, even if the company works with the multiple other countries? Well, it would make sense not to translate. Maybe having an English version, for instance. Because I mean, it's pretty apparent sometimes when you have to translate. Like for instance, with a friend of mine came from the neighboring country of 150 million almost, and there was the guy who yet came here because he couldn't find something in his own language. He was looking for a motorcycle equipment. So he used Google Translate to have the local store of stuff translated into his language, which is a disaster. In the Google Translate, it's a disaster. So, but I mean, when we should not translate the website for other languages? We actually have one client where they, they're actually a Finnish company, and they're in, I don't know, at least they're kind of present in 10 countries or something like that, and they only have English. I think it depends sort of also on your audience. If you know that your audience, for example, already, it's most likely gonna speak English, and the expense of translating or localizing your content into all these other languages just really isn't worth it. That's probably one situation where I'd say maybe it doesn't make sense. Like, I'm always for like everyone translating stuff. I think it's much nicer, but reality is it costs money. So if it's, that's the whole sort of cost benefit ratio part of it. So if it's really not worth it to translate into all these languages, you're better to keep it in one language. If you're doing one language, then you probably want to keep it into a language, unfortunately, like English, that's sort of a more international language. Does that answer your question? Yeah, cool. Anyone else, any other questions? I can't see any of those light matters. Cool, no. I think that's it for now, yeah? Thank you. Okay, thanks. Great.