Good morning, everyone. Sorry about the technical difficulties, but we're ready. [laughing] All right, so I'm Sarah Roddy and welcome to Localizing with Xcode 9 session. And today, with my colleagues Ia and Chris, who would like to talk to you about some exciting new improvements we made to the localization process in Xcode 9. So let's get started.

Around the world, you have so many people who are looking to access and use your great applications, but they can't do that if you don't give them the ability to use your apps in their native language. And your app can easily access this global audience by following some simple steps and best practices. And, in today's session, we will talk about how Xcode makes it so easy for you to add new languages to make your app look and feel local, which will allow you to go global.

So there are three main topics we will be covering today. First, we will start with how to make your code world ready, then we will walk you through the localization process in Xcode and introduce new features we added in Xcode 9. Finally, and through the presentation, we will talk about testing and give you some best practices to make sure that your app works and looks great in all languages that you support. So let's start with internationalization.

So internationalization is the process of designing your software so it can be adapted to different languages and regions without making code changes every single time you are adding a new language to your app. So the point here is it shouldn't matter which language your app is running in. If the language has short text or long text or tall text or even text or layout that flows from right to left, your app should be able to adapt dynamically to all these scenarios.

And the first step in internationalization is managing your strings. Your app will be localized by translators who would be working with your strings and in this localized string is there to make it easier for you to create localizable content for your translators as well as displaying the right text at the right time.

So if your strings are coming from a storyboard or a zip file they're localizable by default, so we don't need to worry about those. But sometimes you might have some strings that are defined in your source code that will be displayed to the user, like error messages or notifications; if you would like to notify your users about something.

And you want to make sure that this translator is also localizable. And to do that you just need to wrap those strings with NS Localized String. In addition to that you can use NS Localized String as a format string with localized language format to get a localized and a formatted string.

So here let's go through a quick example together. So here they have a label. When I set its text to a string called population. So again, my string is hardcoded and is not localizable. To make it localizable, you just need to wrap it with NS Localized String. And as you can see here on the screen, NS Localized String takes two arguments, your string and a comment. Comments here are really, really important to provide to your translators so they have context about the string they are translating.

And I would say most of the time you just need to use NS Localized String, but in some cases when you're working on a framework or a shared component you might want to use NS Localized String from table where you specify the table name where your strings are coming from.

And as I mentioned before, you can also combine NS Localized String with Localized String with Format, where NS Localized String is a format string. And in this case it's really, really critical that you provide those comments for your translators so they have context about the string they are translating.

Then at run time NS Localized String will determine the preferred language of the user and find the corresponding localizable string files. As you can see here, this is an example of a localizable string files coming from the French localization projects and it contains all your localizable strings, the one that you wrapped with NS Localized String as well as the comments that you provided. And this is the information that will be provided to your translator.

And if you're using Objective Senior App you can run the static analyzer to find localizability problems in your code, like if you forgot to make a string localizable or if you forgot to add a comment to a localizable string you can run the static analyzer and you get warnings that will show you what these problems are and you can fix them right on your code. If you'd like to learn more about the static analyzer please check out this talk from last year.

Another thing that your app should handle well when it comes to localization is working with different visual representations of date, time, numbers, et cetera. For example, 12-hour time format is a standard format we use here in the US, but you want to make sure that a user who's using your app in France, for example, is getting 24-hour time formatting set because this is the default format used there. And we provide a variety of very powerful formatters that will let you handle the complexity of data formatting and regions, but just to give you an example on how formatters work, let's take a look at a date formatter example.

So here let's say you want to display a full date format in your app. So instead of setting a date format string that is specific to a region or a country that has a specific order, we recommend that you use date style. This formatter has different styles that you can choose from, but since here we want to display a full date format I'm setting my date style to full. So with that you are making sure that your date is formatted correctly in all regions in the world.

As you can see on the screen, there are differences between the date format in the US and the date format in France, like the French date does not have any commas, the month name is not capitalized, the day of the month comes before the month itself, and this would not be achievable if you have pasted in a date format instead of a date style. In addition to date formatter, we have a series of formatters for common data types available in foundation. If you'd like to learn more about formatters please check out these two great talks from last year.

