Closed Bug 1151449 Opened 5 years ago Closed 4 years ago

Use curly quotes and apostrophes instead of straight quotes in error pages

Categories

(Firefox :: General, enhancement, P5)

x86
macOS
enhancement
Points:
1

Tracking

()

RESOLVED FIXED
Firefox 48
Tracking Status
firefox48 --- fixed

People

(Reporter: rfeeley, Assigned: ktbee, Mentored)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qx:spec][outreachy-12])

Attachments

(2 files, 1 obsolete file)

Whiteboard: [qx]
Whiteboard: [qx] → [qx:spec]
While incremental change is always nice... Is there any reason to limit the scope here to error pages? Shouldn't we generally use curly quotes everywhere?

The reason I note this, is that it's probably worth having some form of L10N linter to catch this, or else people will constantly forget when adding new strings. (Similarly, we should catch "..." instead of a proper ellipsis (…), which still happens.) Couple that with doing a 1-time pass to fix all the strings, and that would get us into a better state that doesn't just quickly start to regress.

[Should check with L10N, but it would be nice to do this as a change only in the actual string files without having to change entity/property names. Locales might want a similar linting tool to update any quotes in their own strings, although that starts to get a little more complex with locale-specific quoting. https://en.wikipedia.org/wiki/Quotation_mark#Summary_table_for_all_languages]
Would love this! I only pointed out error pages because they contain large headines where users would notice, but your approach to eliminate them from the past and into the future is ideal.
Flags: needinfo?(dolske)
Blocks: 1248735
No longer blocks: fx-qx
Flags: needinfo?(dolske)
Attached image apostrophe.png
Attachment #8588583 - Attachment is obsolete: true
Mentor: jaws
Whiteboard: [qx:spec] → [qx:spec][outreachy-12]
Points: --- → 1
Assignee: nobody → kbroida
Status: NEW → ASSIGNED
Comment on attachment 8734583 [details] [diff] [review]
Changes straight apostrophes to curly ones.

Review of attachment 8734583 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, I'll get this checked in and I'll also file another bug for other strings located under /browser/locales that can use smart quotes. I just wrote a patch that will fix those other places.
Attachment #8734583 - Flags: review?(jaws) → review+
I filed bug 1259847 for the other files and included a patch there.
https://hg.mozilla.org/mozilla-central/rev/b872c30803ef
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Congrats on fixing your first Firefox bug Katie. Your changes should show up in tomorrow's Nightly build.
(In reply to Justin Dolske [:Dolske] from comment #1)
> The reason I note this, is that it's probably worth having some form of L10N
> linter to catch this, or else people will constantly forget when adding new
> strings. (Similarly, we should catch "..." instead of a proper ellipsis (…),
> which still happens.) Couple that with doing a 1-time pass to fix all the
> strings, and that would get us into a better state that doesn't just quickly
> start to regress.

Speaking as someone who did it for his own locale a year back, automating and linting might not be that easy. 

There are valid straight quotes in strings (part of HTML code), see for example this very file
https://hg.mozilla.org/mozilla-central/file/b872c30803ef/browser/locales/en-US/chrome/overrides/netError.dtd#l182

There are also DTDs which use straight single quotes as text delimiters instead of double straight quotes. I can think of one in /mobile, not sure if there are others.

It would also be nice to establish a standard for 'quotes' inside a string: is it 'example', "example", “example”?

You can get an idea by spot checking 
http://hg.mozilla.org/mozilla-central/file/tip/dom/locales/en-US/chrome/dom/dom.properties

> [Should check with L10N, but it would be nice to do this as a change only in
> the actual string files without having to change entity/property names.

No need to change string IDs, just fix English. Changing IDs would also basically invalidate half of the translations.
(In reply to Francesco Lodolo [:flod] from comment #11)
> (In reply to Justin Dolske [:Dolske] from comment #1)
> > The reason I note this, is that it's probably worth having some form of L10N
> > linter to catch this, or else people will constantly forget when adding new
> > strings. (Similarly, we should catch "..." instead of a proper ellipsis (…),
> > which still happens.) Couple that with doing a 1-time pass to fix all the
> > strings, and that would get us into a better state that doesn't just quickly
> > start to regress.
> 
> Speaking as someone who did it for his own locale a year back, automating
> and linting might not be that easy. 

I have created such a test that does verify these in bug 1259859 and it is just waiting for review now.
 
> There are valid straight quotes in strings (part of HTML code), see for
> example this very file
> https://hg.mozilla.org/mozilla-central/file/b872c30803ef/browser/locales/en-
> US/chrome/overrides/netError.dtd#l182

The test includes a whitelist for strings where the type of quote is important.

> There are also DTDs which use straight single quotes as text delimiters
> instead of double straight quotes. I can think of one in /mobile, not sure
> if there are others.

The test looks for entities that are defined by either single-quotes or double-quotes.

> It would also be nice to establish a standard for 'quotes' inside a string:
> is it 'example', "example", “example”?
> 
> You can get an idea by spot checking 
> http://hg.mozilla.org/mozilla-central/file/tip/dom/locales/en-US/chrome/dom/
> dom.properties

The test is missing dom.properties right now. I need to figure out how to get a list of .properties files outside /browser, but we can fix those when the test is improved. The general rule here is to use single curly quotes when referring to literals, double curly quotes when referring to a statement, and double straight quotes when referring to a DOM attribute such as the PatternAttributeCompileFailure string in dom.properties.

The test won't be able to differentiate these, and it will be up to us to get these right. As it stands right now in bug 1259859, the quote variants aren't changing from single to double or vice-versa, just from straight to curly unless it makes sense to leave them as-is.

> > [Should check with L10N, but it would be nice to do this as a change only in
> > the actual string files without having to change entity/property names.
> 
> No need to change string IDs, just fix English. Changing IDs would also
> basically invalidate half of the translations.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #12)
> > It would also be nice to establish a standard for 'quotes' inside a string:
> > is it 'example', "example", “example”?
> > 
> > You can get an idea by spot checking 
> > http://hg.mozilla.org/mozilla-central/file/tip/dom/locales/en-US/chrome/dom/
> > dom.properties
> 
> The test is missing dom.properties right now. I need to figure out how to
> get a list of .properties files outside /browser, but we can fix those when
> the test is improved. The general rule here is to use single curly quotes
> when referring to literals, double curly quotes when referring to a
> statement, and double straight quotes when referring to a DOM attribute such
> as the PatternAttributeCompileFailure string in dom.properties.
> 
> The test won't be able to differentiate these, and it will be up to us to
> get these right. As it stands right now in bug 1259859, the quote variants
> aren't changing from single to double or vice-versa, just from straight to
> curly unless it makes sense to leave them as-is.

It would be good to document with examples the expected usages for different cases, as I can see this being pretty confusing to follow (esp. for contributors, but really for everyone) without some list of rules.

Perhaps on https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices or some English specific page.
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #13)
> It would be good to document with examples the expected usages for different
> cases, as I can see this being pretty confusing to follow (esp. for
> contributors, but really for everyone) without some list of rules.
> 
> Perhaps on
> https://developer.mozilla.org/en-US/docs/Mozilla/Localization/
> Localization_content_best_practices or some English specific page.

Thanks. I wrote https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices#Use_Unicode_characters_over_their_ASCII_counterparts_when_possible with details.
You need to log in before you can comment on or make changes to this bug.