52978 - Text truncation character should be localizable

Status: RESOLVED DUPLICATE of bug 403484

(Core :: XUL, defect, P3)

Description

[Karl Ove Hufthammer]

When there isn't enough space for a text string, the text is truncated and three
dots added. An example is in the sidebar, where 'My Sidebar' is truncated to 'My
Side...' if you make it very narrow.

The truncation characters '...' (an ellipsis) should be localizable, so other
characters can be used in other languages. For example, in Norwegian, we use a
space in front of the ellipsis (I can use ' ...' as the truncation string).

Comment 1

[tao]

Hi, Robert:


Would you reassign this bug since slamm is no longer here.

Comment 2

[Robert John Churchill]

Don?  Any idea with this one?

Comment 3

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 4

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 5

[msanz]

Will ask pchen to look at this one

Comment 6

[Viswanath Ramachandran]

yes i think this should be an nsbeta1+. 

Comment 7

[Viswanath Ramachandran]

Eric - this looks like it is related to the #define ELLIPSIS "..." in 
nsTextBoxFrame.cpp and nsOutlinerBodyFrame.cpp. I think that to make it 
localizable ELLIPSIS needs to be in a properties bundle file. Should I reassign 
to someone in XPToolkit to do it - or if I could submit a patch - if you can 
point me to the stringbundle file that XPToolkit uses for its localizable 
strings (so that I dont have to figure that out). thanks, Vishy

Comment 8

[Michele Carlson]

This is not high priority. It does not have to be fixed for beta1.

Comment 9

[Jaime Rodriguez, Jr.]

removing nsbeta1 per i18n/l10n triage

Comment 10

[Viswanath Ramachandran]

l12y issue is in XPToolkit -> evaughan. 

Comment 11

[Peter Trudelle]

->arik/moz0.9.2

Comment 12

[arik devens]

where do we keep localizable strings defined?

Comment 13

[arik devens]

ok, so as timeless pointed out ... could be anywhere, in the c++ code, in xul,
or in js where . was concatenated to ...

so while &ellipsis could be useful the more important cases might be dynamic.

so is it a better idea to have ... just be auto translated? what is the right
way to do this?

cc'ing hopefully relevant people

Comment 14

[Karl Ove Hufthammer]

> so is it a better idea to have ... just be auto translated?

What do you mean by «auto translated»?

Comment 15

[arik devens]

well... what timeless was suggesting i think was to have the backend translate
any ... that is used to the localized version so that no matter where it comes
from it gets translated, a bit of a hack really.

not sure that's such a good idea but i'm not sure what the correct way to do
this is...

Comment 16

[Karl Ove Hufthammer]

> well... what timeless was suggesting i think
> was to have the backend translate
> any ... that is used to the localized version
> so that no matter where it comes
> from it gets translated, a bit of a hack really.

And it won't work. For example, it would translate [...] to [ ...], which is 
wrong. Anyway, it would probably make Mozilla a bit slower if it should 
replace "..." with another string for *every* string displayed in the browser. 
Yes, it's an ugly hack

Comment 17

[timeless]

it would only affect chrome... i don't see why "..." would become " ..." 
although you could argue that's correct ("...." is the case where you have the 
end of a sentence and shouldn't preceded it w/ a space, but no one cares about 
English =). ok so i reread the original request where " ..." is the swedish 
form.

Why would you exepct [...] not to mean ellipsis/truncation?

Comment 18

[Karl Ove Hufthammer]

> it would only affect chrome... i don't see
> why "..." would become " ..."

This bug is about *localization*, not the default ('en-US' locale) behaviour.
The text truncation character used at the end of menu-items, status bar message
&c. should be localizable.

> although you could argue that's correct ("...." is the case
> where you have the end of a sentence and shouldn't preceded
> it w/ a space, but no one cares about 
> English =).

As far as I can see, different style guides recommend different ways of dealing
with sentences that end with a period.

> ok so i reread the original request where " ..." is the swedish 
> form.

Norwegian. And other languages may use other characters, e.g. U+0EAF.

> Why would you exepct [...] not to mean ellipsis/truncation?

It *would* mean truncation, but should still be localizable. E.g., in Norwegian
and English [...] is used, but other languages may use other ways of indicating
omittance in the middle of sentences.

Comment 19

[timeless]

excuse me for the norwegian faux pax.

> It *would* mean truncation, but should still be localizable.
> E.g., in Norwegian and English [...] is used,
> but other languages may use other ways of indicating
> omittance in the middle of sentences.
if you want [...] localizable then i don't see why you're objecting to the 
backend brute force replacement.

Comment 20

[Peter Trudelle]

No longer fits the profile for 0.9.2, ->0.9.3, could still take a fix in 'limbo'

Comment 21

[Karl Ove Hufthammer]

> if you want [...] localizable then i don't see why
> you're objecting to the 
> backend brute force replacement.

In Norwegian ' ...' is used at the end of sentences. If the string '...' were 
made "so that no matter where it comes from it gets translated", [...] would be 
changd to [ ...], which is wrong ([...] isn't currently used anywhere in 
Mozilla, but it could be in the future). The right way to do this, is to create 
an external entity in a DTD file for the string that should be used at the end 
of menu-items and status bar messages.

Comment 22

[timeless]

ok, so is the truncation character different from the ellipsis character?

i'm very confused. i need a picture of norwegian, please use red circles and 
draw lines explaining everything (actually just footnote and comment in the bug 
explaining the footnotes -- english explanations please)

Comment 23

[bobj]

> ok, so is the truncation character different from the ellipsis character?

We should use a truncation "string" not "character".  The difference would
impact the implementation.

As noted in previous comments, Norwegian, needs at least 2 characters: a space
followed by an ellipsis.

Even though ellipsis is used in Japanese, Japanese fonts may not include an
ellipsis character.  Mozilla will probably find an ellipsis from another font,
but it may not look nice if the point size don't quite match, etc.  So a
localizer might choose to use 3 periods instead for Japanese.

Comment 24

[arik devens]

so i still have no idea how best to fix this... maybe i should reassign to
someone more interested/knowledgeable in localization problems?

Comment 25

[Hixie (not reading bugmail)]

[e-mail] is no longer @netscape.com, so moving this out to 0.9.4.

trudelle: Should this be reassigned?

Comment 26

[John Morrison]

Throwing this fish back in the pool for reassignment. ->trudelle, unset 
milestone.

Comment 27

[Andreas Becker]

mass change, switching qa contact from jonrubin to ruixu.

Comment 28

[Peter Trudelle]

->hyatt

Comment 29

[Cindy Roberts]

Marking nsbranch- as it was decided in the August bug triage that we wouldn't
have enough time in eMojo to fix this.  Let's revisit for MachV.

Comment 30

[elaineking]

removed keyword nsbranch since it now has nsbranch-, per pdt mtg.

Comment 31

[Michele Carlson]

ruixu - is this still an issue? Please update us on your findings. thanks

Comment 32

[Rui Xu]

The problem still exists and there might be more related cases: 

1. The same problem happens with the title string in title bar when browser window is narrowed.
2. For button names, ellipses are used to indicate it can bring up a dialog box.
3. Same with menu items, ellipses are used to indicate it can bring up a dialog box.
4. The bookmarks use ellipses to indicate the string is not fully displayed.
5. The tabs in My Sidebar use ellipses to indicate the tab string is not fully displayed.

Comment 33

[Jaime Rodriguez, Jr.]

nominating as this is still a localizability issue. 

is there a possibility that i18n or l10n can take ownership of this one?

Comment 34

[Peter Trudelle]

nsbeta1- per nav triage team

Comment 35

[Karl Ove Hufthammer]

> 2. For button names, ellipses are used to
> indicate it can bring up a dialog box.
> 3. Same with menu items, ellipses are used to indicate
> it can bring up a dialog box.

These two are not an issue, as the ... are already localizable for buttons and menu (they're included in button/menu name).

The other points are (1, 4 and 5) are still valid.

Comment 36

[David Hyatt]

--> default owner

Comment 37

[Simon Montagu :smontagu]

Forward duping to bug 403484, which has patches.