So you're all very welcome here today. It's great to see such interest in the first of two localization sessions that we're running this week. My name is Colm Murphy, and I manage a localization tools group for Apple. So I'm absolutely delighted and privileged to be here today to announce two new technologies that are going to make your lives as localization tool developers and tool users a whole lot easier.

The first of these two new localization technologies is a project called Monty. It's a code name for a project we've been working on for about a year and a half now. And the first version I'm absolutely thrilled to be able to announce today. This project called Monty is actually middleware. It's a data services library which provides a lot of services and various features for you, the localization tool developer.

And so the second technology that I want to talk to you today about is a project called AppleGlot version 3. It's a third generation of a tool that has been in existence for some time. But this is a complete revolution. It's a redesign. It's a new modern feel and look. And it handles modern data types and techniques and so forth.

So the complete spectrum of localization tools, if you look at any modern localization process, you're going to see tools in many of these different types of areas, whether it's in release engineering or in the translation and localization process itself. And the two technologies that we were going to talk to you today about fall into the area of text extraction and text insertion, or probably more accurately, localizable data extraction and localizable data insertion.

So, what is Monty? Well, first of all, in order to illustrate this, what I want to do is explain an industry-wide problem. On the bottom here, you can see that we've got some structured data. This is any type of data, probably packed binary data of some format. It might be a nib file, it might be a resource file, it could be anything. And presumably, this structured data contains some localizable information.

So, it's information that you want to get at, whether it's strings that you want to extract to translate, or whether it's bounding rectangles or whatever that you want to actually localize for a particular product. And on the top, what I've done is grouped three different types of localization tools together, such that these are the types of tools that actually typically manipulate those types of data in a localization process. And the first type of tool that we have... is they're the data editing tools. These are the tools that are like Interface Builder and the ResEdits and the resources, etc. And they typically need to interface with this structured data in some format.

Okay? The second type of tool... groups of tools that we have are the incremental localization tools. And these tools are the AppleGlots and so forth that have formed the core of your localization process. And the third type of localization tools... that operate on structured data are those tools which specify localization rules. They specify the relationships and the dependencies between different types of data to be localized.

So, across the industry, what has typically happened is that the tools themselves have always operated directly on the data types. They've interfaced directly with that structured data. They've had to interpret the format of data. They've had to interpret which elements of that formatted data actually are the localizable ones. And they've had the responsibility of extracting and inserting that data during any sort of a localization process.

And this creates a couple of fundamental problems. First of all, what happens when that data changes? You know, your engineering department might bring out a new kind of variant of that data type to describe new structures or whatever. Suddenly, the localization tool developer has to go off and describe that new format either with a complex template mechanism or revise his tool, his localization tool, which is typically what he does to handle that variant of data type. And more important, what happens is that the data type changes altogether.

So, what you've got is you've got, for some strange reason, maybe it's an engineering department producing a new data type. Maybe, you know, it's Apple producing new files that maybe eventually will be available to the public. And so, you know, you have to go back and look at the data type. And you have to go back and look at the data type.

of interest like help files or something like that, or it might be the industry actually producing maybe new different types of technology whether it's XML files or HTML files, et cetera. So the burden falls on the localization tool developer or the process developers themselves to actually respond to these new different data types. So what has happened across the industry? And I've looked at many different companies and I've seen similarities right across the industry here.

It doesn't matter what platform you're working off of, the same thing happens. The localization tool development department or the process people, what they do is they develop new tools to handle these new data types. So what happens over a three or a four or a five year period is that you end up with hundreds of different types of tools and all fundamentally the same. The only thing they're doing is actually extracting and inserting different types of data from different types of data forms.

So what we've done. We've done at Apples, we've recognized that this is a fundamental problem. It certainly has caused me grief over the last few years as a localization tool development manager. So what we've done is sat back from the problem, looked at it and said, "Well, there must be a simpler way.

There has to be a more efficient way of doing this." And there is. And that project is called Monty. So what we've done is we've created this middleware and this is kind of like a toolbox which the localization tool developers can actually build their tools on top of. So what happens is that when a localization tool actually wants a piece of data, a piece of localizable data, what it does is it asks Monty for it.

