[00:00] Project translation, or what is called a client localization, is the ability to define translations for text on screens. That way a project can be displayed in any language that a user chooses. The process is fairly straightforward. For every element of text on the screen, you provide a translation in the desired language. Then, when the user logs into a project, they can choose their preferred language, and the screen will be displayed in that way. To get started we'll come into the Translation Manager, and define a language that we want to translate to. By default we have an English language defined. This allows us to provide an alternate translation, for a given key, and that is, although our keys are assumed to be in English, they don't have to be, and they can be symbolic codes instead. For our example here, we'll add Spanish as the language that we want to translate to. So we click on Add New Language, and then find Spanish. The Translation Manager allows you to view all of the terms in your translation database. The translation database is shared across all projects. And so you'll see all the terms that have any translations from all projects in this space. It allows you to manually add and remove terms, and provide translations in this space, as well as import and export terms and translation. Additionally there are several settings that can affect how terms are matched up. For now though we'll go back to our window and look at a couple of the other ways that you can provide translations. First and foremost, on any text element, you can edit the text and click on this translation button at the bottom. If the term is defined in the database, it will show up here. Otherwise, you have the ability to add it. If we add the term, it now exists with no translations. In this space we can choose to translate it. That's all there is to it. Now let's store it in the database, and anywhere the word temperatures appears it will be translated if the user switched to Spanish. A key aspect to this system is that you're not actually creating any bindings to the translations. Instead, throughout this system, it automatically takes the text of the component and looks it up against the shared term database. To see it in an action we can quickly add a language selector component to this window, which lets the user choose between the defined languages. Go into preview mode and toggle language. It's a subtle change but we see it take effect immediately. The other way to provide translations is to use the component translation panel. When I right click on the screen, also a Control + T, at any point, the panel appears on the left. This component recursively browses all of the available text from the current location. So for example clicking on the the Temperatures label, gives me the text property. By going up to the parent container gives me the text properties of all the contained components. I can keep going up, all the way to the root container or window level. At this point I can select a text property and provide a translation in all of the defined languages. We see here that there's a distinction between global and component translations. This subtle difference means that the translation will be stored on the window or template as opposed to the global database. This allows us to more easily import and export translated components and share them with other people. Providing a translation here under the global section updates the same term database. So now we can come back to the Translation Manager and see that we have both of our translations. We can come to different labels, edit them and provide translations. If we don't want to translate them at this time, we can choose to mark them for translation and let somebody else come into the Translation Manager later and provide the translation that we want. Or we can export them and have a third-party provide the translations at a later time.