The Linguist

@Linguist_CIOL FEBRUARY/MARCH The Linguist 13 FEATURES numbers and genders. In fact there are seven cases, two grammatical numbers and three grammatical genders. Each influences the words and their endings. So if you have a phrase such as 'X just liked your activity', the word for 'liked' will be different depending on whether X is male or female. Conversely, if we have 'X trips planned', the word 'trips' will be different depending on what number X represents. If X is 0, 2, 3, 4 or a number ending in 2-4, it will be translated as X zaplanowane wyprawy; if X is 5-19 or a number ending in 5-9, it will be X zaplanowanych wypraw. Another issue is variables – something that translators hate. Let's examine the string 'You're planning an X trip' (e.g. cycling or hiking). In English it is fairly simple: if you have a list of sports for users to choose from, the same list can be reused to fill in the variable. In Polish and other Slavic languages that's not the case. The grammatical case used in a list (nominative) is different to the case used in most natural-sounding sentences. So while 'cycling' on its own is translated as kolarstwo, in the sentence 'You're planning a cycling trip' it should read kolarską, or even rowerową. Otherwise we will get a jumble of grammatically incorrect phrases that make the user experience fairly painful. Many modern online CATs (desktop solutions are lacking in this regard) allow multiple translations for a single string, typically labelled ONE, FEW, MANY, OTHER. This means that we can enter different translations for different number ranges to ensure the text sounds natural. This does require the app developers to include such an option in their software. Some CATs allow us to tackle a similar issue with grammatical gender. But what if this option isn't available? Then we have to rephrase the content. Coming back to the example above, we can switch from 'X trips planned' to 'Planned trips: X', which would be translated as Zaplanowane wyprawy: X. This isn't as natural as a regular sentence, but it's an acceptable workaround. In our case, we were able to ask the end client to include the variations for different number ranges, which is the ideal solution. For variables, we opted for paraphrasing and used a parenthesis to denominate the sport. So where we had cycling as a sport, we translated it as Planujesz wycieczkę (kolarstwo) ('You're planning a trip (cycling)'). Again, this is not an elegant solution, but the workaround allows us to remain grammatically correct and faithful to the original. Context and multiple meanings. As we all know, context is king. But in app localisation this can be a serious issue, as we often lack a full body of text which provides that context. Returning to the word 'name', when it refers to an object it is no longer translated as imię i nazwisko but as nazwa (and in some cases tytuł; 'title'). The word 'save' can mean both 'to save money' (oszczędź) and 'to save data' (zapisz), each translated differently in Polish. The preview function helped with this. We had extensive screenshots, so in most cases we knew which items of text went where and could work out the meaning from that. If we didn't have the relevant screenshot, we could use the key name or ID to find out details about the string (the ID is a designator used in programming which often provides basic information). And if that failed, we could always install the app and try to find the given string. The last resort was to ask the client. The key takeaway here is that you shouldn't assume anything. Ask the client – they may even go as far as rephrasing the source string once they realise it could be misinterpreted. This is a common issue, especially as app developers and copywriters have an intimate knowledge of the subject, so certain things seem obvious to them which may not be obvious to the end user. Mistakes are inevitable, even if you have the full context, ask questions and put a lot of effort into paraphrasing the source to ensure it fits the layout. Things get misunderstood, linguistic errors evade even the closest scrutiny, and most apps are living, breathing organisms that change frequently. What then? The best way to minimise any serious issues is to test the app extensively. If this isn't part of the project, try to persuade the client to include it. I'd recommend avoiding the 'play around with the app and see if it's all good' method, as it's easy to miss things. The best tests include either a full set of screenshots, which you go through, marking errors, or extensive testing scenarios. A scenario is a list of steps you need to take to move to a particular screen, prompt or action. It's usually quite a time-consuming process, but it is the most comprehensive way of testing an app. App and software localisation is a complex and varied field. If you're lucky, like I was on this assignment, you'll receive plenty of support, including context, a reasonable tool, access to the app and extensive responses to your queries. As with all translations, the key here is to take the end users' perspective. Only then can you provide translations that will not only sound natural but may even improve the original app. USER INTERFACE A preview is an invaluable tool for app localisers to solve any issues (right); but it's as important to keep in mind the end user (main image) IMAGES © SHUTTERSTOCK

• Cover