Monty then takes the request, takes care of any sort of translation of script systems or character formats or whatever it is, can interpret the actual structure of the data through a very simple translator mechanism. And it's also capable of identifying which are the localizable elements within that structured data.

So what it does is it takes that data in question, presents it back up through a common API, back up to the localization tools. So what you have is you have something that's actually doing all the work for you. In the same way when the localization tool itself does its manipulation at the higher levels, presumably it sends it out for translation, the translation comes back in, the translation is encapsulated.

And the tool itself makes a basic API call to Monty to repack that data. Monty takes that data itself, does any necessary encodings and script conversions, et cetera, and repacks the data into that final structured form. You don't need, as tool developers, you do not need to know what type of data it is. Monty takes care of everything for you.

and why is that important? Well, it's important because the structured data shown at the bottom of this program, and again, it could be a lib file or a resort file, it doesn't matter what it is, that data can change, can change significantly. And your localization tools and your process tools and everything else don't have to change. A very simple translator, which plugs into Monty, represents new different data types. Very, very simple compared to previous complex template mechanisms. Very, very simple model. It also handles very modern data types and object-oriented structures, etc.

So enough about Monty for a second. We'll get into that in more detail in a minute. So what is AppleGlot? Well, a lot of you are going to be familiar with AppleGlot. AppleGlot was actually a revolutionary tool back in 1987. The first version was released and created a complete revolution within the localization industry, because what it did for the first time was it created an incremental localization model. And what is an incremental localization model? Well, an incremental localization model is not only a process where it gives you, where it can extract the localizable strings and insert the translated strings into your objects.

It is actually a process which allows you to propagate previously translated and localized information from previous builds and from previous releases. And typically, these are the information wouldn't have changed between builds. It also is, again, capable of extracting and inserting your localized text. So what's new? What's new about AppleGlot? Well, first thing, it's a completely new application. It's designed from the ground up using modern development techniques, modern architectures, etc. It's a carbon-based application, which is going to provide support for all the modern data types that you're seeing under 8, 9, 10, etc. The second thing is that it uses Monty.

For all the reasons I just described earlier, it doesn't need to know about data formats. It basically, Monty handles everything. So it's making very simple API calls to Monty. Monty's doing all the work for it. So it's the first serious application that's actually using the Monty framework. The second thing is that this is actually a flexible framework. The application architecture itself is actually based around a centralized state machine. And it's a very modular in design, such that you, as localization tool developers, can actually create custom plugins into AppleGlot to customize this operation.

So it's a very simple application. It's a very simple application. It's a very simple application. It's a very simple application. I mean, incremental localization is only one of the things that AppleGlot can do. You can now customize by developing these plugins through a series of SDKs, which we're providing. You can actually create these plugins to interface AppleGlot into very simple or very complex localization processes.

And why is that important? Well, what you want to be able to do is you want to be able to use AppleGlot such that it can interface possibly with some computer-aided translation machine in a different platform or a different country. And that's what we're trying to do. So what we've done is designed this very modular architecture. It provides all the basic functions of Glotting, but also you have the capability of expanding it. It's totally extensible and very, very flexible. Very, very flexible. Very important for a modern localization process.

But do you know what the most important thing and the most important aspect of these two technologies are? I'm going to bring up some of my engineers in a second to go through these two types of technologies in more detail. But the most significant aspect of these two technologies is, one, we're not going to charge you $50,000 for these technologies. And we're not even going to charge you $6.99 for these technologies, right? And you definitely don't have to buy a box of cereal to get these two technologies. Because what we're doing is it's completely free. We're making these available free of charge.

The SDKs, the examples, the technologies, we're making them available free of charge to developers to do whatever you want to do with them. And we have the necessary support through our worldwide developer support services. And you'll be able to feedback any comments and suggestions for upgrades in the future. So what I want to do is... Thank you.