Finally, you want to make sure that your user interface is flexible and looks nice and beautiful in all languages that you support and to do that the process is really simple. We just need to use base internationalization and auto layout. So let's talk about base internationalization for a moment.

So by enabling base internationalization in your project, Xcode modifies your projects for Destructor and separates your UI from your strings, which means any file that is related to your user interface, like a zip file or a storyboard file, will be stored in base [inaudible]. While your strings, either if they are coming from a storyboard file or if they are in your code that you wrapped with NS Localized String, they will be stored in the specific language folders so that way you only have one set of user interface instead of duplicating your UI every single time you are creating a new language in your app. And base internationalization is enabled by default since Xcode 5. So if you have an older project that you want to localize, please make sure that you enable it there.

And you might be already familiar with auto layout or you're already using it to support different presentations of your app or different screen sizes, but auto layout is also a critical technology to use for localization. So by using auto layout you are making sure that your app is flexible and it can adapt to different string lengths and different configurations of your app.

And new in Xcode 9 we are introducing new interface builder localization warnings to validate your constraints for localization, which means when you are working on your UI and your storyboard file or your zip file and you're setting up these constraints and they are not localization friendly you will get this warning as well as suggestions on how to fix them. And new interface builder warnings will be available in the future seat.

Additionally we are introducing an Xcode -- 9 used to the localization options for you to simulate a localized environment. So instead of having a real strings, translated strings, to see how they look like in your app you can just use one of these pseudo localization options that we are providing.

So, in Xcode 9, we have new options for accented Latin strings for a fixed strings and new options for right to left languages. And with that I would like to call Ia on stage to give you a demo about how to prepare your app for localization. Thank you.

Thank you, Sarah. Hi. I'm Ia and today I want to show you this really cool app I've been working on called International Effects. As you see on the screen, my UI consists mostly of this table view and a user can go and select a country or territory from this list and they'll see some information about it like the flag, the population, and even the language population.

So I made sure my app looks beautiful in English and I'm happy with the way it looks, but now I want to internationalize it so it can be ready for my first localization. And to do that I'm going to follow the steps that Sarah just showed us in her slides. So the first thing I want to do is my strings management. I'm loading all of these strings in my table cells in code. So I'm going to open my Xcode project.

And in my table view controller, in my cell for wrote indexpath function I want to make sure I don't have any hardcoded strings that I'm loading into my UI. And instead I want to replace them with a call to NS Localized String. And I'll pass in my English string and I'll also give a helpful comment. So; "Label preceding the selected territory." And then I also went ahead and made sure I'm calling NS Localized String for all the other text I'm loading in code.

So the next thing I want to do is I also want to make sure I'm displaying and representing data correctly for different locales. So in this case my data are mostly these numbers that you're seeing on the right side. And numbers are displayed differently in different countries. So to format them correctly I'm going to use a number formatter.

Number formatter is similar to date formatter that Sarah showed us earlier, except, of course, it's used to format numbers instead of dates. So for population I can simply set my formatter's number style to decimal and I set "uses grouping separator" to "true," which makes it easier to read by separating the number by the thousands, and that's because population tends to be a large number.

For GDP I can also use a number formatter, except this time I would set the number style to currency and the currency code to US dollars because our data is in US dollars. And finally, for the literacy percentage cell, as well as my language population, I set the number style to percent and I give it a maximum and minimum fraction digits to make sure it looks consistent.

So now that my strings are localizable and I'm displaying my numbers -- and I'm formatting my numbers correctly, the next thing I want to do is make sure my user interface is also ready. And to do that I'm going to open my main storyboard and I want to show you how you can use pseudo languages in Interface Builder Preview to test your app for localization. So first I'll click on the top right corner on the Assistant Editor icon. And then under this dropdown I want to choose "preview" and basically it's showing me a preview of my storyboard.

And on the bottom, right corner I get a language chooser and if I had any localizations on my project I would see those here, but in this case it's showing me all the pseudo language options I can use in the preview. So new in Xcode 9 we've introduced a fixed pseudo language. So I'm going to select that to see what it does.

