When localizing SAP material into Japanese, there are many factors to take into consideration. Through years of experience, Kawamura International has been an SAP language partner for the past decade, and our board member, Kozo Moroguchi has provided us with the 3 main things you should know when localizing SAP material into Japanese.

1.      Double-byte characters

As everyone knows, Japanese text uses double-byte characters.

The number of characters that can be displayed on a product’s interface is limited, and there are many cases in which characters are not fully displayed on the actual screen as localization into Japanese has been done without taking this limitation into account.

Numbers, katakana, and the alphabet also have double-byte and single-byte versions, and, if there are no stipulations regarding their usage, they could force a system to shut down in a worst case scenario. There are cases in which a single-byte slash used for an area of a translation in which only double-byte characters are permitted has resulted in corruption of all the characters in the report subsequently output.

As such, it is best to decide the rules before starting a translation project.

2.      SAP Term

Although there is a database and website that allows you to view SAP terminology, for Japanese there is a very unique process that involves having the relevant SAP field staff member check each term to be defined before release. Field staff members are responsible for making the final decision on terminology, so this has a high degree of reliability.

As there are a lot of SAP expressions and terminology that have been handed down from the R/3 era, we have to comply with SAP Term as users who have been using SAP products for a long time will feel something is wrong or in the worst case be hindered in their use of SAP products if we don’t.

In terms of ease-of-use as well, complying with SAP Term is very important.

3.      A range of notation rules

As Japanese text is comprised of single- and double-byte characters, katakana, hiragana, letters and numbers, there is more variation in notation rules than other countries.

Even for brackets, you have four varieties of 「　（　『　【  and there are single- and double-byte variations for these as well. If there are no clear rules about which brackets to use, then this can cause inconsistences during translation.

In the case of SAP, as the number of products they acquire increases, so does the burden on the people doing the translation. Acquired products have already been translated in some form and have their own terminology and notation rules. They are acquired and added to the SAP product family, and this causes conflicts between the terminology and notation rules henceforth and SAP terminology and notation rules.

While there are some projects where translation is restarted from scratch using SAP notation rules, there are others in which notation and terminology conventionally used are reused as far as possible,

 We have to listen to the requests of the developers and make proposals based on the current situation while considering what is best for the customer without simply sticking to the notation of one side or the other.

Mobile App Localization – tips to get the best outcome from your Language Service Provider

As a mobile app developer or marketer, one of your main targets will be increasing your app’s exposure, which would increase its MAUs (Monthly Active Users). After all any increases in revenue, are directly proportional to this. For you to be able to increase your exposure, you would have to explore the different regions and user types in order to determine their preferences and to some extent tailor the app to best meet their interests. One of the ways this is done is through mobile app localization.

As with every project your localization project starts with a planning process. To prepare your mobile app for localization it is necessary to internationalize it. Internationalization describes the process of extracting texts and placing them in so-called resource files. These files are then used for localization. Think of localization as customizing the content; and internationalization as customizing the code.

Internationalization is a process that should ideally be included in the very first stage of app development. That way you’ll avoid having to go through the hassle of editing a final product. In most cases, localization does not need to be planned ahead of the development of the app, unlike internationalization, where it’s harder to modify the code after its creation.

Some of the key phases of the internationalization process are as follows:

• Place UI text into separate files—not in the programming code
• Set up a multilingual architecture so your app can run in the language that is set on the user’s device
• Design a localization-friendly interface
• Avoid text on graphics
• Make an inventory of country adaptations

If you are working with a language service provider that has a technical team of localization engineers, they can help you with the internationalization initiative. They will not be as deeply involved in the code as your developers are, but they can add valuable insight by giving advice based on their experience with other projects. They can also help you in assessing whether your fields can contain the special characters in your desired target languages. This is a good test to make sure that your app does not produce unexpected bugs and that your interface allows for text expansion.

Professional Language Service Providers (LSPs) will translate your files using a Translation Memory (TM) which is a database of identical translations between source and target languages that assists them in their localization process. If you allow your LSP to read into your XML files directly, this would save you a lot of time preparing the source (which would otherwise involve copying and pasting your strings or preparing the text into Excel or similar formats). As mentioned before, the localization engineers that coach you at the internationalization stage would minimize the risk of your variables being overwritten in the process of localization. In addition, almost all LSPs use Computer Aided Translation (CAT) tools, which automatically detect your strings on the basis of identifier separation and make it easier to automate the translation process. Of course this is not machine translation, which is a completely different thing.

Very often, several parties are involved in reviewing content and making changes (e.g., a local marketing office or your LSP’s language specialists). Integrate everyone into the process. Ideally, your local LSP would be reviewing your content and making changes in order to adapt the content to the culture of the target market, which would save you the hassle of having to involve different parties in your localization process.

If your localization provider has a trained technical team, you can outsource the full process, i.e. you can send them the complete environment for app compilation and they send back the localized app, ready for release. However, if your localization provider does not have the technical capability to do so, you will want to take some time to determine the most efficient process for localization. For example, you would need to weigh the time and effort of the back and forth between your developers and the linguists versus having a trusted vendor that would take the application as it is and explain to you the pros and cons of each process transparently.

Localization is not a one-time job. It’s more like an investment you’ll get return on in the future. Localization supports the growth of your business and helps you to sell your products across the world. With the right tools and support localization will no longer be a hurdle for startups