Localising application/preference names by default

Okay, then let’s take a step back and see the Haiku user not as a tourist but as a human being with a functioning brain and the natural curiosity that everyone is equipped with.

You make it sound like once everything in the OS is localized, the user will have no problems at all using Haiku, even if it’s the first time he/she enters this environment that will always be different to other operating systems.

I mean: the same level of intelligence + curiosity needed to overcome those differences in functionality and the way they are presented (and/or set up) will also be needed to deal with the language differences for the parts of the OS that we’re talking about.

Are you then also going to state that you cannot for example “force” a user to learn even a few differences in functionality from what he/she is used to? What would he/she be used to? It can be anything. Windows, because most people use it? Doesn’t cover each case, and how can you be sure?

Remember the brain and subsequent natural learing capability that every human capable of using a PC has. Learning capability that cannot be separated from curiosity. This curiosity to try a different OS will always include an amount of goodwill, which means the new aspects are unlikely to be experienced as something that’s forced upon that user.

Plus (going back to the tourist metaphor), Haiku has documentation that I believe is localized and provides short descriptions in the local language. There’s a tourist guide after all, so to say.

A third help comes in the form of icons that are not guaranteed to give a clear understanding, but will help in most cases.

1 Like

Can you provide a study about this tourist metaphor suggesting that it actually works in software UX?

I prefer to take example from other commercial operating systems, which base their decisions on actual usability studies, not from some vague metaphor.

2 Likes

I kindly disagree. It’s not about curiosity, intelligence, brain wisely usage ore neuroscience stuff. It’s about expectations. A user who is operating a computer, and Haiku, in this case doesn’t necessarly expect to have to do runtime translations of a UX. You cannot assume he does, or he’s comfortable with. This is unregarding of his avg. IQ. You cannot make your UX assumptions on it.

Perhaps users running a niche software or somewhat could expect that their experience would be non-localized. It is ok. It is a kind-of unwritten agreement between the authors and the users; it is context-dependant.

Maybe all the Haiku users are in this audience, too. But Haiku itself is not. Again, Haiku is targeted to the average user. Thus, his experience should be consistent with this positioning (and it is, actually)

As a Mac (power)user I would say the opposite. I like having the file system monkey-user folders translated. What I mean to say is that it does not depends on what we (individuals) thinks, but what the intended user will.

Said that, I’m happy that Haiku has not that gibberish. I mean, those useless, folders like “Downloads”, “Pictures” etc. Not because they are ambigious in translations, but because I hate the concept (I’m not going offtopic here saying why).

IMHO home and config are notable exceptions as they’re universal jargon. Ok, maybe Unix jargon, but i can handle that. I would not translate.

DeskBar stuffs, on the other hand, I personally think we should.

Here’s my dock at the time of writing.

so, no, you cannot rely to icons to understand the app purpose (unless you’ve a very well branded and very widespreaded app)

1 Like

I wouldn’t translate too the name of the programs for the Italian translation.

In Italian language “Character Map” become “Mappa caratteri” as written in all grammar books with this example:

Alessandro Manzoni. I promessi sposi (OK)
Alessandro Manzoni. I Promessi Sposi (wrong)
Alessandro Manzoni. I Promessi sposi (wrong)
Alessandro Manzoni. I promessi Sposi (wrong)
Alessandro Manzoni. i promessi sposi (wrong)
Alessandro Manzoni. i Promessi sposi (wrong)…

I neither see a unique criteria in another OS about the translation of applications. For example, “Microsoft Office” is named “Office” in every language I know. The same for “Wordpad”, “Explorer”, etc.

However, another programs (or more like small tools), like Notepad, are translated.

Maybe we must differentiate between a name that is merely a description of the application (like: Calculator, Notepad, etc.), to the one that is reallly a “name” (in the way than “John” is a name).For example, “People”, “Expander” , etc.

2 Likes

How about this crazy idea: Tracker supports Attributes, so we always have the option of adding a Language attribute. When displaying files and applications, display the default English name, and on the condition that a “Language” attribute exists, append in a different style (font/colour) the translated version. So the user will see “Office (办公室)”. When the language changes, possibly run a script to update the Language attribute (to prevent having 30+ extra attributes per file). Potentially offer a user setting to swap the display order to “办公室 (Office)”

Just an idea.

2 Likes

I don’t think that polluting with extra options or “let the user choose” is always the best idea. In this case, I strongly believe it isn’t.

