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

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

On Thu, 5 Dec 2019 11:33:53 -0500, Solomon Peachy wrote:
> On Wed, Dec 04, 2019 at 08:08:48AM -0500, Robert Krawitz wrote:
>> I saw.  I discussed it with the Russian team, but it's not very
>> apparent why it looks like only the Russian translation has this
>> problem, or why it's happening at all.
>
> So far I've found four strings that trigger errors, because their UTF-8 
> character sequences take up over 80 bytes:
>
>   Japanese Western-style envelope #4 landscape  (50c/88b)
>   Japanese Western-style envelope #6 landscape  (50c/88b)
>   Shrink (print the whole page)                 (47c/88b)
>   Expand (use maximum page area)                (61c/115b)

There are a lot more than that.  I tried writing a .po file scanner.
Aside from the fact that there's a lot of noise (help strings and
such), it's still very easy to miss something in the exception rules.

> IMO the most prudent path forwared is to ask the translators to shrink 
> these down under 80 bytes.

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.

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.

> I don't know if it's worth writing a test to scrub the translations for 
> max length, as these limits only apply to stuff that land in PPD 
> files, and the existing PPD tests catch them (albeit ineffeciently).

"Inefficiently" is putting it rather too mildly.  cupstestppd does
have a number of flags, but some warnings (like page size tags not
matching the standards) can't be turned off in at least the version I
have.  I was thinking of vendoring it in, but it uses all kinds of
private interfaces, and the really big problem is that the routine to
open a PPD file barfs if there are certain errors (including -- you
guessed it -- too long strings) and just reports the first thing.

> I've opened a CUPS bug ticket to ask about the feasiblity of rasing the 
> limit to something larger than 80 bytes, but that won't help with 
> existing CUPS deployments...

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