> If devs follow certain simple rules while writing UI text, it would make a tremendous difference for translation quality

As a UI Developer that has accidentally focused my whole career in building (complex) forms, I can tell you there is a night and day difference from when I worked alongside User Assistance professionals vs when UX designers had to come up with the texts. These “User Assistance professionals” were usually English/Language-majored that would exclusively take care of how to properly write the texts on the screen for the users. From help texts to button labels, to release notes and RCA, and especially taking care of how to write texts in English so the app would be easily translatable, they would own all. The apps that had that sort of handholding with the devs were extremely easier to use and input data to, even when the UX itself was subpar.

I used to think it was standard to have English-focused professionals helping UI teams to deliver easy to understand products, only to find out that that company was kinda odd in that regard, and having UX or even product people coming up with labels is quite common. I do miss being able to fire an email when I need a quick text reviewed to be sure that a button is well labeled for the user and translation.

> I used to think it was standard to have English-focused professionals helping UI teams to deliver easy to understand products, only to find out that that company was kinda odd in that regard, [...]

Which is a bit of a shame, because English/Language-majored people's time is cheaper than techies' time.

Google is another outlier in a related way: they have dedicated tech writers to produce internal documentation.

> they have dedicated tech writers to produce internal documentation

The trick with tech writing is retention!

> English/Language-majored people's time is cheaper than techies' time.

Which is odd, because it's harder to communicate unambiguously in English than it is in code.

Compensation ain't about how hard something is in an absolute sense. At least that's only one part of it.

Playing an instrument is harder than being a code monkey. On the one hand, you can make good money being a top tier musician, there's almost no money in being a mediocre musician (or even an above average one). On the other hand, it's fairly easy to get by as a mediocre code monkey.

Even as a somewhat subpar software engineer, you can make enough money that you don't have to be waiting tables as your day job.

(Waiting tables itself is a good example at least to contrast with acting or making music or writing novels. None of these aspiring artists and poets is necessarily any good at waiting tables, but it still pays the bills compared to even pretty good acting skills.)

It would be nice if they employed some of those dedicated tech writers for external documentation (sorry for the snark, couldn’t help it)

The role you are describing is UX copywriting. In companies working on international markets it’s common to have it assigned to a dedicated team responsible for localization, but it’s also perfectly normal and common for UX designers to do it - it’s part of their job. Product managers can do it too, but ideally shouldn’t.

Edit: Also have to note that education in language or literature doesn’t make person a good UX copywriter automatically. It’s a cross-domain job with multiple career paths towards it. You were lucky to work with someone who really excelled in it.

I am a mere programmer, not any kind of UX writer.

A company I worked for some 20 years ago had writers who mostly thought about the "happy path". When things went wrong, the error messages were left up to the programmers.

I discovered this when I tried to install our product on an old Mac and got this message:

Your hard disk is too small

Wait? My what is too small?

Later, on Windows, I got this popup:

You are not here

WTF?

I searched for this message and found it came from a function called CantHappen(), which was kind of like an assert(false). Something you throw into a code path just to note a place that you really know the code can never reach. Until it inevitably does.

I went on a rampage through our code, finding all these crazy messages and updating them - and when possible, fixing the code so the error messages wouldn't be needed.

My manager and his manager, to their credit, knew how bad our messages were, and they helped me pull together a little team with a writer and translators to fix these up. And we did. Our messages got a lot better, easier to understand and more helpful.

All because our Mac installer told me my hard disk was too small.

Great story and exemplar attitude from you and your manager! Too often such issues are eternally deprioritized, but you have got it into the pipeline and the team committed resources for fix. Ideally this should not happen, but that would require end-to-end collaboration of the entire team where UX people are involved on later stages of development process, adapting design and copy based on feedback from engineers. Many modern product designers just work based on „shoot and forget“ principle.

What's wrong with "hard disk"? You do realize that is a valid name for an HDD (hard disk drive), even if it's not super common today?

Of course I'm aware of that. After all, I was born before IBM announced the RAMAC 350 Disk Storage Unit. [1] [2]

To understand the problem, consider two things.

First, imagine another word that rhymes with "disk". I will just call it "di*k" here.

Second, the problem wasn't that my hard di*k was too small. I could have the biggest hard di*k in the world, but if it didn't have enough free space, there wouldn't be room to install Acrobat.

So the message had an admittedly slim chance of being misconstrued, but more importantly it was just plain incorrect.

[1] https://www.tomshardware.com/pc-components/hdds/ibm-announce...

[2] https://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_d...

Translation is always a pain in the ass if developers are monolingual in English.

On every project I ever worked on somebody had thingCount == 1 ? 'thing' : 'things' somewhere and it drives me up the wall having to explain that and pgettext thingy

At the risk of driving you up the wall, but please explain

One simple example is slavic languages where you have different forms of plural depending on the number.

pluralization is much MUCH more complex in many languages than in English: https://www.unicode.org/cldr/charts/47/supplemental/language...

