June 4, 2024 / by the SimulTrans Team Estimated read time: 6 minutes
Here are the top five questions we get asked most frequently by our clients for app localization projects
Q 1: What type of files do I need to send to my language service provider?
There are a host of potential file formats, which can be either Text based (XML, RC, HTML, PO, PROPERTIES) or binary (XLSX, DLL or EXE). Technically, you can send any of these file formats in for localization.
But it is important that when you send files to your LSP that these files can be easily identified, and the text that requires localization can be easily isolated.
Once we know the file format and isolate the localizable content in the source files, then we can decide on the most suitable tool for localization.
The more information a client can provide here the better, as it ensures we understand the scope of the request and we can set expectations accordingly.
Q 2: What tools are used for app localization?
Selecting the right app localization tool is important in many ways, most notably we want to ensure the efficiency of the localization process while maintaining the integrity of the file.
Certain file types by their nature work best with certain tools.
- Visual Software Localization Tools: These work best with files that have dialogs and form objects for RCs and DLLs.
- Help Tools or professional authoring tools: these are used for developing help systems, e-learning content, Knowledge bases or policies and procedures.
- Digital Audio-Editing Tools: these are perfect for sound recording and for Voice over type work.
So depending on the project and file format, your LSP will decide which tool is best.
Once the tool is selected by the engineering team for a particular project, then that tool is used to prepare the resource files to go directly to the translation team.
Q 3: What are the most typical app localization issues in a project?
The most common issues we encounter are:
The localizable content is not easily identifiable
Comments should be used in the files where possible to denote the extractable text.
For example <!--not loc--> or # DO NOT LOCALISE comments.
The strings or text are without unique ID’s or identifiers
This makes it more difficult to re-use the strings as part of a later update or the next version release.
Think about using files that have unique numbers or id’s per string.
Some strings that need translation may be hard-coded by the developers
This means text cannot be easily extracted for translation. Consider keeping the localizable text file in a separate file that can be easily identified when sending files.
The file format is not agreeable with our toolset
The file may be in a format that is not useful for localization. Use standard file types where possible.
Locating the resource strings within an app or on a website is difficult
Be sure to provide a reference to a specific location of the site so the software localization engineer knows where to search. For example “Within the Feedback section or from within the main page”. This is particularly important when the string appears in a number of files, but only one instance needs to be modified.
Q 4: How Do You Test a Localized App?
The localization testing phase is important to ensure that the localized version has stayed true to its original design. The level and type of testing more commonly carried out is Functional and/or Linguistic testing.
Linguistic testing
This means having linguistically-focused testers verify the correct use of terminology in context, while looking for incomplete translations, spelling and grammar mistakes.
Functional testing
This means a tester navigating the entire app, to discover localization issues in the layouts and strings that can affect user satisfaction.
The aim with any testing phase is to spot and fix any localization issues found. The most common issues are: string truncations, concatenations, untranslated words, etc.
The use of an Emulator is a popular method for testing localized apps. This means that by changing the display language in the device to test your localized app, it can help verify that your content renders correctly.
Q 5: What Do I Request Back from my Language Service Provider?
Generally speaking, this is specific to the individual customers' requirements and is dependent on the type of file.
If you are going to build your localized app in-house, then simply request the return of the fully translated file (Bilingual).
This means that your internal engineering team can then drop the localized file into their system. Think an XLIFF file here!
For text based files, these can just be returned as a translated version of the source files. Think XML, PO or JSON files here! For more complex projects or when you want your LSP to also build the app for you, then you would decide on a set of specifications and milestones for delivering builds or projects within a dedicated build environment.
One shortcut when embarking on localization for the first time, is to complete a pseudo translation to find out the most typical app localization issues in a file.
If you would like a pseudo-translation, send us your file, and we can give you a free pseudo-translated file back for you to test internally.
