make reproducible-builds.org translatable?

[Daniel Shahaf]

Hans-Christoph Steiner wrote on Wed, 29 Apr 2020 14:05 +0200:
> Daniel Shahaf:
> > Hans-Christoph Steiner wrote on Wed, 29 Apr 2020 10:44 +0200:  
> >> Mattia Rizzolo:  
> >>> I didn't check, but is the proposed framework able to properly track
> >>> translation updates?    
> >>
> >> Of course, that's an essential part of any localization process.  
> > 
> > What happens between the update of an English original and the time an
> > update translation is pulled and deployed?  Will there be, say,
> > "English last updated on: ${DATE1} / This translation last updated on:  
> > ${DATE2}" information on the translated page?  (I don't see anything  
> > like that on fdroid which you linked to, but that doesn't mean much.)  
> 
> With websites, there isn't clearly defined workflows for this, so you
> have to define it.  po4a and Weblate provide tools to do it.  The
> easiest is to set po4a's --keep to 80%, which will automatically revert
> pages to English if they fall below 80% translated.  Then just take
> translation updates as they come from Weblate.

My concern was to inform users of a translated page that's behind the
English master that the content they're reading is out-of-date, and
give them a way to access the content the translation lacks, albeit in
English.

I don't see how using --keep=80% would address that.  It would seem that
if a page had been 100% translated and had fallen to 95% because of
a recent update to the English content, there would be no indication of
that in the translated page, so readers of the translated page wouldn't
know there are updates they aren't seeing.  What am I missing?

I do see that --keep=80% would exclude translations that are very much
out of date.  However, it would also exclude translations that are
incomplete due to still being booted up, and in any case, I don't see
why we'd want to unlist a translation just because it's incomplete.
Doesn't that amount to letting the perfect be the enemy of the good?
I expect monolingual people would prefer having _some_ content in their
language (even if the content is outdated, or partly in English) to
having to choose between content entirely in a foreign language and
nothing at all.

Of course, we could have an info box at the top of the page warning that
the page might be incomplete and to refer to versions in other
languages.

> > Personally, I'd even consider putting on the translated page a link to
> > a diff view of the changes to the English page between ${DATE2} and  
> > ${DATE1}, for the benefit of any English-speaking readers of the  
> > translation.  Ideally we'd link to a rendered markdown diff (because we
> > can't assume all readers are comfortable with reading markdown in raw
> > form) but gitlab doesn't support that [1], so we'd have to link to the
> > regular or side-by-side diff view or to a mirror of the repository.
> > 
> > [1] https://gitlab.com/gitlab-org/gitlab/-/issues/14603  
> 
> One thing that can easily be added using Liquid scripting is a list of
> all languages that a given document is translated into.  I've seen that
> on the Apache docs, for example.

*nod*

Cheers,

Daniel