[lou1306]

> People may prefer the English experience because they expect the translated version to be inferior

As an Italian, I can relate so much to this, because translated apps will happily treat verbs as adjectives and vice versa. A couple example:

* Flixbus' app translates "Open ticket" to "Biglietto aperto" (treating "open" as an adjective, not as an imperative verb). Correct translation should be "Apri biglietto". Nothing bad, just unnecessarily confusing (what is an "open ticket"? As opposed to a "closed" one?)

* EasyJet's app does the reverse and makes it much worse. The English version likely says something like "Gate close: xx:xx (am|pm)". They mis-translated this as "Gate chiuso: xx:xx", which actually means "Gate has closed", even though the gate is still open. So you get a small heart attack, notice the actual closing time, curse the translators, and go on with your life.

[travisjungroth]

I think the issue is many translation databases just hold the English text and then all the translations. So the entry is “Open ticket” and then you just drop in the translation anywhere that phrase shows up. But sometimes “open” is a verb, sometimes a noun.

The actual identifier should be something like “Open a ticket (imperative, button)” and then that phrase has translations, including the English “Open ticket”.

[ygra]

That's actually a nice idea in forcing even the default language to be handled by the same workflows, processes, and tools as the other languages. I've found that in a lot of those cases there simply is lots of context missing from the strings that should be translated. If all you get is the English text without any indication of how and where it's used in the UI, you're bound to make such mistakes in the translation.

For example, it took me a while to figure out why Word 2007 in its German version used the word »Gliederung« for the stroke of a shape. But translating »outline« in a word processor to mean »document outline« instead of »shape outline« is actually quite understandable.

Back then I tried thinking about automatic or semi-automatic solutions to get a bit more context for the translator. The trouble is that most UI toolkits make it very hard to impossible to solve this, unless the developer actually knows enough about the problem to always include context and a description. Qt has (had? That was pre-QML, I think) a nice mode in its translator UI where the XML UI description could be used to show the string in its UI context. Windows Forms had a way of changing the form's language and simply replacing all strings directly in the designer (which has the problem that the translator might accidentally destroy all layout). Most things that are used just from source code have no visual way of relating strings to UI at all.

[smoe]

In most places I worked that used translation systems, all languages where translations including the default one. Within code using message keys like "thing.title", "thing.add_action", "thing.on_save_error", etc or something like that.

I really like this approach because it makes the code and especially templates much more readable. You usually don't care about the verbose form of the text that should be displayed and those type of keys give you just enough information to understand what it is.

Problem is, it makes it harder to outsource the translations, and well, as it is known, naming things is hard.

[DougWebb]

Oh, cool. You just reminded me of a feature I had built into my web app many years ago when we implemented translations. We accepted internal commands in our search box, and one of the commands told the app to display the language text identifiers alongside the language text. It was a great mode for developers, QA, and translators. Developers and QA could easily locate text that needed to be put into the language system, and translators could work page by page to find the identifiers they needed to translate.

[toast0]

Yep, there's a ton of software that wants to use the english text as the translation key, which leads to all sorts of bad results.

Things like Open Ticket used as a verb to create a bug report, or open a bug report, or as an adjective to indicate a bug report is still active. Or similar when ticket means a transportation or entertainment event. If your key is the English text, you can't translate those three usages differently which is not good.

But also, minor edits to the English text are hard to manage for the translations, some systems have a way to suggest an existing translation, but it requires a translator to affirmatively select it. If the key doesn't change, you can still use the existing translations until the translators review the English change and decide if they want to also make a similar change or not.

Of course, the worst thing that people try to do is numbers; there are tools for that, but trying to do Open Ticket vs Open Tickets as singular vs plural falls over with languages that have a form for one, two, three, or more, or even more forms.

And then you get people trying to do string math. Delete this ticket vs Delete this image need to be translated as whole units, you can't add 'delete this' to the type name, gendered verbs and objects and sometimes even more complex stuff makes it not work.

[ziml77]

