Closed Bug 52978 Opened 19 years ago Closed 12 years ago

Text truncation character should be localizable

Categories

(Core :: XUL, defect, P3, major)

defect

Tracking

()

RESOLVED DUPLICATE of bug 403484
Future

People

(Reporter: karl, Assigned: jag+mozilla)

References

(Blocks 1 open bug)

Details

(Keywords: l12y)

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).
Hi, Robert:


Would you reassign this bug since slamm is no longer here.
Assignee: rchen → rjc
Status: UNCONFIRMED → NEW
Ever confirmed: true
Don?  Any idea with this one?
Assignee: rjc → don
Keywords: mozilla1.0
Blocks: 12394
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
Keywords: l12y
Changed QA contact to andreasb@netscape.com.
QA Contact: teruko → andreasb
Will ask pchen to look at this one
Keywords: nsbeta1
yes i think this should be an nsbeta1+. 
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
This is not high priority. It does not have to be fixed for beta1.
QA Contact: andreasb → jonrubin
removing nsbeta1 per i18n/l10n triage
Keywords: nsbeta1
Blocks: 66555
Blocks: 72798
l12y issue is in XPToolkit -> evaughan. 
Assignee: vishy → evaughan
Component: Localization → XP Toolkit/Widgets
->arik/moz0.9.2
Assignee: evaughan → arik
Target Milestone: --- → mozilla0.9.2
where do we keep localizable strings defined?
Status: NEW → ASSIGNED
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
> so is it a better idea to have ... just be auto translated?

What do you mean by «auto translated»?
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...
> 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
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?
> 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.
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.

No longer fits the profile for 0.9.2, ->0.9.3, could still take a fix in 'limbo'
Target Milestone: mozilla0.9.2 → mozilla0.9.3
> 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.
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)
> 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.
so i still have no idea how best to fix this... maybe i should reassign to
someone more interested/knowledgeable in localization problems?
arik@netscape.com is no longer @netscape.com, so moving this out to 0.9.4.

trudelle: Should this be reassigned?
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Keywords: nsBranch
Throwing this fish back in the pool for reassignment. ->trudelle, unset 
milestone.
Assignee: arik → trudelle
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.4 → ---
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → ruixu
->hyatt
Assignee: trudelle → hyatt
Blocks: 99227
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.
Keywords: nsbranch-
removed keyword nsbranch since it now has nsbranch-, per pdt mtg.
Keywords: nsbranch
No longer blocks: 99227
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Blocks: 107067
Keywords: nsbranch-
ruixu - is this still an issue? Please update us on your findings. thanks
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.
nominating as this is still a localizability issue. 

is there a possibility that i18n or l10n can take ownership of this one?
Keywords: nsbeta1
Blocks: 123821
nsbeta1- per nav triage team
Keywords: nsbeta1nsbeta1-
> 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.
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
QA Contact: ruixu → jrgm
Target Milestone: Future → ---
Target Milestone: --- → Future
Forward duping to bug 403484, which has patches.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 403484
You need to log in before you can comment on or make changes to this bug.