So since we're going to be talking about application localization, we're going to do a presentation in French today. OK, just kidding, but we have some Irish people. All right, I'd like to welcome you to session 129, Mac OS X Application Localization. Last year, we talked a lot about how you're going to be able to localize your application on Mac OS X. We talked about this new bundle mechanism, which is going to make your life easier to ship one application in several languages. We talked about Appleglot 3.

And I think this session will cover actually how you're going to be able to do the real work. This year, we have the whole solution for you. And tonight, going back to your hotel, you'll be able to start actually localizing your application in French. I'd like to introduce for this session Chris Hansen, who works in the RE here in Cupertino and will talk about the advantages of Mac OS X and the international issues. Thank you.

So all these international technologies I've alluded to, like Unicode for text rendering and font management, so on, they have other sessions here at WWDC, and I encourage you to go to those or review them for some that have already occurred. But I do want to touch on one area in particular, and that's application packaging and how that enables multiple localization. So you're all familiar with the application packaging mechanism that's used for application packaging. I use that in quotes online.

It's a single file model. You have a resource fork, a data fork. Your HI is typically in the resource fork. Your executable is typically in the data fork. So this single file model enables a couple of very nice things. So one thing is it's very simple for the users, right? So there's a single icon in the finder, double clickable. The user doesn't have to know anything about the internals of this file structure.

The other thing that's very nice about this mechanism and this model is that, the executables and the resources are separate. So we can localize an application, and we don't have to recompile the code. Typically, we don't have to touch the executables. So that's a very nice advantage of this resource fork, data fork split. But this model does have some shortcomings, especially with modern applications.

So one issue we have is that there's no support for multiple localizations within a single resource fork. So if you want to ship a French, a German, a Japanese version of your application, well, you have to create a new application. So you have to create a new application. So you have to create a new application.

So you have to create three versions of that application, localize the HI within those resources to the appropriate target locale, and then you, of course, have duplicates of the executables in each of those files. So there's no support for multiple localizations. The other issue is that modern applications have a lot of different types of files that don't fit very well into the resource fork, resource sort of model. So things like plug-ins and help files and other things like that aren't easy to shoehorn into the resource fork format. So you typically... So you typically have a bunch of loose files sitting around that may be necessary or useful for your application to run.

So that's the Mac OS 9 model, right? So on Mac OS X, applications are packaged as a set of folders or folder hierarchy. So there's a place within this folder hierarchy for, for example, your executables. So you could, for example, have multiple executables within this application package for different platforms. So if you wanted your application to launch a different executable, if your user launched it on Mac OS 9, you can do that.

There's also a place within this application, excuse me, this folder hierarchy for multiple localizations. So the language project or lproj folders contain resources for different locales. So you can recognize these language project or lproj folders within the application package by name, by language name. Sometimes they'll be called like english.lproj, french.lproj, japanese.lproj, things like that. You recognize those.

Chris Hansten, Jack Sampson, Mike Butler, and Chris Halpern. So you can recognize these language project or lproj folders within the application package by name, by language name. Sometimes they'll be called like english.lproj, french.lproj, japanese.lproj, things like that. You recognize those. Chris Hansten, Jack Sampson, Mike Butler, and Chris Halpern.

This mechanism also supports an ISO naming convention. And so for example, you might have en.lproj, which would be universal english content. You might have ja.lproj, japanese, universal japanese content. And en.gb.lproj, which is british english specific content. That mechanism is a little more flexible than the language naming and is recommended. There's also a place within this application package for the other stuff.

So things like help files. And plugins and package data, other metadata can be packaged together within this application package structure. So you see the point of this, the purpose here is to group all of these required resources together into one folder hierarchy. And yet still make it simple for the user so they see one double clickable application in the finder.

So let's look at a very simplified example here. This is extremely simplified. I've left some things out of this. But there's a simple app package. You see at the top there, mail.app or mail, the user will still see a single icons double clickable item. If you actually expand that in the file system, you'll see there's various folders under there and files. And looking on the right side of it, the Mac OS folder contains the executable for the Mac OS platform. You could potentially have other folders there supporting other platforms.

