The Qt guidelines go on to recommend also avoiding "please" unless it's really necessary to avoid sounding abrupt, as in "Please wait" versus "Wait." That may seem surprising (isn't saying "please" always politer than not?) but I think the real point is that "please" is a marker for telling someone what to do (or at least asking), and in keeping with my own guideline, software generally shouldn't request action from the user.

Now, here are three messages I removed from my GIMP fork in this commit. The context is that the user has entered a filename extension that isn't appropriate for the type of file being saved; there are three different messages because this code is re-used in several different dialog boxes that all have the general function of storing information in files.

"You can use this dialog to export to various file formats. If you want to save the image to the GIMP XCF format, use File→Save instead."

"You can use this dialog to save to the GIMP XCF format. Use File→Export to export to other file formats."

"The given filename does not have any known file extension. Please enter a known file extension or select a file format from the file format list."

See what they did there? Every single one of those messages tells the user what to do with the imperative mood - "use File→Save instead," "Use File→Export to export," or "enter a known file extension," all breaking my guideline. Two of the messages also address the user are "You," breaking the Qt guideline and actually breaking the Microsoft guideline as well, because the messages do it gratuitously in non-imperative sentences. "You can use this dialog to export" doesn't tell the user what to do; it is just a statement of fact and could as well be written without the "You." The third message includes a non-Qt "Please."

I replaced all three of these messages with the following:

"The given filename does not have an appropriate extension for this command."

Since I hope to merge the three contexts where the messages are used into a single save dialog, there's not much point continuing to give the specific information about why this was the wrong dialog for what the user was trying to do, or what would be a better choice. The fact that the given filename's extension was inappropriate is still something we have to point out, but that's all, and we can stick to the fact itself; it's not necessary to drag the user personally into it by saying "you" when we are talking about the filename.

Thinking about this some more, I wondered about the Japanese translation. The fun thing with Japanese is that there isn't just one word for "you" - there are several second-person pronouns and pronoun-like nouns, some of which are gender-specific and all of which have implications for politeness. It's also easier to avoid using a pronoun at all, and it's polite in some contexts to just use the person's name and title where we'd use a pronoun. A lot of the tone issues that these UI guidelines flail around trying to describe in English are much more clearly understood and agreed on in Japanese. So, which form of "you" should an image editor use to address the user in Japanese? The answer to that will say a lot about what the relationship between the software and the user actually is.

I didn't have to think too hard to realize that of course the software should have the personality of an anime little-sister character and call the user oniichan, "elder brother." However, that way lies madness. Next thing I'd have to replace Script-Fu with Kirikiri, add "Put it in" as an option on all the context menus, and port the xscreensaver SkyTentacles code as a rendering filter. Actually, I'm not seeing much downside.

But instead of going there, let's look at what the mainline GIMP's Japanese version currently says. Here are the same three messages with my own translations back to English, in which I'm trying to preserve the tone of the Japanese text as closely as possible:

「この保存ダイアログでは xcf 形式とそのアーカイブ以外のファイル形式で画像を保存できません。xcf 形式以外の画像ファイル形式で保存したいときは、メニューの [ファイル] → [エクスポート] を実行してください。」 "Saving an image, other than into XCF format or an archive of that, is not possible with this Save dialog. When [you] wish to save into a non-XCF image file format, please perform the File→Export menu operation."

「指定されたファイル名には既知のファイル拡張子がありません。既知のファイル拡張子を入力するか、ファイル形式の一覧からファイル形式を選択してください。」 "The filename that was specified does not have a known extension. Please choose a file format from the list of file formats, or enter a known extension."

I wrote "[you]" in a couple of places where I needed it to form a grammatical sentence in English, but in fact this Japanese text doesn't use a pronoun for the user at all. That is probably the right choice; it is a general rule in Japanese that it's politer not to refer to people directly, and a grammatical feature called "pronoun drop" makes it easier to do that without writing incomplete sentences. The informational sentences about what is and isn't possible with this dialog box have been changed to refer only to the facts instead of mentioning the user personally - as required by Japanese politeness standards and, really, as would be a good idea in English too.

However, it still explicitly uses the equivalent of an imperative "please" (「〜でください」) to request that the user do something, in all three messages. It also twice uses 「したい」, "wish to do," to refer to the user's wishes. That's inside a conditional - when you wish to save - and it may be all right there, but I think it's an interesting choice. I've been taught that in a non-conditional sentence, one should only use that word to describe one's own wishes, because otherwise it sounds rudely presumptuous. "Who are you to know what someone else wants?"

Although the command for saving to a non-XCF file format is called 「エクスポート」, which is just the English word "export" transcribed phonetically, nonetheless the first two messages both refer to 「保存ダイアログ」, a "Save dialog," and the action of storing into a file with either dialog is called 「保存する」, "to save." The consistent pattern of the English-language messages that "saving" is a fundamentally different action from "exporting" - which we know is an important point the original authors of the messages wanted to make - has been lost in translation.

I think the bottom line on the translated version is that the translators did a good job of translating the tone of the English version into the Japanese version. They probably felt that was their job, and not their job to rewrite the text. But I don't think the Japanese version sounds the way it would if it were originally written in Japanese, and it has some of the same problems of ordering the user around unnecessarily that the English version had.

ETA: Something I just noticed is that the original English versions say "GIMP XCF format" and the Japanese versions just "XCF format" without mentioning GIMP. I don't know what if anything that signifies, but it's an interesting change.

ETA: Oh! Oh! I've got another one! I read further down in the Microsoft UI document and found this:

