 Okay, I think we'll get started. Today we're gonna be talking about building multilingual websites in Drupal 7. And we're gonna be focusing a lot on the options that Drupal 7 has for us that we didn't have in Drupal 6, so things like entity translation. And we'll be walking through the process of configuring a Drupal site and talking about some of the challenges that you face as site builders. My name's Suzanne Kennedy and I work at Evolving Web in Montreal, where we do an awful lot of multilingual site building, it being a very bilingual place. Hello everyone. My name is Florian Lorten. I'm from Wunderkraut, we're based in Munich, Germany. I'll be talking about the content registration part, but for now I'll let Suzanne do her part on pretty much everything else. So this is the outline we have today. First of all, talking more about planning the site and questions to ask before you start building. And then we'll be walking through the process of setting up the site and translating the different aspects of Drupal. And then we'll wrap up with some of the outstanding challenges we have in Drupal 7 and where things are going for Drupal 8 with the multilingual initiative. So to start off, what do we mean when we say a multilingual site? This can mean quite a number of things in Drupal. It's most basic. We're talking about a foreign language site where you would install a language other than English on your site using the locale module and where the user interface would be in the other language as well as all the content and other elements of Drupal like blocks and menus. And then adding a level of complexity to that, we have multilingual sites. So websites where more than one language is enabled on the site. And here in addition to locale, we need the IATN module, which allows us to translate things like menus and blocks. And because we have more than one language on the site, we wanna be able to flag pieces of content as being in a particular language, which we can do with the locale module. And then adding one final level of complexity, we have multilingual sites with translation. And this means that you have a language switcher on your site and you can switch the language back and forth. And the content on the site is mapped together in translation sets. So if you're looking at the about us page of a website in English and you switch the language of the site into French, then that content is mapped to the French translation and you see that there. And in addition to locale and IATN, for these types of websites, we need a module to do some type of translation. So either the core content translation module or the entity translation module, which Florian's gonna talk about quite a bit in the next part of the presentation. So before you start building a multilingual site, there are a number of questions that you should figure out. So if you have a client, you need to sit down and talk about these with your client or if you're building the site for yourself, you need to figure these things out. First of all, what type of language support are you providing across languages? So what type of language experience are you providing to users? And a lot of the time, this comes down to the resources you have to actually come up with the translations as well as what your user's expectations are. So are you creating a really consistent user experience across languages where everything is translated? Or are there gonna be certain elements that are missing in certain languages? In a lot of cases, it's just the most important content of the site or just the static content of the site that gets translated. So in certain situations, you're gonna want to create a fully symmetric experience across languages. So this is a site I built for Travelocity last year and all the content had to be translated into eight languages before it was published. So there were really strict restrictions on content being consistent across languages. But in other situations, you're not gonna have that luxury and you're gonna have a lot of content that's left untranslated. So this would be an example of a site where if you switch the language from French to English, a lot of the content just disappears and the menus are much shorter. For example. And in a lot of other cases, you'll have sites where there's mixed language experience. So this is my corporate website and at some point we translated all the static content on the site but things like user profiles and portfolio items and blog posts don't get translated. So if you switch the site into French, you'll see all of that content in English. Which leads to the next question of whether or not you want to show untranslated content on your website. In a lot of cases, I think it makes sense to show untranslated content. On the left, here we have an example from Node 1's blog and they have a lot of users who speak Swedish and English and so because they have that type of audience, it makes sense to show content that hasn't been translated into the other language. And then on the other side, we have an example of comments from trippadvisor.com and they also show untranslated comments which are valuable to users because you can see the rating that users have given. You can see the number of comments that a restaurant or a hotel has received. In other situations, it's not gonna make sense to show translated content so you can choose to hide untranslated content. This is just a corporate blog where content that is translated is shown and content that's not in the current language of the site is hidden. A really important thing to figure out before you start building the site is whether or not the expectation is that the language is related to a region. A lot of people expect that when a site, when you switch the language of the site somehow the currency also changes and the time zone also changes and we're not really gonna get into that in the talk today. It's kind of out of scope for this session but that adds a lot of complexity to the site and so you really need to figure out whether that's a requirement. For example, when you try and switch the language I think on Apple.com, you're presented with an actual region selector so you're not selecting the language so much as the location. It's also a really good idea to try and figure out who's doing the translation. So what's the process for translating things like user interface and comments? Is the content always being translated from French to English, for example? Is the translation gonna be outsourced to a third party? Also important to figure out whether the administrative UI needs to be translated. If your administrators or your translators are logging in and they need to see the site and they don't speak the default language of the site, if they don't speak English and you have to translate all of that administrative UI that can be a lot of overhead. Especially if translations for the languages you're using aren't, there aren't a lot of translations contributed already. This is a really important one that I would really recommend figuring out before you even start prototyping your website what the default language of the site is. And there's two components of this. First of all, considering what the language, the majority of your users speak because the default language is used by Drupal to determine the language fallback for the site when determining what language to display the site in. And also for site administrators, when they're entering configuration settings in a particular language, that language should be the default language of the site. So hopefully your site administrators and your site users speak the same language and that'll be the default language of the site, but if they don't, then you might have a more difficult decision here. In a lot of cases, the language also affects the design of the site and has some impact on theming. So for example, some languages take up a lot more space than others and you'll need to take that into account. Also, certain fonts that you might want to use might not support all the characters that the languages you're using would require. And if you're using right to left languages, you'll probably have to add more CSS files to make sure that you have a layout that reflects the right to left mode. So you can see here that the sidebar would be on the right for right to left languages, whereas it would be on the left for left to right languages. And finally, something to figure out by looking through your wireframes is what type of your text you're translating in Drupal. Drupal has all kinds of texts that it stores and from content to user interface strings and it's a really good idea to look at where all this text is coming from. So you have UI text and we have more content-like text. First of all, we have variables. So these are strings that are stored in the system table in Drupal, things like the site title and the site slogan. And then we have text that's stored in code. So this is text that's passed to the translation function and this would be code like Drupal core modules that you're installing as well as themes. We also have user entered strings. You know when you're configuring views, you end up adding a lot of text to Drupal so you're adding maybe a title for your view, maybe the read more link. In my example here, I have the label for a field in a view and all this text that you're adding as the administrator also has to get translated. Then we have content, so nodes and other entities like comments and users and taxonomy terms. And finally we have something called text groups, so things that don't really fall into these other categories that are kind of like content but they're not entities. So menu items and blocks and things like field settings. So taking an inventory of all these things, looking at your wireframes and trying to figure out what text is gonna have to be translated is a good step when planning your multilingual site. So now moving on to actually building your site. The first step would be to set up the languages, install the languages that you need to support and choosing a default language for the site. And one thing that people struggle with a bit is this language detection and selection configuration. So you've installed a couple languages on your site, now Drupal needs to know how to determine which language to display the site in. And usually this is kind of obvious, right? Like the language is specified often in the path to the page you're looking at or in the domain. But there's other factors that can determine what language Drupal displays and Drupal needs a fallback in case the language isn't specified in the URL. So this would be a typical configuration. The first method of selection that we're using here would be the URL but if the language isn't in the URL then Drupal will look at the user's profile to see if the user has a language preference there and it'll use that. And if the user doesn't have a language preference then it'll look at the browser settings because your browser actually has a language setting so if that's set to the English or French then Drupal will use that. And finally if there's no language set in any of these methods then Drupal will use the default language of the site and display that as the fallback. So for example if you go to, using the configuration I just showed you if you went to example.com slash fr slash user then Drupal would show the site in French but if I just went to slash user and I'm not logged in so I don't have any language preferences in my profile then it would just go to slash user because it would use my browser settings. So the next step would be translating the UI of the site. So we already talked a lot about where the different types of UI that you can translate. And the first one is variables. And to translate variables in Drupal you need to use the I18n variable module. So it's a variable is a sub module in the I18n suite. And the first step is to actually select which variables you want to translate. And in Drupal 6 we had to use this by adding these variables to the settings.php file which was a little bit of a clunky solution. So now in Drupal 7 we can do this through the UI. So there's a page you can use to select which of these variables you actually want to translate. So I've selected site title and site slogan. And then to actually translate these things I need to go to the page where they're set in Drupal. So the site information page has some of the core variables on it like site title and slogan. And those fields are marked as multilingual variables. And to actually enter the translations I need to switch the language of the site. So if I wanted to enter the French site title I'd need to switch the site into French. And for that reason the variable module inserts a language switcher into the page if there's variables that are configured on the page you're looking at. And some variables are not text settings and you might wonder why you would want to translate these. And in some cases you might want to translate something like the time zone of your site if the time zone was dependent on the user's language. So now we're gonna move on to translating UI strings that are stored in code. So for example if you wanted to translate the login button in the user login form so there's a search UI that you'd use for this the translation interface and it's not the most easy to use translation UI in Drupal but basically you enter into the search the string that you wanna translate and it'll show you the results and you can add it the translations that way. And for user entered strings it's really similar so for strings that you've entered say when configuring views or another module then you'll use the same translation interface to find the strings that you wanna translate. And the catch with things like this is that Drupal is actually using the English string as the key so if you change the string in views like if you change the original English string and in your views configuration then this is gonna break. So that's why it can be really important to map out the translations of your user interface strings in advance. And now Florian's gonna talk about translating content. So translating content is kind of a different beast because all these user interface translation that Suzanne has talked about these are generally things that need to be done once when you build a site and then as long as there's no major modification to the functionality of the website there's nothing that needs to be translated. The strings don't change and there's no need to translate text. However, content is typically the part of the website that is changed regularly. And this is not necessarily going to be done by the people who built the website but it's going to be done by the people who entered the content maybe translators who are while who are working on the site specifically to just translate the content. And so in this case we really need to spend some more time focusing on what is going to be the translator's experience. We don't want to show them that table that you just showed. We want to spend more time just figuring out what is the translation workflow. And we need to make sure that the translation model that we have is something that our editors or translators can understand. So for translating content there's actually two major models. The first one on the left is the node translation. This is the translation method that you get by default when you enable the content translation module that comes with Drupal Core. In this translation model you have pieces of content and when you translate a piece of content well you have the English content that was created first and then you say I want to add a translation in French and I want to add one in German and at this point you just create additional nodes that just have a connection that's saved in the database that says these three different nodes are actually the same thing in different languages. The drawback of this is well it pretty much comes down to instead of having just one piece of content that is available in multiple languages you actually have multiple pieces of content each of which has its own identifier and it has a tendency to cause problems anytime you need to make references between pieces of content or references between comments and piece of content or any kind of relationships that take place as part of your content it's going to be a little bit difficult. Also there are parts of the content that will not be translated typically images and in this model well you will have one image that is there for the French node one image for the English node maybe it's just a reference to the image but you're actually storing duplicate information and all these duplicated pieces of content need to be somehow synchronized this is not very elegant. On the other hand we have field translation and this is enabled by the entity translation module and this is what I want to focus on a little bit more today because this is something that is pretty new it's pretty exciting it wasn't possible to do before Drupal 7 and many people don't know about it yet so I want to tell you a little bit more what are the advantages of using entity translation and what are the drawbacks as well. But before we get into entity translation and node translation there's a couple of things that are common to all of the translation mechanisms for content in your content type configuration you can choose how the content will be translated so you could just say well this content does not have any language association you could say that well each piece of content has a language but it doesn't get translated this is particularly meaningful when you have user generated content which will not get translated but you want to just separate things so you know what's in French what's in English, what's in German but there's no correlation between the French piece of content and the German piece of content then you have enabled with translation which means that it's going to be using the core translation mechanism and you also have the entity translation mechanism which is also available then for user interface when you are viewing a node that is of a content type which is translatable you will have a translate tab or in French traduire and you will just click on the tab you have an overview of what content well what translations are available if one is not available you can add it and if one is already available you can edit it so the user interface at this point looks pretty similar for both mechanisms there's some slight variations but the difference is really in the way that it works internally so for the field level translation which works with entity translation what we're working is we really we're working at the field level and this is taking advantage of one of the new things that's in one of the new functionalities that's part of Drupal 7 is the fields API and if you look at the structure of the way the structure of the data stored in fields you see pretty often well you always see this language code that's part of the language structure of the field structure and if you wondered why is it there well it's there just so that we can save multiple values in different languages and so the ability to do that translation is part of the fields API there's just no user interface for that and entity translation is actually providing a user interface that lets us take advantage of this multilingual storage mechanism the advantage of this is that we have a structure for storing the content that is really semantically correct there are things that get translated and they get saved in multiple languages there are things that don't get translated and they're just saved once typically you have text fields which get translated and you have image fields which don't get translated although there are some cases where you want to translate images and there are some cases where you have texts which will not get translated so it's really up to you to set what is meaningful for your structure so in the field configuration settings you can decide for every single field will this field be translated and this is one more of this point where you really need to spend some time thinking what is meaningful for my very specific case the advantage of entity translation is that it doesn't only work for nodes it really works for any kind of entity so it works for nodes it works for users so you can translate user profiles it works for taxonomy terms this is, I think in my opinion the use of entity translation where it really shines and it provides a much better alternative than the ITNN taxonomy translation method which is kind of more a solution that is grafted on on the taxonomy terms but it doesn't really store the data store the translations in a semantically interesting way well, a semantically correct way with entity translation you can also translate comments doesn't make much sense but if you wanted to, you could and of course since it's built on top of the fields API it really works with any kind of entity that can have fields that can be fieldable so as I mentioned all fields can be translated and entity translation also stores additional metadata about each individual translation so when was it added? who added it? is it published? does it need to be updated? but there are things that don't get translated the author, the promotion status the creation dates all these properties of nodes and other entities that are not fields so most of them we don't care about it but one of those it's very important is the title property and the title of a page the title of a piece of content it's generally something that you really want to translate it's not optional it's a requirement and just for this case there's the title module the title module lets you replace those text properties it replaces them with a field and kind of works transparently once you've replaced them so when you load a piece of content it will automatically load the value from the field and save it and set it to the title so it works pretty transparently and it works for node titles it also works for taxonomy term names and descriptions and as I mentioned it works pretty transparently there's just one case where it might be a little bit surprising and it's when you have listings because when you have listings the database is queried directly and it's a little bit more difficult for the module to just do its magic automatically so when you create a view where you want to select well, typically a view where you just want to show the title of a list of nodes use the replacement field and not the original property this is a little tip I'm making a slide just for this because I've seen a lot of people waste a couple of hours of work just trying to figure out why things were not getting translated so use the replacement fields not the original properties as you mentioned before sometimes it's not possible to translate everything translating is a lot of work translating content is a lot of work and sometimes the clients well, they just don't have the resources to do that and sometimes you just want to show everything that's even though it might not be translated and with the standard translation mechanism this can be a little bit difficult to have that kind of fallback mechanism the entity translation is actually providing great fallback mechanism where you can decide that if a piece of content is not available in the current language then it will go through the lists of languages as they are defined and just pick the first language where the content is defined this is really a huge benefit when you have websites with a lot of content typically what we use this on is, for example, a product catalog where you have thousands of products which are not going to be translated but at the same time you really want to show that content because there's a lot of information that is relevant to people even if they don't speak the language that the content is in one of the questions that we get a lot is, well, so entity translation is this new translation thing that does everything do I still need IATNN? and the answer is yes, you do because entity translation really helps you work with translating content but there's a lot of things that are related to content which are not content themselves so for example, menus also the fields that make up your content they have properties like the label of the field the description for the field these are all texts which are kind of related to the content but are not content themselves and so for all of these add-on texts you still need IATNN which lets you translate those however, there's a couple sub-modules from the IATNN suite that conflicts directly with entity translation one of them is IATNN select which filters out content which is not in the current language and this really doesn't work work nicely with entity translation so disable IATNN select if you want to use entity translation and our one is IATNN taxonomy it really does exactly the same function well, it provides the same functionality as entity translation but just for taxonomy terms and does it in a way that really doesn't work that well so if you're using entity translation for taxonomy terms you don't need IATNN taxonomy I think that IATNN taxonomy given that entity translation is now available IATNN taxonomy should be deprecated so it seems like entity translation really solves a lot of those common problems that people have had with the content translation but there's a couple of things that still need to be figured out for one the integration with other modules still needs some work typically for the user interface for example when you have the overview of your content you have a column that shows the language and typically this is the language of the content but when you have entity translation enabled it kind of changes the meaning of that column and it's not the language of the content anymore it's just the default language that the content was created in so it can be a little confusing for the editors who are just looking at the site and so there's a couple adjustments that are needed another thing that doesn't work that well is revisioning because revisions are really per entity and what we would like to have is revisioning per language and this just doesn't work that great and this is a very, very difficult problem I'm not sure that we can find a solution for revisioning with entity translation that works for Drupal 7 this is something that we might be able to solve before Drupal 8 but this is a very difficult problem and also menu items need to be translated separately so you have your content and you have the menu item that points to the content and usually with the standard translation mechanism you can just have different menu items for different pieces of content this works pretty transparently however when you have entity translation you really need to translate the menu items and translate the content so it's one more step it's something that's not very elegant from the workflow it's something that's kind of hard for the translators to work with but overall for many use cases it's a great solution we've been using it at Wunderkart for a couple of months now well yeah we started last fall and since then we've been using it pretty much exclusively we're not using the content translation from Drupal Core anymore it has a couple quirks that people need to be aware of when building sites but it really solves a lot of common issues so I would really encourage all of you if you have a multi-linked website give entity translation a try see how does it work, how does it meet your needs and I think that it's a solution that is very promising for the future and I think that what we'll have in Drupal 8 will be based on a lot of those new concepts and now, step 4, translating everything else so we've talked about translating the user interface and we've talked about translating content but there are still a few elements of Drupal that don't fall into these categories things like blocks and field settings, menu items taxonomy terms are translatable with entity translation but also with I18N so all these elements here are translatable with the I18N module and just to give you a couple examples although I should point out that we do recommend using entity translation for taxonomy terms just because it's more robust than the I18N module so the block translation module which is part of I18N allows you to make blocks translatable and it also lets you specify if you want your blocks to just show up in certain languages so if your blocks are just targeting users who speak that language or are only available in certain languages and the block translation UI is now available right through the block configuration interface in Drupal 6 we had to use that translation interface I showed you for the user interface strings so it's nice that now this translate tab is here for blocks that you've made translatable and also like I mentioned blocks that you just want to target for users speaking a certain language you can do that so you can change the visibility of the block to target certain languages also things like field settings so field settings can be a bit confusing field settings are not fields themselves they're things like the label of a field or the health text or the default text so you can translate these using the field translation module in the I18N suite and the translate tab again is just added to each field so it's right there you don't have to go to the translation interface UI and it allows you to translate the label and the health text as well as the default text unfortunately for fields that are not provided by core like if you're using the date module and there's additional field settings you can't translate those yet with the field settings module so you'd have to do something custom and menus are something that you can translate using the menu translation module in the I18N suite and sometimes you'll want to have completely different menus in different languages and that's more common if you have asymmetric sites if your menus aren't the same structure in each language but if your menus are quite similar it'll probably be a lot easier to manage if you just choose to translate the individual menu items and you can configure that on a per menu basis and there's different types of menu items in Drupal so if you're using node translation and you're linking to a node that's in a particular language then the menu item is only going to appear in the language of the... if the node matches the current language of the site so then you're not going to be able to actually translate the menu item it's only going to appear if you're viewing the site in the language of the node but if you're using entity translation or you're linking to views that are... sorry, if you're linking to a page that's just meant to be seen in a particular language so if you have a view that's only targeted at users of a certain language then you can choose to only show menu items in one language and then if you have a page that is a generic page like the home page or if you're linking to an entity that's using entity translation then you can choose language neutral and then you can translate just the title of the menu link and again you have a translate link to translate these things if you are setting up a multilingual site there's a couple additional modules that you want to use in addition to the core modules entity translation and IATNN which is mostly what we've been talking about today so the localization update module is what will pull in translations from localize.drupal.org so if you have contributed modules installed and you have drupal core installed there's a lot of translations that people have contributed for these modules and if you're using localization update then you can pull these in automatically on your site so I highly recommend using this module and the other module that can be really useful is the localization client module which provides an alternative for that translation interface UI and this is a bit easier to use it's embedded in the site so if you come across a user interface string that's not translated you can just translate it on the spot so there are still a lot of outstanding challenges as you saw today there's so many ways of so many user interfaces in drupal for translating different aspects of drupal and that can be a big challenge for translators especially depending on who's doing the translation on your site so improving the translation UI and translating custom elements can be still a huge challenge and there's a lot of work being done on this there's a multilingual initiative for drupal 8 and there's a code sprint that's happening this Friday and on Saturday as well if you want to get involved and some of the work that's being done will hopefully apply to drupal 7 like there's work being done on the entity translation module to improve the user interface and if you want to get involved there's also some buffs coming up this week that I recommend going to so the entity property translation buff tomorrow that's going to be talking about translating properties like titles on entities there's a multilingual buff tomorrow at 2 o'clock and that'll be around like multilingual use cases talking about answering questions if you have any more after today and then another buff on Thursday about configuration and translation and then Friday and Saturday is the code sprint so hopefully if you're interested in learning more or contributing you'll come out to some of those and if you have any questions there's now a multilingual book that is just about to be released and so we're going to give a free copy to the person with the best question the book is written by Kristen Paul and I don't actually have the copy but I'll get one to you if you have the best question can you help? if anyone has a question please use the microphone hi you talked about the entity relationship translation and from what I understood from that using the taxonomy, using that for taxonomy you're getting a one-to-one relationship between all the terms for taxonomy so for example if I had a user searching SCA on my site then they're going to get results I could in theory return results for SCA and I could return results for steel is that true? maybe the relationship works for the taxonomy I'm not sure I really understand the question could you rephrase that? so the taxonomy you're going to enter a piece of content and you're going to tag that with SCA and in English you're going to tag it with steel so when I use a single search term within the search tool I'm able to programmatically get both pieces of content back using one search result so with tags this is particularly difficult because it's called free tagging so it's generally tags that are entered that are not really structured in a way that they are translated so what you can do in this kind of case is to just have tags that will be applied to content and the tags themselves don't have a language it's just that for example when you have a tag cloud which is limited to content of one specific language it will automatically filter out the tags that have not been applied to content in that language so the free tagging is kind of a special case but if you have those categories as strictly defined categories SCA and steel then I think in this case you really have just one reference to the term and then it's... it can be interchangeable they can be interchangeable at that point you mentioned searching this is a whole in our issue multilingual search there's a couple adaptations that need to be done but it's possible that kind of leads into my next question if you don't mind regarding searching if you don't pass the language parameter in the URL and you have a default language slash en slash user returns the same results as slash user based on the steps, the criteria that we met how does that get rendered for somebody searching within Google let's say the search result is going to come back and they hit just slash user slash user without the language parameter in the URL Drupal is going to decide for the user what language to return what language to display this is true but when you have the selection method that is based on the URL all the links that are generated by Drupal will always have a language so generally the links that will be indexed will be the ones that have the language parameter I'm not sure that this really covers all possible edge cases but I don't think I've never seen any problems slash en slash user slash user is not going to be considered duplicate content by search engine index I'm not sure I don't know the answer Thanks for the talk I got a comment and two questions comment is I don't think you mentioned in the talk but I think that Drupal 8 is going towards the entity translation model so it might be one it might be something people should think about if they're choosing between the two that seems to be the direction of Drupal and two questions number one can you publish a node in one language and not another and the other question is if revisioning doesn't work well now with entity translation is there work being done to make it work well what's the status of that thanks okay so the first question it's specific translation can be published or not this is possible this is part of the base functionality from the entity translation well the functionality in the standard translation model it works pretty transparently because you have two separate nodes one of them can be published you are not this is not an issue what you cannot do however is unpublish the original and keep the translation published but there's few cases where this would make sense the second question was revisioning the second question was about whether revisioning there's plans to make revisioning work and Drupal I think Gabor might be able to answer that but well it's a very difficult question I think that the perfect solution is not clear yet I don't think there is I don't think there's card problems with revisioning in the sense of it's not being supported it is supported I think the problem with revisioning multilingual content is basically you get a new revision for any edit to any language version of the node so basically you have a new revision for any language even though you have not edited the content for that language which is not nice but the revisions are tracked all your changes are tracked and we can tell whether you actually made changes in one language or the other so I have two quick questions I saw that there's a pluggable architecture for the language negotiation where you can do it by user's choice or browser etc how does that work with anonymous users and the page cache or yeah you mean if if the if user if the user's profile is one of the methods of negotiation for example like if the browser is set to Spanish and it primes a cache for that page in Spanish and then an English user comes to the page will that user then see the cache page in Spanish even though they're an English user both anonymous okay so there's one case where one of those detection methods where this could be the case is when you're using the session based language so pretty much it saves in a cookie that you want to view the page in Spanish I think this would in this case it wouldn't work that well with caching otherwise since it's based generally based on the URL then the URL gets cached so that means that the Spanish version and the English version would get cached separately so this would not be a problem I know that also front-end well caching systems like varnish also have some methods that some little tweaks that let you keep well save different values for per language typically where this could be problematic is for the front page because it's the same this is the one page that has the same URL in every language otherwise it's generally not a problem and then the second question is if I have an existing multi-lingual site is there an easy way to transfer it from the node translation paradigm to the entity translation paradigm so for example with taxonomies is there an easy way to move all of that data into entity translations there is a entity translation upgrade module which tries to do that automatically give it a try not on a production server but yeah so it's possible generally it's it does require some work so it's not something you can just enable it but yeah it's possible to do that kind of migration if we're building our own entity do we need to do anything to expose that entity to this module or does it just work through field API and the core entity API so for the entity translation to work well the field translation to work there's not much that needs to be done what you want to do is well the user interface for translating those pieces of content or those entities that you created you need to put that in place but in most cases it's pretty much reusing some of the code that's available for nodes or taxonomy terms there's not much much work that is involved I just have 17 questions no I have one I was curious if either of you has built a site using entity translation and organic groups and if so are there any particular challenges with that we have we actually discussed about it we talked about this yesterday no we haven't done that the only case where we thought that this could eventually be meaningful is when organic groups are used more as a structure to take care of access restrictions if you use organic groups in a typical case where it's a discussion group then generally a discussion group and so there aren't that many cases where it is really meaningful to have multi-lingual groups my use case is a bilingual school so I don't want a Spanish kindergarten and an English kindergarten I want one kindergarten classroom where everyone is together so I need it there's definitely some use cases like that you just need to take a look at it I think it should be possible we haven't tried it one more question I have a pretty specific question as it relates to non-Latin character sets we built a site last year with 7 languages and ran into a lot of the issues that you guys talked about and one specific challenge has been around paths and redirects and we're having specific problems with not being able to use Chinese or Japanese character sets for example do you see any work arounds or solutions for that I haven't had any similar cases one thing that's very useful when working with languages that have non-ASCII characters is using the translation module which pretty much creates path aliases using ASCII characters most languages have a substitute for those characters I don't know how it works for Asian characters or really non-Latin characters yeah I'm sorry I have an answer there is a UI for translation sets you didn't mention it what can you say a UI for translation sets yeah well we we did talk about a number of text groups that content translation maybe you want to come I think we're out of time do you want to come and talk to us after this I think we need to leave this stage for the next presentation thank you