 Hello. Welcome to my presentation about providing shortcuts for different languages. With Collaboration Online, users can collaboratively work and edit a single file. And while they are using collaborative editing features, they can use also shortcuts of their language. For example, a user with an English language selected can use the English shortcuts. But at the same time, if a second user is working on the same file with a German language, then the second user cannot use German language shortcuts. In this case, our Collaboration Online is separated from CoreSide, LibreOffice Desktop Suite. So, as a requirement, we support now different languages with different shortcuts while collaboratively editing the same file. When a user opens a file with a Collaboration Office Suite, they can use the shortcuts specific to their language. This was the same for Collaboration Online, but with an exception. Once a file is opened with a language, other collaborators have to use the first person's languages shortcuts. Users should be able to use their own language shortcuts when they are collaboratively editing a file. The aim is to provide the same comfort to Collaboration Online they have when they use the Collaboration Office Suite. And the challenge is, SFX VeevShell holds the accelerator configuration implementation and executes the commands. For every Veev, SFX VeevShell has an accelerator execute class for handling the operations. The accelerator execute class in the first call checks if shortcuts are loaded and cached. If shortcuts are not cached yet, then a shortcut manager is created and shortcuts are loaded. So, with every Veev, SFX VeevShell checks if there are shortcuts or not, and if they are not loaded to the cache, then it caches the shortcuts. The problem is, even though every Veev has its own accelerator execute class, they use a shared cache for the shortcuts. The office suite is designed as a desktop application suite. Therefore, it didn't need to support multiple Veevs, multiple UIs, or multiple accelerator configuration instances until Collaboration Online arrives. Many of the manager classes for UI, shortcuts, Veev, etc. were singleton classes. These singleton classes are not necessarily implemented with a singleton pattern, but used as if they are singleton by the app. The app checks if there is an instance of the class or not. If there is one, the app only uses the pointer of already created class. So, when another user opens a view for the same file, then the app turns back the only created class to the user. And UI shortcuts is not an exception in this case, and the same shortcuts of the first user is turned back to the second user, even if the second user's language is different from the first one. So, when a code piece calls a create foo function, that function may not necessarily create any instance of a class. The singleton classes challenge was already beaten before. After Collaboration Online needed multiple views for collaborative editing. For providing shortcuts for different languages, we also needed to break the singleton barrier for accelerator configuration. Shortcuts are loaded according to the UI language, and then they are catched in the class implementation. To accomplish our goal, we needed to change the UI language to the target language, create a new accelerator configuration class, cache the shortcuts for that language, set the accelerator class of the view, change the UI language back to its actual value. And the result. All the changes to the core API are done with checks. When the brofiskit is not active, the changes cause no different behavior for desktop users. But with Collaboration Online, users can now collaboratively edit documents while they use their languages shortcuts. Thank you for listening.