If you look on the left side of it, the resources folder. There's a couple things there. There's a myapp.rsrc. Now that file contains global content. Content that applies to all of your localizations and does not need to be localized. So that might contain things like icons or pictures or other things that don't require localization.

The English L approach contains the content that does require localization. So for example, the localized.rsrc, should say localized.rsrc, would contain things that do require localization. Your strings, your layouts, your other content that should be localized on a per locale or per language basis. So the strength of this mechanism, if I wanted to localize this application into say French or German, all I need to do is duplicate the English L approach. Name it appropriately. So French L approach, German L approach, etc. And localize the content within that L approach. So I can use the localization tools that will be discussed to localize that content.

If I then put those L approaches back within this application package, as in this picture. So I have a French L approach there, a German L approach there. The great thing about this is that this application is now localized and multilingualized. So if the user that has this on their system was running with French as their preferred language, let's say. And they launch this app, it will show the content that's in the French L approach.

It will have a French UI. And they decide to switch to German as a preferred language or more likely another user to multi-user system. Another user logs on. And they want to be running in German. They launch Mail app. It will be running in German. Okay. Very nice for the user.

So what have we learned in doing these couple versions of the OS, doing the multi-lingual, that's helpful for you guys? Well, there's really two main things. One is to use this application packaging mechanism. This gives you a flexible delivery mechanism. So on the one hand, you could potentially package together multiple UIs within your application with one executable and deliver that in a single CD or single deliverable to your users.

On the other hand, if you don't want to do that for whatever reason, you could also deliver that language later as an add-on, a plug-in of some sort. So you could, for example, ship your application and version of your application and then deliver a language over the web as an add-in plug-in.

It's a separate folder. All of this stuff can just be plugged into your application and will just start working. The other nice thing about this is it's very flexible for your users. So many of your users may want to run their application, run their system, with other languages than English as their preferred language, and they would like it if your application responds to that. and displays its UI in that language.

So the other thing we learned is to use the Mac OS X international support that's available. Never forget when you're working on your app that it is a multi-script, multi-local, and multi-lingual environment. And use all of the international support, the Unicode for text rendering, the font management, MLTE, all the different things. There's other sessions that you can look at on that.

Use those. And if you do use those technologies, then there's a lot of really cool things you can do for your international users in your application on Mac OS X. So with that, I'd like to turn this over to Jack Sampson, who's our Localization Tools Development Manager, and he'll talk to you about the Localization Tool side. Thank you very much.

Thanks, Chris. We are delighted to show you Apple's very latest localization tools today, namely Appleglot 3 and Monte. Appleglot 3 is Apple's incremental localization tool. It supports incremental localization for Classic, Carbon, and Cocoa applications. It uses the Monte API to access and decompress resource type structured data. Monte, which was announced at last year's conference, has been updated to support Appleglot 3's features and requirements.

But before we get into the detail of Appleglot 3, let's talk about the concept of incremental localization. What is it? When we talk about incremental localization, we're talking about the reuse of translations that have been used in a previous version of a particular application. This assumes, of course, that localizable elements in the previous version are exactly the same in the current version. Nothing has changed.

Let's take an example. Say I've developed Super Mega App 1.0. It's brand new. All the GUI are populated with text strings which are in English. As we've already heard from Chris, Mac OS X applications are inherently multilingual. They can support multiple language translations. We can translate all the text strings in version 1.0 into various languages. And we can enclose them within the application framework.

Now, I realize that SuperMegaApp, I'd like to add some extra features. Now, not everything has changed. We would like to pull forward automatically the localized elements that have existed in the previous version. This leaves us with just the work of translating the changes that have occurred in version 2.0. This is the essence of incremental localization.

Some of you may be familiar with previous versions of Appleglot, such as 2.4. Appleglot 3 is completely new. It has been designed and written from the ground up. It is based on the Monte architecture and technology. It supports a state machine architecture and has a very powerful extensible plugin system. This is available to not just in-house but also third-party developers. But rather than talking about Appleglot 3, I'd like to hand this presentation over to Mike Butler, who is the principal engineer and developer for Appleglot.

Thanks, Jack. OK. I'm going to talk to you today about Appleglot 3. And the easiest way for me to do that is to actually work through a couple of examples, a couple of things you normally do with it. So some of the things you're going to see as we work through these examples, we're going to create a new environment. And I'll explain a little later what an environment is. But if you've used Appleglot 2 before, you'll see that the environment is actually quite similar. It's only some small changes. And I'll point those out.