it can largely be turned into six categories of behavior, with tons of languages choosing different boundaries for those categories. ios/osx and android have tools for this, and probably others (I'm just personally familiar with these).

and even English isn't even that simple in the way many treat it - you don't pluralize sentences, parts of sentences change in contrast to each other (a car drives vs cars drive). so e.g. widely used APIs like https://apidock.com/rails/v7.1.3.4/String/pluralize are blatantly misleading merely by existing, and it leads to mistakes in many (most?) languages, and also English, even though the authors of the API speak English.

That has to be one of the most cursed functions that I've heard of in my life. Anything less than a call to ChatGPT is doomed to fail.

It is a solved problem with tools that help to do it right, but nobody does it right. People wrote that cursed function for every language long time ago, but you as a developer need to know it exists and use it

yeah, I mean `toUpper(string)` exists in basically every language and it's equally cursed. it's nothing even slightly new, just another sigh-inducer when you see people using it.

Making it plural doesn't always mean "replace one word by another".

The right thing to do it:

add_one = "Add one thing" add_multiple = "Add {n} things"

Then you'll provide the full sentence for each language. Of course some languages will need more cases, like slavic language where it's 1, 2-4, 5+, so depending on the languages you need to support you need to put more than 2 strings.

Not the parent, but you use a translation format like `translations("INVITE_USER", {gender_of_host, num_guests})`

Then you will have an algorithm that knows to translate based on some rules - like the ICU messages format - https://unicode-org.github.io/icu/userguide/format_parse/mes...

In the link there's an example of how such rules look like (they'll be different for each language)

For example, in Arabic, nouns have three forms: singular, dual, and plural. Dual and plural are not interchangeable.

Polish has different plurals for [2:4],[5:21], then [2n+2 : 2n+4], [2n+5 : 2n+11], restarting at 2n = 100

1 osoba

2, 3, 4 osoby

5, 6, 15, 21 osób

22 osoby

25 osób

101, 112 osób

It's impossible to provide enough context for translation strings. You need links to mockups, designs, or any other visual aid so that translators don't make huge mistakes. Even then, they'll eventually find that the programmatic parameters are insufficient for returning the correct translation, and they'll have to duplicate strings because the same sentence has different translations in different contexts. It's a never-ending job.

Turkish is especially funny here, but not even close to how creative you might need to get for some other Asian as well as Slavic languages.

Lucky that you never had to translate Ekşi Sözlük, how do you even translate "şükela" :)

Would you have an example for Slavic languages? (ideally non-Cyrillic ones)

Russian having singular, few (2-4), and plural (5+) forms is one from the top of my head. I can't remember any specific examples from non-cryllic ones but remember we having to duplicate a lot of translation keys to make them more context specific.

Also things like:

    _('There are:') _('%d items', count=len(items))

—-which look correct until you want to translate them into a language with a different order of words in a sentence.

Not the parent commenter, but -- days of week in Polish are a nice example, IMO.

`Środa` means `Wednesday`, but depending on the grammatical case it's going to be translated either to `środa` or `środę` (or five more, but somewhat less likely to appear in UI [1]).

- Next <Wednesday> is 2018-01-03. = Najbliższa <środa> przypada na 2018-01-03.

- This event happens on <Wednesday>. = To zdarzenie ma miejsce w <środę>.

If you mix the variants, it's going to sound very off (but it will be understandable, so there's that).

What's more, days of week have different genders, which affects qualifiers:

- <this> Wednesday = <ta> środa (Wednesday is a "she")

- <this> Monday = <ten> poniedziałek (Monday is a "he")

... together with the grammatical cases affecting the qualifiers:

- <This> Wednesday is crazy. = <Ta> środa jest szalona.

- <This> Thursday is crazy. = <Ten> czwartek jest szalony.

- I'm busy <this> Wednesday. = Jestem zajęty w <tę> środę.

- I'm busy <this> Thursday. = Jestem zajęty w <ten> czwartek.

[1] https://en.wiktionary.org/wiki/%C5%9Broda

This is fascinating, thank you. The intricacies of languages is so interesting. I especially love the insane way we danes spell out numbers.

59 == nioghalvtredssindstyve

59 == 9 [ni] + [og] ((3 [treds] - 0,5 [halv]) * [sinds] 20 [tyve])

So 9+2,5*20 == 59

Halvtreds means half third, or halfway to three. There's also halvfjerds and halvfems for 3,5 and 4,5. Exercise: spell out 79.

I once worked with translating an application to polish, and found out we had to have separate placeholders for "name" for persons (nazwisko) and for things (nazwa).

Which is a simple example why you need context.

All UI frameworks should have a "translate" mode, where all labels and static text can be right-clicked and modified...

Do you think any i8n library (in any language) gets it right?

https://projectfluent.org/ comes close. The syntax is hard to read though. I guess you can't have the cake and eat it too.

> If devs follow certain simple rules while writing UI text, it would make a tremendous difference for translation quality.

As a dev that often writes UI text, which simple rules do you recommend that I should follow?

Not OP but I’ll suggest one that is very dear to me: make sure you use the same verbs for the same actions, the same nouns for the same things, the same proper nouns for the same important concepts. This alone removes a huge mental burden from users: it’s always “delete”, not sometimes “remove”, “cancel”, etc

I'm actually compiling a list of UI text mishaps, and I plan to publish it as a blog post at one point. A simple one would be to avoid using "your" in a "user -> UI" context (command), and "my" in a "UI -> user" context (message). For example, "Delete My Files" is okay on a button, but, in a message it must be "Are you sure you want to delete your files?". But, the better is to avoid generous use of "your" and "my" unless necessary to disambiguate.

For example, don't have a button that reads "Go to your profile", that screws up translations in languages like Turkish.