Follow-up to bug 300578. nb-NO and nn-NO must have a space before the ellipses, so we need to separate it out into it's own entity to prevent an extra space on the end of the toolbar button. I'll attach a patch shortly and we can CC firefoxl10n once we have an acceptable fix.

This was done in bug 298170 to avoid late-l10n issues.

(In reply to comment #1) > This was done in bug 298170 to avoid late-l10n issues. Yes, but now we can fix it for trunk.

I didn't mean to imply otherwise :)

I'm just assuming Robert can review this, but I really don't know.

(In reply to comment #0) > Follow-up to bug 300578. Err.. I meant bug 298170, of course.

I'm cc'ing bsmedburg on this, as through discussion with him on IRC, and via bugzilla, he clarified on hardcoding it. If were changing, I want confirmation that this is the _right_ thing to do (and done for the complete tree). Back during 298170 it was a clear 'no'.

(In reply to comment #6) > Back during 298170 it was a clear 'no'. Based on the discussion in bug 298170; not really a clear "no." Quote bsmedberg in bug 298170 comment 3: "I think that we should do this by adding the ellipsis directly to the XUL, instead of changing the localized entity, to avoid late-l10n problems (AFAIK nobody needs to localize the ellipsis)." So this was done only to avoid late-l10n problems, and he remembered incorrectly -- we need to localize the ellipsis.

Pike's posted to npm.l10n about this: I would like to hardcode the ellipsis in one form or another to make it less error-prone (forgetting the ellipsis on an entity is one of the most common translation errors): if necessary we can use an entity so the menu would look like this: <menu label="&myMenuItem.label;&menu.ellipsis;" /> Where the menu.ellipsis entity is defined in global.dtd or somewhere equally universal.

I agree, but what you're proposing is another bug. I don't want to wait 3 months for the global entity when this can be fixed today.

We can fix the global entity today...

I think this is a much better approach. I'd rather we move reporter towards using the entity.

For the fr-FR locale, we're using \u2026 instead of ..., which is shown differently in the menus (it looks smarter). So there is an inconsistency in the help menu between "Search for updates\u2026" and "Report broken website..." : the three separate dots are bigger than the ellipsis entity. So the global entity seems also a good idea, provided that there is no language requiring a different positioning of the ellipsis.

smontagu: (I'm assuming that the default value of &ellipsis; would be "...\u200e", with a localization note saying "change this to \u200f in RTL") It will fix a lot of bidi problems too.

I think a policy is really needed for ellipses encoding : see bug 348203 which recently did the same error as bug 298170. Now we've got two bad hard coded ellipses in the Tools menu (the second one (in time) still has to be fixed).

Actually, it's bug 337484, but it's not that important.

(In reply to comment #8) > Pike's posted to npm.l10n about this: I would like to hardcode the ellipsis in > one form or another to make it less error-prone (forgetting the ellipsis on an > entity is one of the most common translation errors): if necessary we can use > an entity so the menu would look like this: > > <menu label="&myMenuItem.label;&menu.ellipsis;" /> I wouldn't be surprised if this would just break the other way around, that is, localizers adding the hellip to myMenuItem.label and we'd end up with two of 'em. And I'd feel dirty in hardcoding string compositions in XUL, even if in this case, I can't come up with an counter example.

So this wasn't actually a global i18n bug, but one for the Reporter. Can we leave it at Core/Internationalization anyway, given the last comments?