We'll show you how Appleglot figures out where to pull the right information from. We'll show you what we've done to hopefully make it a little easier to use. For example, we know that you typically using Appleglot, you're going to jump out into the finder, jump back into Appleglot, jump into your own application that you're localizing, maybe run a few tools, come back into Appleglot. We're trying to make it all much easier, flow much better.

As Chris has explained, OS X provides support for a number of different locales all within the one package. So obviously, Appleglot has to support this. We'll show you how it does it and how seamless it is. We'll also take a look at some of the support files that Appleglot uses and produces.

And we'll show you what we've done to hopefully make these more accessible to other users or other tools and other processes. And finally, we'll show you just incremental localization and how it'll work with packaged apps, classic apps, funded apps, Cocoa, Carbon, all the bits and pieces you're going to find on OS X. So I'm just going to go to demo now.

I'm going to go and create an environment. Now, Appleglot deals with a large number of files. And most of these will have very similar names. And they'll only be just different versions of the same file. So we need to have a safe way of knowing which file we want to pull information from so we do it right and safely. So I'll just close up that example there.

We use what's called an environment. And basically, it's a hierarchy of folders. Each folder in this hierarchy has its own specific job. So when we put something in there, we know that we can safely deal with it a certain way. So if I just open up an environment there, I'll show you what it looks like in Appleglot.

To create an environment, we'll just go up to the tool menu, choose Create Empty Environment, And we'll pick where we want it. So I'm just going to pick a new folder in here and type in the name of our example. Now I'm going to tell Appleglot to populate that with all the folders that we need. So if I go and look at that in the finder, just the same place again.

WC, example environment, we'll see there's all the folders that is created. Now as I said, most of these will be familiar to you from Apiglat2. Some are new, like we have a temporary one and we have a translators folder then to support Monty. But most of them as I said are as you've seen with Apiglat2. So this is my first time around, I have a brand new application. I need to produce a localised version. So what I'm going drop in those applications that I want to localize. Simply drop them into the new base folder.

Now if I go and open that environment with Appleglot, So it's selected already. Choose. OK. So you can see Appleglot here is mimicking some of the folders that you-- in the finder there. So we have a new base, new loc, old base, old loc. And anything that's in those folders will show up here in these columns. So I true in disk copy and mail into new base. So they show up here in the new base column.

Now, as Chris already mentioned, we have support for multiple locales. So previously with Appleglot, you would have just run Appleglot, put in your translations, and whatever translations you put in, well, that meant it was for that language. So if you did put in French translations, we had a French version. This time around, you need to tell Appleglot what locale you want to produce.

So if you look at the title here, for our example environment here, we have our base locale as English and our target locale as French. These are just defaults from my preferences. If I wanted to change them, I just go up to the Tools menu, choose Set Base Target Locales, and I just pick a few. I pick whatever I needed from here. There's only a few here. This is just in this preview release. As we go forward, we put in the rest of the locales. So I'm just going to stick with French here.

What I'm going to do is I'm going to choose this copy here, and I want to process that. Now, there's a number of files in the environment, so I just want to tell Apple that I just want to localize this copy. So I just tick here, and as you can see, it tells us that one item is selected for processing.

Okay, so I'm just going to go ahead and go to the Actions menu and choose Generate Glossaries. And Appleglot is going to start working. So what Appleglot is doing now, it's running through all the different resources, all the data that it can find, looking to see if it can find any textual information or localizable information, pulling it out, and it's going to store it in one of two places. So if we have a translation available, then it will get stored in what's called an application dictionary.

If we have no translations available, then the information will be stored in what's called a work glossary. This is our first time through, so we shouldn't have any translations available, so everything should just go into the work glossary. Okay, this is going to take about another 30 or 40 seconds. So once we have our work glossary, we can start working with that and putting it in our translations. Which should be any minute today.

So at the moment, as you can see from the progress there, what it's doing is it's reinserting information into Nib files. So it's at this Nib file stage and putting information back in. And as we've had no translations, this might seem strange, but what's really happening is even though we have no translations, we've still produced a localized version. So this is still the double clickable app here.