So what I want to do is I want to bring the chief architect of the Monty Project up on stage, Christian Walsh. And I want to bring him up to stage to go through the finer detail of what Monty is and what it's going to do for you. Thank you.

So I'm going to talk to you in a bit more detail about the Monty technology that Colm has given such an excellent sales pitch for.

technology. First of all, what is Monty? Well, Monty is the foundation for the next generation of localization tools inside Apple, and we're hoping outside Apple as well.

It provides data extraction and editing services to any type of tool that wants to use them. Now, this may not be just in the localization area, but also for data editing tools, for example. So the main features of Monty are first of all, the big thing, we're going to provide you with a way of developing your applications quicker. That's always good. Because we've put in a lot of effort into getting the data extraction and reinsertion features of Monty working, you don't have to. So you can just take our work and build upon it, and everyone's happy.

Second, Unicode support. We are providing support for Unicode in Monty. If you've seen any of the other sessions, and I hope you have, you'll know that OS X is Unicode-based. The future of the Mac OS is Unicode. So we're providing you with a way of editing, creating, manipulating Unicode-based structures.

Third, we have support for object-oriented data structures. All modern software is object-oriented. The data structures it uses are also object-oriented. This means we need tools that support them. Unfortunately, the current generation of localization tools don't deal very well with object-oriented data. Monty, hopefully, will change this. and most importantly, we were insulating your tools from any changes in the format of the data they need to manipulate.

So looking at Unicode support of Monty, you can see that inside of Monty, which is the two boxes in the middle in this diagram, you can see that Monty, by providing the extraction and recoding services into Unicode text for you, insulates your application from the details of what a Macintosh Roman encoding is or what Big Five encoding is on the other end. So for the tool developer, they just replaced the text there, sample text, with its equivalent in Chinese and let Monty worry about the recoding and the repacking.

So if we look at Monty's place in a typical range of localization tools, we see that Monty's purpose is to take the original packed data structure and it converts it into a generalized representation, which is a tree-based representation. That's the blue box in the middle. From there, the different classes of tools can either modify it or edit it or just look at it.

For example, workflow and localization tools, or workflow localization tools, generally don't need to make any modifications. They're just there to count strings, layouts, and provide some sort of estimate as to how much work is involved in the localization. So they will read the data only. But because Monty provides all these extraction services, they can produce a better estimate of the workload involved in this project.

Localization Tools then will typically extract some part of the information, either a layout or just simply text, send it off to be translated, and then reinsert that information again. And that's the middle purple box up above. And then the last tool, which is probably the simplest, are the data editing tools.

They just open the structure, look through it, allow the user to make changes, and repack the whole thing. And when the changes or whatever have been made, Monty also provides the features, or the facility, to get from that internal representation back to a packed binary data structure. They have the same format of the original data, which the tools didn't even need to know about.

So how Monty gets from a packed binary structure into a generalized representation is by means of what I'm calling a disaster, a data translator file. Oh, yeah. A data translator file is an object-oriented data description. It's a text-based description of the data. But because it's object-oriented, generally we have very simple translators, but we use a lot of them to define structures. We do this where we have substructures, list items, or any kind of common sequence, or macro sequence within the data structure.

We're also using inheritance, which means that if you have one data type that is very similar to another, but with the addition of several fields, then you can inherit the new type, or you can inherit the old type when you create the new type. This means to modify your translator to deal with a new type, you typically only have to add one or two lines to the data translator. You don't have to edit an 8,000 line template file anymore.

Which means, which means, which means, We can finally deal with PPOBS easily. We'll go back to the keyboard. If we look at a sample data translator for a very simple data structure, you can see the main points. First of all, that this structure is text, or the translator is text-based. Now, doing this allows us to extend the translator language in the future, which was a problem we had with the template mechanism, that it really wasn't able to be extended very far.

So, in this particular structure here, we have six fields, and they're each represented by a line in the translator. We've labeled them top, left, right, bottom. This could be an item within a graphical user interface layout. It has some text, and it has a bounding box. It's a very simple structure. It's probably so simple that you've never come across one in real life, but it fits on the slide. So, let's look at the next slide. But most structures are more complicated than this. And the first level of complexity away from this is lists of items.

