After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 647087 - Cut off module titles for long strings without spaces in translations
Cut off module titles for long strings without spaces in translations
Status: RESOLVED FIXED
Product: l10n
Classification: Infrastructure
Component: Danish [da]
unspecified
Other Linux
: Normal normal
: ---
Assigned To: l10n-da-maint@gnome.bugs
l10n-da-maint@gnome.bugs
: 675503 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-07 19:27 UTC by Kris Thomsen
Modified: 2018-01-18 02:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of whats happening (118.19 KB, image/png)
2011-04-07 19:35 UTC, Kris Thomsen
Details
Settings[ru] - cut off suffix in titles (125.07 KB, image/png)
2016-04-01 08:34 UTC, Anton Maklakov
Details

Description Kris Thomsen 2011-04-07 19:27:01 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.
Comment 1 Kris Thomsen 2011-04-07 19:35:30 UTC
Created attachment 185464 [details]
Screenshot of whats happening
Comment 2 Bastien Nocera 2011-04-13 11:00:48 UTC
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.
Comment 3 Kris Thomsen 2011-04-13 11:13:14 UTC
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.
Comment 4 Matthias Clasen 2011-04-13 11:20:02 UTC
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...
Comment 5 André Klapper 2011-04-13 11:34:16 UTC
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)?
Comment 6 Kris Thomsen 2011-04-13 11:36:59 UTC
André: Yeah, I can do that :) But its suboptimal, but I will do it for now.
Comment 7 Bastien Nocera 2011-06-21 14:14:29 UTC
*** Bug 652936 has been marked as a duplicate of this bug. ***
Comment 8 Bastien Nocera 2011-10-07 13:56:27 UTC
*** Bug 661114 has been marked as a duplicate of this bug. ***
Comment 9 Bastien Nocera 2011-10-07 13:56:40 UTC
*** Bug 657854 has been marked as a duplicate of this bug. ***
Comment 10 Sebastien Bacher 2012-01-02 13:34:02 UTC
*** Bug 655840 has been marked as a duplicate of this bug. ***
Comment 11 Bastien Nocera 2012-10-03 07:12:33 UTC
*** Bug 685340 has been marked as a duplicate of this bug. ***
Comment 12 Bastien Nocera 2012-10-03 07:15:05 UTC
*** Bug 675503 has been marked as a duplicate of this bug. ***
Comment 13 Matthias Clasen 2013-02-07 12:32:30 UTC
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.
Comment 14 Matthias Clasen 2013-02-14 01:33:20 UTC
not going to make any changes in gtk here for 3.8
Comment 15 Bastien Nocera 2013-04-02 14:02:00 UTC
*** Bug 696980 has been marked as a duplicate of this bug. ***
Comment 16 Bastien Nocera 2013-07-23 08:36:10 UTC
*** Bug 704727 has been marked as a duplicate of this bug. ***
Comment 17 Bastien Nocera 2013-08-07 09:50:59 UTC
*** Bug 705572 has been marked as a duplicate of this bug. ***
Comment 18 Bastien Nocera 2013-10-12 15:21:40 UTC
*** Bug 709971 has been marked as a duplicate of this bug. ***
Comment 19 Bastien Nocera 2016-04-01 08:19:11 UTC
*** Bug 764444 has been marked as a duplicate of this bug. ***
Comment 20 Anton Maklakov 2016-04-01 08:34:57 UTC
Created attachment 325133 [details]
Settings[ru] - cut off suffix in titles

Espessialy in "Lage text"-mode, but in normal-mode too.

Конфиденц - Конфиденциальность
Уведомлени - Уведомления
Электропит - Электропитание
Подробност - Подробности
Ползовате - Пользователи
Универсальны доступ - Универсальный доступ
Comment 21 Matthias Clasen 2016-04-02 16:35:07 UTC
Moving back k
Comment 22 Bastien Nocera 2016-04-07 14:10:02 UTC
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.
Comment 23 Ask Hjorth Larsen 2016-11-28 20:00:18 UTC
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?
Comment 24 Bastien Nocera 2017-01-03 12:53:09 UTC
(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.
Comment 25 Ask Hjorth Larsen 2017-01-06 17:51:00 UTC
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.
Comment 26 Bastien Nocera 2017-01-10 14:14:27 UTC
(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.
Comment 27 Anton Maklakov 2017-01-10 14:54:57 UTC
(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.
Comment 28 Bastien Nocera 2017-01-10 14:56:24 UTC
(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.
Comment 29 Matthias Clasen 2017-01-10 15:15:05 UTC
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.
Comment 30 Ask Hjorth Larsen 2017-01-10 15:22:00 UTC
(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?
Comment 31 Bastien Nocera 2017-01-10 15:35:14 UTC
(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.
Comment 32 Ask Hjorth Larsen 2017-01-10 16:04:08 UTC
(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)
Comment 33 Bastien Nocera 2017-01-10 16:05:43 UTC
(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.