If we had translations, what would happen is the translations would be put in. It'd still be a double clickable app. When you ran it, you'd get your partially localized application. So if we just take a look at over here, you can see that a work last year was produced for this copy. And we'll just have a look at that.

Now I know if you've worked with Appleglot 2, you're used to much simpler work glossaries. So this actually would look quite daunting or complicated. But if you also notice, it's an XML file. So this opens up work glossaries to numerous other tools that can read XML. Or if you want to write your own tool, you don't have to try and figure out what Appleglot's format is. You don't have to write a parser for that. You just use your own XML parser that comes with the system, and you gain instant access to the work glossaries or any other files that Appleglot produces in XML.

Also, being XML, you can take advantage of XML tools that are out there. And as we go forward, XML will become much more popular. As it becomes more mature, it will find its way into all types of applications. So your favorite text editor will eventually have XML support. So this text editor here actually has some XML support. I can go in and turn on what it calls Syntax Styling.

Now if we look at that XML file again, while it's still quite complicated, it stands out more. The information you want stands out more. And you can tell it what way you want the information to be displayed. As we go forward, you may produce something yourself which will translate this XML into HTML. You can view it that way and maybe use backend scripts to populate guesses or whatever.

So if we take a look at this work glossary, if you're used to Appleglot 2, you'll be used to all the information from one file goes into one work glossary. Now, we have a packaged app. We have loads of different files there inside the package. So instead of having a separate work glossary for each file, we have all of the appropriate files, all of the information from all of the different files goes into the one work glossary. This makes it easier for you to work with.

So if you can see here, we have all our Info.plist information has gone in here. So we have the bundle name, so we can change the name of the application. We also have some nibs here. If you scroll down through, you can see more nib files. So what I'm going to do is I'm going to change or enter some translations. So if I pick a couple of easy ones, we'll take the name of the application itself. So I'm not very good at French, unfortunately. So I'm just going to cheat and call it.

Follow the-- the funny was always so easy. OK, and one of the other-- like here, the text that I'm entering that I want to have-- the translated text that I'm entering is coming up in a different color. It's a visual cue that I'm typing in the right place. You can do some much more strict things. I believe a future version of this application will not let you type inside tags so that you can't damage the format.

Okay, let me pick something else. Say, let me look for a window. Something that'll pop up in the menu bar. Okay, so again, cheat, So all I'm going to do is save that and go back into Appleglot. Now if I go up to the Actions, I can produce a finished version. And it's very similar to the Generate classes, but this time it's going to go through, turn away.

And it's going to do the same stuff again. It's going to try and pull out all the information it can, look, see if it has translations for it, reinsert it, whatever. Except this time around, we're going to find two translations. So there's going to be-- the name-- the application name is going to have fr.discopy.

And the window title will come up as-- they'll have a translation for our window. So this time around, not everything will appear in the work glossary. Only the things that need translations go into the work glossary. So the two files that we've-- or the two translations that we've just entered, they'll go into the application dictionary.

So again, we're reinserting information into the Nib files here. It's just finishing up. So when this is finished, what we can do is we can actually go and have a look and see if our translations worked. Okay, so it's done. So what we can do now is we can go to our system preferences.

Wait for it. And it's over on this window machine over there. OK. So now if I go to International. choose French as my main language. Click that. With the wonders of Mac OS N technology, I should be able to run this copy here and see it in French, or at least my version of French.

So there you have it. This copy of the name was translated. So as you noticed, the information for the name of the application came from the strings-- the Info.plist strings file. And the name for the window came from a completely separate nib file. So as a translator, I wouldn't care. It would all just be in the work class. I'd do whatever I have to do, and it would all just work. The whole point of this version of Appleglot is that it's supposed to hide any complexities of OS X from you. OK, so I'll just quit that.

So now we'll take a look at a slightly more complicated example. So if I open up another environment, which has a few more files in it, Okay, so I have a whole bunch of files in here. And I see I have new disk copy. Okay, so I know I've just done disk copy.

So what I want to do is not have to go reinsert and reenter those translations that I've just done. It takes too long to enter those two strings. Okay, so what I'm going to do is I have my original versions here, but I'm just going to copy over a whole bunch of them as well at the same time.

