Help contents title bar shows cubes with numbers instead of a proper title

[Jasper Frumau]

Binary package hint: evolution

When I am in Evolution and go to help>content I see funny cubes with number in them in the window frame instead of a proper title. See screenshot. This could be a character display issue. I am not sure, but I believe I did not have this issue before this last Maverick Meerkat update.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: evolution 2.30.2-0ubuntu5
ProcVersionSignature: Ubuntu 2.6.35-7.12-generic 2.6.35-rc4
Uname: Linux 2.6.35-7-generic i686
Architecture: i386
Date: Wed Jul 14 12:31:42 2010
ExecutablePath: /usr/bin/evolution
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100318)
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANGUAGE=en
 LANG=en_US.utf8
SourcePackage: evolution
XsessionErrors: (polkit-gnome-authentication-agent-1:1748): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

[Pedro Villavicencio (pedro)]

 could you paste the output of: locale , to the report? thanks.

[Jasper Frumau (jfrumau)]

please explain how I post locale as well.

[Pedro Villavicencio (pedro)]

open a terminal, type locale and paste the output to the report.

[Jasper Frumau (jfrumau)]

~$ locale
LANG=en_US.utf8
LANGUAGE=en
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

[Jasper Frumau (jfrumau)]

Here one more screenshot of the window titles in Gnome under Maverick Meerkat not being displayed properly. All help windows in my Ubuntu setup display cubes with numbers in them instead of proper titles.

[Jasper Frumau (jfrumau)]

After the latest Maverick Meerkat upgrade all help windows still show squares with numbers and now the bottom bar somehow is not showing properly anymore either.

[Nobu (benjo316)]

I'm experiencing the same behavior in yelp.

Interestingly, some of the menu items in yelp's help menu display correctly (attachment).

[bbordwell (benbordwell)]

Changing to triaged since the requested information was provided and this bug is easily reproducible.

[bbordwell (benbordwell)]

I am not 100% sure this is not Ubuntu specific but I forwarded this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=627555

the output of locale on my system is identical to the original bug reporters.

[Dennis Sheil (dennis-sheil)]

I posted some information in bug #622082 but I made it a duplicate of this.

The "funny characters in a cube" printed are Unicode characters. Specifically, Unicode Shavian characters - an alternative method of displaying the English language, invented by George Bernard Shaw.

I ran gnome-language-selector, switched my language to Spanish (from Spain), restarted Gnome and the bad toolbar went away, the proper Spanish characters were displayed in yelp. So this is a problem that those with a Spanish language environment are not having, but those with an English environment are having. I should note that I only chose Spanish as I understand a little of it, I'm sure other languages are functioning.

The problem is English is being displayed in a Shavian mode instead of as en_US or en_GB or the like. In fact, it's not even being displayed in Shavian mode - most systems don't have the Shavian characters installed, so it just comes out as Unicode numbers in a box gibberish.

[Jasper Frumau (jfrumau)]

This is something. I wonder why Shavian was chosen. To revive the ancient dream of Bernard Shaw to make the English alphabet simpler and the orthography phonetic for the English language to replace the difficulties of the current spelling? A joke perhaps? Or just a typo? Either way, let us try to reverse it. I for one am more familiar with the conventional alphabet.

[Dennis Sheil (dennis-sheil)]

When I look at the output of "msgunfmt /usr/share/locale-langpack/en/LC_MESSAGES/yelp.mo", I see the line

"Language-Team: Shavian <email address hidden>\n"

The msgstr's in the lines are in Shavian English.

In fact, when I move the yelp.mo file to yelpUSERDISABLE.mo - the problem with the weird characters goes away

I did an "apt-get source yelp" and within the po subdirectory are three English po files, which I believe are Canadian, British and Shavian po files. I guess the Shavian file got changed into a binary catalog file and was pushed into that directory as the default for English, and that catalog overrides the default. Because when the binary catalog is disabled by moving the file, the problem goes away.

[Dennis Sheil (dennis-sheil)]

OK, I have found the problem. It is in the package language-pack-gnome-en-base

$ dpkg -l language-pack-gnome-en-base|tail -1
ii language-pack-gnome-en-base 1:10.10+20100817 GNOME translations for language English

When I do an apt-get source language-pack-gnome-en-base, I get the source, in which is the file data/en/LC_MESSAGES/yelp.po which, other than the header and footer, is identical to ./data/en@shaw/LC_MESSAGES/yelp.po .

My solution would be to replace data/en/LC_MESSAGES/yelp.po with the more standard yelp.po from the data/en_GB subdirectory. There are other solutions as well.

[Maurice Aarts (ice-blade)]

I'm noticing the same behavior in 10.10 after a dist-upgrade from 10.04 earlier today. Everything was working properly in Lucid.