Limit please to situations that inconvenience the user in some way[.]

Of course, my suggestion would be:

Limit situations that inconvenience the user in some way.

Such situations are sometimes unavoidable and nobody's fault, and the Microsoft guideline isn't bad advice. But I wanted to share that thought.

6 comments

There are soft imperatives and hard imperatives. Not all imperatives are imperious. I, for one, am not offended by instructions in the imperative voice. As for translations that keep the tone of the original vs those that sound as if they were composed in the end language, that is the eternal question. Always a judgment call.Axel - 2012-05-20 19:06

Translation is difficult. Something that is straight imperative/factual in German may come across as drill-sergant shout when translated straight into English, and these two languages are less different.
Though German does have two forms of the second person and more if one includes contextual meaning changes.
Actually some MS guidelines result in outputs that are not strictly correct in 'high-German' ( but perfectly all right in most regional dialects - something like "ain't no sunshine when she's gone" )

Thank you for making me think about the difference between saving and exporting. The way I now define it is that an Export MAY not be reversible, a save in anything but the native format of the application can be loaded again, but some features may have been lost in transforming to the 'other/foreign' format. ( open/libre office : exporting to pdf, saving can be done to rtf, doc, HTML, ... ) [Now I want an export to HTML feature ]
( not having experience with GIMP I draw my interface experieces elsewhere : Audacity comes to mind ) .
So maybe the proper response mode of the sytem for any software should be to point out the consequences of a non-native save. ( if you save as gif the number of colors must be reduced to 256, if you save as jpg all layers will be merged, ... ) something that I have seen in open office when saving as really was exporting to formats readable by other people on different systems with diferent software ( calc to excel, odt to doc or rtf ... )
So maybe the real solution might be to offer 3 choices in the store menu : save ( native, reversible ) , save ( non native, partly reversible ) , export (not reversible ) , however I am not going to hold my breath for MS o implement that.Andreas Schaefer - 2012-05-21 07:44

Pointing out the consequences may be problematic with save in particular just because it's such a common operation. I might save to JPEG (which is lossy compression and loses data even in the best case, when there are no layers and guidelines and so on to be lost) many times a day, and I'm going to be annoyed if the software pops up a message just to remind me that JPEG is lossy (I know exactly what quantizing the coefficients of a discrete cosine transform does, thank you very much), every single time.

One way to deal with that would be the classic "Do not show me this message again" check box. Another would be what GIMP 2.6 did, and my modified GIMP now does: make use of the fact that we need more user interaction at this point anyway. When you save to JPEG, the system needs to know some more information about your preferences, such as what compression level you want. So it pops up a box to ask for that extra information, not just to tell you JPEG is lossy. Since it has a purpose that is useful no matter how much you already know, it doesn't come across as an impediment to an expert user who knows exactly what they want; it's just their chance to say what they want. However, it's still an extra step that someone could object to because of the added time.

Maybe the best option would be to have some way of specifying stuff like JPEG compression level outside the main flow. Some of GIMP 2.8's several "store" commands will automatically use the last "export parameters" instead of popping up another box to ask for them. That is billed as an improvement in convenience. I think the inconvenience of separating "Save" into several commands is too high a price to pay for the convenience of not specifying file-format parameters every time they're needed, but I could imagine something like what "Print" does in many applications. There's a separate "Print settings" command which basically sets the defaults for the "Print" command. When you use "Print" you get those settings, and the opportunity to open "Print settings" again if you don't want the defaults. Maybe a "Save settings" command could edit the current defaults for file format parameters, and then "Save" would use those defaults if appropriate to the file format, while also giving the user a chance to open the "Save settings" again. This would involve some nontrivial new UI code, however.Matt - 2012-05-21 09:22

Interesting stuff. I write and document commercial software, and I don't think our doc is particularly rude or condescending, nor does it go overboard with obsequious language. But I was surprised at some q&d word/phrase counts:
you 239
can 218
cannot 8
you can 41
must 189
you must 48
may 17
you may 2
if you 41
that you 33
suggest 6
suggest you 2
suggested 0
recommend 24
recommended 3
recommend you 8
recommend that you 8
recommend that 9

Now this is an installation and use manual - not stuff being told to the user while the software is running. But still, the "must" and particularly the "you must" counts seem much higher than I would've expected. Looking harder, this isn't RFC style use of must; it really is telling the user what to do. But it doesn't, imo, come across as high handed. Now of course what I can't pick out by doing little phrase counts is use of the imperative. This isn't German, so there are no handy exclamation marks to search for. My impression, though, is that we have a lot of things of the form "if you want to do x, then you must do y".

Well, I digress again... As for "save as" and the like, while obviously experienced users understand, it might be worth explaining (but surely not on every save) the notion that the program works in a lossless format, and that it's not that saving as PNG or some similar lossy thing is evil, even when repeated, but that transcoding (almost always) causes relentless loss if you repeat it.

WRT GIMP, in my very limited experience with it the biggest problem/surprise was that there is almost no help with setting reasonable values for compression in PNG, JPEG, and the like. Taking the defaults with each of these results in a PNG file that is five or ten times the size of a subjectively as-good-viewed-in-a-browser JPG file.Tony H. - 2012-05-22 13:28

Tony H, I'm sure your company is not high-handed. If a specific action is necessary then "must" is appropriate. Word counts won't tell us much until a context-sensitive search function is invented.Axel - 2012-05-22 19:28

I think the main problem with the "oniichan" thing is that some users would appropriately be referred to as "oneechan" instead. Other than that it sounds fine to me.Ronixis - 2012-12-12 21:25