But in Monty, when we define a list, we use at least two translators. First of all, we define a translator for the list items, and then we can include those into the larger enclosing translator, which defines the item, the entire structure. So for the example here, we have a very simple styled text type resource, or style text list item. And this could be for a font menu, or it could be for anything that needs to gather a list of style texts.

And we first create a translator for each individual item. And in this case, there's an integer font ID followed by a string with the text of the item. Then we can include that translator to define each item of the list of items. And that's what the second translator does. And you see that it uses the list command to include the first translator.

This way, if the list item changes, we don't have to change the simple list translator. We just need to redefine the structure of the list item. And it's time-saving again, especially if those items appear in other types of structures on their own or in different arrangements. We've changed it from one place.

The next problem we have typically is that a list of items where all the items are the same is quite rare. In even the simplest structures, like a Dittl resource from the classic world, we'll find that there are different types of data, and they're identified by one or more keyword values. So in Monty, we refer to these as variant structures, and I've shown two very simple variants up above, where the type of the structure is decided by the value of the first field.

Now, one is an item, a textual item, the other is a picture item. There could be other fields. But to define this in Monty, we first make a translator for the basic type. These are the fields that don't change no matter what the format is. And in this case, there's only one field that doesn't change.

It's the first item which identifies it. Then, having done that, we can define variant translators by just saying that this translator is a variant of the basic translator, where the type field is equal to 1, 2, or anything. Monty uses this information when it's presented with a block of data.

It uses this so that it can-- it uses this information to decide which format of the data it has and generate the proper information. So no more case statements. You're actually dealing with actual structures. So I've only shown a single level of variance here, where we're deriving two variants from a common base. But it's possible to derive a variant from a variant from a variant and build up entire frameworks of translators. And a very important framework for a lot of you is the power plant one, which I'm now going to demonstrate a little more. Thank you.

So I'm going to show you a more complicated translator file, and you'll see why it didn't fit on the slide. So if we look at-- we have a basic set of PowerPlant PPOB templates defined using the Monty translator language. Just out of interest, you see a lot of them make use of inserting existing types to define it.

For example, this LTexColumn class is four lines long, its definition. The old template for this class would have been 20 or 30 lines long. So by making these translations smaller, they're easier to debug. You're building on existing work. You don't have to try and debug the whole 8,000 line thing every time.

So I have an application here that I know has a custom type in it. And the custom type is a class with the ID ERCL. Now, the existing templates don't include this, but I can just produce a definition by looking at the C type or talking to the engineer, whatever we normally do, and adding this new type. I know that this type is based on the text column class, which I just showed you. But it has the addition of an icon ID. So I'm going to add this field here. And I'll give it a little label.

Save that off. And now I'm going to show you a little tool that we developed pretty quickly just to test the Monty API and to show how really easy it is to produce applications developed or based on this technology. This is a simple data viewing application, and I'm going to use it to open our little power plant application and have a look at the PPOPs inside it. In fact, there's only one PPOP. But if we look down the list, this - First element here is defined as a C error table, which was the class that I've just defined with my one line.

and right at the end, these are all the information that came from the original Colm view. And there's the fields that I added, the icon. Now to implement that new type, I just had to add one line and create a new translator file. Because this thing was in a separate file, it's easier to version control it because you're not modifying the same translator over and over again. And you can create translator files for particular projects and manage them better. But that's about that. So and come back to that.

Now, because it's easy to add new data types, we have another problem, which is more a problem of success than anything else, that we'll sooner or later end up with about 300 or 400 different data translators. So we're nearly back to the situation we had before, where the tool needs to know about every single data type, because all of these types have different field names, different structures, and there are different things that need to be taken out. For example, the localizable text of a button could be called title, whereas the localizable text of a static text item could be called the text.

The tool would need to know this information. Well, it would if it wasn't for Monty, because Monty provides a mechanism of mapping complicated data types into a set of standard properties, which tools can then use to extract, for example, the localizable text. So we'll take two structures here, where they have very different internal structures, but in both cases, there is some element of localizable text.