It's happening on the regular help pages as well as when I open the Preferences > About Ubuntu etc...

laptop ~% locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[Robert Roth (evfool)]

I suggest raising the importance of this bug even more because of the number of duplicates growing day by day, and people trying the beta of Maverick do not get a good first impression when they look at te help showing in the menu and title cubes only.

[David Planella (dpm)]

Here's what happens:

In an English system, the English language pack installs the following translation catalogs for yelp:

/usr/share/locale-langpack/en/LC_MESSAGES/yelp.mo
/usr/share/locale-langpack/en@shaw/LC_MESSAGES/yelp.mo
/usr/share/locale-langpack/en_AU/LC_MESSAGES/yelp.mo
/usr/share/locale-langpack/en_CA/LC_MESSAGES/yelp.mo
/usr/share/locale-langpack/en_GB/LC_MESSAGES/yelp.mo

They correspond to each one of the variants for which there are translations. However, /usr/share/locale-langpack/en/LC_MESSAGES/yelp.mo should not exist, since that corresponds to the POSIX (C, or US English) locale, in which all applications are written - and therefore no translations are needed.

The 'en' translation is being created from the 'en@shaw' one, and that's because the translation tarball exported from Launchpad to create the latest full language pack on 2010-08-17 [1] contains the yelp en@shaw translation in the en/LC_MESSAGES folder. I'm not sure why, but perhaps because of the recent changes with @ locales in Launchpad?

I'm adding a task for Launchpad Translations.

Thanks Dennis for pointing to the cause of the problem.

[1] https://translations.launchpad.net/ubuntu/maverick/+language-packs

[David Planella (dpm)]

What happened was that for some unknown reason an en.po file containing en@shaw translation was imported into Launchpad at some point. We do not know if this was because of a bug in the imports and how they deal with @ translations or a mistakenly commited translation or something else.

What we do know is that it is not a bug in the translation exports, so I'm marking the Launchpad Translations task as Invalid.

In order to fix this, I've uploaded an empty (without msgstr translations) en.po file to the yelp template in Launchpad Translations, and this empty file should replace the current en.po with wrong Shavian translations.

This effectively means that in the next translations export the empty file will fix this. If we're lucky, and the file is imported some time today before the scheduled export, the next Maverick language pack tomorrow should include the fix. If not, the next one on Sunday will fix it.

[Jonathan Dotson (dotson83)]

I have the same problem.

~$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

My system is also fully updated

[Pedro Villavicencio (pedro)]

the fix is not yet released, please be patient.

[Andrea Chiavazza (andrea-c7a)]

The latest language-pack-gnome-en released update didn't fix it!

[exploder91 (d-cosner)]

The bug does not appear to be fixed in Maverick x64. I received the updated package this morning and the bug is still present.

[Dani Soufi (compengi)]

The problem persists for me too..

[Delan Azabani (azabani)]

I would like to avoid offending anyone in saying this, but for an active bug like this, please do not repeatedly post 'me too' comments or remind us that it is not fixed yet.

[Delan Azabani (azabani)]

On the same note, why has it been declined for Maverick? Does this mean that Maverick will be released with an unreadable help browser?

[Andrea Chiavazza (andrea-c7a)]

I vote for making an exception to the final freeze and fix it before release.
It might just be a "cosmetic" issue, but the "about ubuntu" application is also affected and will most likely be run by people that don't know much about Ubuntu and want to find out more.
This bug really wouldn't make for a great first impression about Ubuntu as an operating system.

[Ben Isaacs (bisaacs)]

Yes, I aggree to make an exception. This may only be a small bug but new users will struggle to cope as it doesn't happen on Windows or Mac OS X.

[Ben Isaacs (bisaacs)]

Help will be useless if this isn't fixed.

[rusivi2 (rusivi2-deactivatedaccount)]

I strongly agree with Andrea Chiavazza, and frankly, it's a deal breaker.

[Shunsuke Akagi (shoon)]

Is this just issue of help menu?
Because the same thing happens when I unzip files in Japanese title.

By the way, when I see the help menu in Japanese setting, I can read
them well in Japanese.

I am just telling this so that someone figure out these root cause.

On Sat, 2010-09-18 at 01:49 +0000, Delan Azabani wrote:
> On the same note, why has it been declined for Maverick? Does this mean
> that Maverick will be released with an unreadable help browser?
>

[Shunsuke Akagi (shoon)]

Is this just issue of help menu?
Because the same thing happens when I unzip files in Japanese title.

By the way, when I see the help menu in Japanese setting, I can read
them well in Japanese.

I am just telling this so that someone may figure out these root cause.

On Sat, 2010-09-18 at 01:49 +0000, Delan Azabani wrote:
> On the same note, why has it been declined for Maverick? Does this mean
> that Maverick will be released with an unreadable help browser?
>