So this is Olock, so it goes in the Olock folder. So these are previous localized versions of certain applications. Now if I look at my old base. So we're going to copy all these over to the old base folder. And these are the old original versions of the applications. Now, if I look at that environment again, now if I go back into Appleglot, We should see there, it's after automatically matching up all those files that I'm after putting in.

So it knows that if it goes here, it can find the previous old address book. And it knows if it goes here, it can find the previous old localized version of the address book. So what we wanted to do with Appleglot, we wanted to make it as extensible as possible. Why? Did somebody say? Sorry.

So what we did was we, from the ground up, we made it a plugin-based architecture. And we didn't just leave one section of a B plugin. We tried to bring that philosophy throughout the whole app. So you can write plugins that will provide services to Appleglot itself. You can provide plugins that can provide services to other plugins. You can write plugins that can process data that Appleglot doesn't already process. And you can write plugins that just sit there, watch all the data flying by, and say, record information or maybe change the behavior of certain plugins.

So the benefits of this are the general benefits you get from plugins. From our point of view, we have quicker update time. We don't have to turn Appleglot again if something comes up, if a feature comes up that we hadn't thought of. We maybe just do a plugin and release that plugin. It's much simpler.

For yourselves, if a process that you have that doesn't quite work with Appleglot or Appleglot doesn't support it, then there's the ability there for you to write plugins. If you've thought of writing plugins, if you've come up with something that you could write a plugin for, then maybe somebody else could use it. Maybe you could give it to them, or maybe they've already done it, so you can just take it from them.

Okay, so just a couple of examples of the kind of plugins that we wrote. The first one is the NibTool plugin, and you've actually seen that without really noticing it. The NibTool plugin basically allows Appleglot to process nib files, which is what I did earlier. And it's a good example of a plugin because we were able to leverage from work that was done by other people. The interface builder team had already written the tool, the command line tool, the Unix command line tool, and that was able to go take a nib file and the rest of the team.

NibTool, do your wonder stuff there. It puts out all the information, and AppleGot goes along as normal. And all the information still ends up in the same place, still ends up in the work glossary, the glossary that you've seen there and you normally work with. So if you're just a translator, everything that you want just appears in the one place. You don't have to worry about how you would deal with nib files. You don't have to worry about how you would deal with classic apps.

Another kind of plugin that we used was ResStats. When we were developing Appleglot, obviously we wanted to make sure that we were hitting every resource type we should be. We also wanted to know if we were pulling out all the information out of those data types. We wanted to know how long it was taking us. So we wrote a little plugin, it's called ResStats, and it just sits there and watches all the information fly by.

And it just takes a few notes. So at the end, then, it just checks out a file and... Basically, it just tells you, right, you had 10 resources in there, and they were blah. And of those 10, only two of them produced any localizable information and entered 10 strings into the work glossary.

So you're able to see one of the strange things, or one of the enlightening things, I suppose, was that we saw that maybe just 10% of the resource types that we were supporting had any localizable information in it. So 10% produced 90% of the information that we were localizing.

So just by being able to produce a small little plugin that sat there, watched things go by, we were able to find out that sort of information. And we were able to see that, yeah, I'm looking at it in Resourcer here. I can see 10 resources. Yeah, Appleglot worked with 10 resources.

And I can see that there was 10 strings in here. Yeah, grand, Appleglot worked with 10 strings. So it was very handy for us. So in a similar situation, if you needed to check things, or if you needed to add something or watch something, you can write plugins to do that.

At this point, I was supposed to hand over to Kristian, but we'll see. So just before Kristian does come up, I'll just tell you that Monte is a core technology that Appleglot uses. It's what allows us to access resources, whether in the data file or in the data fork or in the resource fork. And it lets us do that pretty seamlessly. So I'd just like to welcome Kristian Walsh on stage to talk to you about Monte.

So Monte is a technology that we in Apple developed to deal with structured binary data types or resources to you and me. And Appleglot uses Monte for its Carbon and Classic resource support. But one of the best things about Monte is that we get full Unicode support. Monte is entirely Unicode based.