It should be designer choice. This is to ensure a consistent experience, ensure that Haiku is easy to use and to setup. But also to make homogeneus documentation, knowledge base, tutorials and, at the end of the day, making the community.

Haiku is not Slackware after all :slight_smile:

I mostly agree. Although using the camel case is an universal jargon in computer science for proper names, I’m not worried about that.

1 Like

This thread is not about technical issues. These are already solved. You can check the checkbox in Locale and translation will work. This thread is about wether the checkbox should be checked by default, and wether it should apply to everything or only a part of things.

We need a “fortune” file to save this somewhere :sweat_smile:

Anyway, it may seem easy from my European viewpoint (and in general to everyone contributing here, we all have some level of English skills obviously). So imagine that: how would you feel about this if all the names were in Japanese, written in an alphabet you don’t know? Would you be ok with that? I certainly wouldn’t. So it’s clear that in some cases, translation is needed.

There is a clear majority in the vote for translating Preferences (either just them, or them + some apps, or them + all apps). I’d say let’s do that, and the Deskbar “folder” entries. Maybe the applications need more discussion, our choice of name being somewhat a middle ground between being just descriptive (“Magnify”) and somewhat arbitrary (“PoorMan”) with many intermediate levels (“CodyCam”, “PatchBay”, “HaikuDepot”, “People”, …), not to mention the “I removed a space to make it cool” trend (“ShowImage”, “CharacterMap”, “DiskUsage”, …) where I’m not convinced it actually looks that cool (I think it originated in BeOS as a “our buildsystem doesn’t handle space in names” thing). So, of course, there are mixed feelings here. Is localization going to lose these playful names? Could the translators come up with equally creative naming in each language? Why not, after all?

And we may even keep the checkbox for those of you (or us) who really want to keep this all in English.

As the majority is clearly for having names translated by default, for the next action I believe we should decide on the following issue:

  1. Mark individual applications translatable or not in Pootle level
  2. Let each translator decide if the application is worth translating

If we want to keep the Haiku touch, we have to decide which applications should be translatable or not.

Maybe we should open another poll with each application as a separate entry?

Do we really need a poll? Let the translation team for each language decide. There are cultural reasons to translate things or not, and that can only be handled by each language team discussing it case-by-case.

2 Likes

That’s what I think as well. My point was about the “Haiku Touch” concerns raised in other posts.

It is not every time a easy thing to change program names to other languages because this are names dicided by the developer and part of the license.

On the other side, to translate the preferences menu entry to the user language should be easy if this are done using translated links instead in the original program to select in the menu.

Personally, even being French, I prefer to have original system names everywhere and have only dates, times and currency translated.
The main reason for this is that most references to an app are in English.
For example, if I see something on the forum about Background, I will know what app it is and where to find it. Same thing if I see in Source Activity Network preference.

Ideally, you want the system to be usable by a user who knows only his mother language. What it means is that

  • user’s able to download and install the system in his language;
  • user’s able to configure basic things in his language;
  • user’s able to install additional software in his language;
  • user’s able to report problems and receive help in his language.

First point, we all agree and is mostly covered.
Second point is actually what we are discussing. So, yes to preferences translated.
Also, if an app is an essential part of the system, its name needs to have a meaning.
Third point already raises few problems. Yes HaikuDepot is translated but neither each software nor their package descriptions are. Honestly even linux distribs who have way more manpower can’t handle that. Maybe, in a distant future, a short description limited to a line could do but, more is unrealistic.
The fourth point is quite annoying because it assumes that you have a lot of manpower for each language but also that there is coordination between all languages teams. For a same question on forum, you will want different answers in French and German but they need to keep absolutely same meaning which represents the project orientation. Each track tickets would have to be translated to the language of the maintainer, what about parts who don’t have one assigned?
So, with a limited user base, it is also unrealistic. For the moment, we have to stick with English for Track tickets and most forum discussions.
At the end, users need to know system names of things they use when they are reporting a bug or asking a question about them and perhaps it could be a good idea to make it available easily somewhere without having to mess with whole locale setting.

1 Like

I guess we should find a common standard and not to demand to single translators/individual to decide. Yes, final choice is to them, but a set of guidelines to provide to them is advisable.

Actually it is possible to translate the packages. But it’s a huge works and almost nobody is working on it. As an example, I’ve just started (translated more or less 50 packages and applications names/descriptions in italian)

