Working with agile principles within a distributed team and separate code branches is complex on its own. Adding interface localization into the iteration cycles adds another layer of linguistic complexity – unless Text United is used and especially until you find out about the benefits of continuous translation.
Building international software that’s translation-ready
If you’re in the early stages of building your groundbreaking system bear in mind that at some point you’ll have to translate it. Ideally, that would happen without refactoring your entire code – especially if you’d want to test your international markets first. Here, continuous translation steps in.
For the sake of simplification, I’ll talk about web apps mostly.
With frameworks and methodologies for building software available at hand you needn’t worry about complying with localization software – in the end, interface content comes in arrays and strings – or does it?
Let’s divide the content up into two categories: front-end and back-end.
The back-end is so wide that I’ll just paint it in broad strokes (I know nothing, I know)
Text United can filter out most of the content automatically and keep you from refactoring for some time but think of clean code maintenance as if you would of avoiding the dentist. It’s worth the effort.
Don’t write any front-end content into the layout!
However you call content within HTML, you should avoid writing it into the markup. By doing so you’ll force yourself to create as many HTML duplicates as languages you intend to use. Monitoring that for consistency may eventually become a huge burden. Text United can handle that too but it isn’t as efficient as it could be.
Call back-end content from resource files or your database
A well-planned database schema will allow for efficient, non-resource consuming, and dynamic interface creation.
Example? Think of your app’s navigation. Label each item and call its name for the currently selected language – even if you’re only working with English – you’ll thank me later.
Work with resource files. This may be the simplest, most effective way to build translated software. Instead of stuffing your DBs with content, load an entire, localized content file each time your user switches the language.
There is something you don’t know about translation technology, and as you learn it you’ll build international software using the principles mentioned above.
Time and time again developers keep asking how in the world are we able to keep up with matching strings with keys in a continuous integration environment without having an army of elves patrolling the vicinity. The real secret of continuous translation?
We have proprietary Translation Memory.
It resides on our servers, remains unique to your instance of Text United, and initially, it’s a mirror image of your content’s structure. As translations are delivered, the Translation Memory database gets filled up. From that point on it can match words and sentence repetitions, suggest similarities in previous translations, and automatically propagate simpler sentences or interface elements.
Turn on abstract thinking now and get ready to have your mind blown.
Each language version you order maintains its own Translation Memory that’s derived from the source language you use to write your interface with. This means that if you change a button in your base version it will affect all other translations.
Example: If you change “Log In” to “Sign In” in your original, source content file, the change will apply to every language you are maintaining via Text United.
Continuous Translation will automate identifying content differences
Sure, you may want to periodically drop in the source YAML or RESX file with your interface’s content and scan it for Translation Memory differences against all other languages (is your sanity still with us?), or you can hook up your repository through one of our integrations: GitHub or BitBucket.
What that will do is essentially take a look at your source files in a custom-set interval and submit changes for translation so all of your production-server content stays relevant ALL THE TIME.
No more ridiculous language mix-ups that your clients complain about to Dave from Customer Service. How’s that for flashy modern tech?
Search for libraries that improve your framework of choice.
Free GitHub libs can be a mess, but sometimes you find a user-maintained gem that greatly enhances i10n (you should know this term by now) possibilities. Have a look at this localization library that follows i10n rules for ASP.NET.
10 tips to get your Interface Localization up a notch! (Front-end)
Your back-end developer is probably serving everything the way it’s supposed to be served. Those guys are just like that. But you’re the front-end virtuoso who needs to comply with the UI design people who don’t have the slightest idea how interface coding works. Luckily there are a few tricks you can use to stay consistent with the designs and still keep the app translation-proof.
1. Expand and contract text by about 30%
Leave about 1/3 of the wiggle room each time you put text on a button. Translations are unlikely to be of the exact length as your original text. Sure, you can fix line breaks in proofreading but why risk it in the first place?
2. Relative objects, wrappers, and containers instead of fixed values
I know this is web-dev 101 but in fast-paced startups, it’s sometimes easier to just fix a positioning problem with height or width parameters instead of having to relate everything to each other. Go as far as to menu items with this – not only will it comply with your RWD ideas but it’ll save you from having cropped/cut/line-broken words in the translated interface.
3. Research your fonts and prepare to optimize per language
Before selecting a fancy and fashionable font like Roboto be sure you are actually aware what UTF-8 and UTF-16 stand for. After you’re good to go with your encoding knowledge think of which languages will be used. A decent font will last you a lifetime. Pick and choose from Google’s free NOTO or its counterparts. Don’t skip testing this via in-country reviews though – the font is a powerful medium that can make or break your whole interface!
4. Ditch UI elements with embedded text. You can’t translate them!
Well, you can but it’s just not worth it, especially since you can build virtually anything usable with CSS. If you have embedded text on graphics and use it as buttons – swap that and your localization efforts will be WAY faster.
5. Get detailed with foreign metric systems, currencies and alphabetical sorting
You will have this covered in your development framework…Most of the time at least. What’s the issue here? If you run an eCommerce store and your payment gateway accepts foreign currency, allow it to display it. If you sell products in Europe, allow it to display KG instead of LBS. Building a weather app for Germany? Degrees Celsius, please! And don’t forget sorting – you don’t want the über-rific t-shirt to be skipped simply because you don’t know if the ü goes before or after u. We can help you figure this out for Japanese or Arabic, too.
6. When in doubt refer to ISO symbols encoded in UTF-16 standards
Did you know that a thumbs up in Greece is regarded as offensive? And sure, the Facebook like button is something we’ve all grown accustomed to by now. Still, there may be a whole lot of local idiosyncrasies that are not widely known. Use symbols that are universally acceptable and well understood. A bonus tip would be to use them as font characters (if available) and not images. That way you’ll save up a bit on page load time and won’t have to translate those few alt=”” parameter words. You use alt=”” right?
7. Mobile first!
Everything in this matter has already been covered virtually everywhere so I’ll simply take the opportunity and ask you this: does your refrigerator need an LCD display on its door to tell you how cold is it inside? Don’t add things your interface doesn’t really need and you’ll immediately become a responsive web design champion.
8. Account for line breaks when translating
Normally when you use relative dimensions you can easily position text against an image in a single row. If you, however, translate “translation platform” into “übersetzungplatform” you will not be able to automatically line-break. There will be a lot of white space left, but this is still better than having elements overlap. Now think of Chinese that rarely uses spaces – you truly need a professional language service provider to handle that.
9. All your screenshots require an update since yesterday!
This may very well be the most dreaded problem of all web developers. And screenshots often ARE used in web apps – especially in tutorials or embedded support content. You can make a new series of screenshots, but you also can ask Text United to translate them through photo-editing. An option good to have if some of your screenshots are fakes. 😉
10. 3rd party software that’s available in your interface
There is absolutely no easy way to say this. If your support software, helpdesk, tutorial, chat, or other vendor does not provide a localized UI, you will have a difficult time providing a unified and concise experience to your international users. You could pitch them Text United of course – if they bite we’ll share 20% of the wealth with you and throw in a discount to your subscription!
Need more knowledge?
We’re preparing an eBook for developers to better explain the mechanics of building internationalized software – let us know what you’d like to learn and I’ll ask some experienced engineers to join forces with me in guiding you through the topic!