But what we can do is we can define a Monty translator. It says, for structure A, the fourth element is the localizable text, and for structure B, it's the third element. Now tools can just look for the locale text property and say, I want that, or I want to change that, or let me do this and that.

We've defined several standard properties with Monty for things such as localizable text and bounding rectangles, and all suggestions are welcome. But the idea is to keep the names consistent. So now we can treat very different data types, basically using the same tool. And now the tool doesn't even need to know the name of the text. It doesn't even need to know what it's dealing with.

The tool is lifted away from needing to know about a Dittl or a Powerplant layout, and now it just knows I have a layout with text and bounding rectangles. So I'm going to show a little demo of using this. You can have the... I have a very, very simple application here.

And that's what it says. Okay, that took months, that did. Okay, so I also have an Apple script. And that AppleScript is going to interface with an application that we've written that provides an AppleScript interface to the Monte library. What it'll do is it'll open that application's Dittl resource, which was the source of that message, and change the text of the items and resize the button. And I'm just going to run this. is going to ask me for the application I want to change, which is this simple application. Let it run.

Now I'm going to launch the same application, and it's being translated. You notice the button has also been resized. But this Apple script didn't know anything about the Dittl format. If we look at the script again, it brains of this is down here. And basically it asks for two properties.

It asks for the name or it asks for the local text, which is the localizable text of the item, and changes it. And then it asks for the bounds of the box and changes that. The script doesn't know that that was a dittle. It just knew that there was a layout with text and bounding rectangles.

And this is one of the things you can do with Monty. So if you have tools that need to work on layouts, then Monty is going to make these a lot easier for you. If you have data editing tools, Monty is going to make it a lot easier for you.

In fact, Monty is going to be pretty useful if you're involved in any kind of localization. So we hope you're going to use it. Now we can go back to the... and one of the applications of Monty, which I'm sure you'll be very interested in, is AppleGlot 3. And to talk to us about that, we've got Mike Butler.

Thanks, Christian. Hello, can you hear me? So what is AppleGlot 3? I'm sure most of you know what AppleGlot is, so you don't really need me to go through that. But just say that AppleGlot 3 is still a text extraction and insertion tool. is still forms incremental localization. But as Colm said, the important thing is that it's completely new. We've thrown away all the sources. We've started from scratch. So all those problems you've had with AppleGlot, we've had a blank sheet. We can start again, decide how to do it properly.

So what are the benefits of AppleGlot 3? Well, the reason we're all here this week is Mac OS X. So AppleGlot 3 provides Mac OS X support. But as Colm said, AppleGlot 3 is a user of Monty. And Monty hides all that low-level stuff for us. We no longer care about data formats. All we need is get Monty to look at our data and decide that's localizable.

So it could be OS 8, OS 9, or OS 10. We also have full Unicode support, and as Christian also said, Unicode neatly gets around a lot of the encoding problems that you normally have. Besides this, it's one of the base technologies of OS X, and it's also a base technology of Monty itself.

We know that performance is a big issue for a lot of AppleGlot users. But if you think about it, AppleGlot has been around since '87. The files that AppleGlot used to process back then were in tens of K, hundreds of K. Now they're in tens of megabytes. AppleGlot just wasn't designed to handle that sort of data. So we've started Scratch so we can. We've designed, we've used modern technologies like Monty, and we've used modern techniques to solve these problems.

We also know from talking to you that AppleGlot is not so easy to use. So we've designed a modern user interface. And whatever we could make automatable to take the judge out of the work, we did. And whatever we couldn't, we made it easy to use, but we also made it as safe as possible. We have a number of versions of the same file hanging around. We wanted to make it impossible to choose the wrong version.

This is the biggie. We made it extensible. We didn't want to be back here in a couple of years going, everything's changed again. We needed to do AppleGlot from scratch. So we've made AppleGlot scalable in the first case, but we've also made it completely modifiable. If a new data format comes along, well, Monty will look after that first. But if a new process comes along, if you wanted to do something different, well, then you can modify AppleGlot yourselves to do whatever you need to do. As Colm said, if you needed to link up with a machine translator, then you can do that yourself. yourself.