As you can see it simply added those square brackets and the pound symbol before and after each string. And that makes it really easy to spot if something is clipping or not fitting in my UI because those symbols would be missing. So in this case it looks like my button on the bottom doesn't have the pound symbol and that's the first thing I saw, but if you take a closer look, even -- the y is clipping in "play." So I'm going to go back to my storyboard and see why that is.

And it looks like I have a fixed width constraint, which in this case is not necessary and generally fixed width constraints on text controls are a bad idea for localization. So if I get rid of it you'll see that my pseudo language looks exactly as expected and now I know that I'm not going to be clipping anything.

So these interface builder previews are even more helpful if you have more of your UI defined in your storyboard. In my case, a lot of my UI is loaded in my table view controller. So I also want to show how I can use pseudo languages at runtime to test that.

So if I select -- if I click on my scheme and select "edit scheme" -- and make sure you have "run" selected in the sidebar -- under "application language" you get a list of languages you can choose from, but over at the bottom you have a list of all the available pseudo languages you can use as well -- at runtime.

Another pseudo language we've added in Xcode 9 is the accented Latin pseudo language. And if I go ahead and play that -- My app will launch with accents above and below each of my localizable strings. And what this really helps with is it gives me a preview of what my app -- how my app would handle languages that use a lot of accents, diacritics, or even languages where the scripted self is generally taller than English -- like Thai for example.

So I can quickly scan this and make sure that everything's fitting vertically and I'm not seeing any clippings. And everything looks good here. And then finally one more pseudo language I'd like to show you at runtime is the new right to left pseudo language with right to left strings.

And this pseudo language is very helpful in testing whether your app is ready for right to left languages like Arabic and Hebrew where the text itself is written from right to left. So as you can see, my UI controls are already adjusted and mirrored to look the way they would look in a right to left localization.

And what we also do is we display the localizable strings from right to left. So the letters themselves have flipped order and that really helps give you an idea -- or put you in the mindset of somebody who reads their text from right to left. So these are some of the pseudo languages. I highly encourage you to try them all. They're very helpful to test your app before you even add localization.

And to summarize the internationalization process; first make sure you're using standard APIs to load localizable strings as well as to format your data, like dates and numbers. And make sure your app is using base internationalization to separate your UI from your localizable content. And, of course, use auto layout in your UI to make sure that the app itself is flexible and can adapt to different translations.

And, finally, we showed a lot of tools that can validate your internationalization, like the new pseudo languages we've added and the auto layout warnings that are coming soon in the future seat. So my app is internationalized now and I'm ready to add my first localization. So I'm going to call Sarah back up on stage to show us how to do that since she's the expert on the topic.

Thank you, Ia. So now that you're done with the steps that Ia showed us earlier in her demo, you are ready to add new languages to your app. And you can do that right from Xcode from your project info and you have over 100 languages to choose from.

So now that you've added these languages that you want to support in your app, so to generate the localizable content for your translators Xcode will find all the localizable resources that you have in your project, then when you export your projects for localization Xcode will extract the strings from this localizable resources and generate XLIFF files for every single language that you have added. And XLIFF file is simply a standard XML localization file format that is standard in the localization industry. So if you send your XLIFF files to one of the localizers they will be already familiar with the formats and how to work with it.

So once your XLIFF files are translated you can import them back and Xcode will integrate automatically your localized text back into your project. And that's the localization process in Xcode. It's very simple and straightforward. And new in Xcode 9 we are adding support for exporting and importing string dics file formats.

So string dics is the powerful tool that lets you handle plurals and adaptive strings in your app. In Xcode 9 you can now add and create string dictionaries right from the file template list in Xcode and that will generate an editor for you where you can add and edit your keys and values. So now let's talk more in detail about what can you do with strings dictionaries and why they are helpful.

So first strings dictionaries can help you handle the complexity of plural forms without writing any code in your app. So let's assume I have this logic in my code to handle plural variants. So here I have an array. If the count of my array is one I set my string to one popular language.