I was using Qt recently and saw that example code did that English keying. It's good that they're promoting creating translatable UIs, but I don't know if it's the right thing to do if they're encouraging people to do it by using English text as the key.

[toast0]

I think that approach is quick and easy for an English only developer to understand and do, but it's hard to get quality results. A synthetic key tied to the context so the same English text can be translated differently as appropriate.

Tools that show translators the application context are really helpful, too. Bulk translation in a spreadsheet is an OK place to start when there are a lot of new translations to do, but everything needs to be checked where it's used as well. Especially for languages that tend to result in layout issues when added to formerly English only apps, like German (lots of very long compound words) and LTR languages like Arabic.

[shoulderchipper]

>The actual identifier should be something like “Open a ticket (imperative, button)”

Or even better: "ui.ticket.actions.open" — trying to shoehorn linguistic categories into translation files is a painful experience, but dumb specific IDs work great and make untranslated captions apparent.

[IncRnd]

Or even Create Ticket. From the description, it seems a ticket is being created not opened, despite the slang that people incorrectly use for buttons.

[kemitche]

If a ticket is closed upon completion, it stands to reason that creating a ticket is "opening" it.

[IncRnd]

> If a ticket is closed upon completion, it stands to reason that creating a ticket is "opening" it.

That's faulty reasoning.

At the inception of a ticket, it is first created and then opened. It is common to have these programmed to work as a single button push, but they are two actions, and creation always happens first, even when the ticket is not opened. Later, when the ticket is completed, it gets closed.

When you go into your house, an opening must first be created, either a doorway or some other hole in the wall like a window. Then, after the hole is created, you can enter the house.

[james_marks]

Not faulty reasoning, good UX.

What you’re describing is putting a priority on technical correctness instead of how the user will experience it.

Open and Close are natural opposites, and intuitive UX. Does the user care that technically the ticket needed to be created before it could be opened?

[d1sxeyes]

Or you have a list of tickets that you have purchased in the app, and may need to select one from the list to show to the controller.

[yarcob]

Or maybe the translator should get annotated screenshots of the app. Laid out in a story board.

If you just hand someone a list of strings to translate, there's no way you'll get sensible results.

Also, you should test you translations. Some of the translations that I've seen (even from reputable companies) are so bad that it's pretty obvious no native speaker has ever looked them over.

[travisjungroth]

The tension is that people want to reuse translations. So maybe you have the story board for the first version. Then, someone makes a new button. In Django, they'd put _("Open ticket") as the text, see there's already a translation, and think they're good to go. Sure, having every page looked at by a translator for every language every time you make a change would be ideal, but also a bit costly and slow. I think there are better options in the middle.

[yarcob]

I don't think there are any "middle options" that result in a good product. You want a localized app, but you don't want to put the work in.

If you add some new text somewhere in the UI, you need to start the app and make sure it looks right. If you only do that for one language, and don't check other languages, then there's going to be one language that's broken.

So your app is going to look broken in one language. And you probably will never find out, because the people who run into the bug don't speak your language.

[travisjungroth]

> You want X, but you don't want to put the work in.

Yes! That is exactly what people want.

[david_allison]

> Also, you should test you translations. Some of the translations that I've seen (even from reputable companies) are so bad that it's pretty obvious no native speaker has ever looked them over.

Testing is a must. Before I fixed + linted it, we often had community-provided translations which would cause the app to crash due to missing/additional format strings.

[spookthesunset]

Yup. The “key” for the translation is the English phrase itself. It also makes English text changes weird because you either have to change the key across all languages to match the new English or you leave the key alone and change/add an English “translation” that is the new text.

Personally I think it is better to use a “surrogate key” that isn’t the English text itself.

[spinny]

I think a bit more of context would even be better.

The usage of "discover" and "find out" in english and portuguese comes to mind.

words from the "discover" family, in the english language are generally used when talking about discovering something that nobody or few people knew (somebody discovers a cure for some disease), while "find out" is generally used at a more personal level (somebody finds out that someone else bumped his car)

