French translation broken and character encoding bugs

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.

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

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

I have reported your issue of your comment #3 (https://bugs.edge.launchpad.net/ubuntu/+source/gutenprint/+bug/303273/comments/3) as Gutenprint bug 2359394:

https://sourceforge.net/tracker2/?func=detail&aid=2359394&group_id=1537&atid=101537

> I have reported your issue of your comment #3

Thanks.

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.

Hi Till,

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

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

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.

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).

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.

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).

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.

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

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

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?

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.

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

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?

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?

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

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

I tested in Lucid.

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.