Ubuntu

French translation broken and character encoding bugs

Reported by Jean-Philippe Fleury on 2008-11-28
16
Affects Status Importance Assigned to Milestone
Gutenprint
Unknown
Unknown
Ubuntu Translations
Undecided
Ubuntu French Translators
gutenprint (Ubuntu)
Undecided
Unassigned
system-config-printer (Ubuntu)
Undecided
Unassigned

Bug Description

Here's the steps to follow:

- Go to the Ubuntu menu > System > Administration, to configure the printers.
- Click right on a printer and choose "Properties". The window manager appears.

In this manager, there are French strings broken and character encoding bugs. My config:
Gnome 2.24.1
Ubuntu 8.10 32-bit

I attach a screen shot. In this image, there's a blue dot for each broken translation, and an orange dot for each character encoding bug.

Related branches

Jean-Philippe Fleury (jpfle) wrote :
Till Kamppeter (till-kamppeter) wrote :

These are two bugs:

1. The translations in Gutenprint are incomplete, therefore there are the untranslated strings which you have marked with a blue dot.

2. system-config-printer does not respect the encoding of the translated strings. You have marked the strings with an orange dot. Multi-language PPDs like the ones of Gutenprint have all translations in UTF8. Non-English single-language PPDs (PostScript printer PPDs from printer manufacturers, SpliX driver) have the encoding specified in the PPD file. It is possible that CUPS sends all the strings already in UTF8.

Both bugs are upstream bugs, they would occur the same way also with any other distribution. On 1. you could help solving it, by volunteering to do translations.

Please report the problems to the respective upstream projects:

1. Gutenprint: http://sourceforge.net/projects/gimp-print/ Choose "Bugs" in the "Tracker" menu

2. https://fedorahosted.org/system-config-printer/report

In both cases you need to create an account for posting bug reports.

Jean-Philippe Fleury (jpfle) wrote :

Hi Till,

You wrote:
> 1. The translations in Gutenprint are incomplete, therefore there are
> the untranslated strings which you have marked with a blue dot.
> [...]
> 1. you could help solving it, by volunteering to do translations.

I really think that the strings marked with a blue dot aren't all untranslated strings. I think that there's a lot of broken translations. Go to this page:

https://translations.launchpad.net/ubuntu/intrepid/+source/gutenprint/+pots/gutenprint/fr/+translate

and search strings marked with a blue dot. There are a lot of these strings that are already translated. An example with «Grayscale»:

89.
English: Grayscale
Current French: Niveaux de gris
Translated and reviewed by Raymond Ostertag on 2006-03-19

Despite this, it's not «Niveaux de gris» that is displayed, but the English string «Grayscale». A lot of French translations aren't used. Other examples:

32.
English: Media Source
Current French: Source du support
Translated and reviewed by Raymond Ostertag on 2006-03-19

566.
English: Shrink Page If Necessary to Fit Borders
Current French: Réduire la page si nécessaire pour tenir dans le cadre
Translated by Sun Wukong on 2007-04-19
Reviewed by regis rampnoux on 2007-06-20

567.
English: Shrink (print the whole page)
Current French: Réduire (imprimer la page entière)
Translated by Sun Wukong on 2007-04-19
Reviewed by regis rampnoux on 2007-06-20

Jean-Philippe Fleury (jpfle) wrote :

Hi Till,

You wrote:

> Please report the problems to the respective upstream projects:
> 1. Gutenprint: http://sourceforge.net/projects/gimp-print/ Choose
> "Bugs" in the "Tracker" menu

It's done. The request ID is 2359260.

> 2. https://fedorahosted.org/system-config-printer/report

It's also done. It's the ticket #114: https://fedorahosted.org/system-config-printer/ticket/114

Jean-Philippe Fleury (jpfle) wrote :

> I have reported your issue of your comment #3

Thanks.

Jean-Philippe Fleury (jpfle) wrote :

On https://fedorahosted.org/system-config-printer/ticket/114 the bug has been closed, with this comment:

> The PPD advertises its encoding as ISOLatin1, but it is in fact
> encoded in UTF-8. This indicates a bug in the application that
> created the PPD file, gutenprint-5.2.0-rc1.

Jean-Philippe Fleury (jpfle) wrote :

Hi Till,

You wrote:
> I have reported your issue of your comment #3

Should we open a specific bug report on Launchpad about that?

Till Kamppeter (till-kamppeter) wrote :

