Localization should not be a single task that you perform after everything else but an ongoing process that continues throughout the product lifetime. Such kind of process is called continuous localization. Using Soluling, you can make the localization process a part of your development process. You can start localization at an early phase of the development, and the localization process can continue simultaneously with the development process.
Traditionally location process contains three steps: Create a project, translate it, and finally build the localized files or database items.
When you create a project, you select the files or databases you want to localize. Soluling scans the selected items and extracts the elements that need to be translated. After you have created the project, you can fine-tune the project settings and settings of each item in such a way that only those items that you want to localize are included in the project. For example, you might exclude some strings and include some rare resource types. You can change the setting at any time. Because these settings determine what items are included in the project, Soluling will rescan the selected items after you have changed settings. Also, if the original files get changed (e.g., application get changed), you should let Soluling rescan the items. After each rescans, the project contains all the items found from the original files. The rescan process does not affect your existing translation, but they remain unchanged.
When you have a project file, it should be translated. Soluling gives you several ways to translate the project. The next paragraphs on this page described different translation options.
The third step is the build step, where Soluling uses the original files and translation in the project file to create localized files. You can perform a build step at any time. Your project file does not need to be fully translated. If there is no translation for a specific item, Soluling will use the original value. You should build the localized files right after you have created the project to make sure that the localized files or databases can be properly created. Every time you receive or import new translation, you can let Soluling build localized files. Testing localized files is an essential part of the build step.
When using continuous localization, you perform the same steps but instead performing them once you repeat the translate and build steps each time you have modified your source code. You typically perform translate-build steps several items, for example, after you have changed original files or found a translation error on the localized files. The process keeps going until all items are translated in all languages, and there are no changes in the original files. Once you change original files or you want to add a new target language, you continue the process.
Most often, a developer or localization engineer controls the process. She creates the project, builds the localized files, and in many cases, also tests the localized files. Create and build steps are pretty automatic. When creating a new project, Soluling collects all the information needed for the project. The build step is simply a matter of clicking one button on Soluling. The translation step, on the other hand, requires much more work, and in most cases, additional human resources are needed. Let's study different translation methods.
If you know well both the original language (i.e., language used in the original files) and the target language(s), you can do the translation job all by yourself.
You can either type the translation in the translation grid, you can import translations from various sources, you can use translation memory to reuse existing translation, or you can use machine translation to automate translation task. Because you work alone with the project, there is no need to share it. You do everything by yourself. Unfortunately, the above scenario is very rare. Very few developers can both develop an application and translate it to all target languages that are needed. In most cases, you need the help of translators.
When you use translators, you can target more languages, but it also introduces some challenges. The most obvious is how to deliver strings to the translator and in what format. In the old times, text files and Excel sheets were used extensively. They seemed like an easy solution but generated massive extra work when preparing the localization kits when receiving translated kits. Soluling lets you create an exchange package (i.e., localization kid) easily. You can then send the package to the translator using email, for example. Once the translator has completed translations, she will send you back the translated package. You import the package, and all the translation done by the translator will appear in your main project file.
The above process works well and does not require any additional software. However, if the number of target languages if high or your original files change often, you have to create exchange packages frequently and send them to a translator and finally import them back one by one. This job may be frustrating and should need some optimization. You can use this method only if your translator also uses Soluling's desktop tool. There is a free translator edition and low-cost professional translator edition available. If they do not use it, then you have to export data into the format that the translator can use and then manually send the file to the translator.
Will be available in early 2021!
Unlike the above method, when using the cloud tool, you just publish (i.e. upload) your project to the cloud where it waits for the translator to start working. The developer can, at any time, download the most recent translations into his or her project file. This can also be done from the build automation process.
If you use manual localization then the process looks like this.
The whole process is very automatic. Whenever you have new strings to be translated, you click the publish button, and Soluling uploads the new strings into the cloud where they are instantly ready for translations. To use Cloud Translation Service, you need to purchase a Cloud Translation Service account.
You can easily make this fully automated by using continous localization. Your build server uses SoluMake to scan your Soluling project to find any new or modified strings. If found then the build server uses SoluMake to push the changes to the cloud. Next time the build server builds the localized files it first get the most recent strings from the cloud.
Another situation where the cloud tool is used is when using the crowdsourcing (Wikipedia). It is a process where you outsource translation jobs to a distributed group of people. Unlike in the above team approach, you don't have to know the translators, and you don't have to make any contract with them. In most cases, your translators even work for free. As explained previously, Cloud Translation Services contains the translation. Once a translation has been entered, it is immediately available to be used by the developer or build automation. When using crowdsourcing, the developer uploads the created project to the cloud, where it immediately gets ready for translation. The developer can give only certain translator access rights for the project (private mode), or the access can be public, making it possible for anybody to translate the project (public mode).
Crowdsourcing has many advantages over traditional localization and even over team localization. First of all,l it is completely free. You have to purchase a crowdsourcing enabled account, but you don't pay anything for translations. The cost of a crowdsourcing enabled account is fractions of the traditional translations job. Second, the quality of crowdsourcing is surprisingly good. In most cases, it matches or tops the quality of paid translations. The reason is that the translation job is done by persons knowing your product and the terminology it uses. Also, there might be many users working together on the same language, so each translation is viewed and rated by several translators. This improves translation quality. Third, the translators are not limited to using Soluling on Windows. There is a web interface that translators can use from any browser. Also, there are mobile and tablet clients for all major mobile and tablet platforms (iOS, Android, and Windows ). Translators can get the free client application from the application store of their device.
The disadvantage of crowdsourcing is that it might not work unless there is no solid fan base of your product. Crowdsourcing only works when there are people eager to translate your product. Also, it might take longer to translate your project using crowdsourcing compared to using paid translators. Unlike the Soluling editor, web interface lets you translate only strings. No UI size changes or image translations can be done. However, if you design your application correctly, there is no need to translate anything but strings.
In many cases, crowdsourcing is a serious alternative for traditional translation. Crowdsourcing is used by many social networking sites such as Facebook.
Will be available in 2021!
This option uses the same process as above, except you don't need to have your translators. You order translations from a cloud translation service that uses a pool of professional translators to translate your project.