[Jonathan Dotson (dotson83)]

I agree with the above posts. If this isn't fixed most people who have never used Linux and many who have will ditch it as soon as they see this. It shows a rushed product and lack of professionalism and pride in the distribution. Ubuntu seems to be more worried about time lines than making a quality product as of late.

[madbiologist (me-again)]

At least put up an official Wiki page with a workaround, possibly the one described in comment #14. And maybe link to the Wiki page from the Maverick release notes as well.

Sebastien - will David's fix be an SRU candidate post-release?

[Matt Eskes (matt.eskes-deactivatedaccount)]

I'm going to add my two cents to this one. If we know what the issue is and that a fix for it is rather trivial, then A> Why is a fix frozen, even though the problem is rather cosmetic and B> Why is A even up for discussion? Why can't we just fix it push it out? As Jonathan stated quality should top ALL priorities.

[madbiologist (me-again)]

What they are worried about is that introducing a change this late may have the side-effect of causing an unexpected regression. In this particular case I think they are worrying unnecessarily but they are following their standard practice which they have followed in previous releases. Also, I'm not a software developer.

I wish this was fixed for the release too, but history tells me it won't happen.

[David Pothecary (david-pothecary)]

I'm confused as to how this could ever cause a regression - the file
affected is only for the use of Yelp anyway surely?

On 18 September 2010 20:38, madbiologist <email address hidden> wrote:

> What they are worried about is that introducing a change this late may
> have the side-effect of causing an unexpected regression. In this
> particular case I think they are worrying unnecessarily but they are
> following their standard practice which they have followed in previous
> releases. Also, I'm not a software developer.
>
> I wish this was fixed for the release too, but history tells me it won't
> happen.
>
> --
> Help contents title bar shows cubes with numbers instead of a proper title
> https://bugs.launchpad.net/bugs/605577
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Launchpad Translations: Invalid
> Status in Ubuntu Translations: Triaged
> Status in The Yelp Help Browser for Gnome: Unknown
> Status in “language-pack-gnome-en-base” package in Ubuntu: Confirmed
> Status in “yelp” package in Ubuntu: Invalid
>
> Bug description:
> Binary package hint: evolution
>
> When I am in Evolution and go to help>content I see funny cubes with number
> in them in the window frame instead of a proper title. See screenshot. This
> could be a character display issue. I am not sure, but I believe I did not
> have this issue before this last Maverick Meerkat update.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 10.10
> Package: evolution 2.30.2-0ubuntu5
> ProcVersionSignature: Ubuntu 2.6.35-7.12-generic 2.6.35-rc4
> Uname: Linux 2.6.35-7-generic i686
> Architecture: i386
> Date: Wed Jul 14 12:31:42 2010
> ExecutablePath: /usr/bin/evolution
> InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100318)
> ProcEnviron:
> SHELL=/bin/bash
> PATH=(custom, user)
> LANGUAGE=en
> LANG=en_US.utf8
> SourcePackage: evolution
> XsessionErrors: (polkit-gnome-authentication-agent-1:1748): GLib-CRITICAL
> **: g_once_init_leave: assertion `initialization_value != 0' failed
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/rosetta/+bug/605577/+subscribe
>

[exploder91 (d-cosner)]

The issue effects: "Help and Support", About Ubuntu" and "Contents" in Evolution. This type of bug makes an otherwise very good release look bad and unfinished. The final release is still 22 days away, certainly this is enough time to resolve this. It makes no sense to fix over 100 paper cuts and leave something like this unfixed.

[Brian Vaughan (bgvaughan)]

I agree that this should be a high priority. Readily accessible support documentation is critical for a Linux distribution that emphasizes user-friendliness.

[exploder91 (d-cosner)]

Judging by the large number of people that have duplicated this bug report, the bug has a pretty high profile and should have a higher priority. I agree with the "user friendly" comment, this is after all about documentation. This is extremely noticeable, it would be a wise move to correct this because it would have a negative effect on the overall quality of the release.

[exploder91 (d-cosner)]

One last comment. If fixing this could effect the stability of the release, how stable is it to begin with? Come on, the release is very stable! I would like to see a very small list of "Known Issues" this time rather than half a page worth.

[ptashek (ptashek)]

Freeze or no freeze, it does not matter. Releasing a broken product, and in my view 10.10 *is* broken until this is fixed, just to meet a deadline is, quite frankly, silly, irresponsible *and* very poor project management. I dare saying that absolutely none will care if 10.10 slips a week or two. On the other hand every average user will have a "what the...?" moment as soon as they see this issue.

One other thing is, why give your competition something they may (and rightly so!) laugh at you about, or simply tear you apart in reviews, comparisons etc.

So, whoever has declined this for Maverick should get their act together and seriously consider the potential wide-context impact of an otherwise utterly silly bug.

[mike2357 (mike2357)]

Please remember, it's not just the "About Ubuntu" option in which garbage characters appear. The cubes appear in many Gnome application help screens. Examples: Nautilus, Gnucash, gCalctool, gedit, F-Spot, Simple Scanner and probably lots more since so many applications use yelp. Perfection can be carried too far, but I think we should do what's best for users: fix this even if it means delaying the final release.

[Charlie Kravetz (cjkgeek)]

To be honest, the boxes that have the unreadable text do NOT affect the help when called from any application. They only affect searching in yelp. They are the title of the text help, the search box, the bookmarks, etc. The actual text that one reads when trying to use the application is not affected.

[Murat Gunes (mgunes)]

People, please calm down; the rejection of the nomination does not mean that this bug will not be fixed in Maverick. Nominations are mainly used for stable release update candidates, not for bugs in the development branch [1]; any bug that isn't being tracked in a specific release is implicitly considered to apply to the development branch. As you can see, Matthew has milestoned the language pack task to ubuntu-10.10, which means he and/or the documentation team are aiming to fix this for the final release.

Nobody has said that the bug can't be fixed due to a freeze, or that it won't be fixed in Maverick. Please be patient, and observe the CoC.

[1] I note that if we have a strict policy on this, it doesn't seem well documented, and the common practice is in conflict with https://wiki.ubuntu.com/RCBugTargetting, which in turn may have been outdated.

[Murat Gunes (mgunes)]

Please don't reopen the yelp task.

[Nobu (benjo316)]

In reply to Charlie Kravetz's comment #45:

To be clear, basically any (localized) text which isn't being rendered
in the html viewing area--button text, menu text, tool-tip text,
etc.--is effected. This has little impact on reading the current help
item and related items are still easily found, but it's still a big
accessibility issue for anyone who doesn't know or hasn't memorized (any
of) the menu items, icons, or keyboard shortcuts, in addition to being a
"cosmetic" issue.

Good to know this will be fixed before release. ;-)

[David Planella (dpm)]

It seems that the fix was not picked up by the latest delta language pack, but it will be included in the next full language pack before release.

Another thing that might need to be done is to remove the en.po translation from debian/patches/07_rosetta_translations_update.patch. Otherwise I believe the en.po will be reimported on the next yelp upload. This can be done in either of these two ways:

* Removing en.po from the current patch
* Exporting translations from Launchpad and updating the patch. The exported translations should no longer contain the en.po file, but it might be worth checking it out. This might be the easier thing to do, as around this time in the release translations are updated this way for packages affected by the NonLanguagePackDeadline anyway.

[Andrea Chiavazza (andrea-c7a)]

@David Planella
Last time a fix was released it didn't fix the problem after all (see #21).
We should avoid this happening again to the final release.
So can we test the fix before it is released ?
Is there a place we can download it from ?

[David Planella (dpm)]

Hi Andrea,

El dv 24 de 09 de 2010 a les 12:32 +0000, en/na Andrea Chiavazza va
escriure:
> @David Planella
> Last time a fix was released it didn't fix the problem after all (see #21).

As I said on my last comment, I'm well aware that the last delta
language pack did not fix this.

> We should avoid this happening again to the final release.

I'm also aware of this.

> So can we test the fix before it is released ?
> Is there a place we can download it from ?
>

The last language pack is scheduled for the 30th with the release
candidate, and I guess it will be built in a day or two after that,
which will be when it can be tested.

Regards,
David.

[Didier Roche-Tolomelli (didrocks)]

as discussed with dpm on IRC later today, I will do it on Monday

[Martin Pitt (pitti)]

Fixed English GNOME langpack uploaded, needs to be reviewed by release team member now.

[Martin Pitt (pitti)]

I just checked yelp, and although 07_rosetta_translations_update.patch has the faulty translations, the patch isn't currently applied, so this is a non-issue (I fixed the patch in bzr, but it doesn't need uploading). So fixing the langpack is sufficient for this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package language-pack-gnome-en-base - 1:10.10+20100817.1

---------------
language-pack-gnome-en-base (1:10.10+20100817.1) maverick; urgency=low

  * Drop the broken en translation for Yelp. This was accidentally copied from
    the en@shaw translation. This was corrected in Launchpad later on, so the
    next regular language pack update will fix this; but that rebuild will be
    too late for the release candidate. (LP: #605577)
 -- Martin Pitt <email address hidden> Mon, 27 Sep 2010 12:49:04 +0200

[exploder91 (d-cosner)]

I can confirm the bug has been fixed. Nice work!

[Federico Vera (fedevera)]

Same here everything works OK!