So all the editing, all the extraction of text, it comes out of Monte in Unicode. When we want to make a change, it goes into Monte in Unicode. Monte handles the conversion of that text from Unicode to whatever the native encoding is. So for Classic applications, when we ask for some text to be set to Japanese, Monte will handle the conversion from that Japanese text to Shift JIS encoding or whatever the Mac is using. As part of this, we also have data validation.

So that if we took the same Japanese text and tried to set it into a French resource, we get an error saying that, well, you've said that this resource is French. That cannot encode this particular stream, so I'm not going to let you. And doing things like this prevents your editing tools from corrupting the data you're editing, which is an occasional cause of these bugs that it takes weeks to track down.

Also, we tried to make Monte extensible. Anyone who's had to deal with frameworks and class libraries, particularly power planters is the most popular, will find that they keep having to rev the PPob translator. Every time a new subtype comes along, you've got to rev the whole PPob translator, which is quite big now. But with Monte, we've designed a system whereby we just have to add the extra pieces, just add what's changed, and we can leverage on the existing stuff we've done.

So it makes it very quick, very easy to do this. It also makes it easy to control the changes. But if you have a lot of templates, and you still need them for your own process, we have a template conversion tool, which will automatically convert the ResEdit or Resourcer templates into Monte translators suitable for Appleglot, which is a great starting point for you to get advantage of all the features that Monte will offer you. Okay, so I'm going to ask Jack Sampson to come up and wrap up the session. Thanks, Kristian.

Okay, we got there. You have just seen, yes, Apple's very latest localization tools and technology in action. You've seen the power of Appleglot 3. and yes, the very powerful Monte technology. And all running on Mac OS X. We've gone through incremental localization of Classic, Carbon, Cocoa. We've leveraged previous translations. We can give better efficiency and accuracy of localization.

have been examples of the scalability of Appleglot 3 with its extensive plugin technology. Mike has gone through the NibTool plugin and the ResStats plugin. All the files that Appleglot uses are in XML format and have the capability going forward even for XSL format. You've seen the Monte translator, which we've been able to update quite easily using the PPOD resource.

Now that we know what Appleglot 3 is, or does, I'd like to take some time to talk about what Appleglot 3 is not. Appleglot 3 is not a machine translation tool. Neither does it support document localization or multimedia localization. If you're so inclined, please feel free to write a plugin which will interface with Appleglot 3 so that it can use already well-established translation mechanisms. At this venture, I'd like to hand the presentation back to Xavier, who will address the very burning question, where can we get Appleglot 3? Xavier.

Okay, just a quick wrap up. I'd like to remind you that with Mac OS X, we're shipping with several languages. As Avi mentioned in his presentation as well, we just released a new version for traditional, simplified Chinese and the rest of the European languages. One out of two Macintoshes are sold outside of the U.S. So for you as a developer, it's very important as well to localize your application. So of course, French is one of these languages, but don't forget Japan and China, who are like, you know, main markets now where things are growing very fast.

We showed you in this presentation that actually now we have the tools for third parties for you to have and localize your application, support all these languages, support application bundle, and actually support whatever needs you have as a third party. So we saw that Monte is very powerful because now, you know, it was a nightmare to translate before with like, you know, resourcer or things like that, things like PPOBs. Well, with Monte, you're going to be able to actually write your own defined templates. And Appleglot will take, like, you know, advantage of all the plugins you'll be able to write.

So I think I'm very happy about the work that Jack's group has been doing this last year. It was very difficult to support many platforms and many types of objects. And believe me, it's very great to see Appleglot 3 in action. So when do I get Appleglot 3 and Monte? Soon. You'll get it soon. And actually, we hope to post it on the web probably next month.

Maybe before that. But this is something that you'll be able to download directly from our website of developer.apple.com in the international web page. We have already posted there some glossaries. Some of the developers have been asking about that. Right now, we have support for French, Italian, Spanish, German, and English, of course. We'll be adding Japanese probably next week. And we hope to have, of course, simplified traditional Chinese, Korean in the upcoming month.

So please, try to download the Monte SDK, try to get your hands on Appleglot 3, and of course, try to write as many plugins as you want to integrate in your localization process. Should you have any questions, please don't hesitate to contact me at [email protected]. We're more than happy to show you the powerful Monte. If you need to get your hands on VSDK and you cannot find it, please send me an email.