Else if the count of my array is more than one I set my string here to something like person d popular languages where person d is a format string that will replace the runtime with the count of my array. So this logic might work -- well it would work for a language like English where there are only two plural forms; one singular and one plural.

But this would be a complete disaster for a language like Russian where there are more plural variants. So Russian has four different plural variants and your translators need to think about work arounds and ways on how to translate all these variants with the one generic plural that you provided -- the one you are using for English, which will make basically your translations sound robotic and not very natural for a native speaker. So this example here sounds like something; "popular languages column one, popular languages column two," and you don't want that in your app. So to solve this kind of problem, when we're done writing any code you can just use strings dictionaries.

So all you need to do in your strings dics file -- so you need to add your localized format key. In this example my localized format key is "languages." Then you need to add the plural variants that are relevant for your development language. So since here my development language is English, I only care about two plural variants, one and other. So one is for the singular case and other is for the plural case.

Then by wrapping your plural string with NS Localized String, as you will do with any other string that you have in your code, when you export your projects for localization, Xcode will generate automatically for you the plural keys for other languages that you support. So the variance for other languages will be included in your XK files and your translators when they are translating the strings they will find the plural variants that are relevant for the language. And now our translation will be correct and your users will have more grammatically correct translations. So this is Strings Dics support for Plural Variants in Xcode 9. Another thing you can do with strings dictionaries in Xcode 9 is support for adaptive strings.

So if we take this example from Ia's app earlier, she had a string here called "Gross Domestic Products in Billions," which is kind of long, but it fits fine on an iPad because there is enough space for it. If we run the app again in a smaller device like an iPhone 7 -- so this string does not fit anymore. As you can see on the screen, the number on the right side now shrinks and you can only read the three first characters, which is kind of wrong because we are given the wrong information to the user.

So you can take advantage of strings dictionaries again to solve these kinds of problems and provide different string variants for your app. So here I have three different keys; 20, 25, and 50. They correspond to different screen sizes. And then I have the strings that I want to show for every screen size. So if you call NS Localized Strings on the key within your strings dics file. So you enable -- we pick the right value for you at runtime based on the space available on the screen.

So if you are not using UI label and you are using a custom control of your own, you can still take advantage of the functionality by calling variance fit in presentation with API, where you pass in one of the keys that you have defined in your strings dics file and then at runtime this will choose the right value for you that corresponds to that key. And we will be providing the keys and the corresponding screen sizes in the documentation if you would like to check out that later.

So now if we run again the app on the iPad, still using the full string, and if we run it again in a smaller device like an iPhone 7 now we pick the right variant that will fit nicely on the screen size. And thus without erasing a single line of code your app looks nice and beautiful in all different screen sizes and configurations of your app. And adaptive strings are really helpful if you are supporting localizations in your app because you might have some languages that are longer or shorter than others and you want to give this flexibility to your translators to provide like adaptive strings for the language.

So now that you're done with supporting plural support as well as adaptive strings you are ready to localize your app. And the first step in localization is exporting your project. So when you export your projects for localization -- so Xcode will ask you which languages you want to localize first. So once you pick the language you want Xcode will generate XLIFF files for you to send to your translators.

So once your XLIFF files are translated you can import them back in your project and Xcode will show you this nice diff with what was changed by your translators. And after that Xcode will just integrate your localized text back into your project and your strings will be localized.

So now that your strings are localized, what about other resources that are not string based that you want -- probably you want to localize, like images or audio files? So you might have something like this, an image that has text on it, and you want to provide an alternative image for other languages.

So you can localize other resources in Xcode easily by clicking the "localize" button in the "file inspector." Again Xcode will ask you which language you want to localize this asset for. You can pick from the list of your languages and Xcode will move this asset to the specific language folder where you can replace it with the image or the asset that you want to show for that language. So this is the localization workflow in Xcode 9. So we saw how to support plurals as well as adaptive strings and how to localize other resources. And with that I would like to call Chris on stage to give you a demo. Thank you.

