GNOME Bugzilla – Bug 647087
Cut off module titles for long strings without spaces in translations
Last modified: 2018-01-18 02:14:40 UTC
The control center cuts off some of the module titles when translated to languages where the words are to long. I have added a screenshot - the text with red is what the titles was supposed to be. Btw. the screenshot is in Danish.
Created attachment 185464 [details] Screenshot of whats happening
This seems to me like a bug in the GtkIconView. We don't ask it to ellipsise the text, or clip it, so it shouldn't.
Det problem is that it doesn't ellipse or clip the text, it just doesn't show it all. Like, it can also show the half of a letter.
You don't tell it to clip or ellipsise, but you tell it that it only has a fixed width for each item. So, you get what you get. Now, we do allow the label to wrap a word boundaries, but that doesn't help for long words. Unfortunately, allowing to break at character boundaries leads to really suboptimal results, and Pango doesn't do hyphenation...
Kris: For the time being, is it possible in Danish language to add dashes/hyphens in such long strings (at least in German you can split long words and it's still considered a valid spelling)?
André: Yeah, I can do that :) But its suboptimal, but I will do it for now.
*** Bug 652936 has been marked as a duplicate of this bug. ***
*** Bug 661114 has been marked as a duplicate of this bug. ***
*** Bug 657854 has been marked as a duplicate of this bug. ***
*** Bug 655840 has been marked as a duplicate of this bug. ***
*** Bug 685340 has been marked as a duplicate of this bug. ***
*** Bug 675503 has been marked as a duplicate of this bug. ***
I've looked a bit into the current state of affairs. Here's my findings: 1. Some of the duplicate bugs have screenshots showing the last line of text being cut off horizontally - that is not happening anymore with current GTK+ - the icon view correctly allocates vertical space. 2. Pango does support breaking after hyphens and soft hyphens. What it does not support is a) inserting hyphens only when a break is taken and b) automatic determination of break points. So, as things stand now, you can insert a soft hyphen (SHY, U+00AD) at appropriate points in long words, and they will be broken - you won't get a visible hyphen at the break, but the text will not be cut off.
not going to make any changes in gtk here for 3.8
*** Bug 696980 has been marked as a duplicate of this bug. ***
*** Bug 704727 has been marked as a duplicate of this bug. ***
*** Bug 705572 has been marked as a duplicate of this bug. ***
*** Bug 709971 has been marked as a duplicate of this bug. ***
*** Bug 764444 has been marked as a duplicate of this bug. ***
Created attachment 325133 [details] Settings[ru] - cut off suffix in titles Espessialy in "Lage text"-mode, but in normal-mode too. Конфиденц - Конфиденциальность Уведомлени - Уведомления Электропит - Электропитание Подробност - Подробности Ползовате - Пользователи Универсальны доступ - Универсальный доступ
Moving back k
commit b3be07609a9bae43947ee3e59d8982a7715c9acf Author: Bastien Nocera <hadess@hadess.net> Date: Thu Apr 7 14:22:50 2016 +0200 panels: Fix truncated panel names for larger fonts Note that this fix will not automatically fix translations, which will need to add soft-hyphens (U+00AD) to their translations themselves, and will not fix larger fonts for which the split up syllables end up being bigger than the maximum text width. It's the best we can do without redesigning the Settings shell, which is already something planned. https://bugzilla.gnome.org/show_bug.cgi?id=647087#c13 Translators, see: http://thread.gmane.org/gmane.comp.gnome.internationalization.general/33633 for more information. Reassigning this bug to the Danish localisation team.
Hello Bastien Some time ago I did a test on my own system (Ubuntu 16.04) to check whether soft-hyphens would work. Unfortunately they did show up, /all/ of them, which would have been a disaster. Do you know for a fact that it is safe to fix this now? What's worse, some of those strings (at least in Ubuntu, which may have modifications) come from different templates and I have no reliable way of finding out which. To me it appears that I have no realistic chance to fix this error on the localization side. Or do you have any advice?
(In reply to Ask Hjorth Larsen from comment #23) > Hello Bastien > > Some time ago I did a test on my own system (Ubuntu 16.04) to check whether > soft-hyphens would work. Unfortunately they did show up, /all/ of them, > which would have been a disaster. Do you know for a fact that it is safe to > fix this now? I don't know what Ubuntu ships, or how it behaves. It's possible you added normal hyphens instead of soft ones. Sorry, can't help.
I have tested this again and now it behaves as described by Matthias Clasen: Long words split around the soft hyphens into different lines where necessary, but no actual hyphen character is inserted, so the output is still wrong. (Thus I did not remember the behaviour correctly when I described it previously.) The only way to fix it for a translator is to insert real hyphens and hope they never change fonts or widths for the text. But that is too fragile and difficult. Conclusion: This is an i18n bug. No translator can fix it. Where and how is it best reported so it will be fixed? After 6 years I think the time has come to make the necessary amount of fuss.
(In reply to Ask Hjorth Larsen from comment #25) > Conclusion: This is an i18n bug. No translator can fix it. Where and how > is it best reported so it will be fixed? After 6 years I think the time has > come to make the necessary amount of fuss. Making fuss doesn't magically fix long-standing, hard-to-fix bugs. The control-center redesign would obsolete that problem. In the meantime, you'll have to live with it, or find somebody with enough knowledge and time to fix it. I have neither.
(In reply to Bastien Nocera from comment #26) > The control-center redesign would obsolete that problem. In the meantime, > you'll have to live with it, or find somebody with enough knowledge and time > to fix it. I have neither. Are you sure that the new redesigned control-center does not have problems with not-fit-labels, including all locales and DPI? Rewriting software from scratch does not solve the problem of fine design and usability issues.
(In reply to Anton Maklakov from comment #27) > (In reply to Bastien Nocera from comment #26) > > > The control-center redesign would obsolete that problem. In the meantime, > > you'll have to live with it, or find somebody with enough knowledge and time > > to fix it. I have neither. > > Are you sure that the new redesigned control-center does not have problems > with not-fit-labels, including all locales and DPI? Yes, because that's one of the goals of the new design. > Rewriting software from scratch does not solve the problem of fine design > and usability issues. We're not rewriting it from scratch.
In any case, if you are interested in improving our font rendering stack, the minimum we need here is a pango patch to make it render a hyphen when it breaks at a SHY character.
(In reply to Bastien Nocera from comment #26) > (In reply to Ask Hjorth Larsen from comment #25) > > Conclusion: This is an i18n bug. No translator can fix it. Where and how > > is it best reported so it will be fixed? After 6 years I think the time has > > come to make the necessary amount of fuss. > > Making fuss doesn't magically fix long-standing, hard-to-fix bugs. Right now it is I who am sometimes getting the fuss. Assigning it to me/us (l10n-da-maint@gnome.bugs) has zero chance of fixing it though. The fuss must propagate, and if not to me or you, then to whomever can actually fix it. From my perspective, a fix is anything that allows a motivated translator to succeed in the task of writing correct strings. This means it does not need to be a software fix. A practical workaround would be a recommended maximum string length given as a msgctxt, e.g. msgctxt "maximum-line-length-approximately-12" (so the relevant messages become fuzzy if the allowed length changes). The soft hyphens unfortunately do not suffice to produce correct texts (erroneous splitting of compound words is an embarrassing spelling error in Danish), but I will now manually hyphenate the strings unless someone knows a reason to do otherwise. All of those strings in gnome-control-center are of course trivial to fix because they are well commented in the po-file. Some strings appear to have been added downstream (Debian or Ubuntu). Possibly this affects the strings (in Ubuntu 16.04) of Language Support, Landscape Service and Software & Updates. That means they have to be reported elsewhere. Is this correct?
(In reply to Ask Hjorth Larsen from comment #30) > (In reply to Bastien Nocera from comment #26) > > (In reply to Ask Hjorth Larsen from comment #25) > > > Conclusion: This is an i18n bug. No translator can fix it. Where and how > > > is it best reported so it will be fixed? After 6 years I think the time has > > > come to make the necessary amount of fuss. > > > > Making fuss doesn't magically fix long-standing, hard-to-fix bugs. > > Right now it is I who am sometimes getting the fuss. Assigning it to me/us > (l10n-da-maint@gnome.bugs) has zero chance of fixing it though. The fuss > must propagate, and if not to me or you, then to whomever can actually fix > it. The fix that's required of this bug, and of you, is adding those invisible hyphens so that the strings are split on multiple lines rather than clipped. > From my perspective, a fix is anything that allows a motivated translator to > succeed in the task of writing correct strings. This means it does not need > to be a software fix. The hyphens won't be showing, but that's a different problem. > A practical workaround would be a recommended maximum string length given as > a msgctxt, e.g. msgctxt "maximum-line-length-approximately-12" (so the > relevant messages become fuzzy if the allowed length changes). The soft > hyphens unfortunately do not suffice to produce correct texts (erroneous > splitting of compound words is an embarrassing spelling error in Danish), > but I will now manually hyphenate the strings unless someone knows a reason > to do otherwise. Changing the maximum length of the strings won't fix the problem. English is also affected, though it has shorter strings, when "Large fonts" is toggled on in the "Universal Access panel". > All of those strings in gnome-control-center are of course trivial to fix > because they are well commented in the po-file. Great, that was the plan. > Some strings appear to have been added downstream (Debian or Ubuntu). > Possibly this affects the strings (in Ubuntu 16.04) of Language Support, > Landscape Service and Software & Updates. > > That means they have to be reported elsewhere. Is this correct? That's downstream's problem, indeed. We can't offer translations for things that don't exist upstream.
(In reply to Bastien Nocera from comment #31) > (In reply to Ask Hjorth Larsen from comment #30) > > (In reply to Bastien Nocera from comment #26) > > > (In reply to Ask Hjorth Larsen from comment #25) > > > > Conclusion: This is an i18n bug. No translator can fix it. Where and how > > > > is it best reported so it will be fixed? After 6 years I think the time has > > > > come to make the necessary amount of fuss. > > > > > > Making fuss doesn't magically fix long-standing, hard-to-fix bugs. > > > > Right now it is I who am sometimes getting the fuss. Assigning it to me/us > > (l10n-da-maint@gnome.bugs) has zero chance of fixing it though. The fuss > > must propagate, and if not to me or you, then to whomever can actually fix > > it. > > The fix that's required of this bug, and of you, is adding those invisible > hyphens so that the strings are split on multiple lines rather than clipped. That was done once comments were added which called for them. (I did not realize that those were these same strings at the time though, or at least not all of them) Then perhaps this bug can be closed after all, at least in GNOME. > > > From my perspective, a fix is anything that allows a motivated translator to > > succeed in the task of writing correct strings. This means it does not need > > to be a software fix. > > The hyphens won't be showing, but that's a different problem. > > > A practical workaround would be a recommended maximum string length given as > > a msgctxt, e.g. msgctxt "maximum-line-length-approximately-12" (so the > > relevant messages become fuzzy if the allowed length changes). The soft > > hyphens unfortunately do not suffice to produce correct texts (erroneous > > splitting of compound words is an embarrassing spelling error in Danish), > > but I will now manually hyphenate the strings unless someone knows a reason > > to do otherwise. > > Changing the maximum length of the strings won't fix the problem. English is > also affected, though it has shorter strings, when "Large fonts" is toggled > on in the "Universal Access panel". > > > All of those strings in gnome-control-center are of course trivial to fix > > because they are well commented in the po-file. > > Great, that was the plan. > > > Some strings appear to have been added downstream (Debian or Ubuntu). > > Possibly this affects the strings (in Ubuntu 16.04) of Language Support, > > Landscape Service and Software & Updates. > > > > That means they have to be reported elsewhere. Is this correct? > > That's downstream's problem, indeed. We can't offer translations for things > that don't exist upstream. I will try to get it fixed there, then. Else someone will just open a new bug here when they discover that there is a problem. (I take it that you confirm that the mentioned strings do not originate from within GNOME itself)
(In reply to Ask Hjorth Larsen from comment #32) > (In reply to Bastien Nocera from comment #31) > > (In reply to Ask Hjorth Larsen from comment #30) > > > (In reply to Bastien Nocera from comment #26) > > > > (In reply to Ask Hjorth Larsen from comment #25) > > > > > Conclusion: This is an i18n bug. No translator can fix it. Where and how > > > > > is it best reported so it will be fixed? After 6 years I think the time has > > > > > come to make the necessary amount of fuss. > > > > > > > > Making fuss doesn't magically fix long-standing, hard-to-fix bugs. > > > > > > Right now it is I who am sometimes getting the fuss. Assigning it to me/us > > > (l10n-da-maint@gnome.bugs) has zero chance of fixing it though. The fuss > > > must propagate, and if not to me or you, then to whomever can actually fix > > > it. > > > > The fix that's required of this bug, and of you, is adding those invisible > > hyphens so that the strings are split on multiple lines rather than clipped. > > That was done once comments were added which called for them. (I did not > realize that those were these same strings at the time though, or at least > not all of them) > > Then perhaps this bug can be closed after all, at least in GNOME. Great, I'll close this bug then. > > > > > From my perspective, a fix is anything that allows a motivated translator to > > > succeed in the task of writing correct strings. This means it does not need > > > to be a software fix. > > > > The hyphens won't be showing, but that's a different problem. > > > > > A practical workaround would be a recommended maximum string length given as > > > a msgctxt, e.g. msgctxt "maximum-line-length-approximately-12" (so the > > > relevant messages become fuzzy if the allowed length changes). The soft > > > hyphens unfortunately do not suffice to produce correct texts (erroneous > > > splitting of compound words is an embarrassing spelling error in Danish), > > > but I will now manually hyphenate the strings unless someone knows a reason > > > to do otherwise. > > > > Changing the maximum length of the strings won't fix the problem. English is > > also affected, though it has shorter strings, when "Large fonts" is toggled > > on in the "Universal Access panel". > > > > > All of those strings in gnome-control-center are of course trivial to fix > > > because they are well commented in the po-file. > > > > Great, that was the plan. > > > > > Some strings appear to have been added downstream (Debian or Ubuntu). > > > Possibly this affects the strings (in Ubuntu 16.04) of Language Support, > > > Landscape Service and Software & Updates. > > > > > > That means they have to be reported elsewhere. Is this correct? > > > > That's downstream's problem, indeed. We can't offer translations for things > > that don't exist upstream. > > I will try to get it fixed there, then. Else someone will just open a new > bug here when they discover that there is a problem. (I take it that you > confirm that the mentioned strings do not originate from within GNOME itself) There are no settings panel by those names in GNOME upstream.