So before I go on, you can look at AppleGlot from two ways. You can look at it as just a user. I want to use AppleGlot 3 just the way I've always used AppleGlot. So I'll just look through some of the new UI features that we have in AppleGlot.

We can also look at it-- because it's so flexible, you can look at it from a developer. It's almost like a framework for localization tools. You can decide, I want to do something completely different with AppleGlot. You can do it. Chances are you can do it. So we'll look at that in the second section of the presentation.

So some of the main features of the UI. We have automatic and intelligent file matching. If you have a project of, say, 100 files, if you're localizing in under iOS 8 or 9, you'll have four versions of those files hanging around. You'll need to match all of them up together to perform incremental localization. If you have OS X, you'll have to match up two versions of each file. Obviously, this takes quite a while. So AppleGlot 3 provides a couple of different mechanisms.

First, it will provide automatic matching if it can. Where it can't, it will try to intelligently match the files. And where it really can't match any of the files at all, it'll let you do it. But first, it makes it easy. And second, it just won't let you-- or will try not to let you choose the wrong version. It should make it a lot more safe.

Again, if you have a large project, say, for example, a system folder, you're not going to work with all of those files at one go. You're really only generally going to work with a small section of them. So again, if you had a system folder, you might only work with the control panels, or you might only work with the extensions. So we've introduced the concept of file groups.

This just lets you group your files together. You can look at all your files as normal under AppleGlot 3, or you can decide, I just want to look at one of my groups. So I only want to look at, say, my control panels, or I only want to look at, say, my extensions. So file groups allow us to do this.

We wanted to make the UI itself extendable, so we've added script support. You can run scripts yourself. So you can choose a number of files inside AppleGlot and run a script on those files. Or you can run them on all the files in the new lock, or whatever you want to do. You also added external tool support, so if you want to view files in external tools, Interface Builder, or Resource or whatever, you can just choose it very easily with AppleGlot 3.

And to support some of this stuff, we've extended the environment. We have a couple of new folders in there to handle, say, plugins and scripts that I've talked about. But we've also given it a distinctive icon to make it easier to recognize. And we've made the folder itself intelligent. So if you drop support files on the environment folder, they'll automatically get put in the correct subfolder.

So if you have-- it's like the system folder. Again, if you're dropping on control panels onto the system folder, they go into the control panel folder. You drop a plugin on the environment, it'll go into the plugin folder. So I have a tool here which we use to test AppleGlot itself.

But it contains some of the features that I've just described and may make it more clear. So I'm just going to choose a small environment here. And this window will look pretty similar to what you normally see with AppleGlot. Sorry, can you switch screens? OK, so I've just opened-- actually, I've opened the wrong environment there. We'll open up a small environment first.

OK, this looks pretty much like your old AppleGlot. And we have our four columns representing the four files that we need to perform incremental localization under OS 9. As you can see, AppleGlot hasn't been able to match some of the files. and it's done one of them, but we need to match some of the others ourselves. Now, if this is the old AppleGlot, you'd have to go off into another file. All your files would be sorted in a different order, and you'd have to use standard file dialog to choose whichever file. With AppleGlot 3, we have contextual menus.

So you can simply go down and choose a file, but you're only presented with the appropriate files. You're not given all of the files there. You're just the two that, in this case, are available in the new lock folder. So I can simply just choose the appropriate file.

Now you can see that it's been able to make an intelligent guess at the old lock version, but this also fills out some more information so it's been able to guess at all the other ones as well. So it's done a little bit of automatic matching for you, but you've done some of it as well. So just take a look at a slightly larger environment.

Okay, this is probably a bit more normal. You have a whole load of files. There's a lot of information here. So as I said, we have file groups. And this is an environment I've used before, so I've set up a couple of groups myself. I have a control panels group and an extension group. So I simply just select one, and then I only have those three files.

