Bug 30349 - RFE: i18n of printconf printer driver options
RFE: i18n of printconf printer driver options
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: printconf (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-02 13:26 EST by Christian Rose
Modified: 2007-04-18 12:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-02 17:23:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Christian Rose 2001-03-02 13:26:02 EST
This is a split-up of bug 30198.

Printer options should naturally be marked for translation. This affects a
lot of messages, among those:

"Density"
"Economy mode"
"Standard Mode"
"Economy Mode"
"Floyd-Steinberg Dithering"
"Standard printing"
"Floyd-Steinberg dithered printing"
"Ghostscript Resolution"
"Manual Feed of Paper"
"Off"
"On"
"Number of Copies"
"Page Size"
"REt Setting"
"Medium"
"Dark"
"Light"
"Off"

There are probably more options that need to have their settings
translated, these are just the options for my printer. If these options are
taken directly from the printer drivers, a special i18n scheme has to be
made for the printer options so that they can get translated with gettext.

This is my reply to a comment regarding this from crutcher@redhat.com in
bug 30198:
> The options are generated from data files. There are over 500 strings for
> translation in them, and there is the issue of how to split them out. The
> dynamic options were added after the drop, and while I do use gettext on
them,
> we had no expectation that they'd get translated for this release, as
they came
> in to late and there are to many of them. (And I wanted to make sure that
the
> main interface strings were translated, and not lost in a wash of minor
options
> that apply to 3 printers made 5 years ago.)

That's a very valid concern. However, I think that in situations like this
maybe the best solution would be to split the printer options in a seperate
module in the i18n robot. Then you can assure that the more prominent, but
few strings, in the printconf gui can be translated seperately from the
massive amount of obscure printer driver options.

> I will address this today, but it will massively swell the pot file

Please consider adding the printer options to their own module... that will
make it easier for translators to split up the work. Module could be named
"printconf-options" or "printer-options" or something like that.

> and I really don't expect them to be translated in time.

No... They probably won't be. However, I think you should send a mail to
translators explaining the situation, and that they are not expected to
translate this in time. You hereby also have my permission to put the blame
on me for the situation in your mail to translators. I take full
responsibility for my request, and that will probably help you avoid flames
from translators in panic (I'll take those flames, you take the credit for
the implementation)...

> Wait, there /were/ over 500 strings in them in the old database. The
updateed
> version I moved us to on wednesday is 70% larger, so I expect that it has
a
> couple more...

Uh-oh... Well, let the tidal wave come...
Comment 1 Trond Eivind Glomsrxd 2001-03-02 15:54:54 EST
I want to defer these to the next release: The problem with flooding the
translators this late is too big. Preston, is that OK?
Comment 2 Christian Rose 2001-03-02 16:50:49 EST
I don't see why this should be put on hold.
Doing it as soon as possible will only give translators more time to finish it
in time for the next release. Also, doing it now will also allow these
translations to go in the next version of printconf, and allow this to be tested
early and thoroughly.
The only reason *not* to do it seems to be "don't flood translators" and the
risc of annoying translators. I don't think that's a risc if this is put in its
own module in the i18n robot, and translators informed that they are in no way
expected to translate this in time for this release, but that it is put in the
robot as a service for those who want to start on it.
Comment 3 Trond Eivind Glomsrxd 2001-03-02 16:54:35 EST
Having two modules inside the same program will be rather unclean - I'd very
much like two avoid that. And I don't want to add hundreds and hundreds of
strings now - it annoys people.
Comment 4 Christian Rose 2001-03-02 17:23:15 EST
> Having two modules inside the same program will be rather unclean
> - I'd very much like two avoid that.

The GIMP does this for example. One po directory for the enormous amount of
plug-ins, and one for the program itself. All in the same cvs module.

> And I don't want to add hundreds and hundreds of strings now
> - it annoys people.

As I said previously, I don't think that it does, if properly explained.
Comment 5 Crutcher Dunnavant 2001-03-09 20:04:48 EST
It is too late for this release.
I've got the code to hook this up, but not until after gold.

There are over 600 strings, yes many of them are trivial, but that reduces, not
increases the need to translate.

Note You need to log in before you can comment on or make changes to this bug.