Bug reporting is somewhat the average user won’t do much often, unfortunately. Perhaps we could eventually try to increase the bug submission rate by average users. But this would mean to add a more user-friendly bug submission platform in addition to the made-for-developers ones we already have (trac etc.)

Does it matter if the Turkish and Japanese translations make different choices about this? What’s the point of a common standard here? It will just raise lot of discussions, with people from countries were speaking English is common arguing that they want to keep the “identity” of apps, and people from other places complaining that this means users will be lost with completely meaningless application names. There is not a single solution for this problem, it depends on the locale. That’s what localization (and not just translation) is all about: letting the team for each language make their own decisions, because the answer isn’t universal.

We have set good guidelines already:

  • The “folder” names in DeskBar should be translated
  • The system folders like /boot/home and /boot/home/config should probably not be translated (the link to home on the desktop may be translated, I guess)
  • The preference apps should be translated
  • The applications may or may not be translated, that’s up to the localization team for each language to decide.

Our developers are already overwhelmed with the current rate of bug reporting on the existing bugtracker. At this point there isn’t much to be gained by collecting more reports. Doing so would require a dedicated QA and/or support team to handle the requests from the users and do the follow-up, and prepare submissions for the bugtracker (or whatever other way is found convenient to forward info to the developers).

Yes, i think it does. Turkish and Japanese translators will have the final choice ofc, for cultural reasons. But a set of common design elements will probably help them. Some were already defined (also on this thread), others could be added maybe. Pls don’t forget that many languages have just one guy working on, not a team. Not having an even weak guidelines means that it’s all about common sense and vague, subjective, tastes.

Yes, perhaps the swedish team will prefer to leave Magnify as is. Nothing offensive here. But the standard could cover different issues.

Just cherrypicking:

  • Should the app have a space between words or not?
  • Which terms should be translated and which should be not? With proper excetions, ofc. for ex. in french more words are usually translated than other latin languages. Ie. “computer”, “downloads”, “font” etc. Other are more sublte for ex. “installer”, “package” etc. (this is not about app names I know).
  • Which app are considered “branded” enough to not have to be translated. WebPositive, Deskbar and Tracker, for sure. What about other bundled apps? What about HaikuDepot? And StyledEdit?

(yes, actually I’ve still not decided about “package” :confused:)

Ofc not. Not now at least. I was just saying that there’s no need to provide a localized platform for bug/support if, like now, this is purely a technical tool.

There are wiki pages about internationalization efforts, both common, and specific to each language: https://dev.haiku-os.org/wiki/i18n

There are also mailing lists for coordinating things, and probably a lot of this discussion should go there.

It’s interesting that you’d think French translates everything. It’s the case maybe in user interfaces, but not that much whenever you’re in technical discussions (the words exist, but are so uncommon that it’s easier to understand each other using english words there).

I think the French version went with “Éditeur Stylé” for StyledEdit. I think it’s a not too bad rendition of the meaning. However, the style guide on the wiki for French localization clearly says “don’t translate application names”.

And there are more complex issues, for example, even if you don’t translate the names, should you transliterate them when writing in Japanese, in Russian, in Chinese? Or is keeping the name in the latin alphabet acceptable? These issues can quickly be pretty specific to the rules of a given language, and also to existing culture (how was Tracker called in the Japanese version of BeOS, for example? It makes sense to keep the same name).

So, it’s fine that there is discussion between the various localization teams, but I don’t think it will go very far in terms of common guidelines, or at least, nothing we would enforce on any language. But feel free to improve the wiki pages if you think some things should be put in common.

2 Likes

I agree too, if your target becomes a basic user then you will also need to translate the home subfolders. Keep in mind that in Italy some things are mandatory by law, please remind me at the right time to check them, because today I am not an avid user of Haiku.

If a name shouldn’t be translated why don’t remove the option for translation?
some language have made there own rules how to translate as pointed out by PulkoMandy.

I still think’s it’s up to the developer or the ones translating. Is the person alone he/she also have to decide how it’s usually done in there country.

1 Like

Thats’ definitively a huge point. I frankly admit I have no idea on how UX things works (in terms of conventions, standards and best practices) in, for ex., asian countries.

Sure! I’ll keep my mind on it and going to propose some point of discussions, if I end up having some good ideas (help wanted). But I admit that I see your point and you convinced me this is going to be difficult to find a common standard. Perhaps some weak cultural guidelines could help, though. Very hard to do, indeed.