I can work my way on those. I can process them as I want. Or I can switch over to my extension files, do the same. And when I want to batch all of them together, I can simply show all of the files and do whatever I need to do. But we've matched all the files here, so there's a whole lot of information here that we don't need. We don't need all the three columns on the right. So we can shrink it down to just show one column.

as my hard drive spins. That is my hard drive, but it's not that slow. Don't worry. We hope. OK, well, it was a test tool. It's not our real application. Anyway, what would have happened there was that you'd just see the one column. You could resize it as normal, and all you'd have is your one set of files. So I'll just go back now to the slides.

So as I said, the UI is not the big part of AppleGlot 3. It's the architecture, what that allows you to do. So if we'll just take a look at that now. Monty, as I said, we use Monty. So that takes away a lot of the icky, low-level stuff for us. That leaves AppleGlot itself being much simpler and much cleaner.

That leaves us with AppleGlot being, say, a set of managers that provide services, and just a state machine. The managers provide services like managing the environment for you, they manage plugins, they manage errors and logs and stuff like that. But the power comes from being able to write your own plugins. You can write a plugin that will change the way the managers work.

So you can write a plugin that would, say, change the way the glossary manager works. So instead of coming back with just one translation, it would come back with, say, maybe five of the closest matches. Or go off to a machine translator and pull back a translation from that.

Similarly, the state machine processes the files for you, but you can write plugins that will fit into the state machine. So you can change the way the state machine works. So you can, if you want to handle a particular data format a different way yourself, you can do that just by overwriting the normal default behavior of the plugins.

Now, there's no UI shown here. It's completely separate. It's just a user of AppleGlot. It's just a user of the services. So you can write your own UI or whatever you want to put on top to control it. The UI that we provide, well, that also has plugins. So they just let you alter your own plugin behavior, or let the user alter your own plugin behavior, without you having to write user interface code yourself.

So just to look at it in slightly more detail, we have the state machine and the managers which make up AppleGlot itself. Then we have the plugins that the state machine uses to alter the behavior of the state machine, or how it processes files. And we can also see here where Monty fits in. Monty fits in under the plugins. So if you're a plugin, if you don't want to use Monty as your base technology, you can go do whatever you want. But obviously, we believe Monty is the best thing to do.

The manager's managing the environment for you, and you can write plugins that will change the way the manager works. The UI just sits on top of it all, and you can write any other UI as you want. So you can write a command line interface, package the whole of AppleGlot up, and use it as part of a build system. Or you can package it up with Apple events and just use it completely from scripts if you want.

So just to go through some of the services we provide, we have environment services that I mentioned. These just manage files. They do the matching of the files for you if you want. We have glossary services. These look after the internal glossary. So they look after looking up translations or asking for translations like that. We have logging services, which just log errors and warnings and whatever notes you want to log. We have plugin services. Now you wouldn't normally use these. AppleGlot himself uses these to manage all the plugins. But if you needed to control the plugins yourself, you could do that.

And finally, we have State Machine Services. So this just lets you control the state machine, start it off, stop it, and get information from it. So the snake machine itself, a bit like the passes you have in the current AppleGlot, has three modes of execution. We have extraction, where you would run through the snake machine just to extract data.

We have insertion, where it just runs through the snake machine to insert data. And we have a final mode, which AppleGlot 3 itself doesn't use, but it's there for anybody who wants to write a plugin. You could maybe do verification or tidy up or do whatever you need to do after the file has been created.

So the state machine itself is just like any state machine. It runs through a series of states. It completes everything it needs to complete in one state before moving on to the next. The states are kind of separated out in AppleGlot 3. We have preprocessing states, and these are called before any processing is done, obviously.

So you'll be called, say, before a file is opened to be processed. You would be called before a particular data type is processed, or it would be called before the individual piece of data is processed. We have the data processing state itself, where you would either extract or insert data. And we have the post-processing states.

And these states just give you a chance to clean up. So after the data type state, you can maybe get rid of the translators or the templates. After the file state, then you maybe close the file or do whatever you need to do to tidy up after processing that file.

The states themselves don't contain any logic. All they do is they call out all of the plugins registered to be executed in that state. And they execute those plugins in order before moving on to the next state. where they will execute all the plugins that are registered to execute in that state, and it will keep going on as it moves through all the different states in the state machine.

So the plugins themselves. AppleGlot comes with a set of default plugins. These implement the normal behaviors that you expect AppleGlot to do. But because we have these as plugins, you can just very subtly override what it does by providing your own plugin that does something, but doesn't affect any of the other behaviors. Or you can ditch them all together and do whatever you need to do yourself.

One single plugin can act as a number of different plugins. So you have one plugin that may be a state machine plugin, and may be a preference panel plugin. It's nice for packaging up your plugins if you want to send it out. Or it's also handy for passing information between plugins.

So the types of plugins we have, as I said, we have service plugins. So glossary plugins, again, you're managing your glossary, so you can change the way the glossary lookups are done. An example of that, as I said, was Fuzzy matching our machine translation. We have glossary file plugins. This just manages the way the glossary is written to disk.

So if you don't like the way Apple writes the glossary to disk, you can maybe write it as an XML file or write it in some form that some other process needs to use. We have log exporters. So if you like writing a log exporter plugin, if you want your errors and warnings to go through the screen so the user can do something straight away, well, you can do that. Or you can even go out to the files as normal.

We have state machine plugins. As I said, they alter the way the state machine behaves. And we've gone through that. We have preference plugins. And these just let you give the user a user interface to choose what it wants to do with your plugins without you having to write the interface yourself.

So the things to take away from AppleGlot 3. AppleGlot 3 works simply and efficiently with Mac OS 8, 9, and 10. AppleLock3 can be customized to fit your own requirements, so you get AppleGlot to do what you want to do. You don't have to fit in with the way AppleGlot works.

And AppleGlot 3, well, the UI has evolved, but we believe that the potential with the architecture means that it's a revolution, and we believe it is as revolutionary as the original AppleGlot itself. So I'd just like to welcome Colm back on stage to run through the more information and to get the questions and answers started.

Thank you. Okay, thank you. So I hope that these two technologies that we're making available to you are actually going to be useful within your processes. I know they're certainly going to be useful internally in Apple in our own localization processes. So, you know, there's certainly plenty of information. We could go into an awful lot of depth here. I don't think it would be of value at this stage. But these are fairly complex applications and tools here. But we've provided very, very simple interfaces for you to use.

And so what we want to do is we're going to make available quite extensive examples, application, sample applications, UI documentation, SDKs, etc. And we're going to make these available to you through the normal WWDR websites. And we also have a contact manager as well, who's going to basically handle all the questions and comments and suggestions which you may have.

And I actively encourage all you users of these particular technologies to, you know, send your feedback, send your comments to us, and we'll certainly respond to them. It's only by, you know, getting us the information and the suggestions that we're actually going to make these and evolve these into even better tools and technologies. So what I want to do is just give you an idea of where these are in the development cycle. First of all, Monty is almost GM. In the next couple of weeks, you're going to see this information.

And we're going to have a lot of great information available on the developer.apple.com websites. The information will be provided up there. It'll be packaged in the format that you require. The Apple framework itself, we're actually currently just finalizing the internal architecture at the moment. So in the next month or so, you're going to start to see the first alpha and beta applications up there. And I actively, again, encourage you to take those applications, use them for, you know, whatever you want, sample projects or live projects. Give us the feedback.

Because we have a fairly aggressive GM target date in a couple of months' time, and we certainly want to incorporate as much features from you guys as possible. And we also actively encourage you to start with the SDKs, look at how you can actually customize the operation of particularly Apple's lot and how you can get that working more effectively and efficiently in your process. So what I'd like to do is just point you at a related session immediately following this session.

We've got a Mac OS X localization session, session 157, following in this hall. And I'd encourage you to attend that session also. There's some very valuable information to be learned about what you need to do to localize for X. And that session is going to run for approximately an hour and a half also. So what I want to do now is actually, I know a number of you have questions, so I'd like to encourage you to...