Your application is finished and uploaded to the App Store. You are happy and eager to see the reactions from customers. Then, a review like this lands in:

After a few dozens of such reviews, you may be tempted to translate the application into another language. In this article I will point out a few reasons why that might be a bad idea and give a few pointers for when you decide to pass the hurdle.

Translation may bring other people into the churn

Working alone on an app makes a things easy and agile—writing new features and fixing bugs takes little time and once they are written nothing stops you from releasing the new version.

If you translate the application into a language that you do not master yourself, you need to bring in translators and to depend on them. This ties to someone else’s schedule every time you modify a visible text in the application.

Someone else might be on vacation, they might be sick or have other stuff to do and will not scramble to translate things for you. You have to plan the releases around their availabilities.

Translation brings additional (boring) work

I assume that you have thought about internationalisation from the beginning and that your code uses localisable strings everywhere. If it does not, this should be done before any translating can start.

You will have to translate all of the strings in the application and the whole UI. Be aware than many terms that are common in English are do not always have counterparts in other languages. This concerns a lot of technical and computer related vocabulary. This means that you will need to do due diligence to find out what terms are colloquially used in the target language for what you wish to describe.

Some languages handle the context differently from others: A menu with a lot of switches may only require a short label in front of each switch in English, but demand longer descriptions when translated. This may require alterations to the UI because the labels might no longer fit in the original space.

Once your application has been translated, you are halfway done. You also have to think about screenshots, documentation, marketing material¹ and the website.

Translation is a commitment

Features which modify visible text will generate more work from now on. Screenshots, for example, are required for each supported language. Depending on your platform, their generation can be automated by tools such as fastlane².

Be prepared to find yourself in a situation when you have finished the features, fixed the bugs, and are ready to submit, only to realise that you have forgot to translate the one button which you have added. If you are using translators, pray that they are not on vacation.

Expect to receive support mail in foreign languages. If you have used an external translator, you may not be able to answer them.

A few hints for future polyglots

If you have considered the above and are ready to start translating I can give you a few hints:

Minimise text in your application

Put as few labels as possible into your applications. Consider them like you consider code, if it exists it must be maintained.

I have removed some settings from my app at the last minute, so I would not have to translate the associated controls. If a feature is hard to explain in a foreign language, it might be too complex to use as well.

If a label can be replaced by a pictogram do so. A good example would be to use a slider with small and large character at either side rather than listing text sizes.³

Use textual representation for your translated strings

In iOS, you can use full Storyboards or string lists for translating the UI. Stick with the plain text lists as they are easy to diff and mistakes in them are quick to spot.

Localisation will live next to the code in your SCM repository and it is important that its format be adapted.

Make the non-translated strings pop

Use a gibberish placeholder for untranslated strings and add them immediately after you create each new string. Most frameworks will use the default (usually English) label for non translated strings and this can lead to forgotten translations.

Closing words

Translating an application might seem to be a good way to increase the number of possible clients and profit. But consider what you are giving up: having an application developed by a single person in a single language gives you incredible flexibility. This agility might be worth more than a satisfying few angry customers.

Over at the DOS Games Club we have played six small games¹ during the cold month of December. I have suggested playing UGH! and joined Florian, Martijn, Mike, Philipp and Tim on the 25^th episode.

In February we will be operating on unfortunate patients in the Life & Death.

Today I have discovered the Dotsies font. Although I doubt I will use this, it made me wonder about using it in Eventail.

I’ll hammer something out to test this.

I have joined micro.blog, to which I will hopefully federate micro posts from this blog.

Let the writing commence.

Increasing amount of tools are written for web, many presenting themselves as replacement for standard desktop applications.

For simple stuff this is fine, few people would like to install an application for every shop or transport provider.

Complex programs running in tabs hit an insurmountable hurdle: “they cannot implement correct keyboard shortcuts”. And it is a problem that nobody has figured out yet, it is a fundamental issue that will never be fixed.

Some examples that come to mind:

• How would you open a tab in your web app? ⌘T opens a new browser tab. What about a new window⌘N?
• How do you undo? In Safari ⌘Z undoes closing of a tab.
• If your application provides a save option, what would you use? ⌘S will try to save a useless HTML document.

Another problem is selection. ⌘A selects everything, this is never what you want to do in an application, but it can be something you want to do on a webpage. This means you need to break one behavior or the other.

MKBHD’s video about blind camera comparison concluded with a baffling result. The most interesting thing is not the winner, but the phones that got to share the last place: iPhone XS, iPhone X and Pixel 3.

Although their cameras are superior on technical level¹, people prefer pictures from other cameras because of increased brightness and saturation.

Of course there is nothing that stops iPhone and Pixel to do the same thing at the cost of losing information rendering further post-processing inflexible. That being said, I can imagine that being beaten by a Blackberry in a photography test must hurt.

Solution

The solution is simple. I am sure that if pictures after auto-enhance have been thrown in the competition, the results would be different. The winner might stay the same, but I doubt that iPhones and Pixels would remain dead last.

What Apple and Google should do is to add an option to turn on auto-enhance by default. This way no information would be lost and people who prefer pictures without it could disable it. It would make the pictures coming straight off-camera punchier.

But first Apple would need to fix their auto-enhance algorithm which makes everything orange.

As a side project I am launching my YouTube channel Binary Campfire. I haven’t decided its ultimate purpose; but as others before me, I will start posting some videos about video games. Old ones, as that is what I play these days.

The first video will take us back to 1992, with a side scroller/shooter game Alcatraz.

The event held on the 30th of October solidified the idea roaming the Internet since a few years: ARM Macs are coming, and they are coming soon. A-series chips have caught up to all but the best Intel mobile chips¹, so why is there an Intel processor inside the new MacBook Air?

I have a theory: A-series chips are not powerful enough–but in an unapparent way.

In my previous article I have predicted that Apple would:

1. Rename the current MacBook to MacBook Air.
2. Discontinue the 13″ MacBook Pro without TouchBar.
3. Introduce a new, cheaper, 13″ computer called MacBook.

This did not happen as predicted. What was announced is a new MacBook Air, which is a 13” version of the current MacBook. Other laptops in the MacBook line were untouched.

What I think will happen next year is:

1. Apple will introduce a new 12” MacBook Air and “discontinue”² the MacBook line.
2. Apple will introduce a new 13” MacBook with Apple ARM chip³.

But herein lies the problem. Which chip would go in? If Apple took the A12X processor from the current iPad Pro and added a bit of RAM, this setup would breathe at the neck of the current 15” MacBook Pro with Touchbar⁴. This would have serious implications for the Pro line as the only differentiator would be the software they can use.

In order to offer compelling Pro hardware, Apple needs to make a beefier A-series chip. One that would give even the Intel desktop chips a run for their money.

A new episode of Dos Game Club podcast was released today. This 22^nd instalment is about a legendary game: The Secret of Monkey Island.

I have been fortunate to be able to join Martijn, Florian, Mike, Philipp and Esko to discuss this great game during an epic 3 hour session. If you enjoy retro gaming and especially DOS games, give this podcast a try!

Every month we select a different game to play and discuss on the forums and IRC. Martijn and Florian then invite a few guests do discuss the episode and record a podcast session.

As a fun exercise I would like to make some predictions for the 2018 September Apple keynote. There are two rumored machines that should come out.

The new Mac Mini

According to rumors, this machine will be geared towards pro users. As usual, the statement is vague. What pro users? Developers, animators, writers?

Current Mac Minis mainly serve three purposes:

• home media server
• “rich man’s raspberry pi”
• server in a colo

Professionals do not need home media servers, and since Apple does not make a standalone screen it means that the machine will have to be usable headless.

As such it will require Ethernet and power, which makes it possible to do away with all other ports. I expect Apple to offer a low-grade Xeon CPU option in order to allow for ECC ram and at least an option with 32G ram.

Why would Apple do this?

1. Nobody uses underpowered desktops today.
2. Apple needs and probably has a similar machine for internal usage.
3. The work on Xcode automation is useless if one cannot have an affordable Mac server.

The new MacBook Air

I expect Apple to sanitize their offering. Nobody except Apple pundits knows how are the machines named before they enter the Apple store.

I believe that Apple will:

1. Rename the current MacBook to MacBook Air.
2. Discontinue the 13″ MacBook Pro without TouchBar.
3. Introduce a new cheaper 13″ computer called MacBook.

This will make the lightest Mac have the Air moniker. The current MacBook is underpowered for the generic user and the current MacBook Pro without TouchBar is a compromised machine with no market.

CPU and Graphics

For CPU it will have the cheapest Intel 15W CPU Apple can get, with expensive upgrades to CPUs with the same TDP. It will not have a discrete GPU and no TouchBar.

Ports

People buying the Pro computer should be savvy enough to know which dongles to buy and people buying an ultra-light computer do not need peripherals.

However, Apple needs the Average Joe’s MacBook to work for most users today, not in an imaginary future. This means it needs at least one USB port. It does not need thunderbolt. It would be better with an HDMI port and an SD card slot but these are unlikely to be included.

I predict that it will have 2 USB-C ports for power and 1 or 2 USB-A ports (for symmetry).

Keyboard

If Apple wants to make this work they would need to backpedal to the old system. Even the new updated 2018 butterfly keyboard keeps failing. If they make a new body for this machine, it is possible that they would introduce a v4 of the butterfly switch mechanism.