User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:126.96.36.199) Gecko/20061204 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:184.108.40.206) Gecko/20061204 Firefox/220.127.116.11 See the Apple Human Interface Guidelines, http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html There is a section: Text >> Style, which is entitled "Using the Ellipsis Character". At the end of this section, it points out the problem with using "dot dot dot", which is that i18n software usually cannot figure it out, where the meaning of an ellipses is clearly defined. Reproducible: Always
Likely, but not certain, to be fixed as part of bug 255051. And they seem to be saying that a11y needs real characters instead of ..., not that i18n does. Though anyone whose biggest hurdle with writing accessibility software is telling the difference between three dots used as an ellipsis and three dots used as, um, a, whatever else you might use them for, has pretty small hurdles.
(In reply to comment #1) > Likely, but not certain, to be fixed as part of bug 255051. This has absolutely nothing to do with bug 255051. It is about using … instead of ... this is mostly an aesthetic difference.
So your theory is that when I finally get tired of waiting for someone to get around to bug 255051 and do it myself, and while I'm looking at every single menu item with an ellipsis anyway I replace the keepers with ellipsis characters, since bsmedberg mentioned in bug 255051 comment 2 that we should, then that will have absolutely nothing to do with this bug? Interesting theory, and well worth the bugspam.
I’m sorry if I wasted your precious time. I am only trying to clear things up a bit: bug 255051 is about checking whether dots/ellipsis are needed at certain places (I do not know the criterion for that), this bug is about how those dots/ellipsis should be typed, *if* they are used. So of course the order in which they are resolved plays a role, but this bug is much easier to fix. In fact I have made a patch already in bug 373623. So no, you do not replace the keepers with an ellipsis, but rather you decide whether they should be there and if they should be there you check for the current guideline on whether ... or … should be used. I hope it will be the latter.
I am seeing that we could change a very few files, such as http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/browser/browser.dtd, to make this change. What would this do on Windows and Linux? Would it cause extra problems? I can see that it would have an effect on the translated strings, but the translations could make the same replacement fairly mechanically.
We really don't need two separate bugs on exactly the same thing: duping forward to the one with the patch.