Your PPD is broken. It has the header of a globalized PPD (with "*cupsLanguges" entry) but in reality it is a single-language PPD for French, and especially the French strings are UTF-8 encoded but the "*LanguageEncoding:" keyword says "ISOLatin1". How did you obtain this PPD? The PPDs generated by the Ubuntu package of Gutenprint are globalized PPDs according to the CUPS extensions on http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html.

Jean-Philippe Fleury (jpfle) wrote :

Hi Till,

You wrote:
> How did you obtain this PPD?

I've not installed it manually, I've just used the automatic installation by the Ubuntu printer manager. I can confirm the encoding character bug on my system (Ubuntu 8.10 32-bit) and on another computer (Ubuntu 8.10 64-bit).

Tim Waugh (twaugh) wrote :

Hmm, I wonder if system-config-printer commit 75f7fe9354040873178d571449442ee313971638 is to blame for this.

It cannot break anything in Intrepid, as the patch is from Nov 19. which is after Intrepid release.

But in general, this localize() function only localizes the data structure in memory or does it replace the queue's globalized PPD by a single-language one?

Jean-Philippe, you do not need to open a new bug about the coordination of upstream and Launchpad translations. I did so already. See bug 303516.

Tim Waugh (twaugh) wrote :

Seems like cups.getServerPPD() is giving us a localized PPD somehow, but I'm not sure how.

(Yes, localize() only localizes the data structure in memory, but we use that data structure to write out a new PPD file.)

Tim, for what do you need to read out a full PPD and write it back? For changing the defaults one only needs to send them to CUPS as key=value pairs, the IPP equivalent of "lpadmin -p <queue> -o <option1>=<value1> -o <option2>=<value2> ...". If you need to download the PPD, modify it and upload it, take care that the full PPD gets downloaded and not only a part of it.

For globalized PPDs keep in mind that they should permanently carry all the languages in the /etc/cups/ppd/<queue>.ppd file so that if there are different users with different UI languages that everyone gets the options and choices in his UI language.

Tim, and if you write back modified PPDs they must stay consistent (not a single-language PPD with *cupsLanguages entry and wron *LanguageEncoding).

Tim Waugh (twaugh) wrote :

The problem lies in the gutenprint package. This can be seen by running the PPD driver directly:

$ LC_ALL=fr_FR.UTF-8 /usr/lib/cups/driver/gutenprint.5.2 cat "gutenprint.5.2://bjc-MULTIPASS-MP150/expert" |egrep -e '(Encoding)|(OpenUI.*StpQuality)'
*LanguageEncoding: ISOLatin1
*OpenUI *StpQuality/Qualité d'impression: PickOne

or by using the cupsGetServerPPD() function:

$ LC_ALL=fr_FR.UTF-8 python -c 'from locale import *; setlocale(LC_ALL,''); import cups, os; c=cups.Connection(); ppdfile=c.getServerPPD("gutenprint.5.2://bjc-MULTIPASS-MP150/expert"); ppd=cups.PPD(ppdfile); os.unlink (ppdfile); print ppd.findOption("StpQuality").text'
Qualité d'impression
(note that we did *not* call ppd.localize() here)

i.e. it is breaking rule 6 of the globalized PPD rules. The gutenprint PPD driver needs to be fixed so that it does not use 8-bit characters in option descriptions for globalized PPDs except in translated descriptions added as part of the extension.

Whether it does this by providing untranslated option descriptions, leaving it to applications to use the ppdLocalize() function to get translations, or by "breaking" its translated strings in the main part of the PPD so that they are 8-bit clean, one way or the other it needs to be fixed.

Regarding reading out a full PPD and writing it back: no, it is not necessary to do this. Please file bugs for whichever cases you can find where this occurs, and it can be looked at later. However, it is not causing the problem at hand.

Regarding keeping PPDs consistent when writing them back: indeed, I realise this, and am working on a fix for this. However, I don't believe it is the entire cause of the bug at hand -- although it may have been the cause for this particular instance (we don't know).

Problem is that Gutenprint's PPD generator (/usr/lib/cups/driver/gutenprint.5.2) only generates fully globalized PPDs if the server's (the machine on which the print queue is set up) default locale is English. With any other locale it produces broken single-language PPDs of the locale's language.

I posted the following in the discussion on the upstream developer list of Gutenprint:

The idea of globalized PPDs is that a print queue has a multi-language PPD and so several users can use it with their preferred UI language. Therefore a PPD generator has always to emit the full globalized PPD with all languages and not to tray to extract a single-language PPD with the server's default locale. Currently, Gutenprint's PPD generator emits the full globalized PPD only when the server's default locale is English (as it is on my machine, and so I did not see the bug during the discussion on getting globalized PPDs here on the list). In addition, the single-language PPDs which Gutenprint genrates are broken. At first the UTF-8 translations from the extension are moved to the place of the standard translation strings, leaving the LanguageEncoding on "ISOLatin1". Also the LanguageVersion is left on "English" and the "cupsLanguages" line not removed.

But what really has to happen is that every queue gets full globalized PPDs, regardless of the server's default language. Either CUPS should take care of it to call the PPD generators with neutral locale ("C") or Gutenprint's PPD generator has to ignore the locale and always to emit fully globalized PPDs.

So Mike {author of CUPS] and Robert [leader of the Gutenprint project], one of you has to fix it.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gutenprint - 5.2.0~rc1-0ubuntu2

---------------
gutenprint (5.2.0~rc1-0ubuntu2) jaunty; urgency=low

  * debian/patches/25_genppd_globalized_ppds_fix.dpatch: Fixed autmatic
    generation of globalized PPD files if the system's default locale is not
    English (LP: #303273).

 -- Till Kamppeter <email address hidden> Fri, 5 Dec 2008 16:35:39 +0100

Changed in gutenprint:
status: New → Fix Released

Got a patch from upstream. I have uploaded a package with the patch applied to Jaunty, please try.

Jean-Philippe Fleury (jpfle) wrote :

Hi,

Here's what I've done:

- I installed libgutenprint2_5.2.0~rc1-0ubuntu2_i386.deb
- I restarted cups: sudo service cups restart
- In the printers manager, I deleted my printer and added it again.

I have the same encoding characters bug. Have I done the update correctly?

Jean-Philippe Fleury (jpfle) wrote :

There's a new snapshot of Gutenprint. See:
http://sourceforge.net/tracker/?func=detail&atid=101537&aid=2359260&group_id=1537

The rlk's message:

> Please try the latest snapshot at
> https://sourceforge.net/project/showfiles.php?group_id=1537&package_id=31377
> -- this bug should be fixed in that snapshot. I'd like to get this tested
> before we release 5.2.3.

Is it possible to have a Ubuntu package for testing?

Thanks.

Adi Roiban (adiroiban) wrote :

Hi Jean,

Since this bug was not touched lately, is this bug still present in Karmic?

I will assign it to Ubuntu French translators, maybe they can help us.

Kindest regards,
Adi

Changed in ubuntu-translations:
status: New → Incomplete
assignee: nobody → Ubuntu French Translators (ubuntu-l10n-fr)
Jean-Philippe Fleury (jpfle) wrote :

Adi Roiban wrote:
>Since this bug was not touched lately, is this bug still present in Karmic?

Hi Adi,

My current config is Gnome 2.28.1 and Ubuntu 9.10 32-bit, and the printer properties are all in English. There's no translation in French. See the attached screenshot "gutenprint-ubuntu-9.10.png".

This bug is really old. Can you tell us if the bug still exists?

Changed in system-config-printer (Ubuntu):
status: New → Incomplete
Jean-Philippe Fleury (jpfle) wrote :

Mohamed Amine IL Idrissi wrote:
>This bug is really old. Can you tell us if the bug still exists?

In the "Printer Options" tab, everything is in English (except the title "Général" that is in French). See the attached screen shot.

Jean-Philippe: Did you test in Lucid or Maverick?

Changed in ubuntu-translations:
status: Incomplete → Confirmed
Changed in system-config-printer (Ubuntu):
status: Incomplete → Confirmed
Gabor Kelemen (kelemeng) wrote :

That is because you had the package gutenprint-locales not installed when adding the printer - could you retry after installing the package and re-adding the printer?
Last time I checked, the encoding worked for me - see my screenshots in bug #415452

Jean-Philippe Fleury (jpfle) wrote :

Mohamed Amine IL Idrissi wrote:
>Did you test in Lucid or Maverick?

I tested in Lucid.

Jean-Philippe Fleury (jpfle) wrote :

Gabor Kelemen wrote:
>That is because you had the package gutenprint-locales not installed
>when adding the printer - could you retry after installing the package
>and re-adding the printer?

Now I have strings in French and in English. See the screen shot.

Jean-Philippe gutenprint is not fully translated in French. You can check the current translation state here : http://translationproject.org/domain/gutenprint.html
That's why you still see English strings in UI.

Changed in ubuntu-translations:
status: Confirmed → In Progress
Gabor Kelemen (kelemeng) on 2011-11-20
Changed in ubuntu-translations:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.