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 Apple Glot 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'd be able to start actually localizing your application in French. I'd like to introduce for this session Chris Hennestern, 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 what would it be? Bienvenue, all? Something like that. Welcome, everyone. Thank you all very much for coming. It's very exciting for us to be able to talk about what we've been working on for the last year or two, so we certainly appreciate it. Before we talk about the Mac OS X localization tool set, I want to first just review the Mac OS X international architecture briefly and discuss as well what Apple has done so far in terms of locale support, script support, and language support in the OS. So the Mac OS X international architecture, the major difference from the user's perspective between the Mac OS X international architecture and Mac OS 9 is that Mac OS X is a multilingual OS, of course. So the user is able to select the desired UI language. They can go to the international system preference and choose the language they would like, and the OS responds dynamically. Now in order to make this a good experience for our users, there were several things that we needed to do. So the first thing we needed to do was, of course, to support the application packaging mechanism in our applications so it was possible for us to package together multiple language UIs within a single application together with a single binary. But it's not enough just to package your application and localize the application into the relevant target languages. We also needed to make sure that the applications and the OS behaved appropriately for the different regions of the world.

So what that required, first of all, was us to support the different locales that might required. So we needed to make sure that our friends in Asia and Europe were able to do things like control their keyboard layouts, their date and time formatting, their printer sizes and things of that sort. So in addition, many of our users might want to do things like display text in a document in multiple scripts or cruise the web and look at Japanese web pages or enter text in Japanese, no matter what UI they happen to be running in the OS. So we needed to support the international technologies in the OS, such as Unicode for text rendering and font management and Japanese text input and things like that that allowed us to give that capability to our users. So always remember when you are converting your application to Mac OS X or designing an application for Mac OS X that the environment your app will be running in is a multi-script, multi-local, multi-lingual environment. And use these international technologies so that your application can also be a savvy international player. So use the Unicode for text rendering and font management, those things I mentioned, application packaging for multiple localization, and so on. So what has Apple done so far in our current Mac OS X product to support locales, scripts, and language UIs? Well, we shipped the first version of Mac OS X earlier this year, and that version of Mac OS X supports seven language UIs, French, German, Japanese, English, Italian, Spanish, and Dutch. When I first wrote this slide, I put all the correct languages there, but I put six language UIs, not thinking English is a foreign language, but English is a foreign language, so I need to make sure to include that. So there are seven language UIs available. Our users can select any of those in the international system preference and use that as their preferred language. We also support all of the locales that are associated with those languages. So our French-speaking users in Quebec have the appropriate regional support. Our English-speaking users in Britain and Australia and so forth have their appropriate regional support. They can use the date and time formats and the video formats and all the other regional formats. In addition, we support in the base OS Roman and Japanese script in this first version of Mac OS X. So those users that do want to display a document that contains text both in Japanese and Roman languages or cruise the web and look at a web page that contains Japanese, print Japanese, so on, those capabilities are in the base OS, not related to the UI that they're running. So any user can do that. It's important to note that in giving our users this locale support, this script support, and this language support, we package this all together in a single CD, a single deliverable. There's no multiple deliverables here.

There's not a French CD that's shipping into France and a Japanese CD shipping into Japan. We package this all together in one single deliverable, so our international customers are buying the exact same CD that our users are buying here in the US. This is made possible by these technologies, and we'll talk a little bit more about that. Now as a follow-on to that, just last week we shipped a follow-on product, a later version of the CD, which contains additional language support. So there's eight -- this 10.03 version contains eight additional language UIs, Korean, Chinese, both simplified and traditional, the four Nordic languages, and Brazilian Portuguese. So there's eight additional language UIs in there. And also, of course, supports all of the associated locales that are associated with those languages. And in addition, we've added to the already existing Roman and Japanese script support, for Chinese, both simplified and traditional, and Korean scripts. So our users that receive this CD can do all those things, you know, display, document, cruise the web in all of the CJK scripts, Chinese, Japanese, Korean, and Roman, of course. So that's really a great product, and I'm sure people will really like that.

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. It's just resources 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 is 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 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. 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 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 a 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 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 language name. Sometimes they'll be called like English.lproj, French.lproj, Japanese.lproj, things like that. You recognize those. This mechanism also supports an ISO naming convention.

For example, you might have en.lproj, which would be universal English content. You might have ja.lproj, 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 plug-ins 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-proj, name it appropriately, so French L-proj, German L-proj, et cetera, and localize the content within that L-proj. So I can use the localization tools that will be discussed to localize that content. If I then put those L projects back within this application package, as in this picture, so I have a French L project there, a German L project 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 project. It will have a French UI. and they decide to switch to German as a preferred language or more likely another user, it's a multi-user system, another user logs on and they want to be running in German, they want to mail app, it'll 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. And 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 and 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. Thank you. Thanks, Chris. We are delighted to show you Apple's very latest localization tools today, namely Apple Glot3 and Monty. Apple Glot3 is Apple's incremental localization tool. It supports incremental localization for classic, Carbon, and Cocoa applications.

It uses the Monty API to access and decompress resource type structured data. Monty, which was announced at last year's conference, has been updated to support Apoglot 3's features and requirements. Thank you. But before we get into the detail of Apiglot3, let's talk about the concept of incremental localization. What is it? incremental 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 Apiglot, such as 2.4. Apiglot 3 is completely new. It has been designed and written from the ground up. It is based on the Monty architecture and technology. It supports a state machine architecture and has a very powerful extensible plug-in system. This is available to not just in-house, but also third-party developers.

But rather than talking about Apple Glot 3, I'd like to hand this presentation over to Mike Butler, who is the principal engineer and developer for Apple Glot. Thank you. Thanks, Jack. Okay, I'm going to talk to you today about Apoglat 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. Thank you.

