Sure, we are working on the documentation and hopefully will have lots of sample code further on. Most of the methods in DataFactory has overrides that take a language selector, and there are some new methods to support create and delete languages. Some examples below to give you an idea, I don't think this code will compile in Beta 1 (all functionality is there but you need to use other method signatures of for example GetDefaultPageData): public class TestGlobalizationExamples { public TestGlobalizationExamples() { } public void Test() { //Create a new page for swedish PageReference newPageLink = GlobalizationExamplesHelper.CreateSwedishPage(Global.EPConfig.StartPage); try { Global.EPDataFactory.GetPage(newPageLink,new LanguageSelector("EN")); } catch(LanguageNotFoundException) { //This will throw because we havent created english yet } // We will get the swedish page here, check returnedPage.LanguageBranch to be sure - it should contain "SV" // The fallback scheme is configured in edit mode by the editor.. PageData returnedPage = Global.EPDataFactory.GetPage(newPageLink,LanguageSelector.Fallback("EN")); //Create the new english version GlobalizationExamplesHelper.CreateEnglishLanguageOnPage(newPageLink); //This should now work as we have created a english version PageData englishPage1 = Global.EPDataFactory.GetPage(newPageLink,new LanguageSelector("EN")); //This code with fallback will now also return english PageData englishPage2 = Global.EPDataFactory.GetPage(newPageLink,LanguageSelector.Fallback("EN")); } } public class GlobalizationExamplesHelper { public static PageReference CreateSwedishPage(PageReference pageLink) { PageData newPage = Global.EPDataFactory.GetDefaultPageData(pageLink,1,new LanguageSelector("SV")); newPage.PageName = "Swedish Test Page"; Global.EPDataFactory.Save(newPage,SaveAction.Publish); PageReference newPageLink = new PageReference(newPage.PageLink.ID); return newPageLink; } public static void CreateEnglishLanguageOnPage(PageReference pageLink) { PageData newPageLanguage = Global.EPDataFactory.CreateLanguageBranch(pageLink,new LanguageSelector("EN")); newPageLanguage.PageName = "English Test Page"; Global.EPDataFactory.Save(newPageLanguage,SaveAction.Publish); } }

Thanks! 1) Lets say you want a language selector on your page where users can change between available languages. How could I realize that? I would like to set the current language for that session for example. 2) I will be needing different label texts, is Translate still the way to go? 3) How can I get information about the currently chosen language? Mostly for language sensitive images like for example ImageEN.gif, ImageSV.gif and so on. /René

1) string[,] langs = EPiServer.Global.EPLang.AllLanguages(); for(int i = 0; i < langs.GetLength(0);i++) { EPiServer.Core.PageReference.AddQueryString(CurrentPage.LinkURL, "EPsLanguage", langs[0, i]); } This code is NOT verified, but it will hopefully get you started. 2) That's the way to go for sure. 3) EPiServer.Core.LanguageManager.GetContextLanguage() /HAXEN

