Re: [Gimp-print-devel] 'make check' failing due to RU translation

[Robert K. <rl...@al...>]

On Fri, 6 Dec 2019 19:30:33 -0500, Solomon Peachy wrote:
> On Fri, Dec 06, 2019 at 07:07:42PM -0500, Robert Krawitz wrote:
>> I'm doing that as I find them.  Unfortunately, email to the maintainer
>> of the Ukrainian translation bounced, and I know there's at least one
>> string in the Finnish translation that's bad.
>
> I take it it's been a while since you synchronzied translations?

Yes, but it might also be the newest version of cupstestppd (in 2.2.7)
that's more finicky.  I'm switching it to the -r (relaxed) mode which
turns off things that I presume CUPS can handle, which solves a lot of
the problems.

>> Another possibility would be to check that the translation strings fit
>> and to not translate messages that don't.  That has its own problems,
>> but it might be one way to save the day.  But we'd definitely need to
>> keep a list of the problems.
>
> This sounds sane, especially since this can be easily isolated to the 
> cups code and its private stp_i18n_lookup() code.. (I wonder if it will 
> break anything to emit WARNINGs out stderr when we hit these at 
> runtime?)

It's a bit harder than it sounds, because some of the strings are
composite (most of the Fine Adjustment ones are combinations of some
other option and Fine Adjustment).  Anyway, with relaxed mode I just
have about 7 or 8 that are causing a problem, all in the Russian
translation which was very recently updated.

>> There's no point in going there.  They want to get rid of PPD files
>> altogether.  I'm all for *that*, but in the meantime we have to keep
>> things working, and as you say, there's the compatibility issue.
>
> Yeah, my ticket got closed almost immediately.  :)

I think that this point Mike wouldn't fix anything short of a security
hole in the PPD code, and I really can't say I disagree with him on
that.

> (Meanwhile, I'm still chipping away at stuff in the backend in an 
>  attempt to make it amenable to daemonization.  This brave new printer 
>  application has to start somewhere...)

Not to mention the plethora of system control frameworks out there.
systemd may be the most common standard for user-focused Linux
distributions, but it's not completely standard even there (look at
the battle taking place in Debian).  Then we have other UNIX versions
including MacOS, the possibility that some embedded Linux
distributions for use in routers (which might also be print servers)
might not be using systemd at all.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton