User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Now, some UI uses "…" in button's caption, and some UI uses "...". I think they should be consistent. Reproducible: Always Steps to Reproduce: 1.Open "Certificate Manager" or "Manage CRLs". (Tools > Option > Advanced > Encryption > View Ceritificates / Revocation lists) 2.Check buttons' caption. 3. Actual Results: "Certificate Manager" and "Manage CRLs" uses "…". But other UI seems to use "...". Expected Results: They should be consistent. In some font (i.e. Windows XP - Japanese - "MS UI Gothic" ), Difference between "…" and "..." is not small. (see screenshot)

Probably a duplicate of bug 373623, but the bug is trying to fix a moving target. These 'exceptions buttons were only recently added in bug 387480. I think we need to get in bug 373623 fast, then mop up all the loose ends.

When using Trunk on Japanese WindowsXP, "…" in buttons' caption seems to be VERY STRANGE in Japanese Windows. There are 2 reasons. 1.I have NEVER seen other than Minefield that uses "…" instead of "..." in Command Button at Japanese Windows. 2.In Japanese Standard UI Font (MS UI Gothic) it breaks UI balance. Width od dots in "…" is same as BOLD CHARACTER's line width. So, It is TOO LARGE. I agree "…" is better than "..." in some language/locale/OS. But in some language/locale/OS, it is not better. I think this is Language, Locale and OS dependent issue.

(In reply to comment #3) > Width od dots in "…" is same as BOLD CHARACTER's line width. Sorry, "od" is typo of "of".

And with Japanese fonts, "…" looks like three MIDDOLE DOTs. So, not three periods.

s/MIDDOLE/MIDDLE

(In reply to comment #5) > And with Japanese fonts, "…" looks like three MIDDOLE DOTs. So, not three > periods. Sounds like a feature, not a bug.

(In reply to comment #7) > (In reply to comment #5) > > And with Japanese fonts, "…" looks like three MIDDOLE DOTs. So, not three > > periods. > > Sounds like a feature, not a bug. I don't think so, because many native applications of Win32 use three periods. So, our current looks of UIs are not natural for Japanese people. # some users are objecting to this changing in Japan.

(In reply to comment #8) > So, our current looks of UIs are not natural for Japanese people. The ellipsis is semantically correct -- So if it doesn't look natural (regardless of other applications using three dots) that would be a bug in the font.

(In reply to comment #9) > The ellipsis is semantically correct -- So if it doesn't look natural > (regardless of other applications using three dots) that would be a bug in the > font. I agree to the semantics of Unicode. However, I think this is really our issue, because our product is just a member of the OS, the members should use common rules on a system.

I get what you mean, but strictly speaking there isn't such a rule -- besides Apple saying the Unicode character should be used.

(In reply to comment #11) > I get what you mean, but strictly speaking there isn't such a rule -- besides > Apple saying the Unicode character should be used. Yeah, I don't find UI design guide lines. Why all win32 application are using "..." for the menus and the buttons which bring up the dialogs? Japanese Windows also has western fonts, so, if "…" is a independent element, we can specify the western fonts only for "…". # Should I file a new bug for this issue?

(In reply to comment #12) > Yeah, I don't find UI design guide lines. Why all win32 application are using > "..." for the menus and the buttons which bring up the dialogs? Because it's easier to type and developers tend to take the easy way. Firefox pretty much pioneers here. > Japanese > Windows also has western fonts, so, if "…" is a independent element, we can > specify the western fonts only for "…". > # Should I file a new bug for this issue? I don't know. It doesn't sound right to me, the Japanese ellipsis must look like that for a reason.

(In reply to comment #3) > When using Trunk on Japanese WindowsXP, > "…" in buttons' caption seems to be VERY STRANGE in Japanese Windows. > There are 2 reasons. The third reason is that you're using the en-US locale. Windows' Japanese font was obviously not designed for that. I think the mid dots actually make sense with Japanese character, but then I'm not a Japanese.

(In reply to comment #13) > (In reply to comment #12) > > Yeah, I don't find UI design guide lines. Why all win32 application are using > > "..." for the menus and the buttons which bring up the dialogs? > > Because it's easier to type and developers tend to take the easy way. Firefox > pretty much pioneers here. er, a Japanese contributor (Kimura-san) found the guide lines: http://msdn2.microsoft.com/en-us/library/ms997491.aspx http://msdn2.microsoft.com/en-us/library/ms997617.aspx These documents said that the applications should use "…" for the menus/buttons. However, the latest applications of MS doesn't use "..." too :-( > the Japanese ellipsis must look like that for a reason. Yes. The the dots of Japanese ellipsis should be middle of line. So, it is impossible the ellipsis of Western and the one of Japanese are same glyph.

> the latest applications of MS doesn't use "..." too er, it's wrong. "the latest applications of MS use "..." too." ^^^^^

(In reply to comment #14) > (In reply to comment #3) > > When using Trunk on Japanese WindowsXP, > > "…" in buttons' caption seems to be VERY STRANGE in Japanese Windows. > > There are 2 reasons. > > The third reason is that you're using the en-US locale. Windows' Japanese font > was obviously not designed for that. I think the mid dots actually make sense > with Japanese character, but then I'm not a Japanese. the Ellipsis of menus/buttons can be replaced to "..." at localization? if so, we don't have the problems on menus/buttons.

(In reply to comment #17) > the Ellipsis of menus/buttons can be replaced to "..." at localization? if so, > we don't have the problems on menus/buttons. I think you should use the Unicode character consistently.

I tend to call this a layout problem. It seems that the ellipsis should be rendered at a different height in an latin and in an japanese script context. CCing some folks that might be able to help. Note, I have no idea how to produce a test case for this, other than selecting Japanese as your windows language and to continue to use an en-US build. I'll attach a small xul-let anyway, with two labels, one English, one Japanese, both ending in a unicode ellipsis.

FYI: If you use Non-Japanese Windows XP/Vista, you can download Microsoft Japanese Font(based on JIS 2004) from: 32bit: http://go.microsoft.com/fwlink/?LinkId=82599 x64: http://go.microsoft.com/fwlink/?LinkId=82601 IA64: http://go.microsoft.com/fwlink/?LinkId=82603 Or, You may able to download Japanese via IE. ( I cannot test because my Windows is japanese-edition) 1. Enable "download font" 2. Set primary language to "ja" (japanese) 3. Go to Japanese site like http://www.mozilla-japan.org

If font of all horizontal ellipsis can be changed by userChrome.css or Language Pack without changing other text's font, we can fix font design issue. But it needs idential class-id for horizontal ellipsis. Is it difficult? -- example of ui description--- <list-item>long croped text is<span class="ui-ellipsis">…</span></listitem> -- example of userChrme.css -- ui-ellipsis { font-family: Verdana; } -- end example --

So, this is actually easy to reproduce, this is just an HTML file with one span in Times New Roman, and one in MS UI Gothic. The bug is really that we use MS UI Gothic for something that looks like x-western to me. I really don't know anything about our font selection, so I can only guess this far.

I presume we're falling back to MS UI Gothic because Times New Roman doesn't have a glyph for Unicode ELLIPSIS, but MS UI Gothic does. I *suppose* we could hack glyph conversion and font selection so that if a font is missing a glyph for ELLIPSIS but has a glyph for '.', then instead of falling back to another font, we convert the ELLIPSIS to '...' instead. But that sounds like a fairly hefty hack and I'm not even sure it would fix this bug for Japanese users ... would it?

Would it help to add a non-sucky font with the ellipsis to font.name.serif.x-western (and possibly the other ones that use Times New Roman only)? Well, name -> name-list, too, I guess. No idea if that'd be perf sensitive.

Yes, that probably would help (presuming users actually have the font, of course).

The glyph replacing is not good... Because the default font for UI on Win-Ja is MS UI Gothic, so it has Unicode ELLIPSIS.

OK, I'm getting confused. It seems there are two problems being talked about in this bug: 1) The "Exceptions..." button label (and possibly other UI text) is using three dots while most other UI text uses ELLIPSIS, and we should be consistent. 2) Some people don't like the way MS UI Gothic renders ELLIPSIS. I suggest we fix 1) by making "Exceptions..." and whatever else is using three dots use ELLIPSIS. I'm not sure if we should fix 2). If we want to fix it, I would suggest modifying gfxWindowsFonts's glyph conversion so that an ellipsis that follows a Latin character is rendered as three dots. This should be spun off into a new bug since this bug as filed is about problem 1), the inconsistency.

(In reply to comment #28) > 1) The "Exceptions..." button label (and possibly other UI text) is using three > dots while most other UI text uses ELLIPSIS, and we should be consistent. Labels and trees use ellipsis (bug 390282), but most of the en-US locale strings are still using three dots. > I suggest we fix 1) by making "Exceptions..." and whatever else is using three > dots use ELLIPSIS. -> bug 373623 > I'm not sure if we should fix 2). If we want to fix it, I would suggest > modifying gfxWindowsFonts's glyph conversion so that an ellipsis that follows a > Latin character is rendered as three dots. Well, one reason for switching to the ellipsis character was to get the more optimized rendering that fonts provide; converting them to three single dots seems backwards.

> Well, one reason for switching to the ellipsis character was to get the more > optimized rendering that fonts provide I don't think performance will be any different. We should do it because we can get better rendering in some cases and because ELLIPSIS is more semantically meaningful than three dots. So I'll make this depend on bug 373623, and someone who cares should file a new bug on the glyph conversion of ELLIPSIS to three dots when it follows a Latin character. Then we can discuss there whether that's a good idea.

(In reply to comment #30) > > Well, one reason for switching to the ellipsis character was to get the more > > optimized rendering that fonts provide > > I don't think performance will be any different. We should do it because we can > get better rendering in some cases and because ELLIPSIS is more semantically > meaningful than three dots. That wasn't about performance at all, I mean optimized as in "looks better". And yes, semantics was the second argument ...

(In reply to comment #28) > 2) Some people don't like the way MS UI Gothic renders ELLIPSIS. ... > If we want to fix it, I would suggest > modifying gfxWindowsFonts's glyph conversion so that an ellipsis that follows a > Latin character is rendered as three dots. Mind you, for Japanese users that would only make a difference if the don't use the Japanese locale, so I think it's kinda pointless.

I can't think of any reason in the world this should block firefox 3 when we've always used dots in the past...

Wait, we don't want to convert Unicode ELLIPSIS to three dots on all cases. We only want to change to three dots in menus, buttons, label of tabs and tree items. I think this should/can not be fixed on gfx level. And we need to ask to Asai-san who is Japanese localizer. Asai-san: What do you think about this issue? If you think that this bug should not be fixed, we don't need to fix this bug.

(In reply to comment #34) > Wait, we don't want to convert Unicode ELLIPSIS to three dots on all cases. We > only want to change to three dots in menus, buttons, label of tabs and tree > items. Why should they be treated differently from ELLIPSIS everywhere else?

(In reply to comment #35) > (In reply to comment #34) > > Wait, we don't want to convert Unicode ELLIPSIS to three dots on all cases. We > > only want to change to three dots in menus, buttons, label of tabs and tree > > items. > > Why should they be treated differently from ELLIPSIS everywhere else? The *win32* native applications which are localized to Japanese are using three dots instead of ELLIPSIS in UI. So, the all applications on Win32-Ja don't prefer to use ELLIPSIS even though the UI guide line prefers to use ELLIPSIS. I think that this is a tradition in Ja localizers. (for compatibility with old applications?) However, the dots of the ELLIPSIS of Japanese language should be middle of the line, so, the three dots on base is not good for Japanese text. (I think that the "Western" ELLIPSIS and Japanese ELLIPSIS should not be a same code point...)

So the real problem is with the Japanese localization? Then the original screenshot was misleading. How about if we implement text-overflow, do we want to use ELLIPSIS or three dots there? I think making chrome behave differently from content is going to be troublesome in general. How bad is it if we just use ELLIPSIS in chrome, so it's consistent with content, and hope Japanese users to get used to it? Once they get used to it they might think the consistency is a good thing...

(In reply to comment #37) > So the real problem is with the Japanese localization? Then the original > screenshot was misleading. Probably, it is most simple resolution if we can fix at localizing. However, the label of XUL and the tree item of XUL needs to change, ELLIPSIS in them is hard coded. > How about if we implement text-overflow, do we want to use ELLIPSIS or three > dots there? I think making chrome behave differently from content is going to > be troublesome in general. No, the ELLIPSIS in menus/buttons doesn't mean overflow. It means they bring up the dialogs.

(In reply to comment #38) > (In reply to comment #37) > > So the real problem is with the Japanese localization? Then the original > > screenshot was misleading. > > Probably, it is most simple resolution if we can fix at localizing. However, > the label of XUL and the tree item of XUL needs to change, ELLIPSIS in them is > hard coded. > > > How about if we implement text-overflow, do we want to use ELLIPSIS or three > > dots there? I think making chrome behave differently from content is going to > > be troublesome in general. > > No, the ELLIPSIS in menus/buttons doesn't mean overflow. It means they bring up > the dialogs. But it means overflow in the tree and label case, and you claim they need to change.

(In reply to comment #39) > > No, the ELLIPSIS in menus/buttons doesn't mean overflow. It means they bring up > > the dialogs. > > But it means overflow in the tree and label case, and you claim they need to > change. Yes. The ELLIPSIS should be got from the localizable pref. It's easy.

(In reply to comment #40) > It's easy. Well, then, write a patch? :) I still think we should simply use the ellipsis character in all cases (layout and locales), but I guess a pref for label, tree and text-overflow:ellipsis wouldn't hurt.

> a pref for label, tree and text-overflow:ellipsis wouldn't hurt. It could be confusing when someone uses text-overflow:ellipsis in a regular Web page and it doesn't give them an actual elllipsis. I would be happier if we used ellipsis everywhere. Is it really important to copy the limitations of an older generation of software?

I opened a separate discussion on what's the right rendering of the ellipsis in different scripts out to the newsgroup, this bug is taking a few more turns than I can grok. Anyway, I'm rather sure that this is not an l10n problem, but an intl problem. We should render the ellipsis right, independent of application and OS locale settings. Filed bug 401364 on that. Once that is done, whether we use ... or &hellip; is just a polish fix, what it should be.

The basic problem here is wrongly analyzed I believe. If you use a japanese font to render western text, you will get a degraded result, with some character that are not displayed using the prefered glyph for the script, just like happens when you use a chinese font to render japanese text. I'm now convinced the real bug is that when using an english localized Fx under a japanese localized OS, Fx better should use the western preferred fonts to display menus and buttons, and not the OS inherited UI fonts (that are configured at the OS level in "Display properties"/"Appearance"). This is a problem that exist since very long, but only becomes really annoying when you start using in the interface some of the characters that look really bad when you don't use the correct font.

It's not so, Japanese people don't want to use Japanese ELLIPSIS glyph in UI (excepting the ELLIPSIS is a Japanese ELLIPSIS in the context of the label), not only with English UI.

(In reply to comment #45) Masa, this is an answer to both your comment here and in bug 401364. IMO you are looking at this problem with the wrong assumptions. You are running an *english* application under your japanese OS and expecting it to "look right". This *can* *not* *work* perfectly, and never has. Now, the thing is that until now english users with the english localisation of the application only used very basic characters that look about right when displayed with a japanese font. But now, they wish to use the typographically correct character for the ellipsis, U2026, and the problem, that already existed, becomes very visible because U2026 looks very different when displayed with a japanese font and with an english font. The initial request of using three dots instead of the ellipsis made as little sense as if I were running a japanese application under my english OS, seeing western ellipsis instead of a japanese ellipsis, finding it ugly, and asking you to replace the japanese ellipsis in the japanese localization with three middle dot characters U+00B7, so that it will look better on my english system. Japanese people run the japanese localization of firefox. What you are complaining about is the english localization of firefox, whose primary users are english people running under an english OS. Now it would be great if the english localization could still display perfectly under a japanese OS. But if so, then let's focus on the real problem, finding a way to make sure the english localization will favor english font for UI display, even if the OS provided UI fonts are japanese, rather than to have tunnel vision and thinking wrongly it's all about the ellipsis character.

In comment #37 I asked if this was a problem in the Japanese localization. I thought comment #38 meant the answer was "yes". Now I'm not so sure. So let's ask again: Is this bug a problem in the Japanese localization?

This issue is reproduced on Fx2.0.0.8-JA (on XUL labels, e.g., the caption of the tabs) too, not only on English applications. And We have complaint from user communities. Why this change which has *big* impact is landed to 1.8.1 branch? I rewrite same idea; if we are allowed to use three dots instead of ELLIPSIS in Fx-JA at localizing, this issues will be gone easily I think. (but we need the patch for comment 40)

(In reply to comment #48) > This issue is reproduced on Fx2.0.0.8-JA (on XUL labels, e.g., the caption of > the tabs) too, not only on English applications. And We have complaint from > user communities. Why this change which has *big* impact is landed to 1.8.1 > branch? Approval for 1.8.1 was requested by the Calendar guys. The problem on branch is that *only* trees and labels use the Unicode character, while locale strings use three dots. So I see how that makes a bad UI especially with the Japanese locale.

(In reply to comment #48) > This issue is reproduced on Fx2.0.0.8-JA (on XUL labels, e.g., the caption of > the tabs) too, not only on English applications. And We have complaint from > user communities. Why this change which has *big* impact is landed to 1.8.1 > branch? That was approved in bug 390282. > I rewrite same idea; if we are allowed to use three dots instead of ELLIPSIS in > Fx-JA at localizing, this issues will be gone easily I think. (but we need the > patch for comment 40) Sorry, but that is wrong. Please see the discussion in .i18n, http://groups.google.com/group/mozilla.dev.i18n/browse_frm/thread/e6ada0f8e9cc040f/7de860a422178a44#7de860a422178a44. I'm with Jean-Marc's comment 46 here. I'm not sure how to do OS consistency and UI consistency and correct layout of ellipsis in the tab strip here. Right now, I tend towards a more or less hidden pref to ignore OS font wishes, but that doesn't make me any more happy. The picture in my head is a browser windows with a bunch of tabs, thus cropping, one tab with a Japanese title, one with a hebrew title, one with an English title, one with a Chinese title... you get the idea.

We should fix the 'use ellipsis everywhere' bug. This is much less clear, and doesn't seem to be worth blocking on.

(In reply to comment #50) > (In reply to comment #48) > > I rewrite same idea; if we are allowed to use three dots instead of > > ELLIPSIS in > > Fx-JA at localizing, this issues will be gone easily I think. (but we need > > the patch for comment 40) > > [...] > > I'm with Jean-Marc's comment 46 here. Well, we are less in agreement than you think :-) I hadn't seen comment #38 initially, especially this sentence : "the label of XUL and the tree item of XUL needs to change, ELLIPSIS in them is hard coded." In fact on that point I agree with Masa. It's not a good thing to hardcode anything in the interface, so XUL elements should not contain any hardcoded text, and the japanese localizers are right to request to be able to replace that text in the JA localization.

So, there are two use cases here, one is the ellipsis for "further action required", at which point, the ellipsis is part of the UI label, and as such, part of the localization effort. In this particular case, we know the language of the content, we sadly don't seem to know the font, though. The other is added by layout for cropped content. For content in content, we know the font, for content in chrome, we seem not to. We don't know the language in either case, I think pretty much in general. As we don't know the language, this one is independent of l10n, but intl. If we have a grip on the second one, the first one will just pop, I think. If we'd just intend to solve the first one as an l10n issue, we had to ban the ellipsis char from our UI consistently, AFAICT.

(In reply to comment #48) > This issue is reproduced on Fx2.0.0.8-JA (on XUL labels, e.g., the caption of > the tabs) too, not only on English applications. And We have complaint from > user communities. Why this change which has *big* impact is landed to 1.8.1 > branch? I guess noone expected it to actually have that big impact... > I rewrite same idea; if we are allowed to use three dots instead of ELLIPSIS in > Fx-JA at localizing, this issues will be gone easily I think. (but we need the > patch for comment 40) This should probably be an additional localizable string in the toolkit. Is that what you meant? BTW, does the ellipsis you see in MS UI Gothic (three middle dots) actually have any tradition where it's used in Japanese language?

Hi all, please let me talk about this as a Japanese l10n lead. This my post will be a little long and I first write in short: What Japanese users want: View three dots on the bottom of the line in the UI (menu/button/tab/tree...) Allow localizers select ellipsis or three periods to to that Current griph selection of ellipsis need not changed As Masayuki explained and you already understood, griph of ellipsis will be three dots in the middle of the line vertically with many Japanese fonts and it looks quite funny if ellipsis is used at the end of alphabet. But, what we need is *not* to output different griph of ellipsis depending on the context (if preceding characters are alphabet or Japanese). Even when the ellipsis is appeared after Japanese characters, many Japanese users will feel discomfort since all the other standard Japanese software UIs (including MS/Apple software) are using three periods (dots on the bottom of the line). # three periods is standard in Japanese UI On the other hand concerning text in the Japanese contents (non UI part), ellipsis should be rendered as three dots in the middle (not depending on the context). In Japanese environment, writers know/believe ellipsis will be shown as three dots in the middle and they choice ellipsis or three periods properly. That is, ellipsis used in the Japanese page means that writer want three dots in the middle their. We will be confused if griph of ellipsis will be depends on the context. That is, we need to view three periods in the every UI but not need to change current behavior about ellipsis. Contents writers are already accustomed with current behavior (same behavior as other applications like Word etc). They can specify charcter encoding and font of the page if they want to select the griph of the ellipsis. This is problem of only UI and we should not hack gfx/xul code, which will be used in contents part too. To make us possible to view three periods in Japanese UI without hack gfx/xul code, making the character for the UI selectable as Masayuki say in comment #40 is only realistic answer I think. Localizer know about what should be used there in their language and all we need to do is just make localizer possible to select ellipsis or three periods for UI as Jean-Marc also agreed in comment #52. (In reply to comment #53) > So, there are two use cases here, one is the ellipsis for "further action > required", at which point, the ellipsis is part of the UI label, and as such, > part of the localization effort. In this particular case, we know the language > of the content, we sadly don't seem to know the font, though. What we should do here is select griph depending on UI language, that is locale. If we require all locale use ellipsis or output ellipsis in the hard corded part, we need font or some complex hack but if localizer can select to use ellipsis or three periods, don't need to care about font of the ellipsis. > The other is added by layout for cropped content. For content in content, we > know the font, for content in chrome, we seem not to. We don't know the > language in either case, I think pretty much in general. As we don't know the > language, this one is independent of l10n, but intl. Concerning about content part, when Japanese (Korean/Chinese too?) user see the western contents containing ellipsis we feel discomfort. To solve this, we need to control the griph (rendering) of the ellipsis depending on the language/font of the content. But if the page contain both English/Japanese, we cannot detect content language and where should be fixed even when we can know font and user language. In that case, contents writers will control it. To allow writers control it, we should not control griph of the ellipsis depending on language or font. That is, it's impossible to detect the context of each ellipsis is English or Japanese (and what writer want) and we should not change current behavior I think. > If we have a grip on the second one, the first one will just pop, I think. If > we'd just intend to solve the first one as an l10n issue, we had to ban the > ellipsis char from our UI consistently, AFAICT. We need not hack gfx xul behavior to solve first one for l10n issue. If we make localizer possible to select use ellipsis or periods, behavior of ellipsis need not changed. Then first one (UI part problem) will be fixed not depending on content part (second one). Second one cannot solved I think (when contents contains both English/Japanese). So, what we should do is just solve first one as an l10n issue by allowing localizer select ellipsis or three periods I believe.

(In reply to comment #54) > > This issue is reproduced on Fx2.0.0.8-JA (on XUL labels, e.g., the caption of > > the tabs) too, not only on English applications. And We have complaint from > > user communities. Why this change which has *big* impact is landed to 1.8.1 > > branch? > > I guess noone expected it to actually have that big impact... Not big impact as a code but enough big impact of *user experience* of Japanese users. Tab and tree is main part of UI and if uses feel discomfort about their appearance, they will feel Firefox is poor. *Actually* many Japanese users are feeling the change is poor and complaining about it. That's because this bug is opened and I and Masayuki is working on this. > > I rewrite same idea; if we are allowed to use three dots instead of ELLIPSIS in > > Fx-JA at localizing, this issues will be gone easily I think. (but we need the > > patch for comment 40) > > This should probably be an additional localizable string in the toolkit. Is > that what you meant? No, if we define new pref for this and set default value of it as ellipsis, no new entity required. Only ja/ja-JP-mac (and if some other language want too) should add pref in l10n.js. Other language need not do anything. > BTW, does the ellipsis you see in MS UI Gothic (three middle dots) actually > have any tradition where it's used in Japanese language? Yes. In Japanese tradition, ellipsis should be in the middle. Only Japanese tradition about software UI is different and that's why we want only change about UI part.

(In reply to comment #56) > > > I rewrite same idea; if we are allowed to use three dots instead of ELLIPSIS in > > > Fx-JA at localizing, this issues will be gone easily I think. (but we need the > > > patch for comment 40) > > > > This should probably be an additional localizable string in the toolkit. Is > > that what you meant? > > No, if we define new pref for this and set default value of it as ellipsis, no > new entity required. Only ja/ja-JP-mac (and if some other language want too) > should add pref in l10n.js. Other language need not do anything. Actually, I'd still go with an entity, unless you have more reasons than simply not bothering other localizations. > > BTW, does the ellipsis you see in MS UI Gothic (three middle dots) actually > > have any tradition where it's used in Japanese language? > > Yes. In Japanese tradition, ellipsis should be in the middle. Only Japanese > tradition about software UI is different and that's why we want only change > about UI part. Hmm... interesting. Just a purely hypothetical question – would the users still feel uncomfortable if most of their UIs would switch to the Japanese ellipsis?

Thank you, Asai-san. (In reply to comment #57) > Hmm... interesting. Just a purely hypothetical question – would the users > still feel uncomfortable if most of their UIs would switch to the Japanese > ellipsis? Probably, Yes. I think many Japanese people thinks that the Japanese ELLIPSIS and Western ELLIPSIS are different character. So, many Japanese users cannot understand why the three dots (Western ELLIPSIS) is replaced to Japanese ELLIPSIS. (And the Japanese ELLIPSIS is not match in Japanese UI with traditional reasons.)

The XUL label and tree code need access to this and for them, using a pref is easier than using an entity.

So we either need to renominate this for Fx3 (or more precisely Gecko 1.9) or get a bug filed to have the ellipsis localizable (and make that blocking 1.9)?

(In reply to comment #60) > So we either need to renominate this for Fx3 (or more precisely Gecko 1.9) or > get a bug filed to have the ellipsis localizable (and make that blocking 1.9)? I filed bug 403484 for the localizable issue.

Isn't this fixed now ?

(In reply to comment #62) > Isn't this fixed now ? > I think this bug can be changed to FIXED. because Bug 403484 is fixed. Nakano-san, Asai-san, how dou you think about it ?

right, this was fixed already. -> FIXED