The answers by Håkan are indeed valid for the multilanguage up to EPiServer 4.51 but does not applies to the globalization support (or multilanguage v2) in EPiServer 4.60 - we will be somewhat compatible but there will be better options to solve some common issues. 1) There is sample code in 4.60 Beta 2 with a language selector and even a ready-to-go Globalized web site on the Install Basic Content setup page. You can either list all active page languages site-wide with the LanguageBranch.List API. Or get languages for the current page which the language selector in Beta 2 uses: PageDataCollection pages = Global.EPDataFactory.GetLanguageBranches(CurrentPage.PageLink); 2) Sure, language branches in EPiServer 4.60 will always change the UI language if the language exists in the Lang-catalog. 3) A single class in 4.60 handles all language context related stuff, EPiServer.Core.LanguageContext.. == This is some raw material to one of the documents == How is do EpiServer know which language to display to visitors ? The short story is that 4.60 will always enforce that the language is visible in the URL, either in the Path part or in the domain part of the URL. The reason is simple, search engines such as Google must be able to crawl a site and easily separate content. And users are expecting that they can cut and paste a link into a mail and send to a friend and that friend when clicking on the links will always get the same content. There are also some technical reasons such as outputcaching in .NET and web browser caching on the client that expects a single URL to be rendering the same content to anonymous users. But, but.. Some scenarios.. Scenario 1: Global domain with multiple languages You want all your visitors going to the offical site.com address but need to display different content depending on their language selection. * Set a default language that most of your visitors will understand, normally english for a global site (EPsDefaultLanguageBranch in web.config) * Activate language detection based on browser preference (EPfBrowserLanguageDetection in web.config) * Add links or flags to the header or startpage that links to other languages (get the URL from PageData.DetermineAutomaticURL in the APi or Language drop down if you are using the Link Editor) Testing the configuration: Click on Tools->Internet options->Languages in Internet Explorer to select the language preference, the visit the site. You should be redircted to the correct language if you language selection can be matched to a site language. Scenario 2: Local domains mapped to languages There are two approaches to this depending on how you market your sites, one approach is to configure a site redirect at your hosting provider - for example redirecting http://site.se to http://site.com/sweden. The other approach that requires a bit configuration and is what is outlined below - you want http://site.se be the same as http://site.com/sweden but without the redirect. * Add a configuration definition section in web.config, example:

* Add the actual configuration: * Add links or flags to the header or startpage that links to other languages with their domain names. Remember that the domain to language mapping always overrides cookies and other client state, so a visitor to site.no will always get language with code NO. The only selection that can override this is a language selection in the Path part of the URL as discussed in the details. This also means that if you can have local sites mapped to different language but still have a .com site that have browser detection on languages. Scenario 3: Remember user preference If you have a single domain and requires the user language preference to be persisted you can set a cookie with the current language selection, this means that the next time the user visits you site they will also be redirected to the correct language. This may also be used if you for example is redirecting the user to another system where language preference is not retained in the URL you can set a cookie to make sure that when the user returns to the site he or she gets the same language as before. Be careful when using cookies and always try to build the site based on the concept that language is included in the URL, this will ensure that you never loose language context when the user is navigating your site. Consider a user with a language cookie NO that clicks on a link from a friend that leads to the english site, they should ofcourse continue to use the english sites when navigating around. So, use cookies with care if you actually need them. Visitor Language Selection Architecture Current language is handled by a single class in 4.60 called LanguageContext in the namespace EPiServer.Core. You can access this class by the static Current accessor, ie LanguageContext.Current. One instance per request is created of this class and it is automatically created on first access. This class also supports scheduled jobs and background threads so it is not limited to an available HttpContext, just access LanguageContext.Current and you will get an instance for the specific thread you are running on. The auto detection steps outlined below is only run once per request on first access. Custom Language Selection Always try to fit your solution into the recommended scenarios and configuration options, selecting language with custom code just adds to complexity so make sure you have a well though out plan before starting. The first step when changing language is to make sure you do not override anything you should'nt, for example overriding the edit-cookie can get you into trouble. But, there is an easy way to see who selected the current language - the LanguageContext class has a accessor CurrentLanguageBranch which contains the current language code, for example "EN". It also has a accessor CurrentLanguageBranchSource which contains which functionality that actually selected the language, this let's you for example only override Default language. The detection steps 1. Friendly URL Friendly URLs in globalization scenarios always include a language prefix that can be defined in admin mode under Web Site Languages. The language prefix will always be used if available as the current language selection (/english/news). 2. Querystring Querystring always takes precidence and is for example used by edit mode to make sure the preview of the site is rendered on a specific language. The language selection is also added to every page's URL to make sure a URL always links to the same content whoever is using it. For example "http:///templates/page.aspx?id=3&epslanguage=EN 3. Editor Cookie "editlanguagebranch" A session cookie used in edit mode to make sure language selection is not lost when navigating between functionality and for example switching between edit mode and admin mode. This cookie is only valid in directories Edit, Admin and Util, in all other directories this cookie is completly ignored. 4. Full Qualified Domain Name If a domain is mapped to a language code it is always used, the only thing that can override the domain name is when specifying the language in the Path part of the URL.