Closed Bug 52978 Opened 19 years ago Closed 12 years ago
Text truncation character should be localizable
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
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Changed QA contact to firstname.lastname@example.org.
QA Contact: teruko → andreasb
Will ask pchen to look at this one
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.
removing nsbeta1 per i18n/l10n triage
l12y issue is in XPToolkit -> evaughan.
Assignee: vishy → evaughan
Component: Localization → XP Toolkit/Widgets
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?
email@example.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
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
Assignee: trudelle → hyatt
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.
removed keyword nsbranch since it now has nsbranch-, per pdt mtg.
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?
> 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 → ---
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.