Stepping Stone assists development teams across the daunting challenge of introducing software to other markets.
The complex process including preliminary internationalisation and other pre-localisation stages, the various translation requirements, terminology consistency and QA and last but not least, testing.
As a general overview, let us assist with:
- assessment of whether your software has been properly internationalised
- cultural assessment
- analysis of what needs to be translated and extraction of the text for translation
- creation of terminology lists
- translation into the target languages
- adaptation of graphics
- compilation of the localised files
- linguistic QA
.NET, Java, po, pot, properties, ts, dklang, dtd, json, yml, resw, resjson, rc, ini and more
- Microsoft .NET (.resx)
- JAVA (.strings)
- GNU GetText (.po & .pot)
- DKLang (.dklang & .lng)
- XUL (.strings)
- Google Chrome (.json)
- RoR & YAML (.yml)
- Windows 8 (.ersw & .resjson)
- Windows RC (.rc)
- Flex (.properties)
- Qt Linguist (.ts)
- Joomla Localization (.ini)
- Generic INI (.ini)
Our PMs and tech planners are well versed in preparing and advising development teams and software architects on the important stages of preparing software to be localised. The key elements are summarised below:
Before the software can be localised we need to make sure it has been internationalised, i.e. it can work under different character sets and regional computer settings. Software may be adapted for dealing with double-byte characters used in Asian languages such as Chinese, Korean and Japanese, right to left writing systems of languages such as Arabic, Hebrew and Farsi, as well as accented European languages.
Another aspect which should be considered is the length of UI strings. There are a lot of languages which are 30% longer than English. Therefore having enough space for your UI messages may be essential. Software messages which end prematurely or menu buttons with half of the word cut off will look unprofessionally.
Cultural assessment also plays an important role in the localisation process. Does your software contain graphics, logos, slogans or colour schemes which might have a negative effect in the target country? We can perform cultural assessment to make sure your software will work in other markets and provide a report of changes to be made prior to the translation.
GUI components are the resource files/strings displayed as menus, dialogue boxes, error or status messages, etc. They can either be translated directly in the resource files or in the compiled program files using either a resource editor or a software localisation tool.
Help files are usually the largest component of a localisation process. They are normally in .rtf, .html and/or .xml format, etc. They are easy to localise as most translation memory tools support these formats.
The documentation includes readme files (normally in .txt format) and word files. These are translated using a translation memory tool.