Closed
Bug 1151449
Opened 9 years ago
Closed 8 years ago
Use curly quotes and apostrophes instead of straight quotes in error pages
Categories
(Firefox :: General, enhancement, P5)
Tracking
()
RESOLVED
FIXED
Firefox 48
Tracking | Status | |
---|---|---|
firefox48 | --- | fixed |
People
(Reporter: rfeeley, Assigned: ktbee, Mentored)
References
Details
(Whiteboard: [qx:spec][outreachy-12])
Attachments
(2 files, 1 obsolete file)
78.16 KB,
image/png
|
Details | |
11.01 KB,
patch
|
jaws
:
review+
|
Details | Diff | Splinter Review |
For more information see Wikipedia or: * http://practicaltypography.com/straight-and-curly-quotes.html and * http://practicaltypography.com/apostrophes.html
Reporter | ||
Updated•9 years ago
|
Whiteboard: [qx]
Reporter | ||
Updated•9 years ago
|
Whiteboard: [qx] → [qx:spec]
Comment 1•8 years ago
|
||
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]
Reporter | ||
Comment 2•8 years ago
|
||
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)
Updated•8 years ago
|
Priority: -- → P5
Updated•8 years ago
|
Reporter | ||
Comment 3•8 years ago
|
||
Attachment #8588583 -
Attachment is obsolete: true
Reporter | ||
Comment 4•8 years ago
|
||
Related: http://smartquotesjs.com/
Updated•8 years ago
|
Mentor: jaws
Whiteboard: [qx:spec] → [qx:spec][outreachy-12]
Updated•8 years ago
|
Points: --- → 1
Assignee | ||
Comment 5•8 years ago
|
||
Attachment #8734583 -
Flags: review?(jaws)
Updated•8 years ago
|
Assignee: nobody → kbroida
Status: NEW → ASSIGNED
Comment 6•8 years ago
|
||
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+
Comment 7•8 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/b872c30803efac37977230476c63586e3196c1db Bug 1151449 - Use curly quotes and apostrophes on the network error pages. r=jaws
Comment 8•8 years ago
|
||
I filed bug 1259847 for the other files and included a patch there.
Comment 9•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b872c30803ef
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Comment 10•8 years ago
|
||
Congrats on fixing your first Firefox bug Katie. Your changes should show up in tomorrow's Nightly build.
Comment 11•8 years ago
|
||
(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.
Comment 12•8 years ago
|
||
(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.
Comment 14•8 years ago
|
||
(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.
Description
•