in portuguese you can only "find" (encontrar) physical things. you can't "find out" information

This makes me thing that in some instances it might be necessary some sort of descriptive context on the meaning

[seanalltogether]

Obj-C and Swift allow comments to go along with translation strings, so you would add

    let buttonStr = NSLocalizedString("Open ticket", comment: "For user to open a ticket")

And the comment would make its way into the eventual xliff file sent to translators

[jraph]

This looks like the right approach: giving context to the translation strings.

Many translation tools give the locations in the code where a string is used. It's a first step, though translators are not always able to read code.

[cyxxon]

In my job I sometimes have to do with rollouts of a centrally maintained software to subsidiaries in other countries. Translation is often done by simply sending a Excel file with all string identifiers and their English value to a key user in that country, and maybe they translate it themselves, maybe they give it to some agency. So we can be 100% sure that now, there will be several additional rounds for them to figure out what the string is really supposed to mean versus what they initially thought it would mean.

Yes, we improved on this somewhat. In the last rounds they got access to the software in English beforehand, and there are now also access keys to press to see the string id for any label in the app. It is still a very time consuming process, and I love it when a rollout is done to a country where we can just say, consumer facing texts get translated, our employees all speak English well enough to use this as is.

[sangnoir]

> The actual identifier should be something like “Open a ticket (imperative, button)”

The identifier should be a GUID with an option for tagging and comments for developers and translators. Other languages depend on other contexts which are not represented here, like multiple forms of "present" tense, or the current time of day. Keying translations on English-language concepts is a bad idea, as a lot of languages are unlike English. Treating English as one of the translations (and not the reference) is a good idea that will prevent problems with future translations and avoid re-architecting your whole localization pipeline (and code base).

[travisjungroth]

That sounds like a nice setup.

[lavabiopsy]

This is what the gettext contexts and the pgettext macros are for: https://www.gnu.org/software/gettext/manual/html_node/Contex...

[yongjik]

Another example I saw was "(N) seconds ago" (e.g., "30 seconds ago") vs. just "seconds ago" (i.e., someone just posted this). They were translated into a single phrase. Hilarity ensued.

[pabs3]

I think Mozilla's translation system called Fluent can handle that.

https://projectfluent.org/

[jakub_g]

> So you get a small heart attack

This is something overlooked by devs and PMs sitting comfortably in their chairs.

People using apps in the modern world, especially mobile apps, are tired, stressed, busy, unfocused, and on the move. Small things like that added to the mix can induce a lot of stress.

For many devs/PMs it's just a piece of text. For the user it's much more.

The translations are somehow unappreciated part of the app dev by many people. I know several languages and I checked all new translations in our app each time but few people cared as much.

[dharmab]

Tom Scott used an example of a phone system for results of an STI test to demonstrate this: https://www.youtube.com/watch?v=LZM9YdO_QKk

[lksaar]

I have a similar experience as a german on the internet.

Aliexpress (straight up wrong translations), Discord (anglicism, adjective ordering and weird sentence/tone structures) and plenty of others I don't remember, the list is pretty long. Size doesn't really seem play an effect aswell.

Another big issue are potential bugs you encounter. If you just get a translated error message without any error number or something similar it's a very frustrating experience to troubleshoot it. I've spend quite some time retranslating error messages to solve issues. Add to it that often knowledge bases are outdated in the translated languages.

[andruby]

Aliexpress in Dutch is lovely!

Plenty of items on Aliexpress can be shipped from multiple locations. "China" is almost always one of the options. Well, in Dutch they've translated that to "Porselein". That is a valid translation, if you are talking about plates and dishes made from porcelain)

I wonder how actively harmful this bad translation is to their business.

https://en.wikipedia.org/wiki/China_(material)

screenshot: https://fransdejonge.com/wp-content/uploads/2019/11/Screensh...

[seszett]

