 Kiitos. Joten tosiaan, että haluatko hieman energiaa tämän luokavuudesta. Olemme pitäneet. Kun olemme olleet, kuten Tomas sanoi, ilmastonmulta-linguista on semmoinen asia, ja jotain, jonka olemme täällä Finlandia, semmoinen asia or can do. My name is Janne Alajela and the first step I step on multilingual sites is to use polylang. I'm not going to go further on different multilingual plugins because as Daniel said there were an excellent talk in last year WorldCamp Finland that you can see on WordPress.tv. And if you want to do and learn multilingual stuff, there is a workshop available tomorrow. So what are we going to talk today? The admin workflow. It seems to be the thing this year. Then some theming stuff. And the last section will be about working with non-ladding alphabet. So the first one. Oh, blimey. Back. Oh, so the translation workflow for the clients, the administrator users of the site. There is not a clear solution for this one. This is something that you need to talk with your clients. Plan with them how they intend to actually manage their translations. Who is the person who makes the translation? Who is the one who adds them from where they come from? And how they fit together in different language versions of the site. So talk with your client. One example of parts that you need to talk with them is copying content from the original post version when they add a new translation. WPML has an option for this by default. Polylan can be extended to have this feature. My colleague Temus Ueranda back there has developed a plugin for this. That's available at our GitHub account. And if you really want to use copying the content as a base to the new translations, that depends quite a lot on the client's workflow of managing the translations. So once again, talk with your clients. A small thing, show the content editors how they can change the administration language. Especially if you have a big multilingual team managing the translations. There are probably different native language users among them. And by default the WordPress sets the administration side as the site default language. But both Polylan and WPML have this feature when on the user profile page they can change the language. Widgets. In general I have found that widgets are a thing that is a little bit hard concept to understand for our clients using the sites. And if we add let's say a few visibility rules and the translations to the widget UI, most of the clients hate the widget UI. So I'm not saying not to use widgets at all, but especially the ones that the client is going to edit. And the more languages you have, the more difficult the widget administration goes. Because I think there is no easy way to handle the widget translations. That actually would be better in user experience view. What do you use instead? Custom fields, custom post types, site option pages, translatable theme strings and stuff like that. Then on multilingual themes. I thought that I wouldn't actually have to mention this, but it's quite often to see something like this in the actual sites code. And I think at least they should have used a switch. What we are told to do is to use the WordPress default translation functions, like load-en, load-load- and etc. Where you pass on the string you want to translate and the text domain to isolate the different translation to own context. But this leads us to the Po and Mo files that in my opinion are awful. I haven't yet met a developer who thinks that these Po and Mo files are nice to work with. Editing them is a little bit hard. That's something that is quite separate from the rest of the development. Po and Mo files are something that no client wants to edit. Or actually I think it's quite impossible for them to edit. One big thing in Po and Mo files and using the default translation functions is that we can't change the original English text without invalidating all the translations. So in case we have a site that's available in Finnish and Swedish, we usually make the strings on our theme in English and add the Finnish and Swedish translations. But if the client wants to add the English translation later and they want to use some different English strings that we have originally used, we have to do all the Finnish and Swedish translations again since we are invalidating the original string. And the reason why the WordPress uses the Po and Mo files at all is that they derive the get text protocol available in PHP. But as I will show you soon, the performance on these files is bad. So not even a performance point of view, these Po and Mo files are good. There is obviously a good place for Po and Mo files. If you're developing a plugin or a commercial theme for sale, it's a good way to add the translations in your package. So the plugin way. This is the polylangs version of load as E. There is also for the other translation functions the similar ones. And also the WPML has a similar system for handling translations. This way we can manage the translations in the admin UI and also let our clients to edit them. Last year we built a site with around 30 languages and it's really nice that the client can change languages themselves of the translations. And one nice feature is that you can change the original string or override it. And we have taken this a bit further and we usually in our themes add just a placeholder text as the base text. So like header call to action button text and then we don't have to actually know the English version of the text beforehand. Also this feature can be used for other strings than visible user interface text. Like date formats, call to action button links, text in footer. Usually the copyright text and footer are used to be widgets. So they could be edited on the admin. But nowadays we usually add them as translatable strings so we don't have that many widgets areas to manage. There is obviously the downside that the translations are stored in database. So it's harder to move them from another environment to another. But I think that's only a little downside. And I think someone should actually write a plugin so we can move them along. And to be sure that we don't break everything, we use fallbacks. So in our theme we add these fallback functions that fallback the polylang translation functions to the default translation functions. If you're developing a theme for sale, you could actually make the theme of polylang or WPML.com valuable by adding these functions. Then it's time to bring in some unicorns. And to be honest this has quite a little to do with multilingual sites, but it has a lot to do with sites that are not in English. Here we have a page generation times for different WordPress installations. Let's start with the default install. No plugins at all. 2016 theme, just the default content that is brought with the installation. Pretty decent lamp stack. So the page generation time is 26 milliseconds. And on the admin side the new post page is 47 milliseconds. When we change the site language to finish, so no multilingual stuff just changing the site base language to finish. The front page generation time pumps up to 37 milliseconds. That's a 42% bump. And on the admin side the difference is even bigger. And if we take this a little bit closer to the real world, we have an installation with 15 popular plugins, like SEO stuff, analytics, WooCommerce, something that we usually have in most of our sites. The front page generation times around 100 milliseconds. And the admin side around 200. And if here we change the language to finish, we almost double the page generation time. So this is not the server response time. This is the time that PHP spends on generating the time page. And on the admin side there is also quite a bump. So if you have ever done performance profiling on our WordPress site, you probably know that there is a slow player in the house. And that's a function called load text domain. By default the load text domain handles all the MO file parsing, so that the WordPress can use these translations that are on the MO files. But by default WordPress loads all the available text domains. So if you have 20 plugins, it loads the text domain for all the plugins. And then for the team and core and for all the things. Even in the front end we usually use one text domain, the text domain for the team. So that's something we can do better. Also the translation files seldomly change, so that sounds like a potential target for caching. So what if we make these optimizations and load only the text domains we need and cache the text domains. On the zero block inversion, we end up having only three millisecond difference to the original one. And on the admin side we can also split the difference in half. But what I think is the most important number here is that when you have it this close to real world situation, we can almost cut off all the overhead that's in the load text domain. And even on the admin side we get a quite nice difference. We've been running these kind of optimizations for a few years now, and on the average side we have seen something around 50 to 20 percent improvement in page generation times. So that sounds like a nice thing. So how to do this? There is a plugin called WP Performance Pack available. It has these text domain optimization features and also a few smaller things. But if you don't like the other things like we don't, we have made only the cacheable text domain loading available in our GitHub account. Obviously there is a small thing and small print available. So to actually have the real performance improvement you need an object cache back end like Redis memcached or APCU. But any of these can actually help and deliver quite the same performance. So back to multilingual stuff and themes, language selectors. And this is something that I wanted to give a bad example again. There is only one good thing on using flags as language selector and that is that they are small so they don't take that much space. Since these are probably quite easy to know what languages these national flags represent, but if you add a few more it comes a little bit harder. Since the lower row matches all the same languages that are in the upper row. So no flags. Again, no flags. Easy one. Then the language codes. This is something I've seen lately a lot and I think this is like a 50-50 good option. If you have only a few languages like usually here in Finland we have Finnish, Swedish and English and maybe some other but usually it's these three. It might be that this is good enough. But when we add more this isn't that clear that what these languages actually are. And here we have Estonian, Russian, Greek, Turkish, Chinese, Japanese, Hindi and Arabic. And I think the last four not even use this kind of alphabet to actually represent their language. So if you have only a few languages write down the full language names. And even if you have more you should use the full language names. That's the best one. Last year we built this site with quite a lot of languages. So we went on a trip and stole the idea from PBC and implemented this language selector that has the English versions of the language and then also the native version of the language name. So especially for the ones using little different alphabet than we here use, they can recognize their own language. Then the last section of this talk is non-laddian alphabet. I've been working with many sites during last year that have languages with non-laddian alphabet and I noticed that there is quite a little information about this available. So that's why I wanted to tell you something about it. And the global share of laddian alphabet is only 1 third. So even it sounds a little far to thinking here in Finland that we should care about something else. We should care. The rest big ones are Chinese, Devanagari which is used in India, Arabic and Cyrillic. And I think the Cyrillic is the one that for geographical reasons comes up quite often. And the first thing on non-laddian alphabet are the web fonts. And I know this is a design thing. But on my experience you are the first one as a developer to think about this. And since I knew that there would be designers sitting here today, that number is only 90. And there must be some exception in the people of designers. So in practice someone spends hours and hours picking up the nice font for the customers site. And they don't know that there will be languages without laddian alphabet. So we end up having this kind of nice CSS rule for font families. Then in the ideal world we have these nice headlines. But then we have a Finnish person appearing on the site and adds a headline in Finnish. And we end up having mixed content. Usually with Nordic diacritics we don't have this issue since most fonts included them. But for example with the Cyrillic characters this usually becomes an issue. Since they have a set of laddian alphabet and a set of non-laddian alphabet in their alphabets. So there usually is mixed alphabet and it's ugly to look. Another example is the Chinese. Here we have nicely to sheriff for the word weather in English and Chinese. But if we take off the actual web font addition, we notice that the Chinese version of the word was already in times all the default sheriff font that's available. So often when we make the site with non-laddian alphabet we don't actually notice that they are not using the same font than the other versions where actually all the alphabets render correctly but with the default font from the font stack. So what to do when we have non-laddian alphabet is to make sure that we include the correct subsets in our fonts. Typekit and Google Fonts you can choose for which languages or which subsets you use. And I think most of the web font vendors have these kind of selectors available when making up the web font kits. On another thing you as a developer should see this issue upcoming upfront and try to consider that and make the design of think that there will be issues with the fonts later on if they haven't considered the... Some easy solutions we've used. There is a font called NotoSans that's developed together with Google and Adobe. It is based on the SourceSans Pro font and it's available in almost all the languages you can think of. And it's available at Google Web Fonts Early Access with many other fonts with non-laddian alphabet. Even if it's Early Access you know what kind of beta programs Google have so I don't take that as a problem. Transliteration. Business of getting rid of unwanted characters. This is something we don't actually kind of notice at all and we're kind of used to it. WordPress does this by default. It replaces non-asci, non-laddian alphabets on slugs. But what if we have Chinese marks in the slug. It does nothing to them. And I think because we are actually transliterating the Nordic diacritics and as and as and stuff like this we should actually transliterate the other alphabet too. So here is a set of different plugins that handle the transliteration for you. And the last thing is right to left. So from right to left. Languages that use right to left are usually Arabic, Hebrew. And at least I've noticed that there has been a raising demand of these right to left languages even here in Finland. This is something that WordPress does by default if you change the language to language that uses right to left. And on the HTML path this is the most important and nearly only thing you need to do. And what you should then do. On the site you should move every element that was on the left side to the right side of the site. And what was on the right side should go on the left side. So for example we usually have the logo on the upper left corner. But on the right to left we should have it on the upper right corner. Sidebar that's on the left side should be on the right side and the content area vice versa. And how we achieve this. Like we have this style.css on root of the theme. There is a place for RTL.css. Which is automatically loaded if we have a language that is right to left. And if you want to manually in queue your right to left things there is this function called isRTL that you can use. And what are the things we need in our styles to mirror our floats. All float left should be float right and all float right should be float left. Asymmetric margins so here you have different margin on the left and right side you should flip them. Haddings, list styles. So on the right to left side the list bullets are on the right side of the column instead of the left side. So they would be here and the text would be aligned on this edge. So you have to make sure that they work. And if you have some JavaScript that is direction aware like masonries or sliders or something like that. There is one nice exception to this and that's Flexbox. By default if you make columns by using Flexbox it takes them from left to right. But if you change the direction element or attribute on the HTML tag to right to left Flexbox automatically adjusts itself to this new order. So that's nice. That's all I have to talk to you today. So it's question time. Thank you very much Janne. Questions over there? Wait to get the mic please. So you said that the performance of PO and MO files is bad but the alternative is storing them in the database. That's faster. Sounds weird. From the both flucking pages that are there there is a long story why it is. But the intention between the PO and MO files is has been using the native PHP get text extension which supports the MO files. But the get text is an extension and not shipped with all the installs of PHP. So instead of using that WordPress has the whole MO parsing code in PHP on its self. And that's slow. The WP performance pack author has actually written the whole MO parsing code again from scratch since the WordPress version is so bad. And the result with the caching is that if you have the object cache available you are actually storing the same array of translations in your memory. So either you store the translation post object from the database or the parsed array of strings from the MO file. But deeper on the issue there is long stories waiting for you behind the links. More questions over there. So I'm just taking this example. I'm setting up a brand new WordPress website. Which character set should I configure WordPress to use? UTF-8 for example. Yes, definitely. And for the database collation as well. So UTF-general instead of Latin one. I think it depends on if you have languages that you finish I think you use the Swedish edition. So you get the alphabetical orders right from the MySQL. Yeah, the collation. More questions. Everyone wants to go home and for beer. How many people have a multilingual site, built among a multilingual site over here? Pretty much everyone. There's a question over there. See that was a trick to get people to exercise. Not actually a question, but a quick note. If you don't want to transliterate like the URLs. Like you want the Cyrillic alphabet for the URLs. There's actually one thing that WordPress does do. And what it does, it encodes the characters in the database. And there's limit like 250 characters there. So you don't have like if you want long URLs in Cyrillic alphabet, you have to take that into consideration. Yes, and I think at least with the Chinese plugin, we faced this limit that the Chinese word transliterations are long. So the plugin has this option where you can limit long transliteration. It will produce so that we don't hit the limit. Any other questions? Hi, you mentioned about the non-Latin characters. Like Arabic and Devanagri and etc. And you also spoke about the fonts. So how do you think a font should be loaded in a multilingual website where there are also non-Latin characters? Should it be all in one file as a web font? Or should it be separate files for separate languages? What we used with the site I showed you with the third in the different languages. Since the different fonts, they are actually different fonts. So not just the subsets of the same font. We include the style sheets for different font faces separately. So a different style sheet for each language, especially with Google Fonts. It's just a different Google Fonts link to all the different languages. Okay, one more question if there are any. Okay, thank you very much, Janne. Kiitos.