So earlier we saw Ia validate that her app as internationalized using both our framework and tools features. So let's get started on actually localizing it. First though, I really appreciated Sarah's discussion of plurals and adaptive width strings. So I've added a strings dict file to our project here. Oops. [laughs] And I've added that GDP adaptive width string with all of the different variants for our different device widths; 20, 25, and 50. And I've also created a plural variant, just like Sarah showed, for the number of popular languages.

Now though, I'm ready to localize my application into Russian. So what I'm going to do is go to the project editor and right under my localizations, where it tells me that English is my development language, I have this plus button. I can choose that and just go about halfway down and choose Russian.

And Xcode will ask me which of my resources I want to take and make Russian placeholders for. Since I want to localize everything I'm just going to tell Xcode to finish. And you can see that in addition to my main storyboard file I now have a placeholder for my Russian strings. Still in the project editor, I'm going to go to the "editor" menu now and I'm going to export my project for localization.

And I'm just going to save this file -- actually this folder -- on the desktop and Xcode is going to read through all of my source code, all of my resources, and it's going to generate that XLIFF file. So let's take a look at what it looks like. Here you can see that the file is named "ru.xliff" where ru is the ISO language code for the Russian language.

And if I double click this we have a little tool that we've written so that we can see all of this localization data in sort of a tabular form so that we don't have to wade through a whole bunch of XML angle brackets just to show you. And up at the top here you can see a bunch of strings that came directly from our storyboard file.

And you can see in our translation column everything is in red because we haven't actually put any translations in this XLIFF file yet. Here in the next section we have file -- we have elements that will go into our localized strings -- our localizable.stringsdict file. And you can see that there are more variants of the percent d popular languages string than we had in our original localizable.stringsdict. And this is because Xcode knows that we're exporting to Russian and creates placeholders for all of the Russian variants for you automatically.

We also have our adaptive width string variants for the gross domestic product and we have a couple other things like our application name and our info.plist and the strings from our source code that will then show up in a Russian localizable.strings file upon import. Now let's say I have a translator who worked really fast and I have a translated version of this XLIFF ready to go.

I could just go to the project editor in Xcode and choose "import localizations" and just choose that file and export -- Xcode will read your project, read the file, and then show you how what that file is importing differs from your project. Here I'm just getting a warning that I didn't actually localize the name of my app in English yet, but I do have a localization now in Russian. And I can also see in the files view here exactly what files will be affected by this import. And this is all what I expect. Now I tell Xcode to import it and it'll write out these new resource files for me.

And you can see that where we didn't have a localizable.strings file before, now we have one. And if I choose it we have a localizable.strings file with a whole bunch of Russian text. Now if I run our application -- it looks like I've hit a little bug here, that's okay. Oops. I'll just quit and relaunch Xcode.

Now if I run our application we're building and Xcode is integrating all of our localizable strings that we just imported. There is one step that I missed though, sorry about that. I want to run my application in Russian so I can see those translations. So I'm just going to open the scheme editor and I'm going to switch from that right to left pseudo language that I was using to the Russian language.

And now if I run our application it'll build the storyboard, copy in the swift standard libraries, and launch. And we can see our application is running in Russian. And not only are all the formatters and everything correct for all of our dates and our numbers, but we also have all of that Russian text that we just imported. So, to summarize, strings dicts are really powerful and you can use them for pluralization and for adaptive width strings in your applications to ensure that they look right not only based on the user's language, but also based on their device width.

It's easy to export an XLIFF from your Xcode application for your localization process and to import your translated strings via XLIFF back into your application's Xcode project. And Sarah showed us how you can also localize non-string resources in Xcode. And now Ia is going to show us how you can test your localization.

Thanks, Chris. I can't believe that my app is already localized into its first language and the steps were really simple and easy to follow. So now that I do have my localization, let's talk about some things that we could do to test it. New in Xcode 9 we've introduced the ability to specify the application language and region that you would like to run your tests in. And you can do this in the test scheme editor right in Xcode. And today I want to talk about UI testing with XC test. So UI testing is a great way for you to validate both your application's UI as well as its functionality.

Let's take this line of code on the screen for example. This is what you would write to simulate tapping on a table cell that has the text territory in it. Now that's not going to work for localization because that text is going to be translated into each language that you run your test in.