Weird, I sometimes get the French translation of AliExpress (when my cookie expires I suppose) and I haven't noticed "China" being translated as Porcelaine in French. I wonder why it's different. Also now I wonder why I get the French version, since I live in Flanders (although I'm a French speaker).

AliExpress translations are totally incomprehensible though anyway. I really don't think they should show the translated versions by default.

(By the way, your second link doesn't respond for me)

[d1sxeyes]

"Ships from" though is perfect Dutch.

[chrismorgan]

> Size doesn't really seem play an effect aswell.

This holds true in all areas of software development—nay, in business in general. To the point where I’m not really sure why people do expect large players to do a good job, because they just about never do.

Large organisations are very close to incapable of producing good results—their software will be clunky and slow, their translations present but bad, their customer support painful. Small organisations are more likely to be able to produce good results. Notwithstanding this, small enterprises are often unable to match large for certain resource availability (including time!), which acts as a balancing factor so that small is not often uniformly superior to large, though it’s much more likely to be superior in a certain subset of fields; and this is the case with i18n/l10n.

I think this actually stands to very simple reason when examined numerically: have enough mass and you’ll produce average results (regression to the mean); be small and you’re more likely to deviate from the mean, whether for good or for bad, and if for bad you’re more likely to fail, so you’ll tend to end up with more above-average small players.

[fabian2k]

I set my Android phone to English mostly to avoid badly translated apps. Not so much for the major ones, but you never know if you might get some really bad machine-translated stuff in some apps.

As there isn't an easy way to set this per app, it makes more sense to me to just switch the phone entirely to English.

[Delk]

That's also one of the reasons why I don't use a localised version of a desktop OS. Especially on Linux, where everything follows the OS locale and the translations of many open source applications are either only half-done or leave a bit to be desired in terms of quality, the original English strings are just a better experience if you're proficient enough.

I'm not saying this to bash open source translations (let alone translators) or anything. A good translation takes a lot of work. That's just how things seemed to be last time I tried, and I don't really have the energy to contribute myself nowadays.

Of course there are other reasons for not using a localised desktop especially if you're a technical person, such as better web searchability in case of problems. But the inconsistent quality of translations is probably one of the top reasons for me.

[SilverRed]

I wonder if there is just any point in doing translations for software unless you are fully committed to having full time I18n people testing the actual app in the language. At my past job it was basically a throw over the wall thing where we send them yml files and they send us back yml files without the translators ever touching the app.

The translators also likely did not understand which words were key app terms which should stay constant. For example "benefit" is a key term which can not ever be substituted out with something like "improvement" even if it seems like it makes more sense in the particular string. But without knowing the app well, you wouldn't know this.

Seems like it would be better just convincing everyone to use the English versions of everything since those are perfect and the majority of the world knows it now.

[Delk]

> Seems like it would be better just convincing everyone to use the English versions of everything since those are perfect and the majority of the world knows it now.

There are lots of e.g. elderly and less educated people in non-English speaking countries who don't speak or understand much English, at least not enough to be comfortable. You don't even have to go further than Europe for that. The aging might not be a key target audience for many apps and it might make business sense to not bother with translation, but there's a significant number of people who might be excluded by that, and it would be difficult to accept that as a solution at least for the most commonly needed apps.

It also seems a little presumptuous that English should be pushed as a general solution to everyone in the first place, but you don't even have to go there before you get into practical problems.

[sdiq]

Sometimes this doesn't work like what happens on the desktop with Google, for example. English is my default language, and in country where English is also the official language but Google in its wisdom, decided that the default for google.com is Swahili. Yet, I don't know of anyone that uses Swahili as his default langauge on digital devices. Microsoft too. Every once in a while they would send me text messages in cryptic Swahili that I have never bothered to find out what it means.

[Blikkentrekker]

I always use the English version of everything simply because error messages in Dutch or any amount of troubleshooting isn't going to helpful at all.

In the Netherlands, almost anyone who has about any device he owns configured in Dutch is almost certainly technically illiterate. People keep everything English not even because the Dutch translation is inferior but because any online documentation one will find is based on the English version. This is so entrenched that any notes I even keep to myself on my computer are in English rather than my native language without even giving it any second thought.

It is honestly somewhat strange and awkward to read technical documentation in Dutch. Many of the translated words they use take a moment for me to figure out since I never heard them in Dutch.

[el-salvador]

Same here. Some IT departments even have a policy of setting up every server in English to make troubleshooting easier.

[asveikau]

> translates "Open ticket" to "Biglietto aperto"

I have a good example. I won't name names. I saw an Italian localization on a "like" count in social posts that localized "N people like this" as "N persone come questa" [N people like this one]

[TrueGeek]

This is surprising. You really think someone as big as EasyJet would get that right.

We're doing a translation now into Japanese and the translator is actually taking the time to look at screenshots and use the app to see the text in context. It makes a huge difference.

As you've pointed out, it's one thing to see the string "open" in a XLF file, it's quite another to realize it's intent. This requires setting up demo environments for each translator though.

[Pinus]

Heck, Microsoft got it wrong — Swedish versions of Windows used to have a folder called "Vanliga filer" (Ordinary files). This was, of course, the "Common files" folder, but the translator, probably having no context, picked the wrong meaning of "common", and chose a Swedish word which does not have the "shared" meaning.

[el-salvador]

In El Salvador (our TLD is "sv") we sometimes get apps or websites in Swedish because "sv" is used as a language abbreviation for Svenska/Swedish. Spotify was like that for months when it launched here.

[Lex-2008]

Another data point:

When Windows 10 just came out, many of apps in start menu had a label next to them, which in Russian version said "Создать" (~Create). It took me some time to figure out that it's a poor translation of "New" (~Recently added). Proper Russian translation would be "Новое".

[r00fus]

The problem isn't the translation, per-se, it's that translation isn't tested (or tested thoroughly enough).

Amazing Microsoft can sell a whole other version of Windows and mess something like that up.

Everything that impacts the user experience needs to be tested.

[seszett]

> You really think someone as big as EasyJet would get that right.

Well even Apple has a wrong translation on the iOS keyboard in French. The "Return" key is translated as "Retour" (generally meaning "Back" rather than "Carriage return") instead of "Entrée".

It might have changed in the last years though, I don't know.

[zapzupnz]

That’s not a mistake.

The English term ‘Return’ refers to a carriage return (on a typewriter, it means to move the carriage back when you’ve reached the edge of the paper).

The French translation of “carriage return” is “retour chariot”, hence the ‘Retour’ key on French keyboards.

In Apple terminology, the Enter key is a completely separate key on the number pad with a different function and has no equivalent on iOS’ on-screen keyboard.

Therefore, the ‘Retour’ translation is appropriate for Apple’s software ecosystem.

[seszett]

> hence the ‘Retour’ key on French keyboards.

But as far as I know there has never been a key called "Retour" on French keyboards. Both Return and Enter are called "Entrée" in French by everyone I know, maybe because Apple's keyboards don't have any text on them, while PC keyboards do have "Entrée" written at this location[0].

Retour is only ever used to mean "Back", and Back is also translated as "Retour" on iOS. Which means in some cases (like in the Mail app) you have two different "Retour" buttons, one that inserts a newline while the other one cancels what you're doing.

I'm certainly not the only person to have a problem with it because I'm the one having to explain why the keyboard says "retour" to iPhone users, even though I mostly use Android phones.

[0]https://upload.wikimedia.org/wikipedia/commons/b/b9/KB_Franc...

[zapzupnz]

> Both Return and Enter are called "Entrée" in French by everyone I know

Most likely because everyone you know has learnt learnt that PCs. On PCs, they're the same button. In Apple's ecosystem, they're completely different buttons that do entirely different things.

> But as far as I know there has never been a key called "Retour" on French keyboards

On Apple keyboards, it has always been referred to in the operating system and documentation as the "touche Retour". Though you're right, there isn't a symbol on the keyboard in Europe in order to sell the same model for the whole region.

> Back is also translated as "Retour" on iOS. Which means in some cases (like in the Mail app) you have two different "Retour" buttons, one that inserts a newline while the other one cancels what you're doing.

The latter is actually a UI error in most cases. Apple's HIG demands that "< Back" buttons actually have a label to say what you're going back to.

But yeah, they have a hard time following their own advice.

> I'm the one having to explain why the keyboard says "retour" to iPhone users

Now you can explain: it's just Apple terminology dating back to the 1980s. :-)

[kalium-xyz]

The secret is that you cant verbatim translate into Japanese as well, which forces more attention (also its a bigger economy)

[franky47]

My Italian teacher in college had the following saying: "Traduttore, traditore": the translator is a traitor.

[addaon]

Thank you for providing a translation of that. Traitor.

[Galanwe]

French here, I do the same, French translation are unbearable.

Not only will there be tons of small mistakes with nouns/verbs as you mentioned, but maybe worst, there is often "overtranslation".

Some words are well established as technical jargon in English, and should _not_ be translated.

- "cloud" -> "infonuagique"

- "email" -> "courriel"

- "freeware" -> "gatuiciel"

...

[franky47]

While I agree that we (fellow Frenchman here) tend to overtranslate, some of our portmanteaus are kind of clever.

My personal favourite is illectronisme, a combination of illettrisme (illiteracy) and électronique (electronic), to refer to people who are not good with computers.

[zapzupnz]

My favourite is autof = selfie. It’s auto-photo, but if you pronounce it, it’s photo said backwards — because you use the hold the camera backwards or use the front-facing camera.

[alex_young]

“Open ticket” doesn’t even really make sense in English. Maybe “Buy ticket” or “View ticket” or similar would make sense there.

Flux bus is German, I suspect the translation was from German and not English in this case?

[yarcob]

In German adjectives and verbs are easily distinguishable without context. The verb "open" would be "öffne" and the adjective "open" would be "geöffnet". So it's unlikely this mistake would happen if you translate from German to Italian.

It's common to talk about "opening" files to view them, so I assume that's why the developer chose that term, even tough "view" would have been better.

[jan_Inkepa]

Don't German UI conventions follow the convention of using infinitive verbs for commands normally? ('öffnen' instead of 'öffne'?) [the only exception I know is the adjective "rückgängig" for "undo" ]

Though even there your point still stands - they can be easily distinguished from the perfect form ('opened' (geöffnet) vs 'to open' (öffnen) ). So I guess I'm nit-picking a bit.

[manuel_w]

Native german speaker here.

Have no clue about UI conventions nor grammar, but I'd expect either "Öffne Ticket" or "Ticket öffnen". "Öffnen Ticket" is wrong, just as "Ticket öffne".

I suppose the Flixbus app was made by native German speakers coding in English language. That would explain why they chose "open ticket" rather than "view ticket" or similar. As some of the parent posts said, you also "open files" here, so they probably just did what they assumed is right.

Denglish (Deutsch-Englisch) is full of this.

Happened to me as well; for most of my life I used "eventually" incorrect, thinking it means "maybe".

  * German "eventuell" = English "maybe"
  * German "schlussendlich" = Englisch "eventually", "at last"

[yarcob]

Oh yes, word order is also a major problem in software translated to German. You can tell when an English speaker programmed something...

It annoyed me more than it should that Word for Mac for years had a menu command "Beenden Word" (Quit Word) where the order of the words was obviously hard coded...

Or how Siri says "In 50 Meter Sie haben Ihr Ziel erreicht." (it should be "In 50 Meter haben Sie Ihr Ziel erreicht")

In English you can just take the sentence "You have arrived at your destination" and prefix it with something like "In 50 yards", and it's a perfectly valid sentence: "In 50 yards you have arrived at our destination". It might sound a bit mechanical, but it's not wrong.

If you do the same in German, it just sounds very confusing and wrong.

[jamespwilliams]

I’ve noticed a few other German-English anomalies in my time around German people. First is “some-” instead of “any-”. Second is the use of “since”, e.g: “I’ve been working here since 8 years”. Present tense confusion - e.g: “I’m having” instead of “I have” - my understanding is that in German there is only one present tense, whereas English has a few subtly different ones, so it’s not surprising that some confusion ensues. “Driving a bike” is always funny. Saying “with X years” instead of “aged X years”.

In all of those cases it’s still obvious what the person means. And to be clear I don’t mean to pick on anyone here, I just find the language differences interesting. Far be it from me to judge - I can barely speak one language, let alone two.

[1986]

English has borrowed so many words from so many other languages that there are false friends everywhere. As a native English speaker and German learner, it took me a minute to get over the same thing with "aktuell" - yes, of course I want the actual news!

[mappu]

Many many years ago, trying to learn German as an english speaker, i was taught Maybe (EN) -> Wehrscheinlich (DE) -

Is that correct? If it's even remotely close to being correct, it definitely makes sense pedagogically to avoid the ambiguity.

[1986]

I learned:

- maybe = vielleicht

- probably = wahrscheinlich

- definitely = bestimmt

But a big part of the gap between being able to speak in a language and being able to comprehend a language is that there are often plenty of ways to communicate/translate the same concept. It's much easier for a learner to say "vielleicht" every time they mean to indicate "maybe" than it is for a learner to learn that "vielleicht", "eventuell", "möglicherweise", etc. all basically map to the concept of "maybe" (which of course conceptually maps to its own set of English words - "maybe", but also "perhaps", "possibly", etc.).

It gets even hairier because word choice is highly culture-bound and the semantics are not guaranteed to be the same as the top dictionary definition. "Could you maybe take a look at this?" is not really asking someone to "maybe" take a look, the asker definitely wants them to take a look, it's just a construction that carries a deferential tone.

[yarcob]

Oops, you are right, now that I think about it it would be weird to see a button labelled "öffne" instead of "öffnen".

I just thought that it was unlikely that the verb/adjective confusion comes from German->Italian translation, it's more likely from English->Italian.

It's a common mistake that I've already seen in software translated from English to German as well, it's just what happens when you translate English strings without context.

[inopinatus]

In many apps, to "open" a document means to "show" it. And a ticket is conventionally a paper document.

So it's pretty easy to get from Open ticket to Papers Please.

[Symbiote]

An open ticket, in English, means a flexible transport ticket rather than one with fixed departure times.

[zelos]

Confusingly, "Open Ticket" is a valid term for a ticket with no fixed date it has to be used on.

[Joker_vD]

While most of modern European languages are heavily analytical, English language is pushing it straight into the isolating language territory. Morpological differences between nouns, adjectives, imperatives, infinitives? Who needs those? Just line the words in the correct order!

[agarsev]

It is true that English is extremely analytical, but most european languages are fusional rather than analytical: https://en.wikipedia.org/wiki/Fusional_language

[missedthecue]

It's crazy to believe that EasyJet wouldn't pay an Italian guy for a few months to translate the buttons and commands and notifications in their application, considering Italy is a fairly large market for them.

[BurningFrog]

Hopefully it's better now, but back when I lived in Sweden, I had to routinely translate strange Swedish wording to English to figure out what arcane computer term the translator had misunderstood.

[kwhitefoot]

Open ticket is ambiguous in English anyway. It could mean the ticket to which this refers is of type open or click here to view the ticket.

I have a different complaint than most others here and that is that most UIs require me to mentally translate from software developers English to real English. It's no surprise then that translating to a completely different language is difficult and error prone.

Edit: mismatched asterisks.

[baxtr]

It’s really embarrassing that two large Europeans companies are unable to pay 20 € per hour for a mediocre translator, which you could find on upwork within minutes.

[OneTimePetes]

I wish the users could edit the text and then the app would take over a text the users agreed upon in majority. It cant be that hard.

[jonas21]

Sounds like a good way to end up with all the strings in your app translating to "penis".

[translator6546]

Facebook did that early on, no idea if they still do. As a professional software localizer, I was not amused by the resulting translations.

[OneTimePetes]

I don't see why as a local user i cant override a crappy translation at least for my account.