And 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 Apiglat2 before, you'll see that the environment is actually quite similar. There's only some small changes. And I'll point those out.

And we'll show you how Apiglot 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 Apiglot, you're going to jump out into the Finder, jump back into Apiglot, jump into your own application that you're localizing. Maybe run a few tools, come back into Apiglot. 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, Apiglot 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 Apiglot 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.

wake up our machine. Can you hear me with this on? OK. So the first thing you're going to do, you're going to load a chapter like here. I'm going to go and create an environment. Now, Apiglot 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.

And 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 Apple Gaunt. Go to here.

environment here. Actually, what we'll do is we'll create an environment. It's probably better to go from scratch. To create an environment, we'll just go up to the tool menu, choose Create Empty Environment. And we 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 Apiglot to populate that with all the folders that we need. So if I go and look at that in the finder. So 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 Apiglot 2. Some are new, like we have a temporary one, and we have a translator's folder then to support Monty. But most of them, as I said, are as you've seen, with Apiglot 2. So this is my first time around. I have a brand new application. I need to produce a localized version. So what I'm going to do is-- 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 Apple app, It's selected already. Choose. OK. So you can see Apiglatt 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 Apiglot, you would have just run Apiglot, 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 Apiglot what locale you want to produce.

So if you look at the title here, for example, environment here, we have our base locale is English, and our target locale is 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. And 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.

And 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 Apriclot 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.

OK, so I'm just going to go ahead and go to the Actions menu and choose Generate Glossaries. And Apoc.glad is going to start working. So what Apoc.glad 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 true, so we shouldn't have any translations available. So everything should just go into the work glossary. OK, 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 class that was produced for this copy. And we'll just have a look at that.

Now I know if you've worked with Apiglot2, 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 WorkGlossaries 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 Apiglot'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 WorkGlossaries or any other files that Apiglot 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'll 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 back end scripts to populate guesses or whatever.

So if we take a look at this work glossary, if you're used to apog.2, you'll be used to all the information from one file goes into one work glossary. Now, we have a package that 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-- Voni was always so easy. OK, and one of the other-- here, the text that I'm entering that I want to have-- the translation 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. OK, let me pick something else. Have a look for window. Something that will pop up in the menu bar. OK. So again, cheat.

So all I'm going to do is save that and go back into Apoc.Lab. 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 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 translation go into the work glossary. So 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. OK, 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 OSN 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 ApiCloud is that supposed to hide any complexities of O 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, OK, so I have a whole bunch of files in here. And I see I have new disk copy. So I know I've just done disk copy. So what I want to do is not have to go reinsert and re-enter those translations that I've just done. Takes too long to enter those two strings. OK, 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 Apiglot, We should see there, it's 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 Apiglott, we wanted to make it as extensible as possible. Why? Did somebody say? Sorry.

And 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 lot. So you can write plugins that will provide services to Apiglot itself. You can provide plugins that can provide services to other plugins. You can write plugins that can process data that Apiglot 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 Apiglot 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 Apiglot or Apiglot doesn't support it, then there's the ability there for you to write plugins. And 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. So maybe you could give it to them, or maybe they've already done it, so you can just take it from them.

OK, 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 Apigot 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, take its text out, produce a strings file from that, and then on the other side, take that strings file and reinsert it back in again to complete that nib file again. So all Apiglot had to do was then to write a plugin that would call nibto whenever it encountered a nib file. So we're processing our package here. We hit our strings file grant. We hit our-- maybe there is a localized dot resource in there-- then we hit a dot nib. So Apiglot just goes, right, nib tool, do your wonder stuff there, and it puts out all the information. And Apiglot 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. And when we were developing Apiglot, 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. And 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 flyby, 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, Apiglott worked with 10 resources. and I can see that there was 10 strings in here. Yeah, grand apoglout 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 Christian, but we'll see-- So just before Christian does come up, I'll just tell you that Monty is a core technology that Apiglot 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 Monty.

So Monty is a technology that we in Apple developed to deal with structured binary data types or resources to you and me. And Apple Glot uses Monty for its Carbon and classic resource support. But one of the best things about Monty is this, we get full Unicode support. Monty is entirely Unicode based. So all the editing, all the extraction of text, it comes out of Monty in Unicode. When we want to make a change, it goes into Monty in Unicode. Monty 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, Monty will handle 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 not going to let you. And doing things like this prevents your editing tools 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 Monty 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 Monty, 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 res editor resourcer templates into Monty translators suitable for Apple Glot which is a great starting point for you to get advantage of all the features that Monty will offer you Okay, so I'm going to ask Jack Sampson to come up and wrap up the session. Thanks, Christian.

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 Apple.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.

has been examples of the scalability of Apiglot 3 with its extensive plug-in technology. Mike has gone through the NibTool plug-in and the ResStats plug-in. all the files that Apricot 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 Apiglot 3 is, or does, I'd like to take some time to talk about what Apiglot 3 is not. Apiglot 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 Apiglot 3 so that it can use already well-established translation mechanisms.

At this point, I'd like to hand the presentation back to Xavier, who will address the very burning question: Where can we get Apoglot3? 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 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 Monty 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 Monty, you're going to be able to actually write your own defined templates. And Apple Glot will take 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 Apple Glot 3 in action. So when do I get Apple Glot 3 and Monty? Soon. You'll get it soon. And actually, we hope to post it on the web probably next month. And 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 webpage. 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 Monty SDK, try to get your hands on Apple Drive 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 portfolio of Monty. If you need to get your hands on VSDK and you cannot find it, please send me an email.