And additionally, if you decide to go and change the wording in your app, even in your development language -- like let's say I want to call it "region" now instead of "territory," you don't really want to go back and update every single test that you've written just so that it can start succeeding again. So instead, what we recommend you do is use accessibility identifiers. These identifiers are unique to every element on your screen and you can use them to find these elements without really knowing what strings are loaded into them.

So to set the accessibility identifier, you can simply set the property on your UI control when create it, or your NS control. Or if you're loading your UI from a storyboard or a zip file you can set it in the identity inspector in interface builder. So now that your tests are localization friendly and they're succeeding in all the languages that you support, there's even more that you can do to take advantage of that. We're introducing -- this year we're introducing XCT attachment APIs, which allow you to attach screen shots as well as any other data you collect during your test and it'll attach it to your test report at the end.

What this empowers you to do is get a full coverage of your UI. So every screen in your app, in every localization that you support, as well as every device that you support. And you can do all that while writing only one test -- well, one test for each thing you want to test. [laughing] To find out more about XCT attachment and what else is new in testing please see those related sessions throughout the week. And now I want to show you a test that I've written for my international facts app.

Okay. So in my Xcode project I've already created this UI test target and I wrote my first test, called Test Some Territories. So let's run it to see what it does exactly. Now Xcode will launch my test runner, which in turn launches my app. And in this specific test we select a different territory, in this case Belgium, and then the test succeeds. So now let's try running my test in Russian.

And to do that I'll go into my scheme and instead of "run" this time we want to select "test" and under language I'm going to choose "Russian" so I can test the new localization that Chris added to my project. Now again my test runner launches, which launches my app.

And this time my app is launched in Russian, but it looks like my test failed. So let's see what's going on. And it looks like my test can't find a cell that has "territory" in it, which is what we just talked about. Silly me. So -- oops, sorry. So in my project I'm going to go back to my main table view controller and make sure that I'm setting an accessibility identifier for my territory picker cell so I can actually select it.

So when I create my cell I also want to give it an identifier. So territory picker cell. And I want to use the same identifier in my test. So where it's failing, instead of using static text I'll simply replace it with this identifier that I just created. And now I'll try to run my test again in Russian using the identifiers.

As you can see, my app launches in Russian again, but this time it actually got further and it chose Belgium as the country and the text succeeded. So I just want to show you what my test does exactly. First, I want to validate some of -- some functionality.

So I have this XCT assert equal to make sure that my app initially launches with the US selected and then I use the XCT attachment APIs to collect screen shots. So my first screen shot is a screen shot of the US page. And I add it to my test case and then I collect more screen shots later when I open the territory list and after I've selected Belgium.

And now finally if I want to see these attachments I can simply go to the "reports" navigator in the sidebar and select my most recent test that I've run. And then if I expand my test some territories test case, you'll see that some of these lines have the attachment icon on them. And these are the attachments that I've created. So as I've mentioned, they're all screen shots in this case. And there's so much that I can do with these attachments.

I can bundle them up and send them to somebody to ensure the quality of my translations, somebody who actually speaks these different localizations -- and to make sure the UI looks good and the formatters are correct. And I can even use these screen shots in my app store preview when I want to launch my app in all these different storefronts around the world so that users can get a preview of what your app will look like in their language.

So, I show you how with one test you can test every single localization that you add in your apps. And to summarize what we talked about today, we covered the localization process for an app. First, you need to prepare your code for localization, and that's the internationalization steps. And then we showed you ways you can validate your apps readiness including the static analyzer and auto layout warnings and the new pseudo languages.

And then you can export your -- all your localizable content into a single XLIFF. And now that includes string dict files, which are really powerful for handling plurals and adaptive strings. And finally, when your XLIFF is translated you can import it back into your project and that integrates the translations into all the different pieces of your app.

And then you can take advantage of your existing tests to run them in all your supported localizations. And you can take advantage of the new XCT attachments to do a lot more than test your app's functionality. For more information, our session is 401, and you can visit our page on developer.apple.com. We highly recommend that you attend, or at least watch, these related sessions throughout the week. Thank you and enjoy the rest of the conference.