830177 - Typographic fix in Account Provisioner labels

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Théo Chevalier]

There are 3 cases in Thunderbird en-US l10n where ’ is used instead of ' , and I assume there is no reason to use it only here.

/mail/locales/en-US/chrome/messenger/newmailaccount/accountProvisioner.dtd 

line 25 -- <!ENTITY partnership.description "In partnership with several providers, &brandShortName; can offer you a new email account. Just fill in your first and last name, or any other words you’d like, in the fields above to get started.">

line 29 -- <!ENTITY content.close "I think I’ll configure my account later.">

line 33 -- <!ENTITY successful.write.desc "Let your friends and family know about your new address.<br/> That’s why you got this new account, isn’t it?">


See also bug 830176 for Firefox

Comment 1

[rsx11m]

Attachment: Use plain apostrophe instead

Agreed that the ASCII version of the apostrophe is used elsewhere. I don't know if using the "pretty" UTF-8 apostrophes may cause any font issues, and I can't quite follow the rationale in bug 771791 that the more complex encoding is preferred from the "code simplicity" point of view.

Anyway, here is the patch - easy fix. The entity names remain unchanged as only the en-US locale is affected here (other locales should decide on their own).

Comment 2

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 702267 [details] [diff] [review]
Use plain apostrophe instead

(In reply to rsx11m from comment #1)
> Agreed that the ASCII version of the apostrophe is used elsewhere. I don't
> know if using the "pretty" UTF-8 apostrophes may cause any font issues, and
> I can't quite follow the rationale in bug 771791 that the more complex
> encoding is preferred from the "code simplicity" point of view.

It’s not from the code-simplicity point of view, but more from the correctness point of view.

> Anyway, here is the patch - easy fix. The entity names remain unchanged as
> only the en-US locale is affected here (other locales should decide on their
> own).

Given that bug 771791 has yet to be decided one way or another, I think we should hold off on making this change.

(The code seems fine, of course, I’m just not sure which way we want to flip the apostrophes. :)

Thanks,
Blake.

Comment 3

[rsx11m]

I understand that, so let's wait for Dão's reply on my bug 771791 comment #6.

> It’s not from the code-simplicity point of view

Which has to be considered though if there are any potential issues with it. I had a couple of content encodings which showed me blank boxes, so I wouldn't like this to spread into the chrome, even if related font issues may be rare.

> but more from the correctness point of view.

Consistently applying en-US typographic rules would have more impact than just the apostrophe, if you want to do it right, and I don't see a reason for that effort.

Comment 4

[:aceman]

It is true that in addition to this special apostrophe there already is a special utf-8 code for ellipsis '...' used throughout the code. I always have problem copying that character. So this apostrophe is only an exception among apostrophes, not among all the other characters.

Comment 5

[rsx11m]

You are correct, of course, though the ellipsis is a different case in that it won't show up as part of a word and thus only would look "funny" but won't make reading the label difficult by impacting individual words.

I was more thinking of opening and closing quotes/double-quotes and ligatures as some other typographic classes that would need to be "corrected" if we start with the apostrophe as a precedent.

Comment 6

[rsx11m]

According to Dão's response in Firefox bug 771791 comment #10 the issue should be restricted to the apostrophe, with reference to the corresponding UTF-8 ellipsis bug 373623 (containing some 100+ comments). A new bug is supposed to be opened for translating ' as ’ while rendering (rather than hard-wiring) the label. This sounds like the better approach but will need some more work, so maybe nothing for the very short term. Disappointingly, no real responses to my questions regarding the justification for such a change or any anticipated possible problems.

Comment 7

[rsx11m]

After having had a look on the Firefox string with my usual desktop settings and seeing an artifact right away (attachment 704846 [details]), I'm strongly opposed against the unconditional change of the ASCII apostrophe to the UTF-8 version.

The following statement made over there applies to this bug as well:

(Quoting my bug 771791 comment #11)
> It appears to me that this bug was mainly opened for reasons of consistency
> (i.e., single usage of the UTF-8 apostrophe), and there would be no harm
> done by simply going for it and correct that single occurrence per current
> policies. Then, if you want the UTF-8 apostrophe or other typographic
> beautifications, clone this bug for each of those to investigate whether
> that specific appearance should be applied (be it by hard-coding or as a
> rendering step, where the latter would certainly be preferable given that
> the user or some desktop/font heuristics can be used to enable or disable
> such effects). Either of those options wouldn't be impaired by just going
> with the patch as posted, thus keeping at least the current state consistent
> until a decision is made.

Comment 8

[rsx11m]

I was able to reproduce the undesirable ’t-"ligature" on another Windows 7 machine with a different graphics card and an XP machine, all with the Windows Classic desktop theme. Thus, my observation wasn't an isolated incident of a specific configuration.

Comment 9

[rsx11m]

It has been three months since this bug was opened and deferred to wait for what Firefox decides in this matter. Well, looking at bug 771791, the last comment (not counting the posts induced from this bug and Dão's non-response to anything related to the issue as such) over there dates more than half a year back. So, question to Blake: How long do you still intend to wait until making up your mind?

We are closing in on the 24.0 cycle, which will determine the strings used for the next year, thus I'd like to have a decision on that. Currently established practice is to use the ASCII apostrophe for labels, thus for reasons of consistency, taking the proposed patch ensures that and resolves accessibility issues with some desktop themes and/or font settings. If at some point UTF-8 apostrophes should become the Mozilla-wide standard, this would need some scripting anyway to catch all occurrences in a single run, thus taking this patch or not won't have any impact whatsoever on such potential future changes.

Comment 10

[rsx11m]

Attachment: Screenshots on Windows Classic

To illustrate the rendering issue seen using the Windows Classic desktop theme with the actual strings used (200% zoom), here a comparison between the current UTF-8 apostrophes (upper row) vs. the ASCII apostrophes (lower row), clearly showing the artifact in the 't and 'l cases.

Comment 11

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 702267 [details] [diff] [review]
Use plain apostrophe instead

Okay, let's take the patch, and hope Firefox fixes this for the next ESR…

Thank you, rsx11m, for pushing on this.

Comment 12

[rsx11m]

Thanks Blake, push for comm-central please.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/54623a361174