 Hello, my name is Chris McGrath. I'm here today to talk to you about our app Kero.com, which you have available in nine different languages. I'm going to talk about the lessons we learned doing that and the mistakes that we made so hopefully you can avoid them. And I should point out that it's human languages I'm talking about here, not computer languages. So just in case anybody was confused. So the talk will be in three parts. The first part I'm going to talk about why we did it and how we did it and give some background. In the second part I'm going to talk about the problems that we faced and the mistakes that we made and how we worked around those. And in the last part I'm going to talk about the tools that are available or are not available and working with translators. What I'm not going to cover in very much detail is the content that's already in the Rails guides, the IH&N guides on rubyonrails.com. It's very well written. You can go and read it there and it saves us going through a lot of boring code. So we're going to try and cover everything else around having your site available in a number of different languages. And it's I've got quite a lot to go through so I'd like it if we could leave any questions to the end. So I work for a company called Portal 47. We have two products. One of them is Kero.com, a property portal. That's the one I'm going to be talking about. That's the one that's in nine different languages. And the other one is something we're working at at the minute called Lokalap, which is still very much in development, but it's for managing Rails translations. So Kero is a property portal similar to RightMove or to DAF, but it's targeted at the XPAP market in Spain. It was started in 2003 as a PHP app and it was just in English then. It's now a Rails 2.3 app and it's in eight other languages. In 2007 we added Spanish, French, German, Danish and Dutch. And in 2008 we added Italian, Portuguese and Russian. So just a little bit of background about the site. It's for state agents are the ones that give us the money. They pay our wages and they pay to advertise on the site. The main visitors are people who are looking to buy our rent property in Spain. So the purpose of the site really is to start conversations between these people and the state agents so hopefully further down the line a sale can be made. So why do we have multiple languages? Well, for us because it's advertising it gives us a bigger reach, a bigger market. The more inquiries that we can send, the more conversations that are to start, the more chances of a sale being made eventually. It helps buyers find sellers. If you have a Russian buyer who maybe speaks Spanish but not English and an English seller who speaks, you know, doesn't speak Russian, it's a bit of a Rosetta stone that they could find if the property was good for the Russian that he has a way of finding it and the English seller has a way of finding the Russian buyer. So that's how it helps buyers and sellers. For state agents it's a competitive advantage for them. The people who, if they're trying to get a client, trying to get a property, they can point to the internet and say, look, we advertise in nine different languages and our competitor down the street isn't going to do that. So you should go with us. And we provide tools to help them translate the property descriptions to standard stuff like close to beach or fitted kitchen into any of the languages. So that's the advantage for state agents. The advantage for us is it's a unique selling point as well. None of our competitors do this. So it's something we can use when we're trying to find state agents and it works very well for us. So that's all I'm going to talk about the kind of why's. How is, there's two steps to making your site available in a number of different languages. The first step is internationalization and the second step is localization. I'm just going to define exactly what I mean by those so that we're all on the same page. So internationalization is the process of developing software that supports different languages, character sets or sets of cultural dependencies without modifying the software. So what it's not is programming in a different language. It's not actually doing the translations themselves. It's using a set of tools to repair your source code to be localized which is the next step. So localization is the process of adapting software to support a specific language, character set and cultural dependency. But cultural dependency there are things like date formats, time formats, that kind of thing. And actually language is a bad term because what you're actually going to translate to is locales. And you can see the example here. It's locales are a combination of a region and a language. And you could maybe include say character encodings and things like that but we've been happy enough with UTF-8 so we haven't needed any of that. So that's all the definitions we're going to do. I'm just going to do a very brief, simple example of how you actually internationalize a site just so that when we go through the further problems everybody at least knows the basics. So this is a very simple example. It's using the IATN engine which is the default for Rails. And what you do is you replace the strings in your template here with calls to T which is an alias to the translate method. And in the call to T you put a key. And when that template comes to run, based on the current locale it will look up that key and pull whatever the correct translation is out. So that works very well and if you've got a variable in your string like name here then you pass it in as a hash with the key of the value. The default simple back end that ships with IATN, it uses YAML as the back end store. So you can see there how the translations would look. You can see how the variables are going to work. It's the same syntax as Ruby 1.9 strings. And you can see how it works in Spanish. And it's very, it works pretty well. It's very easy to do. And it works very well for us. What I want to do is a bit of a side note here. I mentioned a main alternative which is GetText. And GetText uses the base language as the key. So it uses the actual string as the key. And it uses printf style, %s variable substitution. So the original library that we used when we internationalised the site first was globalised. And that used the same stuff. That used the base language as the key and %s as the variable substitution mechanism. And we didn't really like that. We ran into problems with long sentences. We're just horrible for keys. And if we wanted to change the base language, the English text, then we had to go and find all the translations for that and fix them as well. And that was a bit of a pain. I'll show you an example later of why we don't like the %s variable substitution format as well. The second. I'm not a big fan of the GetText tools and the mobile profiles and all that because I think they show their kind of CBS heritage. And it's not, I don't like them. Your mileage might be very, you might like them at all. The reason people like GetText over I18N, I've seen a few people comment on this, is really that they think that I18N is a bit too far, another level of indirection too far. So they want to see the text in the templates themselves. So you kind of have to decide yourself what's going to work for you. And I think the actual tools at Ship of Rails now are built on top of I18N, but I'm not actually completely sure about that. I haven't checked it out myself. But it's something to have a look at if you want to. So I'll just do the variable substitution example now. This actually came from the site when we had globalize. So it was %s, %s, %s, and %s, %s. And if you're a translator, you know, how the hell do you work out what that means? Or how you translate that? So we much prefer the I18N syntax. You can see what the variable names are. And if you need to rearrange them, which you might well do, I'll show an example of that later, you can do it very easily. If you're going to hire a translator, you're going to have more of a choice, I think, if you're using this style, because it's going to be easier to explain to people what to do. I think with GetText you can do rearranging, but you have to do %$2s, %$1s if you want to change the first and second variables around. So that's why we don't like GetText, but I thought I should really mention it for completeness. So the reasons we do like I18N, one of them is we do like that indirection, we do like the separation of the code from the content. And it makes it easier to reuse templates. We like that when you use dots and keys, it gives you automatic namespaces. So it's namespace, and in the YAML it turns it's basically nested hashes. So we like that because that namespacing and those keys are important later when we talk about context, and a translator being able to pick the right translation. So we also like that we can change the English language, our base language, and it will get, we don't have to go through and find all the other language translations and change those. And we also find it handy to use as a mini CMS, so we'll just have a little tiny key and then we'll have a lot of content that comes out of it. And that's worked very well for us. One idea that I've had that we haven't done is to use it for A-B testing so that you can have a method that returns a key based on a cookie or something in Redis, something like that there, and you can pull out the correct whatever strings you're using for your A-B testing, and you can do that in a bunch of different languages. So that's just something that having that extra layer of interaction gives you. So that's all I'm going to talk about, kind of the high now, and I'm going to move on to problems. So when we did our original internationalization we made a bunch of mistakes and I'm going to cover those now so that you can hopefully not avoid doing them and learn something useful. So this isn't an exhaustive list of problems by any stretch of the imagination but it's the ones I'm going to cover today. So string concatenation, text and images, context which is very important, gender and large amounts of content. So I think these are the main problems that you'll have and probably cover like 80% of your problems. So the first one is string concatenation and it doesn't have to be concatenation, it can be interpolation, anywhere that you're substituting strings into other strings or building them up. And we had this problem all over the site and we had to change a lot of different places to make it work properly. And a good example, a simple example of why this is a problem is pagination. So this is a simple, you know, you've all probably written the top line in that a few times in ERB. You got two variables there, the page number and the total, and if you were kind of being very naive you might think well I'm using page all over the site so I'll translate that separately. I'm using off over the site so I'll translate that separately. You probably wouldn't think that badly but it's an example of the kind of thing that can go wrong if you're adding strings together or interpolating them. So with larger sentences you do have a problem with that. So the reason this particular example is a problem is sentence order. Not all languages have the same sentence order as English. And in Japanese the total will come first so you can see with the bottom example there there's no way you can actually make it make sense in Japanese. So this kind of thing is better done like this. We use a key and you're passing in the variables and then you can see easily there that you can rearrange it however it needs rearranged for the target language. And that works very well and it's easy. So I could go on for the rest of the talk talking about all the different ways that this can mess you up. Instead at the end I'll give a list of links and one of them is to an article called text fragmentation and reuse in user interfaces. And it basically goes through all the problems that you can have if you're naively substituting strings into sentences. And it's well worth the read before you do any internationalisation. So that's lesson one which is the first lesson of internationalisation club is don't concatenate strings. And the second lesson of internationalisation club is also don't concatenate strings. So that was one problem we had. Another problem we had was text and images. This is the second mistake we made. Way back when before we started the internationalisation process we paid an external designer to do a very nice design for us. And this was before modern browsers really so we had to have some text and images. And when we were doing that we when we were doing our internationalisation we suddenly thought oh well that means we need two versions of all these images for each language that we have. And we weren't going to do that. It wasn't going to happen. So we basically had to redesign the entire site. It wasn't just text and images either. It was button backgrounds that were sized to the English text. And you can see here from this is the top nav bar on the side you can see how much more space German takes up. English is actually one of the most compact languages. So in general when you do localisation it's going to take up more space. So it's something that we are fixed with images didn't really handle. So we had to do a whole redesign of the site which was fun you know. So that's one problem with text and images. Another thing to do with design here is the space available. And it's the length of the translations. It's important that your translators whoever is doing your translations can see where the translation is going to be used. And I'll talk about that next when I'm talking about context. If the best word is a long word that's not going to fit they need to be able to see it to know that they can put an abbreviation or a shorter word even if it's not the best translation you know something that's going to fit. So the example here is from the sites from our search drop down. And if you excuse my accent in French it's Salon de Bain. That's never going to fit in there and Chris is our other developer. He does the French translations and he does the design as well. So he knew that STB was what had to go in there. So that's lesson three. It's two lessons for the price of one. It's don't use text in images which is a no brainer these days anyway. Design for different text lengths. Make sure you can handle it. So the next thing I want to talk about is context. And it's it's really the big one. It kind of underpins everything. It's it's something we touched on before. We've been able to see the translation in context to know what space is available and what words you can use there. It's important for the translator to be able to pick the right target language word. And it's a reason for having human translators rather than whacking stuff through Google Translate. A human translator can work out what's meant, you know, whereas putting something through Google Translate doesn't know how much space you have and B if there's a number of different phrases that it sends back to you, you don't really know which one to pick, which one's right. And a simple example of that is the word floor. We use this in a couple of places in the site where we see it in a couple of places in the site. We see it in descriptions of properties. So we see a wooden floor or marble floor, that kind of thing. And we see it in descriptions of apartment locations like first floor, ground floor, top floor. That all works in English. You can use the word floor interchangeably there and it's not a problem. In Spanish, you can see here there's two words that you can use. And the word for the floor of a room is suelo. And the word for the floor of a building is planta. So a translator, if they see floor in their translations that they're doing, they need to know the context to know which one to pick in Spanish. It's a very simple one-word example. You have this problem all over the site and with any kind of phrase the context really is important. Because as well, if a translator knows the context and knows where it is, they can use their knowledge of both languages to make a translation that's of higher quality. So this is one of the reasons why we like the 18N keys. This is a bit of a contrived example but it shows that if you were a translator and you saw the key was room.floor.type and you're translating into Spanish, you're going to be able to go well, that's suelo. And if you see lift.panel.heading, you go oh, okay, that's planta. So that's one reason why we like keys. And having a good schema for your key names is going to help your translators figure out the context. Another thing that can help is having a glossary. So if you were doing a flooring supply site, for example, and you're going to be using suelo everywhere, then you do a simple glossary for the translator that says every time you see floor, use the word suelo. And that's a very simple example but if you have a very technical term that you need translated precisely and you need it to be the same all over the site, then again a glossary is something that you can use there and it'll definitely help with context there. It's kind of a no-brainer that if you've got if you're doing ongoing translations, if you use the same translator if they're doing enough work for you, it's good enough quality, keep using the same people and then they'll know what words you use on your site and they'll know what space there is available in your layout and they'll be able to pick what the good words and do good quality translations. So a kind of ideal that I have for the app we're developing is on page translations and this example here is from another app called chufnik.com so it's a web app that runs in a kind of translator mode you can see the words in context you can click on them, you can type in the translation and you press return and in my ideal solution, you know that gets sent off to our app and then magically appears in your reals YAML files or whatever your backend is and you can see how this really solves the context problem you can see stuff on the page where it's used you can see what space is available and it really is an ideal of the kind of interface that we'd like to have I think so this is something that isn't probably immediately obvious when you're talking about internationalization and localization but context really is important if you're going to you know your site, you know what words are used were a translator is coming in generally cold so you need to have some way of helping them find out what the context is so they can do good translations so that's lesson 4 which is make sure that your translators can understand context and find out where stuff's been used so the next problem we had on the site was gender and it's the biggest problem we had after context and because we use English as a base language in English you don't generally have to change the other words in a sentence depending on what now you're using with other languages you do French obviously being the example and a good example of where we have this on the site is property types we have like 10 different property types and we have a number of adjectives that we put together with those and that works okay in English but it doesn't work in French I'll show you an example in a second there's two real kind of solutions to this one is to try and have a key for each combination of sorry, noun and adjective and the other is to try and rearrange the sentence to get around the problem so different keys works best because the translator can pick the exact right language to use but obviously if you've got too much of if you've got too many combinations it's going to be a combinatorial explosion and it's not going to really work so the example I'm going to show you is for I'm not going to show you all 10 property types I'm going to pick three which is apartments, villas and townhouses so this is how you might start off doing it and that works okay in English you can have a luxury villa you can have a luxury townhouse luxury apartment that's all fine, that works but you can't translate that into French because in French you have to use luxeux or luxeuse depending on the type of the property so the way around it is to build up your key dynamically I've just shown a dot key method here you could use table lines and rails to generate your keys and you can see that in the translations that's all going to work and that the French is using luxeux and luxeuse properly and that's great and it's it's manageable for us we have like 10 property types and 8 adjectives that we combine them with and not all of them combine you don't have new land or luxury commercial property so it's just about manageable but when you have more or you have words combined in a sentence it's not really going to work so back to this was the original percent s percent s and percent s comma percent s complex sentence and it's actually a bad sentence anyway to translate because even having the variable names doesn't really help because you're not going to be able to do the gender correctly in different languages and we can see it's a substitution problem as well concatenating things together basically so the actual example where this is from it's from the rss feed title in our site so when you do a search for a specific set of criteria you can get an rss feed of the results and every time you refresh it in the browser if there's any new properties they come up so it's not hugely used part of the site people who know rss use it but it's it's not important but it is something we want to keep around so if we wanted to have a key for every combination in this sentence we've ten property types, there's four payment schemes, we have five location levels which change the text as well and we have adjectives like coastal and inland and I worked it all out and depending on how many of those we wanted to use there's between 40 and 320 combinations and for rss property feed title we're not going to translate it 320 times or even 40 times in 9 different languages on the site it's just not going to happen the way we worked around it was to realise it's a title it doesn't really need to be a sentence as such so we can rearrange it and this avoids the problem and it's actually easier to scan in your feed reader so it's plural property of name, payment scheme title and location name and that worked in this example because we went into a list and when Chris was doing the French translations that's how he works around a lot of the gender problems that we have by just essentially making things less of a sentence so that works okay for us, it's not ideal but it's good enough for us at the moment anyway if we wanted actual French proper French sentences we're going to have to look at another solution for that one thing I came across when I was researching this in GitHub it was called genderise and that had a way of having your translations having your genders in the actual strings so you didn't need 10 or 20 strings or however many combinations you needed so that actually only had it supported masculine and feminine which is fine for French and Spanish but it's not going to work for German because that has three genders it is neuter as well and then Swahili actually has eight genders Cantonese has won thankfully so that's easy enough so that's really the next lesson is to try and avoid complicated sentences in I suppose a general principle anyway of not having big flurry prose on your site but the less there is there are to translate, the easier it's going to be to translate so that's lesson five the next lesson is to talk about is large blocks of content and that's things like emails and terms and conditions and help, that kind of thing the first mistake we made when we did this was we went through our templates and we translated each individual sentence on their own and that ends up being a concatenation problem as well as a context problem so it didn't really work so the second thing we did was the original globalize and Rails now supports having the locale in the template name so if your current locale is spain es niva.es.html.erb it will pick up that template and use it instead of the base language key one so that is okay and it kind of works but the problem we have then is getting the content that's in our files to the translators we use Hamel so we don't really want to have to explain Hamel and keeping indentation right and all that to the actual translators we don't want to have to give them access to our source code and if you're a developer and you sound yourself well I have to copy this template nine times obviously warning bells are going off in your head going well I have to change it in one place then I'm going to have to change it in all those other places so we're not entirely happy with that solution at the minute we'll move towards using keys like a mini CMS where we'll have the content in our actual tool itself we're using to manage translations so one thing it does do is it keeps all these big blocks of content out of your YAML file and you don't really want to be hand editing YAML files especially not if it's all this kind of you're trying to keep a template and code formatted and you want to avoid that so you have to kind of think of the workflow of how you're going to get the large blocks of content backwards and forwards between you and your translators so that's lesson six and that's really the lessons that I want to talk about the there's other ones that you can come and talk to me after I can tell you lots of war stories about doing it next I want to talk for a while about the tools this is the third part of the talk so i18n doesn't have anything built in unless you can't hand editing YAML files as being built in and we've always ended up building our own solutions to do that to handle our translations and I'm going to explain kind of what the problems that we want to solve are to show you why that we've we've always ended up with our own so the main thing that we do is when we launch a feature we launch it in English first and then it so I'm useful back so for a while all the other sites have the Spanish site has some English in it until we do the translations and approve them and when we were on Rails 2 and Globalize 1 we built something on top of that which was we put the translations at the bottom of the page by Monkey Patch and Globalize and we ran a dev mode listener against our production database and they could type in the translations and then when we were happy with them we just restart the production listeners and the site would be all the English would go and it would be in Spanish or whatever language so that worked okay for us it wasn't perfect and we had a list of things that we'd like to do better but it was good enough that the effort required to do all that extra work wasn't really worth it so we still had a list of problems but it was the all lower priority than other stuff we wanted to do on the site so when we upgraded to Rails 2.3 and to the IH and NGM we had to throw all that away and it wasn't a problem to start with because we wrote another tool to one off throw away thing to port our translations from Globalize's database, pull them out of the database and put them in YAML files and put the keys into our source code and that worked okay it wasn't very pretty but it worked and we had our old site back as it were and all the translations in YAML so that was fine but there was nothing really for us to to work with new translations for new features we kind of looked around to see what was available at the time the first thing we looked at was an open source thing called TOE which is 37 signals used that you still have to hand edit your English YAML files in the base language so that didn't really work for us and there's a few older ones that I've noticed over the years but they don't seem to be maintained if you can have a look around GitHub for some of these things so we didn't really see a solution in open source so we looked around for other basic stuff for the service style solutions and there's a few different ones my Gango, WordChuck 99 translations, WebTranslate it the one where we're building ourselves some of those we'd seen before we made the decision to build our own and some of them we'd seen after I'm not going to do a feature comparison or anything now but most of them didn't really do what we wanted there was too many manual steps or just something that we didn't like doing so to explain that a little bit I'm going to talk about just kind of three big requirements that we have for the two, the three main problems we want to solve so I've talked about fallback and the IT and NGM actually provides a fallback backend that you can use it's very easy to use so that's fine we want it to fit into a development process and what I mean by that is we don't want to be having to do very much outside how we'd normally develop code and we definitely don't want to be doing any using YAML around or any of that and we don't want to be having to run scripts to sync translations down we want it to work very smoothly and as I've kind of touched on before we want it to be usable by translators with no technical knowledge we're a distributed company so it has to be a web app but most of our translators are all over the place as well and they have to be able to use it easily we don't want to have to explain Rails to them or to explain HAML that kind of thing so I've talked about the first one already I'll talk about our development process we use the GitFlow model so we'll develop features on a feature branch when we're finished with those we'll merge them into our develop branch when we've got enough stuff on the develop branch and we're happy that it checks out on stage we will do a release to the master branch and then deploy that to the site so that works fine and the problem that we have to solve with this is that when you're developing a new feature you're going to add some keys you're probably going to remove some keys and you're also going to have updated a key that's on the live site so what you don't want is to be changing translations in whatever tool you're using to manage translations and having that break the live site because you haven't deployed a feature yet so that's so we need some way of basically blocking certain translations from being sent to our live site to avoid that until we've done the right deploy but that kind of conflicts with the other requirement that we want which is that when we've deployed a feature in English when the translators do their translations and we are happy with them we approve them we want that to automatically go to the live site without us having to do anything so there's two conflicting requirements there we haven't quite solved it with our app yet it's the next thing we're doing we think we've worked out how to do it technically but the hardest thing is really the user interface to make sure you don't either have fields of checkboxes or lots of confusing stuff on the page that you don't use all the time this is something we want to use ourselves we're pretty confident we can make it kind of smooth and make it fit in with what we want to be doing so those are really business requirements and developer requirements for the translators themselves there's two sides to it really the one side is finding them which I'll talk about next but managing them seeing what their progress is improving translations that's all standard web app stuff so it's not that interesting really for the translators doing the translations themselves I've said the ideal is for them to be able to just look at the page they're translating and type it into that web page that's not something very many people have very many tools have so we want to add in other ways of helping a translator find context like where specific keys were used, what URLs, what path what routes even maybe so that's a bit about tools it's a changing landscape there's a lot of different requirements because it really depends on how your development process works and whether you're happy releasing English versions first and having it fall back if you weren't then you might not have the same requirements as this so I think there would be more solutions over time but that's lesson 7 think about what the requirements are and make sure that the tools you pick and the tools you use fit into your development process so next I'm going to talk about finding translators so the important thing to think about when you're going to go and try and hire some translators is how good quality you want that's one thing you need to kind of have an idea of how many locales you're translating into is it just two or is it 20 because that will affect your decision is it ongoing are you going to be developing this site like we are and you need ongoing translation work done or is it just a one off the most important thing is obviously budget how much money you have to spend and all this so there are different types of translators which one you might pick really depends on your answers to those questions obviously if you can speak all the languages yourself and you're happy handed out in the YAML you can just go and do it you might have friends or colleagues who can speak multiple languages and they'll help you out you might want to hire a freelancer and the website that they all hang out on you can go there and I think pretty much find a translator for any language you want there are translation companies and I'll talk about them in a second you can do machine translation and Google Translate as long as you're happy that people might laugh at your translations when Google Translate there's English ones for you so another thing you can do is try crowd source translations and there's two real ways if you're big enough like Facebook or GitHub crowd source translations can work or if you're small but you're prepared to be patient and find a customer who wants it in their own language and they'll do it for you that could be a way of doing it as well so you have to decide kind of where you are this made up graph here the LSPs or translation companies they are language service providers and they're kind of traditional enterprise-y companies that the kind of people you'd hire if you wanted a printer manual translated into 50 different languages and we looked at those when we were looking at tools and they wanted like $10,000 up front and us to be spending $3,000 a month with them so really it was kind of out of our league and they weren't interested in us below that so I think a lot of people here are going to be not wanting to spend that much money on having translations done so but the best software as a service solution is another is probably what's going to work best for kind of Rails and Ruby applications I think and like I said, keep an eye on what tools are out there because it's a changing landscape we don't have freelancers on that slide but if you hire a freelancer a lot of them use a system called Trados and it basically you can send them if you're doing a one-off project you send them a text file full of strings they'll import them into Trados do their thing and send it back to your translator and that could work very well if you are doing a one-off thing and the way they tend to work to what that software gives them is called a translation memory so every translation they've ever done is stored in there so when they get your file they'll just run it through that see what matches and it works so it's faster for them but translators tend to get paid by the word anyway so them being faster helps them it doesn't really help you very much apart from having faster translations so that's the lesson 8 think about sourcing your translators before you start so assuming you have started and you've localized the site and you don't speak the target language you're going to have to think about the quality control on it so the highest quality we have on our site is in English and in Spanish and we have people who can speak English and Spanish and we can work that out the others aren't quite as good because English and Spanish are our main traffic so that's the ones we concentrate on we'd like to improve them but there's a cost-benefit ratio there and we're kind of happy enough with lower quality for them it's important that we have the site in nine different languages so it's not quite as important that those be very good translations so with Russian we how do we know that's good none of us speak Russian none of us read Cyrillic so what can we do to figure out if that's even in the right ballpark with the translation and the first thing you can try is just running it through Google Translate backwards just to check that it's roughly right so that's just a quick sanity check if you're not you can hire another translator for that language separate to the person who's actually doing the translations to do QA for you just to make sure it's right and if you hire a learning service provider a language service provider that's part of what you're paying the extra cost for is they will have a team of people and some of them will do the translations and some of them will check them for quality and the last thing you can do is just wait for people to complain and see and change it then so it is important to check quality though because this example here is from the Russian Academy of Sciences which is a Guardian article about this not so long ago and they were doing the English version of their site and they were translating the Institute of Protein Research which is the Institute Belka and Belka is also the Russian word for Squirrel so on their site the Squirrel Institute so it's important that you have at least some way of checking that it's roughly in the right ballpark so that's the final lesson is check translation quality so that's all my lessons I'm just going to sum up before taking some questions so if you know you're going to be localizing your site internationalize it from day one it's a lot easier when it's done that way and you might get some side benefits out of having that layer of interaction between your templates and the actual content think hard about what quality level you need does it need to be perfect or not the IT and NGM is not designed to do everything for everybody but it's designed that you can build on it quite easily it's got a fairly simple API so you might have to do that if you're doing something that is not covered by it you might have to write some code yourself or see if somebody else has done it so like I said this is the third time I'm saying this thing but keep an eye on the tools and what's around what's available they're getting better they're improving all the time and hopefully we'll build a good one that you'll want to use and lastly is of course don't use string concatenation so if you don't remember anything else remember locale app and don't use string concatenation thank you very much for listening thanks for having me speak and if you've got any questions I'll answer them now yep yep yes so it's not actually a similar question it's a war story but which is if you're internationalising just do one language first and do it from the start because we had to do this we had to go through all the templates when we were changing to IT and N pulling all the text out and replacing it with keys it's horrible it's done now oh sorry yep we just basically we launch a feature and it's in English and it will appear in English on the Spanish side and on the French side and on the Russian side until we've done the translation so we're happy enough that nobody's really going to complain or if they do complain it's only going to be for a couple of days until we have the translations done so it's just the simplest thing to do we don't have to and then it also means we can work out the bugs in the English version first and we don't have to wait for all these translators all around the world to have everything translated so yep yep yep do you mean functional? I'm not sure what you mean yep the question is about having multiple code bases or one code base and that's really in the definition of internationalisation is making your source code using tools to make the source code work in all different localisations so you only ever have one source code you don't ever have two versions don't start another branch for French you're dead if you do that Dave well the agents can submit if they submit a feed to us they can use most of their systems have little check boxes for near beach that kind of stuff they send that through in the feed and we automatically translate that and we also give them tools if they just want to type in the text to do that so something we'll probably offer further down the line is doing automatic translations that kind of thing the question is do we put markup in the translations and the answer is yes we do in some places yeah in general they are most of them especially ones that are doing web translations are okay with html and probably even erb if we wanted to use that because they're probably used to translating PHP apps as well so they're generally okay with a little bit of technology yep right we don't at the minute we use subdomains to decide on what the locale is our roots are all in English and then what we do when you do a search we don't have a query string it's basically a browse code it's just a little code it's basically all the search parameters squished together and we put localised text after that based on what the code is okay I think that's my time up so thank you very much and er I can drink tonight no