German translation of application names


You are right. But a second problem is the tutorials and other description. You need to make here every time a other making into it.


I am wondering about this too. Why camel case? It’s 2018, can’t we put spaces in filenames when needed?

As for translations, it is indeed a locale specific problem (different cultures, even in the same language, for example fr_FR will be ok with keeping some english names, but fr_CA will be very picky about translating everything).

This is why this discussion should really happen in the locale specific mailing list, and there is no generic guideline for that. There can’t be.

Now on application naming. Recently I replaced the contact application on my phone because the stock one did not provide “favorite” contacts. Both applications show as “Contacts” on my homescreen, even if they have different names in the Play Store (or in F-Droid, for that matter). Once again I think it makes sense to draw inspiration from the early design of Android, which focuses on activities, rather than applications. This eventually did not always work, because it turns out application developers are very attached to their branding.

Does it matter that you are using People or DeeperPeople or MrPeeps to manage your People files? Not really, I’d say. And you should not run the app directly anyway, you should just open People files from Tracker or from other apps (eg. your mail client). So in this case the application name could be completely invisible.

We could extend this to other generic activities: Calendar, Media Player, Image Viewer, Calculator, …

There are other cases where the app is sufficiently specialized to have its own name, however. WonderBrush comes to mind. But even then, a translation could make sense. Think about Pokemon, they were localized too (sometimes with strange choices), but they kept their identity, still.


Namen sind Brands (in den meisten Fällen). Programm-Namen sollten niemals übersetzt werden, das ganze UI hingegen schon. Ihr würdet es ja auch sehr seltsam finden, wenn zum Beispiel “General Motors” plötzlich “Allgemeine Wagenwerke” heissen würde. Oder wenn ihr “Fenster” auf einem PC vorfindet würdet oder “Feuerfuchs”. Ganz zu schweigen von Scripting-Problemen. Es ist ausserdem inkonsistent, wenn man einige Programme umbenennt aber andere nicht. Einer der vielen Gründe, warum ich nur English als Sprache überall einsetzt.


As stated on another thread of the same topic, no. I dont think names should be translated.
Unless you have a functionality for the app and show it instead (i.e. “Terminal emulator” in linux whereas that points to Xterm / Termite / Konsole / …)


Only if the japanese wrote it in romanji, or the average euro/us user is able to read katakana / hiragana. 俳句 is a good name for an OS, but we (average users) probably wont be able to read it.

That’sAChoice, couldhavechosen otherOption but is_a_subjective_thing.
Regarding spaces… only if you can have an alias that’s what’s displayed, and not the real executable name (maybe an attribute on the file?). Otherwise that would cause param calls patch everywhere to use quotes and yada yada


Yes … but here it seems you’re looking at a limited functional domain that wouldn’t lead to multiple competing implementations, is that right? A special case, that wouldn’t for example apply to the web browser where there are indeed multiple competing implementations with significant differences.


As I said, it’s 2018. Why is that still a problem? :’(
In the BeAPI, applications would be referenced by their MIME type, not executable name, anyways.

Why not? When you have a web browser installed, you think of it as the web browser. When you click an URL in another app, it opens.

The branding and app identity matters in HaiuDepot when you install it. But once you have it there, it doesn’t anymore. You just want all links to open in the browser you chose to use, whichever it is.


Es ist eine Sache was man sieht und eine Sache was im Hintergrund passiert, aber ich bin deiner Meinung


I agree that it should be decided per-language (for instance, the current Brazilian translation goes to the point of translating the Tracker name, but I don’t feel that in Portugal the users would be more comfortable with “Rastreador” or any other similar word, so I left it in English).

Looking through what Apple does on macOS, you can seed that Calculator, Contacts, Calendar, Image Capture, Disk Utility, Photos, Maps, Preview, About this Mac, and many others are translated. Most times, they translate anything that isn’t an untranslatable neologism, like LaunchPad or iTunes.

And of course it implies the need to update documentation for that language also. There must be consistency throughout the system and the documentation. It may not be evident for some translators that a name they have just translated is also used in other parts of the system and may also need to be updated accordingly.


This is a good idea, only that I wouldn’t call it “full translation”. “Éditeur du texte”, for example, is not a translation of StyledEdit, but a description of what that application is or does, which can be really helpful, I guess (especially for less obvious application names like Vision).

At best, this would be a UI feature than can be switched on in addition to using a translation.


Too much settings is bad.
This should not be needed. Let’s make better application names (Vision is especially confusing).

Usually the icon conveys some of this meaning. There is also already a description field in application resources, which we currently don’t put to any use I think? Quicklaunch maybe shows it in search results?

A description does not fit well with the current way to access apps (DeskBar), but in something like QuickLaunch I think it makes more sense. Time for a wider re-thinking of our interface here.


BTW, QuickLaunch should really be bundled with the OS, with a default keyboard Shortcuts, like Spotlight on macOS. :slight_smile:


Well, what about Bash (or any POSIX-compliant command-line shell, for that matter)? It does word splitting on whitespace. So, if you had an executable in your $PATH that contains whitespace, you’d either have to use quotes around it or auto-completion, in which case the shell would escape all spaces with backslashes, which looks kind of weird.

And I think that this attachment is actually a good thing, simply because the application is not the same thing as the task it helps to accomplish. Therefore, the application name should be different from that task’s or activity’s name.

Ok, that’s a conceptual question. I very much prefer an application-centred approach (except for the system’s basic command-line tool chest – naming-wise, I mean) because, to me, it really matters which application I run to get something done. I wouldn’t like the operating system hiding that.


On the other hand, configurability is good. Also, I don’t think that Vision is necessarily a bad application name. Ok, it doesn’t exactly say “Hey, I’m probably an IRC client”, but then, the application’s name is its name and preferably not a mere description of what it is or does, IMO. So, Vision is doing it quite right, I’d say.


Why not a tooktip then selecting a icon or menu option (program). So names can be names and users informed about the program type selecting it.


Yes, there’s a long info and short info field in the resources. Unfortunately none of them is translatable. Those are displayed by LaunchBox as tooltips.
Such a tooltip would be useful for Deskbar/Tracker, but not for Quicklaunch, I think. Quicklaunch gives fast access to the apps you already know, so you just enter two or three letters and you’re there. It’s not good for exploring apps.


Tooktips should be only displayed past three second on every app icon


Well, it would be, if one could type “IRC” and find Vision, for example.


Excuse me, but that’s fantasy. If it were the case, there’d be no reason for multiple browsers, but eventually there are reasons. If it were the case, there’d be no mechanism for choosing a default browser - they’re all the same, who cares, why would you even have more than one to choose from? But we do have more than one, because their functional domain is large and difficult enough that they don’t completely overlap. This is the problem with the whole concept, but in cases of much more limited functionality the fantasy may be close enough to reality that it’s worth thinking about the potential benefit, however slight that may be.


what a strange (if not stupid but funny conversation…)

To make things clear and easy:
What happens if you cross the border to another country with another language and another style? What do you do? Will you ask for MCDonnald or will you ask for food? Will you point your finger to your mouth? Or will you show your belly?

lol strange conversation…

P.S.: Try to think different!


Some comments are stranger than others… :crazy_face: