The actual identifier should be something like “Open a ticket (imperative, button)” and then that phrase has translations, including the English “Open ticket”.
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.
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.
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.
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.
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.
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.
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?
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.
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.
Yes! That is exactly what people want.
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.
Personally I think it is better to use a “surrogate key” that isn’t the English text itself.
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
let buttonStr = NSLocalizedString("Open ticket", comment: "For user to open a ticket")
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.
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.
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).