# Localization for Motion Design: Plotting Processes for Success - Link: https://phiture.com/mobilegrowthstack/localization-motion-design-processes/ - Published: 2023-08-22T12:23:49+01:00 - Author: Michał Gryga [[ _Phiture’s award-winning Design Team delivers creative motion design for category- leading apps operating in numerous markets and locales. This makes effective localization crucial. In this article Michał Gryga shows how we at Phiture rely upon robust internal processes to facilitate the delivery of localized motion design, and suggest best practice to inspire your own workflows._ At first glance,  localization for design seems  a straightforward task. The creatives are briefed for several locales, then prepared for the client. It might be required that some aspects of the creative design are tailored to fit specific regions, and any copy and assets translated into different languages.   However, as the asset count increases, so does the potential for confusion and mistakes, especially  so when the scope of a creative brief and localization requirements are not initially clear or change over time. For this reason, it’s worth investing time in planning your approach to localizing creatives and how you organize your files. The benefit? Designers won’t find themselves mired in files, assets, and translated texts later. Instead robust processes will mean Designers and Design Teams can concentrate on delivering great assets. In this article, we introduce our own best practices for managing this process, and discuss the relative merits of different approaches to file storage.     ### **Initial localization considerations for motion designers** Central to the localization process is knowing how many variants there are to prepare. Note we don’t say languages, as each further variant requires its own place within work files – even with just a single difference between two videos in the same language. If there is just one or two locales, this is easy enough to handle without thinking too far ahead. If there’s up to ten locales, it’s worth anticipating the next steps by preparing the source files specifically for the process of localization prior to localizing any asset. If there’s more than ten, there may be potential to save some time by automating the process.   #### Differences between locales With the number of locales locked down, the next topic for the motion designer to consider is the differences between locales. It’s also worth adjusting creatives to better fit new markets, if any, too. These differences might amount to simple cases where only a few lines of copy are translated, or it could be the complete localization of UI elements, images, stock footage, and even preparing a new ‘hyper- localized’ variant that differs from the original. Bear in mind the more changes we expect for each locale, the better our plans for organizing our files should be at the outset.   #### **Number of deliverables** Just like the number of locales, the number of deliverables and formats will also influence the workload. If you need to prepare many ad groups and formats, there are a few localization shortcuts you can try. One shortcut is to reuse assets between formats and ad groups, so you only need to replace them once. However it’s certainly worth doing more planning and source files cleanup for the video you need to create before doing any localization work.   #### **Project cooperation** A separate topic worth discussing is how the project and cooperation will take shape across timelines, and especially if you anticipate making global changes to creatives after localization. Of course, the best-case scenario is that the client approves the localization process beforehand. This is because defined project stages are crucial for clean workflows. However, there might be reasons why you need to make changes to the video after localization, for instance if seasonal iterations of the video are required. Making changes later will be much easier if you organize the source files within a single Ae project as you can share a single pre-composition between all language versions and means you will only need to change once instead of individually for each locale.   #### **The importance of hardware** It’s easy to forget about the limitations of hardware. When planning file structure, consider how big your source files might get, and specifically, what is the limit of what Adobe After Effects can handle on your hardware? Working with big .aep files– especially ones with a lot of expressions, linked assets, and so on – can slow down your hardware. From this standpoint, the fewer project files you create, the better, however this is something you need to reconcile with your workflow.   #### **Timelines** Timelines are also important for the selection of solutions of motion designers. The work can be sped up by dividing the localization between many people. If you take this route (or even if there’s a chance you do so later in the process), it will limit how the source files can be handled, simply because it’s not possible to have more than one person working on a single .aep file at the same time.   ### **Solutions** Based on these initial considerations, we can now ensure the implementation of tailored organization solutions for our motion design localization tasks.  For this end, there are a few ways to organize files; * separate packages (project file and linked assets) for each locale,  * separate project files for each locale but with a shared footage folder,  * or keeping all locales in a single project file. There’s no perfect solution; each brings their own benefits and drawbacks, depending on your client work. The flow chart below outlines good rules of thumb to follow when plotting your organization, with further explanations of these practices’ relative merits below.  ![](https://phiture.com/wp-content/uploads/2023/08/motion-gfx.png) _A flow chart to help motion designers decide which storage solution works in practice, depending on the project. _   ### **Solution 1: Separate packages** The default approach to file organization is to keep the first locale separate and to create a copy of the content (.aep file and all the linked assets) for each additional locale. In effect, this treats each locale as a separate, standalone project. There are many benefits to this approach. ![](https://phiture.com/wp-content/uploads/2023/08/image2-4.png) _Separate packages in practice, with standalone projects for each locale. _ #### **Separate packages – benefits** * **Simplicity of process:** For every new locale required, simply copy an entire folder and you’re ready to go. Any asset can be replaced without problems surfacing, such as inadvertently replacing the asset for another locale. * **Content clarity:** When every deliverable and locale is stored separately, they are easily found. There’s no need to open .aep files to look for a particular composition to render. * **Easy file management:** There are no shared footage elements between folders, eliminating the risk of accidentally overwriting something as each deliverable has its own set of files. Ease of sharing: Whenever there’s a need to share the source files, there is a folder ready to send. * **Fast replacement:** Theoretically, assets can be replaced from the file manager level directly. So once After Effects is opened, all the assets are already replaced. It’s worth noting, though, that this fast replacement can be a double-edged sword. It is sometimes safer to replace the assets one by one to see how they behave in After Effects and catch any errors. * **Software performance:** By working on a single locale at once, the project file won’t grow too much. As a result, problems common for big source files are unlikely to happen.   #### Separate packages – drawbacks * **Disk space**: Each folder created by copying the original will contain a lot of video footage. * **Rendering process**: As there are separate .aep files, each would need to be opened to start the render. It’s a tedious process, even if an external renderer( like Media Encoder) is used, and  even longer again when the file is  rendered from After Effects directly. Unfortunately, this can’t be set up in advance and left  overnight  as each .aep file needs to be opened separately, and the render started from there. * **No easy way to apply global changes**: If there’s a request to change something globally, it will need to be done  many times over in every separate .aep file. The same principle applies to any global footage change – the files will need to be replaced  in each instance.   #### **When separate packages are the best solution** * **Low number  of deliverables:** The drawbacks won’t be a concern if the  localization process only creates two or three separate deliverables (ie. locales, formats). * **Big differences between locales**: If the videos for each locale are very different from others, there’s no need to force any process improvements as there will be few associated benefits. * **Multiple designers**: As files aren’t shared across different deliverables, many people can work on localization at the same time. * **Clear project timeline**: If it’s certain that there won’t be any global changes after approval of the first locale, then this is a safe solution.   ### **Solution 2: Separate project files with a common footage folder** To cut down on some of the obstacles from the previous solution, create a single Footage folder where all the project files will link. That means, for each new instance, the .aep file is copied and the Footage folder will contain files for all the locales. This can be approached in two ways. .  1. All files are dropped there, which works if there aren’t too many locale-specific assets variants,  or 2. have a single folder that will hold all the localized assets. _A common footage folder in practice, with linking project files. _   #### **Separate project files with a common footage folder – b**enefits * **Saving disk space: **All the major files shared throughout the locales exist only once, as a single file. This also means that if an asset needs to be replaced globally, it only needs to be done once. * **Neat file organization:** This approach forces clean file management. It’s obvious  which files require localization by checking the content of the Footage folder, even if the designer is seeing the files for the first time. * **Software performance:** Since the designer is working on a single locale at once, the project file won’t grow too much with none of the problems common for big source files. * **Simple loc process: **Store all assets requiring localization separately and sort them by locale. After that, it’s easy to create another instance, while if another designer is taking over the task, this solution enables them to check which assets need localization. #### **Separate project files with a common footage folder – drawbacks** * **File management:** To prevent changing an asset across all locales or linking a file meant for a different locale, you can control what’s happening in the Footage folder. Here, having a separate folder with shared and localized assets helps. At the same time, pay attention to what’s linked in After Effects, and manage the files properly there, too. * **Rendering process:** In this case, separate project files are also possible. The rendering process looks similar to what’s happening when source files are not organized together. * **No easy way to apply global changes: **If there’s a need to change something globally, it will  need to be done multiple times in every separate .aep file.   #### **When separate project files with common footage folder is the best solution** * **Most versatile solution:** If it’s unclear how many locales there will be to produce, it’s safer to split the project files by language from the beginning. This is because it’s easy to create a new copy of an .aep file. * **Multiple designers:** Several designers can work on the localization at the same time, as long as they’re aware of how the file management functions. Designers can either work on a shared folder or on their private instance, which is then synced into a single place. * **A lot of deliverables:** When there is a big number of locales, After Effects might not be able to handle a single file containing all of them inside.   Table of Contents * [Solution 3: Single project file](https://phiture.com/mobilegrowthstack/localization-motion-design-processes/#solution_3_single_project_file) * [Summary](https://phiture.com/mobilegrowthstack/localization-motion-design-processes/#summary) * [Before you go:](https://phiture.com/mobilegrowthstack/localization-motion-design-processes/#before_you_go) ## Solution 3: Single project file Once all the assets are kept together as a single (footage) folder which the .aep files are linking to, it’s time to declutter the Footage folder and have the common assets and localized ones stored in separate subfolders. It’s also tempting to replicate this approach inside After Effects too, and having all localized versions in a single. aep file to mirror the structure in the (Footage) folder. ![](https://phiture.com/wp-content/uploads/2023/08/image1-2.png) _Assets and compositions grouped by locale within a single project file._   #### **Single project file – benefits** * **All in one place:** Having a single .aep file for all deliverables makes the whole process simpler. This is because there’s no need to make copies of project files or open several  files. * **Rendering simplicity:** Whether rendering using Media Encoder or After Effects, including all output compositions in a single file is far simpler. * **Cleanest organization:** This approach forces a clean structure, both in the( Footage) folder and also in the .aep file directly. * **Easier to make global changes later:** If you need to change something globally, having everything in a single .aep file is helpful so it’s not necessary to change separate instances.   #### **Single project file – drawbacks** * **Software performance: **The biggest problem when storing a lot of deliverables in a single file is that the .aep file size will grow fast. This influences the performance of After Effects, to the point of not even being able to open the project file on a slower machine.  * **Doesn’t enable cooperation: **The work cannot be divided between multiple designers because they would have to work on a single project file at the same time.   #### **When this solution is the best** * **Average amount of deliverables: **If you’re not expecting a lot of locales ( both now and in the future), it’s safe to go with a single file. The worsto- case scenario is that these  locales can be divided by groups or tiers in order to divide a bigger file into two separate ones. * **There is only one designer working on the project: **If it’s certain there won’t be a situation where two designers  have to work on the same project.   ## **Summary** In conclusion, there’s no single solution that’s perfect for every application. That’s also the reason why it’s sometimes hard to form a rigid motion design process to which all designers involved will have to stick to for every project. It’s important at the beginning of every project to take a step back and think about what you need to achieve and what would be the best approach to do so. Asking yourself questions about the scope and the environment you’re working with can help avoid stressful situations later.   ## **Before you go:** * The Persuasion Emotion Trust (PET) Model is a framework used by Phiture to channel creativity into great design concepts for mobile. [In this downloadable resource](https://phiture.com/pet-model/), Phiture’s Design Team shows how they use the PET Model to design for apps, whether that’s for the product itself, or for Retention, App Store Optimization, or Performance Marketing purposes. * Curious to learn more about how we localize for our clients at Phiture? [Find out how we helped Sololearn identify new markets and reduce cost per trial by 40%.](https://phiture.com/success-stories/sololearn/)