Closed Bug 1394458 Opened 7 years ago Closed 7 years ago

Update copy for error: tab crash

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 57
Tracking Status
firefox57 --- fixed

People

(Reporter: ewright, Assigned: nhnt11)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Based on copy and mocks found in Bug 1358305
Attached image error-tab-crashed.svg
this is the image we'd like to use
Summary: Update illustration and copy for error: tab crash → Update copy for error: tab crash
Changing this bug to just be about updating the copy.

The mocks don't specify anything for the case in which multiple tabs have crashed, and also I'd like to confirm that we are doing away with the "optional comments" textbox. Until then, let's just land the new strings ASAP.
Comment on attachment 8909997 [details]
Bug 1394458 - Update copy for about:tabcrashed.

https://reviewboard.mozilla.org/r/181480/#review186724

::: browser/locales/en-US/chrome/browser/aboutTabCrashed.dtd:5
(Diff revision 1)
>  <!-- This Source Code Form is subject to the terms of the Mozilla Public
>     - License, v. 2.0. If a copy of the MPL was not distributed with this
>     - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
>  
> -<!ENTITY tabCrashed.closeTab "Close This Tab">
> +<!ENTITY tabCrashed.title "Tab crash reporter">

Note that this title is replaced by this line:

http://searchfox.org/mozilla-central/source/browser/base/content/aboutTabCrashed.js#61

I've included the new string anyway for now.
Comment on attachment 8909997 [details]
Bug 1394458 - Update copy for about:tabcrashed.

https://reviewboard.mozilla.org/r/181480/#review186728
Attachment #8909997 - Flags: review?(jhofmann) → review+
Pushed by nhnt11@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/6a176aa5ce0b
Update copy for about:tabcrashed. r=johannh
Assignee: nobody → nhnt11
https://hg.mozilla.org/mozilla-central/rev/6a176aa5ce0b
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
(In reply to Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout) from comment #7)
> https://hg.mozilla.org/mozilla-central/rev/6a176aa5ce0b

> -<!ENTITY tabCrashed.sendReport2 "Send a crash report for the tab you are viewing">
> +<!ENTITY tabCrashed.sendReport3 "Send an automated crash report so we can fix issues like this.">
> 
> -<!ENTITY tabCrashed.includeURL2 "Include page URL with this crash report">
> +<!ENTITY tabCrashed.includeURL3 "Include the URLs of the sites you were on when &brandShortName; crashed.">
> 
> -<!ENTITY tabCrashed.autoSubmit2 "Update preferences to automatically send crash reports, including reports for crashed background tabs from this session and future sessions">
> +<!ENTITY tabCrashed.autoSubmit3 "Update preferences to automatically submit reports when &brandShortName; crashes.">

Obviously tabCrashed.sendReport3, tabCrashed.includeURL3 and tabCrashed.autoSubmit3 now use trailing periods whre they should not. (See bug 1358305 comment 0.)

Please understand that trailing periods should only be used in imperative (=instructive) mood, which is rare, hence not for menu items, options, tooltips, selections etc., i.e. user choices or descriptions. Although it may seem trivial, they cause wrong tense/form - not only for English, but for localizers too and massively lead to wrong translations.

This is not the first time this happens. Please just keep it in mind.
(In reply to Ton from comment #8)
> Please understand that trailing periods should only be used in imperative
> (=instructive) mood, which is rare, hence not for menu items, options,
> tooltips, selections etc., i.e. user choices or descriptions. Although it
> may seem trivial, they cause wrong tense/form - not only for English, but
> for localizers too and massively lead to wrong translations.

Can you explain why the final period would trigger a different translation, possibly with an example? I don't see a way to interpret the English string differently, based on the presence or lack of the period.
(In reply to Ton from comment #8)
> This is not the first time this happens. Please just keep it in mind.

Exactly.
I'd be interested in getting an answer to comment 9 as well, so that we can avoid this in the future if it really presents a problem :)
Flags: needinfo?(tonnes.mb)
As said, trailing periods are only required for full sentences, including descriptive ones. They are not for tooltips, menu items, options, checkboxes in general or other listed user choices, etc., which is sometimes and roughly more than 90% in products. Simply said, the periods indicate whether or not a string is imperative (instructive) or not - otherwise called infinitive in general, or as "sentence fragments."

English simply does not visually distinguish imperative and infinitive moods in grammar for the affected verbs. Many other languages however do. This means both English and other languages are affected.

Compare this:
1) Enter a file name  -> Could be a checkbox, tooltip, menu item, choice on a page, etc.
2) Enter a file name. -> Is instructive (to the user!), telling the user to do this.

When the period is left out in 1),
- English readers will read "This is (e.g. a tooltip, option) text telling me _I can_ [enter a file name]" - the option is something I can choose from (it’s part of a sentence).
- Localizers generally don’t have to or just don’t even look at the context to know this is infinitive or part of a sentence, causing them to use full verbs for their localizations.

When the period is included in 2),
- English readers will read "You should open the file" - no doubt about it.
- Localizers immediately know or at least use the trailing period as an indication to know the string is imperative/instructive, and use a total different localization.

Only in very rare occasions, imperative forms may end with a period, such as when a tooltip uses its primary description, but is added with a second sentence to elaborate (see devtools for instance.)

This info can also be found at [1] as well as at [2].

For the tabcrash text as it currently is:
<text>We can help!  Choose Restore This Tab to reload the page.              -> imperative, period required.
(✓) Send an automated crash report so we can fix issues like this.           -> not imperative, user choice, no period required
( ) Include the URL of the sites you were on when Firefox crashed.           -> ^ likewise
( ) Update preferences to automatically submit reports when Firefox crashes. -> ^ likewise

The way these strings for this bug changed added periods by mistake, which should be crystal clear, is highly confusing, creates an exception and meanwhile has lead to localizations overlooking the issues above as expected, as well as inconsistent moods for the 3 strings affected in some of them. Even when English speakers "may not clearly see a difference" in this case, it’s just a standard, common knowledge, and it should be handled consistently within entire products or documents.

It may sound odd, but it took a number of comments in 3 or 4 bugs (mostly devtools related) and a few years to have this info included in the MDN style guide [3], unfortunately mentioning tooltips only. Please don’t make the same happen for strings like these and the error to repeat itself. Therefore I’d be happy to see this fixed and someone added or modified the info to/in any style guide.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb246416(v=vs.85).aspx
[2] http://design.firefox.com/photon/copy/punctuation.html
[3] https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices#Tooltips
Flags: needinfo?(tonnes.mb)
Ok, thanks for the information. This copy came from UX, but given the arguments here I can see why we'd want to change it. Can you open a follow-up bug and needinfo mheubusch so that she can approve?
Thanks, I filed bug 1411618.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: